Claude Managed Agents Can Now Store API Keys in a Vault — and the Agent Never Sees Them
Anthropic's vault-stored environment variables let Claude Managed Agents authenticate CLI tools without the API key ever entering the agent's context window.
Giving an AI agent access to external services has always involved an uncomfortable trade-off: the agent needs credentials to get work done, but handing it those credentials means they exist somewhere a bad prompt could theoretically reach. Anthropic’s latest update to Claude Managed Agents closes that gap in a structurally sound way.
As of June 9, 2026, Claude Managed Agents vaults now support environment variable credentials. You register an API key alongside an environment variable name and a list of approved domains, and the agent’s sandbox can make authenticated calls through CLIs and SDKs without the real secret ever appearing inside the agent’s context window. Both this feature and a companion scheduled deployments capability are now in public beta on the Claude Platform.
The Problem This Actually Solves
Before this update, teams building production agents faced a predictable dilemma. If you passed an API token through a system prompt, an environment variable, or a mounted file, it was visible inside the sandbox where Claude’s generated code runs. That meant it was reachable, full stop. A sophisticated prompt injection attack, where malicious content in a tool response manipulates the agent’s reasoning, could theoretically cause the agent to exfiltrate that token.
The standard workarounds were to build your own secret store, proxy credentials through your own infrastructure, or simply accept the risk. None of those options are great, and the first two mean maintaining plumbing that has nothing to do with your actual product.
Vault-stored environment variables are Anthropic’s architectural answer to this. The secret lives outside the sandbox entirely. The sandbox only ever holds a placeholder. The real key is attached at the network boundary, and only on outbound requests to domains you have explicitly approved.
How It Works
The setup is straightforward. You register a credential in your vault with three pieces of information: the API key itself, the environment variable name the CLI or SDK expects, and the domains that key is allowed to reach. From that point on, CLIs installed in the agent’s sandbox can authenticate through that variable without the harness, or Claude’s reasoning process, ever being made aware of the actual secret.
When a CLI makes an outbound request, the platform’s proxy intercepts it, resolves the credential from the vault, and attaches it to the request, but only if the destination domain matches your approved list. The agent’s sandbox is never in that loop.
Key rotation is handled cleanly too. Update the key in the vault and running sessions pick it up on their next call. Credentials are re-resolved periodically during a session, so rotation, archival, or deletion propagates without requiring a restart.
If you need to retire a vault entirely, archiving it cascades to all its credentials. Secrets are purged; audit records are retained. Future sessions referencing that vault will fail; sessions already running continue until they make their next credential call.
The vault has a current limit of 20 credentials, which matches the maximum number of MCP servers per agent.
Why the Architecture Matters for Prompt Injection
This is worth being precise about, because “the agent can’t see the key” is doing a lot of work.
The sandbox where Claude’s generated code runs is a disposable gVisor container, treated as untrusted by design. The harness that manages session state and tool calls lives in a separate trust zone. A compromised sandbox cannot tamper with the session log, influence the harness, or reach vault credentials, because those credentials are never in the sandbox’s address space to begin with.
The practical implication: even if a prompt injection attack fully controls Claude’s reasoning, there is nothing to steal. The attack surface shifts from “exfiltrate the token” to “misuse the permissions the token already grants,” which is a meaningfully smaller and more containable problem.
One important caveat worth highlighting: this protection only applies to vault-stored credentials. If you hardcode a token in a system prompt, pass it as a plain environment variable, or include it in a mounted file, you have opted out of this protection. Those values are visible to the agent inside the sandbox. The security property is specifically tied to the vault mechanism.
Who Is Already Using This
Early adopters give a good sense of the practical range.
Notion is using vault-stored environment variables to roll out its CLI alongside MCP tools, adding file-upload capabilities to its agents without API tokens ever being passed to the model.
Browserbase built its public catalog of browser skills using the browse CLI authenticated through vaults, and is using the new scheduled deployments feature to run periodic validation of that catalog.
KERNEL uses vaults to connect agents to the databases where it tracks usage and customer conversations, allowing the agent to flag usage surges as they happen for human review.
Most CLIs that authenticate by sending a key in an HTTP header work with this pattern, including the Browserbase, KERNEL, Notion, Ramp, and Sentry CLIs.
What This Means for Your Team
If you have been building agents on the Claude API and managing your own secret store or credential proxy to avoid passing tokens directly to the model, this update removes that work. The platform now handles that layer.
If you have been deferring agent projects because you could not square credential security with the realities of prompt injection risk, this gives you a structural answer to that concern rather than a set of best-practice mitigations.
If you are in a compliance-sensitive industry, one thing to note: Claude Managed Agents currently remain ineligible for Zero Data Retention or HIPAA compliance due to server-side state storage. That limits applicability in healthcare and some financial contexts for now.
For everyone else, both vault-stored environment variables and scheduled deployments are available today in public beta. All Managed Agents API requests require the managed-agents-2026-04-01 beta header, though the SDK sets this automatically.
The unglamorous credential plumbing problem has been one of the more consistent reasons enterprise agent projects stall between proof of concept and production. This update is a direct attempt to close that gap without asking you to build the solution yourself.