What is a secret brokerA definition without the marketing.

The term "secret broker" started appearing in vendor docs around 2024 and became unavoidable after Knostic's February 2026 disclosure showed that coding agents were silently capturing environment variables and writing them to project-local state files. Suddenly everyone selling a secrets product rebranded their offering as a "broker." The word now covers HashiCorp Vault, 1Password CLI integrations, Doppler, sidecar proxies, and at least a dozen AI-agent-specific tools, most of which do fundamentally different things.

This is a definition. Not a product recommendation. A broker has a specific meaning, and some of the things called brokers don't qualify.

A vault stores secrets. A password manager stores secrets for humans. A broker does neither. It sits between the store and a process that needs a credential, enforces which process gets what, delivers the value at exec time, and records the grant. If the thing you are using does not do all four, it is something else.

What to know in 60 seconds

• A broker is not a vault. It reads from a vault (or a secrets manager, or an encrypted local store) and decides what to give to which process.
• Delivery happens at exec time, not at process startup from an ambient environment variable.
• Scoping is the point. A broker should be able to give process A one key and process B a different key, without either process seeing the other's grant.
• Audit is not a log file. A proper audit trail records who asked, what was granted, and when the grant expired, in a tamper-evident format.
• Withdrawal matters. If the process exits, the grant should expire. A secret that outlives its process is ambient state again.

What a broker actually is

Imagine your application needs a database password. Without a broker, the password lives in an environment variable, a .env file, or a secrets manager your app queries at startup. In all three cases, the password is readable to anything that can inspect the process's environment or intercept its startup query.

A broker changes the trust surface. Your application code never sees the password directly. It sees a reference, a placeholder, or a short-lived token. The broker holds the real value, decides at exec time whether this process should receive it, injects it in the delivery mode the process expects (environment variable, temp file, etc.), and revokes access when the process terminates.

The three properties that make something a broker rather than just a secrets manager with a CLI:

1. It delivers to a specific process, not to an environment.
2. It scopes: it can refuse to inject a production credential into a dev process.
3. It audits at the boundary, not just at the vault.

The "at the boundary" part is why brokers matter for AI coding agents. Agents inherit your shell environment. Knostic's February 2026 finding was that the secrets living in that environment were being captured by the agent's state files. A broker breaks that inheritance path. The agent's process doesn't carry the real value; the broker injected it into a child process that needed it, not into the agent's ambient context.

Three broker architectures

The term covers at least three distinct implementation patterns. They differ in where the broker intercepts, what they protect, and what they leave exposed.

Forward-proxy MITM

The broker runs as an HTTP/HTTPS proxy in front of your application. Outbound requests from your app contain placeholder values. The broker intercepts at the TLS layer, looks up the real credential, and rewrites the request before it leaves the machine.

Tools using this pattern include Agent Vault and various "secretless" architectures built on mTLS sidecar proxies. The appeal is real: your application code has no knowledge of credentials. You can ship a binary that contains no secrets, ever. The placeholder is inert if extracted.

The cost is the TLS interception. The proxy needs to terminate TLS, inspect the request, and re-encrypt it. That requires certificate authority configuration, trust store modification, and either a local CA your app trusts or a CA-pinning workaround. Applications that pin certificates, use mutual TLS, or verify leaf certificates fail unless you handle the exceptions. The approach also only protects network calls. A secret that your application reads from disk or uses to sign a local artifact is not in scope for the proxy.

The blast radius if the broker is compromised is wide: every application routed through it is exposed simultaneously.

Sidecar exec-wrapper

The broker is a CLI that invokes your target process with environment variables injected at exec time. 1Password's op run, Doppler's doppler run, and similar tools follow this model. The broker fetches the secret from the backing store, sets it in the child process's environment, and exec's the child. Your app code reads the environment variable and has no idea a broker was involved.

This is simpler to deploy than a proxy. No CA configuration. No TLS interception. Works for any process that reads from the environment, which covers most server software, most CLI tools, and most coding agents.

The limitation is scoping. By default, the child inherits the full set of injected variables. If you run doppler run -- my-agent, the agent gets every secret in the Doppler config, not just the ones it needs. Narrowing requires explicit configuration: separate configs per agent, per environment, per invocation. Most teams don't do this. They create a config with everything in it, run the agent with the full set, and end up with a smaller blast radius than ambient env vars but still a wide one.

The other limitation is process lifetime. The child process keeps the environment variable alive for its entire lifetime. Anything that process spawns, anything it writes to disk, anything it logs, can capture and persist the value.

Process-tree-scoped

The broker launches a specific child and ties the credential grant to that child's process tree. If the child exits, the grant expires. If the child spawns a subprocess, you can configure whether the grant extends to it or not. Each grant is individually audited: a log entry records which process received which credential, when, and for how long. hasp run uses this pattern.

This is narrower in scope than the exec-wrapper pattern. The broker does not give the agent a key; it gives one specific invocation of one specific command a key, for the duration of that command, and no longer. The agent's parent process does not carry the value. Neither does any sibling process.

The audit log under this pattern is more useful than a coarse log entry saying "secret accessed." You can answer "did the agent touch the production database credential between 2 and 4pm?" in seconds, because each grant to each process is a discrete record.

The constraint is adoption: every process that needs a secret must be launched through the broker. You cannot retrofit it onto a running process. It is the strictest model and requires the most upfront configuration, but it is also the only pattern where blast radius is genuinely bounded by construction.

What a broker doesn't do

A broker does not make your code safe to leak. If your application logs the environment variable it received, the broker didn't help. The value is in your log aggregator now. Brokers operate at injection; they do not chase the value through your code path.

A broker does not replace a secrets store. It reads from one. You still need Vault, AWS Secrets Manager, Doppler, a local encrypted vault, or something similar. The broker is the delivery and audit layer. The storage layer is separate.

A broker does not fix prompt injection. If an AI agent is susceptible to an adversarial instruction that exfiltrates a value it legitimately received, the broker's scoping did not prevent that. The value was delivered correctly. The agent misused it. Prompt injection is a model-level problem. A broker operates at the OS boundary, below the model.

The Knostic February 2026 disclosure was about state file capture: the agent wrote environment variables to a project-local file, which shipped in npm packages. A broker prevents that by keeping the value out of the agent's ambient environment. It does not prevent a malicious instruction from telling the agent to write whatever it received to a file.

The part most vendors skip

Most broker marketing focuses on delivery: "secrets never touch disk," "zero-trust access," "ephemeral credentials." The audit trail gets a bullet point. In practice, the audit trail is what makes a broker operationally useful.

Security teams do not prevent every incident. They investigate them. An audit log that records grants at the individual-process level answers questions that a coarse Vault access log cannot: which agent session requested the credential, which child process received it, how long the grant lasted, whether withdrawal happened cleanly. That record is the difference between a five-minute postmortem and a two-day investigation.

The HMAC-chaining used in some audit designs (where each log entry is signed over the previous one) makes the log tamper-evident. Deleting an entry breaks the chain. That matters in regulated environments where you cannot rely on log infrastructure being trustworthy.

The secret broker pattern became more than a niche idea in February 2026 because AI coding agents moved from "runs occasionally on a developer laptop" to "runs continuously in CI with access to production credentials." Knostic's disclosure was a public data point. The private incidents around the same period, where agents with ambient credentials made consequential writes, are a larger set.

Questions worth asking before you pick an architecture

Before choosing a broker pattern, answer these:

• How many processes need secrets? The more processes, the harder exec-wrapper scoping becomes.
• Do your applications pin TLS certificates? If yes, forward-proxy MITM needs a workaround plan.
• Do you run AI coding agents with access to production credentials? If yes, exec-wrapper without explicit scoping is a blast-radius problem.
• Can you require that all secret-consuming processes go through the broker? If no, process-tree-scoped enforcement is incomplete.
• Do you need to answer "which session touched which credential?" in an audit? If yes, coarse Vault logs are not sufficient.

No single architecture wins every question. A team running one service on a known runtime does fine with an exec-wrapper. A team running multiple AI agents in parallel, each with different access levels, benefits from process-tree scoping. A legacy application that cannot be redeployed and reads secrets from its environment is the best candidate for a forward proxy, accepting the TLS complexity.

Checklist for evaluating a secret broker

## Secret broker evaluation

- [ ] Delivery: does it inject at exec time, not at process startup from env?
- [ ] Scoping: can it give different processes different subsets of secrets?
- [ ] Audit: does each grant produce an individual log entry?
- [ ] Withdrawal: does the grant expire when the process exits?
- [ ] TLS impact: if forward-proxy, documented CA setup and certificate-pinning exceptions
- [ ] Blast radius: what is the worst case if the broker process is compromised?
- [ ] AI agent support: are there agent-specific profiles with narrowed scopes?
- [ ] Tamper evidence: is the audit log structured to detect deletions?
- [ ] Recovery: if the broker is unavailable, does the process fail closed or open?
- [ ] Log verbosity: can you answer "which session touched which credential at what time?"

What this means for your stack

The practical question is not which broker vendor to pick. It is whether your current setup has a broker at all. If your AI coding agent inherits secrets from your shell environment, the answer is no. The agent reads your full environment, possibly writes some of it to a state file, and any process it spawns inherits the same set. That model produced February 2026's disclosure. It will produce the next one.

The category fix: put a broker between your secrets store and the agent process. Scope the grant to what the agent legitimately needs. Log each grant. Withdraw it when the session ends.

hasp is one working implementation of the process-tree-scoped pattern. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the next agent session receives a reference instead of a live credential. Each grant is individually logged in an HMAC-chained audit file. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The property to aim for, whatever you use: no secret lives in a process's environment longer than that process's lifetime, and every grant produces a log entry you can query later.