Integrating Claude's Workload Identity Federation with WSO2 Agent ID

As AI agents become first-class participants in enterprise software, the question of how they authenticate becomes just as critical as what they can do. Two platforms are addressing this head-on from complementary angles: Anthropic's Workload Identity Federation (WIF) for the Claude API, and WSO2 Agent ID for identity-aware agent management. Together, they form a powerful pattern for giving every AI agent in your system a unique, controlled, and auditable identity, all without a single long-lived secret in sight.

The problem: Static API keys don't scale for agents

Before getting into what breaks, it helps to ground three terms that get used interchangeably but mean different things.

A workload is any piece of software that runs without a human sitting in front of it. A scheduled job, a backend service, a data pipeline, a CI runner. Workloads need to call APIs and access resources just like users do, but they can't type a password or click through a login screen. So they authenticate with credentials of their own.

An AI agent is a particular kind of workload. It's software that takes goals, reasons through them, calls tools, and produces outcomes, usually by talking to a large language model. A customer-support agent that reads a ticket, looks up the customer in your CRM, drafts a reply, and posts it back. A code-review agent that pulls a pull request, analyzes the diff, and leaves comments. A research agent that searches the web, synthesizes findings, and writes a report. The agent itself is code running somewhere, but its intelligence comes from calling a model like Claude.

Which means every AI agent is a workload that needs to call the Claude API. Many times. Sometimes thousands of times an hour. Each call needs to prove the agent is allowed to make it. And that's where credentials enter the picture.

Most teams today handle this proof with static sk-ant-... API keys.The key is generated once in the Anthropic Console, copy-pasted into the agent's environment, and read at runtime to authenticate every Claude API call. This works for a prototype, but falls apart fast when you have dozens of agents running across environments. Keys get copy-pasted into CI pipelines, buried in environment variables, and forgotten. They never expire. When one leaks, the blast radius is your entire organization's Claude access.

Meanwhile, the agent has no identity of its own. It isn't a principal your security model can reason about; it's a possessor of a secret, and that's a category mistake. The downstream effects show up everywhere you'd expect them to: no central registry of which agents exist, no record of what each one is allowed to do, no review cadence for when their access was last examined. The agent is just a key. It's an argument we've been making for some time, both in the lessons agentic AI taught us in 2025 and in the gaps exposed by OWASP's MCP security guidance.

What each platform brings to the table

Claude Workload Identity Federation (WIF)

Claude's WIF replaces static API keys with short-lived tokens issued through a standard OIDC token-exchange flow. Instead of embedding a permanent key, your agent presents a signed JWT from an identity provider you already trust. Anthropic validates the token's signature and claims against rules you configure in the Claude Console, and returns a short-lived access token scoped to a specific service account and workspace.

The key concepts are: service accounts (named non-human identities in your Anthropic org), federation issuers (registered OIDC providers), and federation rules (the bridge that says "a JWT from issuer X with claims Y may act as service account Z"). Tokens expire in minutes, not never.

This solves the credential half of the problem cleanly. Static keys are gone, blast radius shrinks to minutes, and every Claude call can be tied back to a named service account. But notice what WIF assumes rather than provides: a trusted identity provider already issuing signed JWTs for your agents. Claude’s WIF is the relying party in the OIDC relationship; it validates identities, it doesn't manufacture them. The agent still has to come from somewhere as a named, governed, credentialed principal before WIF has anything to validate. That's the other half of the problem, and it's where WSO2 Agent ID comes in.

WSO2 Agent ID

The relying-party model only works if the identity provider on the other end actually treats agents as distinct, governed principals, and most identity platforms today don't. Agents fall through the cracks of identity systems built for humans and identity systems built for workloads alike. They end up sharing service credentials, leaving no audit trail per agent, and operating outside the access controls the rest of your enterprise runs on.

WSO2 Identity Platform introduces the AI agent as a first-class identity type. Each agent gets a unique Agent ID and credentials, can be assigned to groups, granted specific roles, and given scoped access to API resources, all managed from the WSO2 Console. And because these agents now carry verifiable identities issued by a trusted provider, they can participate in standard OAuth and OIDC flows, integrate with existing security infrastructure, and operate within the same compliance frameworks that govern the rest of the enterprise.

How they integrate: WSO2 Identity Platform as the trusted identity source for Claude

The integration is straightforward in concept. WSO2 Identity Platform becomes the place where the identities of your agents are managed and prove who they are, and Claude trusts those identities when granting access to its APIs. No static API keys sitting in agent environments, no manual credential rotation, no shared secrets to leak.

Here's how it comes together.

In WSO2 Identity Platform

1. Register an application - This is the channel your agents use to authenticate against WSO2.
2. Create an identity for each agent - Give it a descriptive name, place it in the right groups, and grant it the roles matching the resources it should reach. Each agent gets its own Agent ID and credentials. This becomes your control plane: a single place where every agent in your system is visible, named, and governed.

In Claude

3. Register WSO2 as a trusted federation issuer - From this point on, Claude will accept identity assertions signed by WSO2.
4. Create a service account for each agent (or group of agents) and add it to the appropriate workspace. This is the identity the agent acts as when calling the Claude API.
5. Define federation rules that bind WSO2 agent identities to Claude service accounts.

The federation rule is where your policy lives, so it's worth being concrete about what it pins to. A rule typically binds on:

• Issuer (iss) - the WSO2 token endpoint URL
• Audience (aud) - your Anthropic federation audience
• Subject (sub) or a custom claim - identifying the specific agent

Pinning on the issuer alone is too coarse: any agent in your WSO2 Identity Platform swap into any service account. Pinning on iss + sub, ensures one agent can't impersonate another even within the same federation. For agents that act on behalf of users, the rule can additionally constrain the act and sub pair, so a delegated assertion only maps to a service account configured for that specific (agent, user) combination.

At runtime

Step 1: The agent proves its identity to WSO2
The agent authenticates through a redirect-free flow designed for headless services, with no browsers and no login screens. WSO2 returns a signed identity token confirming who the agent is and what it's permitted to do. For the full authentication flow, see the WSO2 Identity Platform documentation on AI agent authentication.

Step 2: Claude exchanges that proof for its own access token
The agent presents the WSO2-issued token to Claude. Claude verifies that the token genuinely came from WSO2, confirms the agent matches one of your federation rules, and issues a short-lived access token of its own.

Step 3: The agent calls the Claude API
Using the Claude-issued token, the agent makes its API calls. No static Anthropic API key ever lives in the agent's environment.

Because both tokens refresh automatically, a long-running agent can operate indefinitely without anyone manually managing tokens and monitoring them.

Why this matters: The advantages

Central governance for all AI agents
WSO2 becomes the place where every agent is registered, scoped, and governed. You can see which agents exist, what they're authorized to do, and revoke them instantly, whether they talk to Claude, your internal APIs, MCP servers, or third-party services.

A unique identity for every agent
Each agent is no longer an anonymous API key. It has a named identity in WSO2 (Agent ID) that maps to a named identity in Claude (service account). Audit logs on both sides show exactly which agent did what and when.

Unique credentials per agent
No more sharing a single API key across agents. Each agent authenticates with its own credentials and receives a JWT unique to that agent. Claude's federation rule can pin to individual agent claims, ensuring one agent can't impersonate another.

Individual access control per agent
WSO2's role-based access control lets you define exactly which API resources each agent can reach. Combined with Claude's workspace-scoped service accounts, you get fine-grained control: Agent A gets the production workspace with full developer scope, Agent B gets a read-only staging workspace, and Agent C gets nothing until you explicitly grant it.

Time-bound access
Every token in the chain is short-lived. The WSO2-issued JWT has an expiry; the Claude access token can be configured down to 60 seconds. Claude binds the issued token's lifetime to the inbound assertion's exp, so a stolen or replayed WSO2 token can't be exchanged for a fresh Claude token after the original assertion expires. A compromised agent's window of useful exposure is measured in minutes.

Zero static secrets
The entire flow eliminates long-lived credentials from the agent's runtime environment. There's no API key to leak from a CI pipeline, no secret to rotate on a quarterly schedule that everyone forgets. The agent proves its identity dynamically, every time.

User delegation when needed
For agents that act on behalf of users, such as booking assistants, copilots, and personalized recommendation engines, WSO2's implementation of the emerging IETF OAuth extension for AI agents ensures explicit user consent. The user sees exactly which agent is requesting access and to which scopes, and can revoke delegation at any time.

The bigger picture

Treat agents the way you'd treat any other principal in your identity infrastructure. Register them, credential them, scope them, audit them. The combination of WSO2 Agent ID and Claude Workload Identity Federation gives you that for the agent-to-Claude leg, and the same primitives (OIDC, OAuth 2.0, RFC 7523, RFC 8693) extend cleanly to the rest of your stack: internal APIs, MCP servers, agent-to-agent calls. Your security team already speaks to these standards.

Static API keys belong to the prototype phase. Once agents are in production, calling tools, acting on behalf of users, talking to other agents, the identity question is unavoidable. This is the shape of the answer.