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.
Updates to this story
2 July 2026: Anthropic launches Workload Identity Federation for the Claude Platform — no more static API keys for CI/CD and cloud workloads
Workload Identity Federation (WIF) is now generally available on the Claude Platform, and it takes the secret-management story further than the vault-stored environment variables covered below. Rather than keeping a static Anthropic API key out of the agent’s context window, WIF eliminates the need to issue a static key for machine workloads at all.
AWS IAM roles, GCP service accounts, Azure managed identities, GitHub Actions tokens, Kubernetes service accounts, and any other OIDC-compliant provider can now authenticate directly to the Claude API by presenting a signed JWT. Anthropic validates it against trust rules you configure in the Claude Console and returns a short-lived access token that expires in minutes. SDKs handle refresh automatically. Nothing static is ever minted or stored.
Alongside WIF, Anthropic is introducing service accounts: named, non-human identities (prefixed svac_) that give each workload its own roles and audit trail instead of a shared API key.
One migration detail worth flagging: if ANTHROPIC_API_KEY is present in the environment, it silently overrides federation. Anthropic documents this explicitly, but it is easy to believe a workload has moved off static credentials when it has not.
Existing API keys continue to work alongside WIF, so teams can migrate one workload at a time. The Connect Workload wizard in the Claude Console handles the full setup in a single guided flow.
24 June 2026: Anthropic launches Workload Identity Federation and service accounts for the Claude Platform
Anthropic shipped Workload Identity Federation (WIF) for the Claude Platform on June 17, 2026, making static API keys entirely optional for automated workloads. The vault-stored environment variables covered in this article were a meaningful improvement, but they still required a static key to exist somewhere. WIF removes that requirement at the source.
Instead of minting an API key, your workload presents a signed JWT from its existing identity provider — an AWS IAM role, GCP or Kubernetes service account, Azure managed identity, GitHub Actions OIDC token, or any standards-compliant provider. Anthropic validates that token against trust rules you configure in the Claude Console and returns a short-lived access token. The token expires in minutes rather than persisting indefinitely.
Per-workload service accounts accompany WIF, giving each automation its own roles and audit trail rather than sharing a single key across multiple pipelines.
One migration footgun worth flagging: if ANTHROPIC_API_KEY is present as an environment variable, it silently takes precedence over federation. Teams can mistakenly believe they have moved off static credentials when they have not. Existing API keys continue to work alongside WIF, so migration can happen one workload at a time.
Full details are in the WIF reference documentation.
23 June 2026: Anthropic’s Workload Identity Federation is now GA: keyless authentication for Claude API with per-workload service accounts
The vault-stored environment variables described below keep API keys out of the agent’s context window. Workload Identity Federation, now generally available on the Claude Platform, goes further and removes the static sk-ant-... key from the authentication chain entirely.
WIF lets workloads authenticate using short-lived OIDC tokens issued by AWS IAM, Google Cloud, GitHub Actions, Kubernetes, Microsoft Entra ID, Okta, or any standards-compliant OIDC provider. Anthropic verifies the JWT against the issuer’s JWKS, then returns a short-lived sk-ant-oat01-... token with a configurable lifetime between 60 and 86,400 seconds. The SDK handles refresh automatically.
Alongside WIF, Anthropic is introducing named service accounts. Each workload gets its own identity, roles, and audit trail in the Claude Console rather than sharing a single API key across services.
One migration gotcha worth flagging: if the ANTHROPIC_API_KEY environment variable is present, it silently takes precedence over federation. Teams can end up believing they have moved off static credentials when they have not.
Existing API keys continue to work, so migration can happen one workload at a time. Federation configuration is also available via new Admin API endpoints for organizations operating at scale.
21 June 2026: Workload Identity Federation is now generally available on the Claude Platform
Anthropic has shipped Workload Identity Federation (WIF) for the Claude Platform, and it closes the gap that vault-stored environment variables left open. Vault storage kept API keys out of the agent’s context window; WIF eliminates static sk-ant-... API keys from your infrastructure entirely.
Instead of long-lived API keys, workloads now authenticate using short-lived OIDC tokens from an identity provider you already operate: AWS IAM, Google Cloud, Azure, GitHub Actions, Kubernetes, or any standards-compliant OIDC issuer. The Claude Platform verifies the signed token, matches its claims against your federation rules, and issues a scoped, short-lived access token. Nothing static is created, stored, or rotated.
Alongside WIF, Anthropic is introducing service accounts (svac_...), named non-human identities at the organization level. Each workload gets its own identity, roles, and audit trail rather than sharing a single API key across services.
Existing API keys continue to work, so teams can migrate one workload at a time. When migrating, remove ANTHROPIC_API_KEY and ANTHROPIC_AUTH_TOKEN from your environment, since the SDK gives them precedence over federation credentials.
One caveat worth noting: federated authentication is only as strong as the upstream identity provider signing the JWT.
Full setup details are in the official documentation.