COMPARE · 2026-06-11Evidence-backed

Market comparison for agent-secret infrastructure. Trust boundaries, strengths, and gaps.

Tier 01 · executive read

System Where it is genuinely strong Where it is weak
HASP Source-available with FCL-1.0-ALv2

Keeps local project secrets in an encrypted vault and releases them through scoped broker runs.

Treats the repo as part of the risk: bindings, leak checks, redaction, and audited grants live in the same flow.

Fails closed by default. Backup passphrases scrub on lock, MCP regressions block releases, and managed values stay out of agent output.

No hosted team dashboard or central identity layer in V1.

No HTTP/WebSocket gateway, provider catalog, or AI spend controls yet.

No declarative policy engine for distributing approvals across many users or services.
Kontext CLI MIT

Smoother first-run onboarding for centrally managed teams

Stronger hosted identity and org attribution story

Claude stays the first-class agent. The deterministic policy engine now runs on-host, but identity and dashboards still live in the backend

Resolved secrets enter the agent process environment, and repo leak blocking is not the main product
OneCLI Apache-2.0

Faster self-serve onboarding with a full dashboard and bundled local stack

WebSocket proxy support and a generic body transform pattern extend coverage to streaming agent-tool flows

The model centers on HTTP and WebSocket gateway traffic, so local command and file-secret workflows stay outside the happy path

It needs a web/database control plane. That is useful for teams, heavier for a solo local repo
fnox MIT

A github-oauth device-flow lease backend mints short-lived user-attributed tokens with no app private key, on top of an already broad provider catalog

The `fnox-core` crate split makes fnox usable as a library for other tools without dragging the CLI/TUI/MCP surface

The default developer path materializes secrets into env vars or shell state, even after POSIX-safe shell hardening

The MCP surface can return raw secret values, and the repo scanner is still a placeholder
Infisical Agent Vault MIT Expat for non-ee code; enterprise features reserved for ee/ Infisical license

MITM-only ingress with WebSocket transparency tightens the network coverage story

The `run` agent mode gives Agent Vault a real path for unattended and containerized deploys

v0.15 flipped the default to passthrough for unmatched hosts. Adoption is smoother, fail-closed posture is weaker

It is strongest for HTTP/WebSocket. Repo leak prevention and non-HTTP command/file delivery are weaker
Tailscale Aperture Proprietary managed service

Much stronger hosted identity, attribution, and centralized AI usage reporting

Full request/response capture, tool-use logging, and SIEM/S3 export

It is a managed beta tied to Tailscale identity and network assumptions

It does not give you a local vault, offline workflow, or repo leak guardrails
Agent Cookie MIT

Much stronger browser and CLI session continuity for a second Mac or headless agent machine

MIT license and public Go implementation

It makes existing sessions available on an agent Mac, so compatibility can mean cookies, sidecars, env files, or adapter blobs

It does not give you a local vault, repo leak guardrails, or explicit per-use grants
Docker Secrets Engine Apache-2.0

Cleaner value-free pointer UX through `se://` references in Docker, Compose, and env-wrapper workflows

Broader provider and plugin architecture with public Go SDKs

The resolver path returns plaintext bytes to clients, and `docker pass run` materializes values into child-process env

`se://` references improve Docker and Compose config hygiene, but they are not per-use grants or repo leak guardrails

Tier 02 · capability matrix

Capability HASP Kontext CLI OneCLI fnox Infisical Agent Vault Tailscale Aperture Agent Cookie Docker Secrets Engine
Local encrypted vault as primary secret store Yes No No Partial Yes No No Partial
Hosted identity and org attribution No Yes Optional Provider-specific only Local users/session roles; Infisical ecosystem path exists but Agent Vault is local-first today Yes No No
Short-lived credential exchange from managed providers No Yes Partial Yes Scoped vault sessions for proxy access No No Partial
Brokered execution that keeps secret values out of agent-visible output Yes No Partial Partial Yes, for HTTP(S) traffic via proxy Partial No No
Direct env injection into agent process Convenience-only Yes No Yes Proxy and CA env injection, not raw provider secrets No Yes Yes
Explicit once/session/window grants Yes No Policy approvals only No Vault roles plus proposal approval Identity grants and quotas Partial No
Repo leak scan and block-by-default hook/deploy path Yes No No No No No No No
Audited override for blocked repo leaks Yes No No No No repo-guardrail override model No No No
Agent-assisted secret capture into managed storage Yes No No No Yes, via proposal/request workflow and vault credential management No No No
Local encrypted backup and restore Yes No No Config/provider-based Not surfaced as a primary CLI feature in reviewed docs No No Partial
Hosted dashboard / centralized session telemetry No Yes Yes No Local web dashboard; Infisical commercial path exists Yes No No
Meaningful local/offline use without remote control plane Strong Weak Moderate Strong when local/encrypted providers are configured Strong local/self-host path Weak Partial Strong

Tier 03 · operating model

01

Trust boundary

Who has to be trusted during a run?

HASP

Your machine. The local daemon owns vault access, grants, redaction, and audit.

Other paths

Aperture is a managed gateway. Kontext keeps identity and dashboards hosted even after moving policy on-host.

OneCLI and Agent Vault route work through gateway or proxy stacks.

Buyer check

Choose hosted control when the buyer needs one dashboard. Choose HASP when the repo-local path matters more.

02

Secret visibility

Can the agent read the secret value?

HASP

Brokered runs resolve values at execution time and keep them out of agent-visible output.

Other paths

fnox and Kontext favor env injection.

Agent Vault and Aperture hide provider keys behind HTTP forwarding.

Buyer check

Env injection is easy to adopt. It also gives more processes a place to inspect the value.

03

Approval

Who decides when access is allowed?

HASP

The operator grants once, for a session, or for a time window. Plaintext access stays separate.

Other paths

OneCLI and Aperture use gateway policy.

Kontext now ships a deterministic policy engine with an authorization ledger; Agent Vault uses proposals, service catalogs, and vault roles.

Buyer check

Policy distribution works well across many users. HASP covers the case where one operator needs to approve one named secret.

04

Repo safety

What happens if a secret lands in the workspace?

HASP

HASP scans, blocks managed-value leaks, redacts output, and records overrides.

Other paths

Most gateway products do not inspect the repo.

fnox supports encrypted config, but the scan command is still a placeholder.

Buyer check

This is the clearest HASP lane. The risk starts before an API call leaves the machine.

05

Audit

What evidence can the operator inspect later?

HASP

Local audit covers grants, guardrails, capture, expose/hide, backup, and runtime events.

Other paths

Aperture and OneCLI give stronger central reporting.

Agent Vault logs HTTP request metadata for proxied traffic.

Buyer check

Central reporting helps security teams. Local audit helps a developer prove what happened in one repo.

06

Setup weight

How much machinery comes with the model?

HASP

One binary, one vault file, and repo binding.

Other paths

Gateway tools often need a web service, database, proxy settings, or CA trust.

Provider managers need account setup across each backend.

Buyer check

More machinery can be worth it for teams. It is friction for a local agent workflow.

One signed binary. One encrypted file. That is the whole product surface.

Source-available. SBOM, SLSA provenance, code-signing status, and reproducible-build sidecar ship inside the release artifact. scripts/hasp-verify-release.sh verifies the signed checksum manifest plus the tarball and binary signatures before install.

Homebrew 
$ brew tap gethasp/tap
$ brew install gethasp/tap/hasp
$ hasp setup
$ hasp app connect myapp
$ hasp proof

→ ok proof passed · 412ms
→ ok vault unlocked · binding ./api
→ ok agent never read