Your Agent Logs In With a Password That Never Expires

Most AI agents authenticate with a long-lived static API key sitting in an environment variable, which is the most copyable and hardest-to-rotate secret in the whole stack.

Anthropic made Workload Identity Federation generally available on June 17, swapping that static key for short-lived scoped credentials issued per request from an identity provider you already run.

The fix is not exotic. Your cloud workloads have authenticated this way for years. Agents were just the last thing still carrying a permanent password.

The secret you forgot you were holding

Look at how almost any agent you run today gets access to the model. There is a value called ANTHROPIC_API_KEY or OPENAI_API_KEY, it lives in an env var, a .env file, a Kubernetes secret, a CI variable, and it does not change. It was minted once, pasted into a few places, and it grants whoever holds it the full billing and capability footprint of your account until a human remembers to rotate it.

That key has three properties that should make a security team uncomfortable. It is long-lived, so a leak from six months ago is still valid today. It is broadly scoped, because most teams generate one key and reuse it across services rather than minting a narrow one per workload. And it is a bearer token, meaning possession is authorization. Anyone who can read it can use it, from anywhere, with no second factor and no proof of who they are.

We have spent a decade teaching engineers not to do exactly this with every other credential in the stack. Database passwords rotate. Cloud access goes through roles, not root keys. Service-to-service calls use mTLS or signed tokens that expire in minutes. The agent layer skipped all of it and went back to a static string in a file.

What changed on June 17

Workload Identity Federation, now generally available on the Claude API, removes the static key from the equation. Instead of storing a permanent secret, your workload presents an identity it already has, from AWS IAM, a GCP or Kubernetes service account, an Azure managed identity, a GitHub Actions token, Okta, or any OIDC-compliant provider. Anthropic verifies that identity against a trust configuration you set up once, then issues a short-lived credential scoped to that specific workload, valid for the request and not much longer.

Nothing durable is sitting on disk for an attacker to find. There is no key to leak, because the thing your code holds is a federated identity that only works from the environment it was issued to. If an agent in your billing pipeline is compromised, the blast radius is that one service account, with its own audit trail, not your entire account.

This is the same pattern that killed static cloud keys years ago. If you have ever set up GitHub Actions to deploy to AWS without storing an access key, you already understand the shape of it. The workload proves who it is using infrastructure you trust, and the credential is handed out fresh each time.

Anthropic shipped it alongside a cluster of changes pointed at the same problem. Self-hosted sandboxes, in beta since late May, let agent tool execution run inside your own perimeter on Cloudflare, Daytona, Modal, or Vercel while orchestration stays on Anthropic. MCP tunnels reach private servers without exposing them to the public internet. A compliance API lets security teams govern Claude like any other app in the stack. The through line is moving the trust boundary back inside the enterprise, and WIF is the piece that handles authentication.

Why this is worth a migration

It is easy to file this under nice-to-have and keep shipping the key. The reason not to is that the static agent key is becoming the obvious target precisely as agents get more capable.

An agent is not a passive API consumer. It reads files, calls tools, executes code, and increasingly chains those actions without a human in the loop. The credential it carries is no longer just permission to generate text, it is permission to drive a system that touches your data and your other services. A leaked key from a logging dashboard or a screenshot in a support ticket used to mean someone ran up your token bill. Now it can mean someone steers an agent that already has reach into your environment.

The agentjacking attack reported in late June makes the point concretely. Attackers planted instructions inside Sentry error output that coding agents read as trusted input, and the technique hit thousands of organizations. Authentication is a different layer than prompt injection, but the lesson rhymes. Anything an agent holds that grants standing access, with no expiry and no scoping, is a liability waiting for the right leak. A static key that never expires is the cleanest version of that liability you can hand an attacker.

How to move without a rewrite

WIF is backward compatible. Every Claude API endpoint, the SDKs, and Claude Code all accept federated credentials, so you are not rebuilding your integration, you are changing how it authenticates. The practical sequence looks like this.

Inventory where your keys live first. Most teams underestimate this number. Grep your infra for the key name and you will usually find it in more services, secret stores, and CI configs than anyone remembered. That sprawl is the actual risk, and it is also the argument for fixing it.

Pick one workload to start, ideally an automated one that already runs under a cloud identity. A CI job or a background agent on AWS or GCP is the easiest first cut, because the identity is already there and you are just teaching Anthropic to trust it. Set up the trust configuration in the Claude Console, point the workload at it, and pull the static key out of that one path. Confirm it still works, then move the next service.

Mint a service account per workload rather than one shared identity. The whole value of this model is a per-workload audit trail and a blast radius that stops at one service. Reusing a single federated identity everywhere rebuilds the problem you just left.

None of this is a heavy lift if your workloads already run under cloud identities, which most production ones do. The static key was always the shortcut, taken once because it was the fastest way to get an agent talking to a model. The shortcut is now the soft spot. The tooling to close it shipped on June 17, and your other services have used the same pattern for years. The agent layer is just catching up to a standard the rest of your stack already meets.