Secrets Management for Agents: Stop Handing Them the Keychain

An agent with a long-lived API key in an environment variable is the new equivalent of the developer who kept production credentials in a plaintext config file. The pattern has been wrong for a long time. Agents have made it urgent in a way that human-driven workflows did not.

The reason is not subtle. A human with a plaintext credential at least has the property of being one person, who needs to be in front of one keyboard, to use it. An agent with the same credential is a capability that can be invoked thousands of times, by hundreds of sessions, against arbitrary inputs, often without the original credential holder being aware that an invocation happened.

The blast radius of a leaked agent credential is structurally larger than the blast radius of a leaked human credential, and most secrets management practice has not yet caught up.

The patterns to retire

A few patterns are common in early agent deployments and are worth retiring before the volume of agent traffic makes them painful.

The first is the long-lived API key in an .env file checked into the repo, or worse, into the prompt itself. This is a familiar antipattern in the human case and is identical in the agent case, with the addition that the agent may read its own configuration and expose the key in a log line, a tool call, or a response that ends up persisted somewhere the team did not intend.

The second is the inherited developer credential, where the agent runs with whatever credentials the launching engineer has in their shell environment. This works for a single-developer pilot and breaks the moment the agent is moved to a shared environment, because there is no obvious owner of the credentials and no obvious revocation point when the engineer leaves the team.

The third is the shared service account credential used across all agent roles in a deployment. This has the same defect as a shared service account in any context — the audit trail does not distinguish actors, and revoking the credential for one actor revokes it for all of them — and adds the agent-specific defect that the scope is invariably wider than any individual agent role needs.

What works

The patterns that work in practice are not novel. They are the patterns that human service-account management has been converging toward for the last decade, applied with more discipline because the volume of agent traffic does not give you the option of being sloppy.

Credentials are issued per agent role, with permissions scoped to what that role's prompt file authorizes. The credential lifetime is short — hours, not months — and rotation is automated through a vault or workload identity system. The credential is never written to disk in the agent's environment; it is fetched at session start, held in memory, and discarded when the session ends.

The vault is the audit source. Every credential issuance is logged, with the agent role, the session identifier, the requesting engineer or system, and the time. Every credential use can be correlated back to its issuance through the vault's logs and the consuming system's logs. The chain of custody is intact even when the agent is fast and the volume is high.

Sensitive credentials — production write access, payment systems, customer data — get an additional layer. They are not issued to the agent at all. The agent calls an intermediary service that holds the credential and enforces a narrower API surface than the credential's underlying permissions allow. The agent gets the ability to perform a specific action, not the ability to authenticate as the privileged identity.

The friction point

The friction point in adopting this is not technical. Most vault and workload-identity systems already support short-lived, scoped credentials, and have for years. The friction is that the agent-deployment workflow has to be designed around them from the beginning, and most early agent deployments were not.

Retrofitting is the unhappy path. An agent that was deployed with a long-lived key in an env var has dependencies on that key being available in that form throughout its codebase. Moving to short-lived credentials requires changing how the agent authenticates, where the credential lives at runtime, how the session boundary is defined, and what happens when a credential expires mid-session. Each of these is a small project and they add up.

The happier path is to start the next agent deployment with the credential model already in place. The first agent role through a vault-backed, short-lived, role-scoped flow is the expensive one. The tenth role through the same flow is nearly free, because the platform work has been done.

The framing that helps

The framing that helps is to stop thinking about agent credentials as configuration and start thinking about them as authorization. A credential in an env var is configuration — it is a value that happens to be present, that the agent reads at startup, that lives for the life of the process. A short-lived role-scoped credential issued at session start is authorization — it is a deliberate grant of capability, tied to a specific actor and a specific scope, that exists because something asked for it.

The distinction shows up in how the system is reasoned about. Configuration is something engineers manage. Authorization is something security and platform teams manage together. Agents need the second model, not the first. The earlier the shift, the cheaper the eventual cleanup.