The New Password in a Config File

You spent the last decade helping customers burn static credentials out of production infrastructure. Vault-based secrets management, dynamic credential issuance, automated rotation. The whole industry moved because everyone agreed that a password sitting in a config file was an unacceptable risk posture.

That pattern is back. It's in every major agent framework shipping today, and it's worse than the original because of how agents consume credentials.

The mechanical reality

A traditional application authenticates to one or two backend services. A database, an API. You know the credential surface at design time because you designed it.

An agent calls tools. That's what makes it an agent. A single task like "pull last quarter's revenue data and draft a summary for the CFO" might require credentials for a search API, a database, a document store, and a messaging platform. Four credentials, four services, one task. The next task might need an entirely different set.

The number of credentials an agent needs gets determined at runtime by whatever the model decides to do. Your credential surface is now a function of model reasoning. Dynamic, and in a meaningful sense, unpredictable.

What the frameworks actually ship

The MCP authorization spec (still in draft as of this writing) is worth reading directly. For HTTP-based MCP servers, it requires OAuth 2.1 with PKCE. But for STDIO transport, which covers the majority of currently deployed MCP servers, the spec says explicitly:

That's the documented recommendation. Full stop.

The pattern repeats upstream. Google's own LangGraph agent docs demonstrate api_key = os.getenv("GEMINI_API_KEY"). CrewAI requires OPENAI_API_KEY as an environment variable at startup. The OpenAI Python SDK expects an API key at initialization and provides no mechanism for dynamic credential refresh during a session.

Developers know this is bad. They do it anyway because implementing OAuth flows for multiple providers, each with different auth mechanisms, adds complexity that doesn't ship features. The path of least resistance is export API_KEY=sk-... and move on. So they move on.

Why this is worse than the original problem

A conventional application with a leaked credential is bad. An agent with a leaked credential is bad in a way that has no clean precedent, because of prompt injection. CISOs will use that term, and the mechanism is straightforward: an attacker crafts input that instructs the agent to "help debug authentication issues" by printing environment variables. The agent complies. Hardcoded API keys become data accessible through the agent's own output. The credential gets extracted through the tool-use interface, by the agent itself, because the agent was told to. This attack vector doesn't exist for conventional applications using environment variables. It is unique to agentic architectures.

The numbers track. GitGuardian's 2025 State of Secrets Sprawl report found AI-service credentials exposed in public GitHub commits rose 81% year-over-year to over 1.27 million. Over 90% were still valid five days after discovery. In January 2026, Wiz researchers found a misconfigured database in Moltbook, an AI agent platform, exposing 1.5 million API tokens assigned to agents, stored persistently without row-level security.

Static credentials, large blast radius, no rotation. The pattern writes itself.

Where your vault intuition helps

You know how Vault's dynamic secrets engine works. An application authenticates to Vault, requests credentials for a specific resource, and receives a unique, time-bound credential that Vault automatically revokes when the lease expires. No shared keys. No manual rotation. Full attribution of every credential to a specific session.

The instinct maps directly to agents. HashiCorp has published a validated pattern for exactly this scenario: a user authenticates to an IdP, the agent receives a JWT, exchanges it for an on-behalf-of token, and uses that token to request just-in-time credentials from Vault. Dynamic secrets, scoped to the specific role and resource, with a full audit trail back to the human who initiated the task.

If a CISO raises agent credential risk, this is the pattern to reference. It maps cleanly to what they already trust.

Where your vault intuition starts to mislead you

The traditional vault model works because the credential consumers are known. A vault admin writes a policy for app-payments-service, a service that was designed, reviewed, and deployed through a pipeline. The policy exists before the service ever requests its first credential.

Agent architectures break this assumption. When an orchestrator agent spawns three sub-agents at runtime to parallelize a research task, those sub-agents weren't designed, reviewed, or registered anywhere. They appeared because the model decided to create them. The vault has no policy for them. Writing a policy requires knowing they'll exist, which defeats the purpose of dynamic agent behavior.

Vault handles high-volume credential issuance fine. The hard part is enumeration. You cannot write access policies for consumers you don't know will exist. Traditional vault patterns solve secret-per-consumer management. Agent architectures require secret-per-task-context management. Those are genuinely different problems, and the gap between them is where the most interesting engineering work is concentrated right now.

A related constraint worth flagging: many downstream APIs only offer static API key authentication. A vault can manage rotation for those keys, but someone has to build the rotation integration for each service. Sometimes the vault helps, but the target service has to meet you halfway, and it doesn't.

What's forming

The IETF has been unusually active here. A draft specification co-authored by engineers from Defakto Security, AWS, Zscaler, and Ping Identity states it plainly:

The emerging architecture composes three existing standards rather than inventing new ones. SPIFFE/SPIRE gives each agent a short-lived, auto-rotating identity document (an SVID) that proves who it is without a standing credential. OAuth 2.0 handles access delegation, letting the agent exchange its identity for scoped access tokens. And Vault 1.21 added native SPIFFE authentication, so an agent with an SVID can exchange it directly for a Vault token without a separately managed bootstrap credential, closing one of the classic bootstrap gaps.

For cloud-deployed agents, workload identity federation (AWS IAM Roles Anywhere, GCP Workload Identity Federation, Azure Managed Identity) eliminates static credentials entirely. The agent gets an IAM role via its platform identity, scoped to exactly the resources it needs. No keys to leak because no keys exist.

What's genuinely unsettled

Multi-hop delegation. When an orchestrator agent delegates to a sub-agent, which calls a tool, which accesses a database, how does authority flow across that chain? How is it bounded? OAuth 2.0 handles one-hop delegation well. It was not designed for chains where the number of hops is determined at runtime by model reasoning.

The WIMSE working group at the IETF is working on workload identity for these scenarios, and a separate draft extends WIMSE specifically to AI agents. But the honest assessment from the research community is that authorization and delegation are partially addressed for simple cases and completely unaddressed for multi-hop chains. The standards are forming. They aren't formed. Anyone who tells you otherwise is selling something or hasn't read the drafts.

What to do with this in a room

When a buyer's CISO raises agent security, don't lead with the unsolved problems. Lead with the question that makes the conversation concrete: "How are your agent workloads getting their credentials today, and what's the rotation policy?"

If the answer involves environment variables or static API keys, you're on familiar ground. The fix is the same architectural direction the industry already trusts: short-lived credentials, vault-issued at runtime, with identity-based access rather than bearer tokens. The buyer's team knows how to evaluate that. It gets harder when agents spawn consumers dynamically, because pre-registration-based vault policies stop covering the surface. That's the gap worth naming, because it's where the real architectural decisions are being made.

Any agent architecture without a clean answer for how credentials are issued, scoped, and revoked is a future incident report with a date TBD. The buyer's CISO probably already suspects this. Now you can confirm it with the mechanism.