We called Claude without a single API key on disk. Here’s how.

We called Claude last week without a single Anthropic API key on disk. An AI agent minted a short-lived OIDC token from 1Claw, exchanged it at Anthropic's Workload Identity Federation endpoint, received a session credential, and used it to call the Claude API. The whole thing took about eight seconds. Every credential in the chain expired in minutes. Nothing was stored.

This post explains how it works, why it matters for anyone running AI agents in production, and how to set it up yourself.

The static API key problem

If you're running AI agents that call external APIs (Claude, OpenAI, Stripe, anything), the default authentication model is a static API key. You generate one in a console, paste it into an environment variable, and the agent uses it on every request. That key doesn't expire. It's the same key every time. And if it leaks through a log, a misconfigured deployment, or a compromised agent, you're exposed until someone notices and manually rotates it.

This isn't a hypothetical. It's the most common credential management pattern in agent infrastructure today, and it scales poorly. Twenty agents hitting Claude across three environments means twenty copies of the same key (or twenty different keys to track). If one agent gets compromised, you need to find every place that key exists and replace it. If you're lucky, you catch it in hours. If you're not, it's been sitting in a staging cluster log for weeks.

Cloud infrastructure solved this problem years ago. GCP Workload Identity Federation, AWS IRSA, and GitHub Actions OIDC all work the same way: your workload gets a short-lived identity token from its platform, exchanges it for access to the service it needs, and the token dies in minutes. No static secret to leak, no rotation to forget, no key sitting in an env var. AI agents haven't had anything like this. Until now.

What is Workload Identity Federation for AI agents?

Workload Identity Federation (WIF) lets a workload authenticate to an external service using a short-lived token from an identity provider it already trusts, instead of a static API key. The service validates the token against the provider's published public keys (a JWKS endpoint) and returns a session credential. The identity provider is called an OIDC issuer, and the whole flow follows open standards: OpenID Connect for discovery and key publication, and RFC 8693 for token exchange.

Anthropic launched WIF support for Claude in 2025, with built-in provider guides for GitHub Actions, Google Cloud, AWS, Azure, Okta, and Kubernetes. What was missing was a way for AI agents specifically to participate in this model. That's what 1Claw now provides.

1Claw as an OIDC Identity Provider

1Claw now publishes a full OpenID Connect issuer. That means three public endpoints:

• /.well-known/openid-configuration — the OIDC discovery document. Lists the issuer URL, JWKS endpoint, supported signing algorithms, and supported grant types.
• /.well-known/jwks.json — the JSON Web Key Set. Every active signing key version, keyed by kid. Both EdDSA and RS256 keys are published.
• POST /v1/auth/federated-token — the RFC 8693 token exchange endpoint. Accepts an agent credential and returns a federation JWT scoped to the requested audience.

The signing keys live on Google Cloud KMS hardware security modules. The RS256 key (used for federation tokens because it's the most universally supported algorithm across OIDC relying parties) rotates on a 90-day cadence. The JWKS publishes all active key versions by kid, so relying parties can verify tokens from both the current and previous key without any downtime.

How the Anthropic WIF flow works, step by step

Here's the exact sequence we ran against production:

1. Enable federation on the agent

In the 1Claw dashboard, open the agent's detail page and find the OIDC Federation card. Toggle Enable Federation, add https://api.anthropic.com to the Allowed Audiences list, and set a token TTL (default 15 minutes, hard cap 60 minutes). Federation is off by default. No agent ships federation-capable until a human explicitly enables it.

2. Register 1Claw in the Anthropic Console

In Anthropic's Console, go to Settings > Workload Identity > Issuers and create a new issuer with:

• Issuer URL: https://api.1claw.xyz
• JWKS source: discovery (Anthropic fetches /.well-known/openid-configuration automatically)

Then create a federation rule that matches subject_prefix: agent:* and audience https://api.anthropic.com, targeting a service account and workspace.

3. Mint a federated JWT

The agent calls 1Claw's token exchange endpoint with its short-lived credential:

POST /v1/auth/federated-token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<agent_jwt>
&subject_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=https://api.anthropic.com

1Claw verifies the agent credential, checks that federation is enabled and the audience is on the allowlist, then signs an RS256 JWT with the KMS HSM key. The returned token carries:

• iss: https://api.1claw.xyz
• sub: agent:<uuid>
• aud: https://api.anthropic.com
• kid: rs256-v1 (resolves against the JWKS)
• exp: 15 minutes from now
• jti: unique ID for revocation tracking

4. Exchange at Anthropic

The agent sends the federation JWT to Anthropic's POST /v1/oauth/token endpoint with the federation rule ID, organization ID, and service account ID. Anthropic fetches https://api.1claw.xyz/.well-known/jwks.json, verifies the RS256 signature against the published key, checks the claims, and returns a short-lived sk-ant-oat01-... access token.

5. Call Claude

The agent uses the Anthropic session token as a Bearer credential to call the Claude Messages API. In our test, Claude responded: "Hello from 1claw!" No static Anthropic API key was involved at any point in the chain.

Security model: zero-trust by default

The federation feature was designed with the assumption that agents will be compromised. Every control is opt-in and restrictive by default:

• Federation is off by default. No agent can mint federation tokens until a human explicitly enables it.
• Empty audience allowlist denies everything. You must list the exact external services the agent is allowed to federate with. There's no wildcard, no allow-all.
• Hard TTL cap of 60 minutes. The default is 15 minutes. Both are enforced as a database CHECK constraint and clamped in the handler. You can't configure around it.
• Rate limited. 5 burst, 1 per second on the federation endpoint.
• Every mint is audited. An auth.federated_token_issued event is logged in the tamper-evident audit hash chain with the agent ID, requested audience, and unique token ID.
• Tokens are revocable. The jti is tracked, so you can revoke an active federation token the same way you revoke a regular agent JWT.

Why agents specifically need this

Agents are not humans. They run unattended. They scale horizontally. They get deployed, cloned, torn down, redeployed across environments. The "give it a key" model breaks down fast when you have 50 agents calling Claude, each needing different scopes, each needing independent revocation if one goes sideways.

With federation, each agent has its own identity in 1Claw. A human controls which agents can federate and with which services. If an agent gets compromised, you revoke its 1Claw credential and every downstream session token dies with it. You don't need to find and rotate a static Anthropic key that might be copied in four places. The blast radius is one agent, not your entire fleet.

This is the same identity model that cloud infrastructure already uses. GCP workload identity, AWS IRSA, GitHub Actions OIDC, Kubernetes projected service-account tokens. They all work on the same principle: your workload proves who it is with a short-lived signed token, and the service it needs validates that token against published keys. 1Claw brings this model to AI agent-to-API authentication.

Not just Anthropic

We started with Anthropic because that's where the demand is and their WIF implementation is solid. But the infrastructure is general-purpose. The endpoints are standard OIDC. Any service that supports OIDC federation can validate tokens against the 1Claw JWKS: GCP Security Token Service, AWS STS, Azure workload identity, or any custom service that verifies JWTs. We publish both EdDSA and RS256 keys, so you're covered regardless of which algorithms the relying party supports.

Pair it with Shroud for defense in depth

A federated JWT is still a bearer credential. If an agent is compromised and the token hasn't expired yet, the attacker can use it. For maximum security, pair federation with Shroud, our TEE-backed LLM proxy. Shroud holds the federated credential, redacts secrets and PII from prompts, enforces per-agent policy, and routes the call to Claude. The agent never sees the upstream sk-ant-oat01-... token at all.

Get started

The discovery endpoint is live right now. You can verify it yourself:

curl https://api.1claw.xyz/.well-known/openid-configuration | jq .

The full setup guide, including how to register 1Claw as an issuer in the Anthropic Console and code examples for the SDK, CLI, and curl, is in the docs:

Questions or feedback? Reach us at ops@1claw.xyz or on Telegram.