COMPARE · 2026-04-29Evidence-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.

No hosted team dashboard or central identity layer in V1.

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

Kontext CLI MIT

Better first-run onboarding for centrally managed teams

Stronger hosted identity and org attribution story

The reviewed repo ships Claude support first; Cursor and Codex were still planned

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

Stronger HTTP-native policy controls, including manual approval and rate limiting

The model centers on HTTP 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

Much broader provider catalog and provider-switching ergonomics

Smoother ordinary developer workflow through shell auto-load and direct exec

The default developer path materializes secrets into env vars or shell state

The MCP surface can return raw secret values, and the reviewed repo scanner was still a placeholder

Infisical Agent Vault MIT Expat for non-ee code; enterprise features reserved for ee/ Infisical license

Broader interface-agnostic coverage for HTTP(S) traffic: API, CLI, SDK, and MCP paths converge at the proxy

First-class container sandbox mode can make egress non-cooperative by forcing TCP traffic through the proxy

The product is still research preview, and the proxy/CA/container setup asks more from the operator

It is strongest for HTTP(S). 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

Tier 02 · capability matrix

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

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

Kontext and Aperture put more authority in hosted services.

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.

Agent Vault uses proposals, service catalogs, and vault roles.

Buyer check

Gateway policy works well for network traffic. HASP fits the moment when a local command needs 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 reviewed scanner was not implemented.

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/homebrew-tap
$ brew install hasp
$ hasp setup
$ hasp app connect myapp
$ hasp proof

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