Managing Secrets for AI Agents

Overview

Every useful agent depends on secrets. A token for the ERP to reconcile invoices, a key for the IT service desk to resolve a ticket, credentials for the CRM to enrich a lead. A secret is any sensitive value that unlocks a system: an API key, an OAuth token, a database password, a signing key, a service account credential, a webhook secret.

Why an agent needs a credential that's structurally its own, distinct from a person's, is covered elsewhere in this series; this piece assumes it and asks a narrower question. Once an agent has a credential, what keeps the secret behind it from becoming the easiest way to compromise the agent?

The answer isn't one control. It's a handful of disciplines working together, and skipping any single one of them quietly reopens the door the others closed: scoping, separation, traceability, rotation, revocation, and limits on who can even see the raw value.

Where Secrets Leak

The first discipline is keeping secrets out of the places they tend to drift toward. With agents, those places multiply, because so much of an agent's behavior is expressed as text, and text gets logged, copied, and shared.

• Prompts. A secret pasted into a system prompt or a tool description can surface in transcripts, traces, and model context windows. Anything the model can read, a prompt-injection attempt can try to extract.
• Plain-text configuration. Environment files and YAML configs end up on developer laptops, in container images, and in backup snapshots, none of which are access-controlled the way a vault is.
• Repositories. A committed key lives in history forever, even after it's deleted from the latest version. A hypothetical marketing-analytics agent whose API key landed in a public repo can be abused long before anyone notices.
• Shared documents and chat. Credentials pasted into a wiki page or a team channel to "unblock" someone become permanent, unmonitored copies.

The alternative is straightforward: store secrets in a secure secrets management system and have the agent retrieve them only when needed, ideally through a broker that injects the credential into the outbound call without exposing the raw value to the agent's reasoning loop at all. The agent should know it can reach the payroll system. It should not know the payroll system's password.

logged, copied, indexed, forgotten |-- committed to a repo ------> logged, copied, indexed, forgotten |-- dropped in a config file -> logged, copied, indexed, forgotten |-- pasted into chat/a wiki --> logged, copied, indexed, forgotten |-- stored in a vault --------> broker injects at call time --> agent never sees the raw value -->

Figure 1 — Four ordinary paths a secret drifts down, and the one path that keeps it out of the agent's own context.

Scoping

An agent should never receive a secret that unlocks more than it needs. Broad credentials are convenient to issue and catastrophic to lose. Scoping is the practice of issuing the narrowest credential that still lets the agent do its job.

Take a hypothetical procurement agent that reconciles supplier statements against purchase orders. Its work is read-only across two systems. There's no reason for its credential to permit creating vendors, approving payments, or touching anything outside the procurement domain. A scoped token might look like:

scopes:
  - purchase_orders:read
  - supplier_statements:read
resources:
  - region: eu-west
  - business_unit: procurement
expires_in: 3600s

Scoping operates on several axes at once: which actions the credential permits, which resources it covers, and how long it remains valid. A short-lived, narrowly scoped token that an attacker captures is far less useful than a long-lived admin key. When you can't avoid issuing a powerful secret, treat it as an exception that requires explicit justification and review, not the default.

Separation

Development, staging, and production agents must use different credentials. A test agent should never hold a production secret. This sounds obvious, yet it's one of the most common failures, because the easiest way to make a flaky integration work in staging is to point it at the credential that already works in production.

Picture a hypothetical data-analytics agent under development. An engineer is iterating on its prompts and tool calls, and the agent occasionally misfires, running an unintended bulk export or a heavy query. If that development agent holds the production warehouse credential, a debugging session can corrupt or exfiltrate live customer data. With separated credentials, the worst case is a mess in a sandbox.

Separation also makes traceability honest. When environments share a secret, you can't tell from the credential alone whether an action came from a tested production agent or an experimental one. Distinct credentials per environment, and where it matters, per agent, keep the boundaries legible.

Traceability

When something goes wrong, the question is always the same: which agent used which secret, when, and to do what. If a secret is shared across many agents, or if access is anonymous, that question has no answer, and an investigation stalls before it starts.

Traceability requires that every secret retrieval and every credentialed action be attributable to a specific agent identity. Each call should record:

• The agent identity that requested or used the secret.
• The time of retrieval and use.
• The action the credential enabled, and against which system.
• The originating user or workflow, when the agent is acting on someone's behalf.

With that record in place, a legal team investigating an unexpected contract export can trace it to a single agent, a single token, and a single moment, rather than to a shared service account that a dozen systems quietly reuse.

Rotation

Secrets shouldn't live forever. Rotation, replacing a credential with a new one on a schedule, limits how long an exposed secret stays useful and forces teams to keep credential hygiene healthy rather than letting keys accumulate quietly for years.

The challenge with agents is that rotation must be invisible to running work. If a sales-operations agent is mid-workflow when its CRM token rotates, the rotation shouldn't break it. This is why short-lived, automatically reissued credentials are preferable to long-lived static keys: the agent requests a fresh token each time it needs one, and rotation becomes a property of the system rather than a manual chore someone forgets.

Revocation

Rotation is routine. Revocation is the emergency lever. When an agent is retired, compromised, or no longer needs a credential, that credential has to come out, immediately and completely.

Revocation is where governance most often fails, because retiring an agent rarely feels urgent. A hypothetical recruiting agent gets replaced by a newer version; the old one is switched off, but its service account credential is never revoked. Months later, that dormant credential is still valid: an invisible access path into the HR system that no one is monitoring and no one owns.

"Complete" is doing real work in that sentence, and it's worth being precise about it. Killing a credential in your own system stops your systems from presenting it. It doesn't automatically invalidate the underlying token at whatever provider originally issued it, unless you also call that provider's revoke endpoint and it actually honors the call. We think teams should treat those as two separate steps and verify both, rather than assume the first covers the second. That assumption is exactly where a "revoked" credential turns out to still work.

Effective revocation has two properties beyond that. It has to be fast, a single action that cuts off access rather than a multi-team ticket. And it has to be complete: every credential an agent held is accounted for and removed, which only works if you knew which credentials the agent held in the first place. Revocation is the payoff for the scoping, separation, and traceability disciplines that came before it.

Human Access Control

Not every person who manages an agent should be able to see its raw secrets. The ability to grant, approve, or revoke access is a different privilege from the ability to read the credential itself, and conflating the two needlessly widens the circle of people who could leak a key.

A platform owner may need to authorize that a finance agent can reach the ledger, and a security reviewer may need to confirm the scope is appropriate. Neither of them needs to view the underlying token. A well-designed secrets layer lets people operate on access as a decision while the raw value stays sealed inside the vault.

• Grant without exposure. Owners attach credentials to agents by reference, not by handling the secret.
• Approve without exposure. Reviewers see scope, owner, and justification, not the key.
• Audit without exposure. Compliance can confirm controls are in place without ever reading a secret value.

The fewer humans who ever touch the raw secret, the fewer ways it can escape. For most agent credentials, we think the right number of people who can read the value is zero.

In Practice

These disciplines aren't independent checkboxes. They reinforce each other. A useful way to see how they fit together is to follow a single credential through its life. Suppose a hypothetical IT operations agent needs to read alerts from a monitoring system and acknowledge incidents.

• Scoped at issue. The agent gets a token limited to alerts:read and incidents:acknowledge, nothing that can delete data or change configuration.
• Separated by environment. The staging copy of the agent uses a staging token, so testing never touches the live incident queue.
• Stored in a vault, fetched at use. The secret never appears in the agent's prompt or repo; a broker injects it into outbound calls.
• Traced on every use. Each acknowledgment is logged against the agent's identity, so an unexpected action can be explained.
• Rotated automatically and revoked on retirement. The token refreshes daily, and when the agent is decommissioned, its access is cut in a single step, checked at both ends.

None of these steps is exotic. What makes them work is that they're defaults of the platform rather than habits an individual engineer has to remember for every agent. When secret handling is built into how agents are provisioned, doing the right thing is the path of least resistance.

Conclusion

Secrets are the difference between an agent that can read a dashboard and one that can move money. They deserve to be treated as a control surface, not as configuration. Keep them out of prompts, configs, and repos. Scope them narrowly. Separate them by environment. Trace every use. Rotate them on a schedule. Revoke them the moment they're no longer needed, and check that the revocation actually reached the provider. And keep the raw values out of human hands wherever you can.