Getting AI agent credential security right in production

Most agent setups share one bag of secrets. Every agent, every run, reads from the same .env file or the same pool of API keys, and any one of them can print, log, or ship the lot to somewhere you didn't intend.

That works fine on your laptop with one agent and one key. It stops working the moment you have a fleet. A run that only needed to read a calendar can read your Stripe key. A subagent inherits its parent's entire environment. And when something does leak, you can't answer the first question an incident review asks: which run saw which secret, and when.

AI agent credential security is the discipline of closing that gap. The goal is simple to state and harder to build: an agent should hold only the secrets a given run actually needs, for only as long as it needs them, and you should be able to prove afterward which run touched what.

One credential pool is the whole blast radius

The default failure mode is a single shared credential pool. You export every key an agent might ever need into one environment and let the whole fleet draw from it.

The problem isn't that this is insecure in the abstract. It's that the blast radius is everything at once. Compromise one agent, or one prompt-injected tool call, and the exposure is the union of every credential any agent in the fleet has ever been given. There's no per-run boundary, so there's nothing to contain.

Operators feel this in three separate places: onboarding a new agent means widening the shared pool, rotating one key means coordinating across every run that might use it, and a leak investigation has no per-run trail to follow. Each of those gets worse as the fleet grows.

What vault-backed run access actually means

Vault-backed run access replaces the shared pool with two properties.

First, secrets live in a vault, not in the agent's process environment. The agent is handed a reference, not the raw value, and the value is resolved from the vault at the moment it's needed.

Second, resolution is scoped to the run. A given run gets the secrets that run is entitled to and nothing else, and the resolution is recorded so you can attribute access after the fact.

Two open tools shipped concrete versions of this pattern in the last few months, and they take opposite routes to it. One resolves secrets into the agent from a vault. The other makes sure the agent never holds the secret at all.

Pull secrets from a vault at load time

The first route keeps your existing password manager as the source of truth.

Hermes shipped this in v0.19.0, the "Quicksilver" release, in July 2026. It added a pluggable SecretSource interface that fetches secrets from Bitwarden and 1Password at load time, using op://-style references instead of literal values. You can enable multiple vaults at once with deterministic precedence, it warns you on conflicts when two vaults define the same variable, and it tracks per-variable provenance so you know which vault each secret came from.

The provenance piece is the part that matters for an audit. When a run reads a credential, you can trace it back to a specific vault entry rather than a nameless line in an environment file. For teams already living in Bitwarden or 1Password, this is the shorter path: the vault you already run becomes the vault your agents read from, and nothing sensitive lands in a checked-in config.

Never hand the agent the real secret

The second route is more aggressive. Instead of resolving a real key into the agent, it makes sure the agent only ever holds a fake one.

OneCLI, an Apache-2.0 credential gateway, sits between your agents and the services they call. You store the real credentials once in its vault, encrypted with AES-256-GCM and decrypted only at request time. Agents get placeholder tokens that are safe to share, rotate, or revoke. When an agent makes an outbound call through the gateway, OneCLI matches the request, swaps the placeholder for the real key, and forwards it. The agent never touches the real secret.

Access is scoped per agent: each one authenticates with its own token and gets its own set of allowed hosts and paths. Revocation stops being a rotation exercise across every run and becomes a single policy change at the gateway.

The tradeoff is that you're now routing traffic through a proxy, which is one more component to run and reason about. In exchange you get a genuine separation of duties. The thing that can be prompt-injected and the thing that holds the keys are no longer the same process.

The runtime still has to scope the access

Vaults and gateways solve storage and injection. They don't, on their own, decide which run is entitled to which secret, or keep the record of who accessed what. That's the job of the layer the agents run on.

This is the credential-confinement layer of the governance stack: the orchestration runtime scopes credential access to a task and attributes it to a run, so the vault tooling has a boundary to enforce against. I run my agents on Paperclip, which shipped run-bound secret access in 2026.722.0. That is the piece that makes per-run credential confinement real rather than aspirational.

Storage, injection, and scoping are three different jobs. A vault without a runtime boundary still leaks across runs. A runtime boundary without a vault still has the secret sitting in plaintext somewhere. You want both.

Where to start this week

You don't need to rebuild everything to get most of the benefit.

Stop exporting one shared environment across the fleet. Pick the model that fits how you already work: if you live in a password manager, wire your agents to read from it at load time; if you'd rather the agent never held a real key, put a gateway in front of it. Either way, scope credentials to the run and keep the provenance so a future incident review has a trail to follow.

The operators getting breached in 2027 won't be the ones who picked the wrong vault. They'll be the ones who never moved off the shared pool.

I'm building Paperclip Blueprints around this kind of production governance, and writing about the stack as I build it. Follow along if you're standing agents up on infrastructure you control.

— Kimmo