← All guides · Agent security operations

How to Manage Secrets for AI Agents in Production

Part 1 of Agent security operations · 1,503 words · ~7 min read · published 2026-09-01 · updated 2026-09-01 · Markdown variant

Why single-agent credential issuance is not the whole secrets problem: auditing which tool servers and MCP connectors hold credentials on an agent's behalf, treating provider-side prompt caches as a disclosure surface, and the named frameworks — OWASP's Secrets Management Cheat Sheet, Twelve-Factor config, and the OWASP GenAI project — that govern the rest.

Part of the How to Secure AI Agents in Production guide.

Why single-instance credential hygiene isn't the whole secrets problem

Giving each agent instance its own short-lived key closes the classic leak paths for the agent itself, but that discipline assumes the agent is the only thing holding a credential — an assumption that stops being true the moment a tool server, MCP connector, or plugin sits between the agent and the resource it is actually calling. The agent security operations pillar already works through that single-hop ground in depth: per-instance issuance, OAuth-style delegation preferred over static keys, secret-manager storage instead of hardcoding, and the rule that any secret reaching model context counts as disclosed. None of that gets re-derived here.

What this article covers instead is the hop the pillar's framing does not reach: what happens once a second system — not the agent, not the final API it is ultimately calling — takes custody of a credential somewhere in between. As of September 2026, that middle hop is routine rather than exotic: an agent rarely calls a payment processor, a CRM, or a cloud provider directly. It calls a tool server, an MCP connector, or a plugin, and that intermediary is frequently the thing actually authenticated to the downstream system.

Who holds the credential when a tool server sits in the middle?

Often the tool server holds it, not the agent. A typical chain runs agent to tool server or MCP connector or plugin to downstream API, and a credential can live at any one of those two joins rather than only at the first one the pillar's single-hop framing assumes. Many MCP servers and third-party tool integrations authenticate to the downstream API once — on the operator's behalf, or on the connector vendor's own behalf — and then expose the agent a scoped capability or tool call rather than the raw key, so the agent genuinely never sees the credential that reaches the API at all.

The agentic security checklist (updated 15 August 2026) names this pattern directly, in its own dedicated secrets-and-credential-management section: "Audit which tool servers hold credentials on your behalf — long-lived third-party tokens stored server-side are high blast-radius targets." That single line is doing more work than it looks like. It is not describing the agent's own key at all; it is describing a second, separate credential that a piece of infrastructure the agent depends on is holding, often with a longer lifetime and broader scope than anything issued directly to the agent, precisely because nobody designed it with per-agent revocation in mind.

That distinction matters operationally. A leaked agent credential is bounded by whatever per-instance scoping and short expiry you designed in. A leaked tool-server credential can be scoped to every agent, every tenant, and every task that connector has ever served — and if the connector is third-party infrastructure you don't operate, you may not even know its credential's scope or lifetime until you go looking.

How do you audit third-party credential custody before you trust it?

Auditing third-party credential custody starts with an inventory, not a policy document: list every tool server, MCP connector, and plugin the agent calls, and for each one determine whether it forwards a credential the agent (or your own infrastructure) supplies per call, or whether it holds one of its own server-side.

• Classify each dependency. For every tool server or connector, mark it either "pass-through" (forwards a credential your own system controls) or "custodial" (holds and manages its own credential to the downstream API). Custodial dependencies are the ones the checklist's audit line is about.
• Assume long-lived unless proven otherwise. Treat any custodial connector's stored token as long-lived and high blast-radius by default until you've confirmed its actual lifetime and scope — the checklist's own framing is that these are high-blast-radius targets specifically because operators tend not to check.
• Test revocation, not just existence. Confirm you can actually cut off a specific custodial connector's access without disabling every other agent or tenant it serves. A shared, multi-tenant connector may not support per-caller revocation at all, which is worth discovering during an audit rather than during an incident.
• Re-run the inventory on every new integration. Each new MCP server, tool integration, or plugin you add is a new potential custody point, not a neutral addition — the chain gets longer, not shorter, with each one.

This audit is distinct from, and sits alongside, the wire-level mechanics of how an agent authenticates directly to an MCP server in the first place — the OAuth 2.1 authorization-code and client-credential flows, PKCE, and resource-indicator validation that let an agent hold its own scoped token to a server rather than relying on that server's own custodial credential. Those protocol specifics belong to implementing OAuth 2.1 for an MCP server; the point here is narrower and comes before that protocol question: know which of your dependencies are custodial in the first place, before you decide whether direct per-agent OAuth is worth building to eliminate one.

Are provider-side prompt caches a secrets-exposure surface?

Yes — a provider-side prompt or prompt-caching store shares the same sensitivity class as the secret it might contain, a fact the secrets management for AI agents reference (updated 23 August 2026) states as one of its practical defenses, and one the pillar's own credentials section never uses. This is a genuinely separate lifecycle point from redacting secrets out of a visible transcript or a log line: a prompt-caching system retains whatever populated a cached prefix, independent of whether a human operator ever sees that content rendered in a session view afterward.

The practical consequence is that a secret accidentally placed into a stable, cached portion of a prompt — a system prompt, a tool schema, standing instructions — does not stop being exposed once you've confirmed it doesn't show up in a transcript export. It persists wherever the caching layer persists it, for as long as that layer's own retention policy allows, and that retention policy is set by the model provider, not by your own logging discipline. Treat a provider's prompt cache and its prompt store as extensions of your own secrets surface when you're reasoning about where a leaked credential could still be sitting, not as a separate, lower-stakes layer outside that reasoning.

What frameworks should govern how an agent handles its secrets?

Three named, dated frameworks — none of them written specifically for AI agents — set the baseline underneath agent-specific practice, and citing them by name is useful precisely because none of them will move as fast as agent tooling does. The OWASP Secrets Management Cheat Sheet is the general-purpose baseline the secrets-management reference points to directly: keep every secret in a dedicated secrets store and inject it at deploy or call time rather than embedding it anywhere in source, a rule that does not change depending on whether the caller is a human-facing service or an autonomous agent.

The Twelve-Factor App principle that configuration lives in the environment remains the right default for an agent's own deployment, but the secrets-management reference adds an agent-specific twist worth stating precisely: an agent's effective environment includes whatever the model itself can see, not just OS-level environment variables — which is why the prompt-cache point above and the pillar's "never enters model context" rule both exist as additions on top of a twelve-factor baseline, not replacements for it. Finally, the OWASP GenAI security project tracks credential and secret exposure through model context under its sensitive-information-disclosure risk class for LLM applications — a distinct entry from prompt injection or excessive agency, and the framework reference to reach for when you need to name this specific failure class in a security review rather than describe it from scratch.

A credential-custody checklist for a multi-hop agent stack

Beyond the pillar's own per-instance issuance and rotation checklist, a multi-hop deployment needs these additional checks before it earns production trust:

• Every tool server, MCP connector, and plugin the agent depends on is inventoried and classified as pass-through or custodial with respect to downstream credentials
• Every custodial dependency's token lifetime, scope, and revocation path has been confirmed directly, not assumed from the vendor's marketing copy
• Per-caller revocation on any shared or multi-tenant connector has been tested, not just documented
• Provider-side prompt caches and prompt stores are included in the inventory of places a leaked secret could still be sitting, not treated as out of scope because they don't appear in a rendered transcript
• The inventory is re-run every time a new tool server, connector, or plugin is added, since each one extends the custody chain by one more hop

None of this replaces the agent's own credential hygiene — it sits on top of it, covering the hops that per-instance issuance was never designed to reach. A deployment that has done the pillar's single-hop work thoroughly and skipped this multi-hop audit has still left its highest-blast-radius credentials — the ones a tool server or connector holds on its behalf — completely unaudited.

#agents #security #secrets #credentials #mcp #owasp