DEV Community

Anton Staykov
Anton Staykov

Posted on

Your AI Agent Doesn't Need an API Key: Entra Agent ID and Anthropic's Workload Identity Federation

#entra #aiagents #anthropic #security

Your AI Agent Doesn't Need an API Key: Entra Agent ID and Anthropic's Workload Identity Federation

Every system that authenticates with a static API key is carrying a liability disguised as a convenience. The key does not expire unless someone sets a calendar reminder. It does not know who is using it. It cannot tell you whether the request that just hit the endpoint came from the production agent it was minted for or from a laptop in a coffee shop where someone pasted it into a terminal two months ago. Static keys are the skeleton key of modern distributed systems — they open the door for anyone who holds them, and they never ask why.

This is not a new problem, but it is becoming a dangerous one. As AI agents proliferate across enterprise environments — calling model APIs, orchestrating workflows, accessing downstream services — the number of static secrets embedded in configuration files, environment variables, and CI pipelines is growing faster than any rotation policy can keep up with. The question is no longer whether your organization has a leaked key somewhere. The question is how many, and which ones an attacker has already found.

The industry's answer has been converging for years, and it has a name.

Workload Identity Federation

Workload Identity Federation (WIF) is a pattern — not a product, not a proprietary protocol — built on top of OpenID Connect and the RFC 7523 JWT bearer grant. The idea is disarmingly simple: instead of minting a long-lived secret and handing it to a workload, you let the workload prove who it is using a short-lived, signed JSON Web Token issued by an identity provider (IdP) you already trust. The receiving system validates the JWT's signature against the IdP's published keys, checks the claims against rules you configured, and — if everything lines up — issues a short-lived access token in return. No secrets to store. No secrets to rotate. No secrets to leak.

The pattern has been adopted across the industry — by major cloud providers, CI/CD platforms, container orchestrators, and increasingly by model providers. Microsoft Entra, for its part, supports WIF both as an issuer (your Entra tenant issues JWTs that external systems trust) and as a relying party (your Entra tenant trusts JWTs from external identity providers to grant access to Entra-protected resources). That bidirectional capability is what makes the rest of this story possible.

Anthropic embraces the standard

Anthropic has brought native Workload Identity Federation support to the Claude API — and this deserves more attention than it has received.

With Anthropic's WIF implementation, any OIDC-capable identity provider can authenticate workloads to the Claude API without a static sk-ant-... key ever being involved. You register your IdP as a federation issuer in the Anthropic Console, define a federation rule that maps incoming JWT claims to a service account, and your workload does the rest: present the JWT, receive a short-lived Claude access token, call the API. The SDKs handle the exchange and the refresh loop. API keys can be disabled entirely on the Anthropic workspace.

Three concepts on the Anthropic side matter here:

  • Service accounts (svac_...) — non-human identities inside your Anthropic organization. A federated token acts as a service account. Unlike an API key, a service account has credentials minted for it on demand, and you can audit which workloads acted as which service account.
  • Federation issuers (fdis_...) — the registration of your OIDC identity provider with your Anthropic organization. Each issuer tells Anthropic "JWTs signed by this provider may assert workload identity for my org."
  • Federation rules (fdrl_...) — the bridge between an issuer and a service account: "when a JWT from issuer X has claims that look like Y, mint a token for service account Z."

The Console includes presets for common providers and a generic OIDC option that works with any standards-compliant issuer — including Microsoft Entra ID. That last bullet is the one this article cares about.

Microsoft Entra Agent ID — identity built for agents

Microsoft Entra Agent ID introduces first-class identity constructs purpose-built for AI agents. Not repurposed service principals. Not human user accounts pressed into service. Dedicated objects with a dedicated governance model.

The constructs that matter for this story:

  • Agent identity blueprints — the template and authentication foundation for one or more agent identities. The blueprint holds the credentials (client secret, certificate, or federated identity credential) and uses them to acquire tokens on behalf of all agent identities created from it. Conditional Access policies applied to a blueprint propagate to every agent identity it parents.
  • Agent identities — the runtime identity of a specific AI agent. An agent identity has no credentials of its own. It authenticates through its blueprint.
  • The Microsoft Entra SDK for Agent ID — a containerized sidecar that handles token acquisition, validation, and secure downstream API calls. Your agent code asks the sidecar for a token; the sidecar handles the identity plumbing.

The proof of concept

The question I wanted to answer was concrete: can an AI agent, using Microsoft Entra Agent ID as its native identity, call the Anthropic Claude API through Workload Identity Federation — with no API key, no certificate in agent memory, and no cloud LLM proxy in between?

The answer is yes. I built a proof of concept that does exactly this.

The architecture

The PoC runs as two containers on a Docker bridge network:

  1. claude-wif-agent — a Flask application that receives user queries, asks the sidecar for an Entra JWT, exchanges that JWT for a Claude access token, and calls the Claude Messages API.
  2. claude-wif-sidecar — the Microsoft Entra Auth SDK sidecar, which handles the client-credentials flow against Entra ID and returns a signed JWT scoped to the agent identity.

The token flow has nine steps, but the critical insight lives in three of them:

  • Steps 4–5: The sidecar uses the blueprint's credentials to obtain an Entra-issued JWT for the agent identity. The JWT carries the agent's appid, oid, and — crucially — the xms_par_app_azp optional claim that identifies the parent blueprint.
  • Step 7: The agent application exchanges that Entra JWT for a Claude access token by posting to POST https://api.anthropic.com/v1/oauth/token using the RFC 7523 jwt-bearer grant. Anthropic validates the JWT's signature, checks the claims against the federation rule, and returns a short-lived token.
  • Step 9: The agent calls POST https://api.anthropic.com/v1/messages with the Claude token. No API key is involved. No MSAL library is needed. No certificates sit in agent memory.

Three Entra objects — and why the third is easy to miss

The PoC requires three distinct Microsoft Entra objects. Two of them sound similar and the third is implicit in WIF mechanics — which is exactly why it trips people up.

  1. An Agent Identity Blueprint — holds the credentials (client secret for local dev; managed identity or federated identity credential in production) and parents the agent identity.

  2. An Agent Identity — the runtime identity of the specific AI agent. No credentials of its own — the blueprint mints tokens on its behalf.

  3. An App Registration representing the Anthropic API — and this is the one that is easy to miss. Anthropic's WIF rule validates an Entra-issued JWT, and the only way that JWT carries the right aud (audience) claim is if Entra issues it for a registered resource application whose ID matches what you configured as the audience of the federation issuer in the Anthropic Console. This app registration uses v2.0 tokens (requestedAccessTokenVersion: 2), has acceptMappedClaims: true, and configures the xms_par_app_azp optional claim on the access token — so that a single Anthropic federation rule can match all agent identities parented by the same blueprint, rather than requiring a rule per individual agent.

The token that reaches Anthropic carries:

  • iss = https://login.microsoftonline.com/<tenant-id>/v2.0
  • aud = the Application ID of the Anthropic API app registration
  • appid = the Agent Identity's client ID
  • oid = the Agent Identity's object ID
  • xms_par_app_azp = the Agent Identity Blueprint's application ID

Anthropic validates all of this against the federation issuer and rule you configured. No Anthropic API key is involved at any point.

Both flows work

The PoC supports both access patterns that the agent identity platform defines:

  • Autonomous (app-only): The agent identity acts independently. The sidecar obtains a client-credentials token, the agent exchanges it for a Claude token, and the response comes back tagged "flow": "autonomous".
  • On-Behalf-Of (OBO): When a signed-in user's Entra Bearer token is available, the sidecar performs an OBO exchange and mints an agent-on-behalf-of-user token, which is then exchanged with Anthropic WIF. The response comes back tagged "flow": "obo".

Both flows use the same Anthropic WIF endpoint. The only difference is whose authority the Entra JWT represents — the agent's own, or the agent acting on behalf of a human.

From local dev to production

The PoC uses a client secret on the blueprint for local development — a pragmatic shortcut for proving the concept. Moving to production requires changing exactly two environment variables in the sidecar configuration to switch from client secret to managed identity, and adding a federated identity credential on the blueprint for the managed identity. No agent code changes. The sidecar abstracts the credential source entirely.

The credentials-free agent

This is where the threads converge. Workload Identity Federation is an industry standard. Anthropic has built native support for it into the Claude API. Microsoft Entra Agent ID provides purpose-built identity constructs for AI agents — with blueprints that centralize credential management, agent identities that carry no secrets of their own, and a sidecar SDK that abstracts the entire token lifecycle.

Put them together and you get something that would have been difficult to describe two years ago: an AI agent that authenticates to a third-party model provider using its own agentic identity, issued by the enterprise identity provider, validated through standards-based federation — with no static API key, no certificate in memory, and no cloud LLM proxy sitting in between. The agent's identity is its credential.

The proof of concept is open on GitHub: astaykov/claude-wif-agentid. It is minimal by design — a Flask app, a sidecar, a docker-compose.yml, and a .env file. The README walks through every Entra object, every Anthropic Console configuration step, and the full token flow. Fork it, break it, extend it.

The age of the static API key — for AI agents, at least — is ending. The identity infrastructure to replace it is already here.

References

Top comments (0)