Workload Identity Federation: How Trust Replaces Secrets

Somewhere in your organization there is a credential that outlived the person who created it. It was pasted into a CI variable for a one-off deploy in a quarter nobody remembers, it still works, and no inventory lists it. That is not a process failure. It is what happens whenever a machine has to prove who it is by holding onto a secret.

Workload identity federation removes the secret from that equation. Instead of giving a service a key it must store, you configure a trust relationship between the identity provider the workload already has and the system it wants to reach. The workload proves itself to its own provider, presents the resulting token, and gets back a short-lived credential scoped to exactly what it needs.

The idea is not new. CI pipelines have used it for years. What is new is the volume of workloads that need it, because AI agents are now the fastest-growing class of non-human caller in most enterprises, and they break an assumption that federation quietly depends on. This guide covers the mechanism honestly: how the trust is built, what is actually in the token, how the same pattern looks across clouds, and the specific things federation does not fix.

What is workload identity federation?

Workload identity federation is an authentication method that lets a software workload prove its identity in one trust domain and receive a short-lived credential in another, without either side storing a long-lived password, API key, or shared secret. Trust is configured once between the two identity providers. Every request after that is authenticated dynamically, with no human involved.

A workload here means any non-human caller: a container, a CI job, a serverless function, a batch process, a microservice, or an AI agent. It has no browser, no password manager, and no person available to approve a prompt at three in the morning. Everything it does has to be provable from a credential it can obtain on its own.

The useful mental model is a passport, not a visa. A federated token is a passport: an authority the destination already trusts has vouched for who the bearer is, and the destination can verify that cryptographically without calling anyone. It is not a visa. It says nothing about what the bearer is permitted to do once inside. Those are separate decisions, made by separate systems, and conflating them is the most common architectural mistake in this area.

Why stored credentials are the part that breaks

Static credentials fail in a predictable order, and it is worth naming the sequence because federation is designed against exactly this list.

• They outlive their purpose. A key is issued for a deployment that ships next week. The deployment ships. The key does not get revoked, because revoking it means finding out what else started using it.
• They spread. A secret that works in one pipeline gets copied into a second pipeline, a developer laptop, a Terraform state file, and a screenshot in a support ticket. Each copy is an independent breach surface.
• They are hard to attribute. When a static key is used, the audit log records the key, not the caller. Two services sharing a key are indistinguishable in the record.
• Rotation is an outage risk. Rotating a credential that six systems depend on means coordinating six deploys, so teams schedule it, then postpone it, then stop scheduling it.

This is the core of the non-human identity problem: machine accounts now outnumber human ones in most environments, and the machine ones are the poorly inventoried half. Cloud platforms say this directly in their own guidance, warning that service account keys are powerful credentials that present real risk when they are not managed carefully.

Federation attacks the root cause rather than the symptom. If there is no long-lived credential to store, there is nothing to leak, nothing to rotate, and nothing to inventory. The proof of identity is generated fresh for each request and expires on its own.

How workload identity federation works

Federation happens in two phases that people routinely blur together. One is a configuration act performed once by an administrator. The other is a protocol exchange performed automatically on every request. Keeping them separate is the difference between understanding the model and copying a tutorial.

Phase one: the one-time trust setup

During setup, an administrator tells the target system three things. First, which issuer to trust: the URL of the external identity provider, from which the target can fetch the public signing keys used to verify tokens. Second, which specific identity within that issuer to accept, expressed as a match on the token's claims. Third, what that identity is allowed to become, meaning the role or permission set the exchanged credential will carry.

That second item is where most of the security lives, and most of the mistakes. You are writing a rule that says "accept tokens from this issuer, but only when the subject claim is this repository on this branch, and only when the audience claim is this value." A rule that is too loose accepts tokens from the whole issuer. On a public CI provider, that means accepting tokens from anyone's repository.

Phase two: the per-request exchange

Read as a sequence, the runtime exchange is six steps:

1. The workload starts with no credential on disk.
2. Its own identity provider issues a signed token. The CI platform, the Kubernetes cluster, or the agent runtime attests that this workload is what it claims to be, and mints a JSON Web Token (JWT) that is valid for minutes.
3. The workload presents that token to the target system's security token service (STS), asking to trade it for a usable credential.
4. The STS verifies the signature against public keys it fetches from the issuer's published key set. Nothing secret is shared between the two providers, only public keys.
5. The STS evaluates the trust rule configured in phase one, comparing the token's issuer, subject, and audience claims against what the administrator pinned.
6. A scoped, short-lived access token comes back, carrying only the permissions the administrator attached, and expiring on its own.

The exchange itself is standardized. The workload authenticates using a signed assertion rather than a secret, a pattern the IETF defined a decade ago as the JWT profile for OAuth (RFC 7523), and the trade of one token for another follows the OAuth 2.0 token exchange specification (RFC 8693). If you want the delegation mechanics in depth, our guide to OAuth token exchange walks through the request parameters and the difference between impersonation and delegation.

What is actually inside the token

Every trust rule is written against claims. It helps to know which ones matter and what each is doing.

Claim	What it carries	Why the trust rule cares
iss (issuer)	The identity provider that minted the token	Determines which public key set is used to verify the signature. Wrong issuer, rejected immediately.
sub (subject)	The specific workload identity, often a structured string such as a repository and branch, or a namespace and service account	This is the "who". The precision of your rule is the precision of your security boundary.
aud (audience)	Who the token is intended for	Stops a token minted for one destination from being replayed at another.
exp / iat	Expiry and issue time	Bounds the blast radius. A stolen token is useful for minutes, not indefinitely.
Provider attributes	Extra context such as environment, runner, cluster, or workflow	Feeds conditional rules, so you can accept production but not a pull request build.

The core components

Vendors name these differently, but every implementation has the same six pieces.

Component	What it does
External identity provider	The system the workload already trusts and can get a token from, such as a CI platform, a Kubernetes cluster, or another cloud.
Identity pool	A container on the target side that holds external identities and gives them a place to exist without becoming real accounts.
Pool provider	The record that describes the relationship to one specific external issuer, including its OIDC endpoint.
Attribute mapping	A transformation that turns claims in the incoming token into attributes the target's policy language understands.
Attribute condition	A boolean expression evaluated against those attributes. If it is false, the credential is refused. This is your allow-list.
Target role or scope	The permissions the exchanged credential carries. Keep this minimal, because it is the only thing standing between a valid token and your data.

Two of these deserve emphasis. The pool is not a security boundary by itself: granting access to every identity in a pool is technically possible and effectively hands the keys to anyone the external issuer will vouch for. The attribute condition is the security boundary, and it should be written narrowly enough that you could describe out loud exactly which workload it admits.

The same idea, three vocabularies

Most confusion about workload identity federation is vocabulary, not mechanism. The steps are identical across platforms. Only the nouns change. This mapping is worth keeping on hand when you are reading two sets of documentation at once.

Concept	Google Cloud	AWS	Microsoft Entra	Platform-neutral (SPIFFE)
Container for external identities	Workload identity pool	IAM identity provider	App registration or managed identity	Trust domain
Record of one external issuer	Workload identity pool provider	OIDC provider entry	Federated identity credential	Federation relationship
The matching rule	Attribute condition (CEL)	Role trust policy conditions	Issuer, subject, and audience match	Registration entry selectors
The exchange endpoint	Security Token Service	AssumeRoleWithWebIdentity	Client assertion grant	Workload API
What comes back	Short-lived access token	Temporary session credentials	Short-lived access token	X.509-SVID or JWT-SVID

Each platform documents its own side of this, and it is worth reading the target's own reference before writing a rule: the AWS guidance on registering an OIDC identity provider is a good example of how much of the security sits in the role trust policy rather than in the exchange itself. The rightmost column is the one worth learning if you run across more than one platform. SPIFFE is a set of open, vendor-neutral standards for identifying software systems, and SPIRE is its reference implementation; workloads receive short-lived identity documents called SVIDs over a local Workload API, in either X.509 or JWT form. Rather than teaching every workload three cloud dialects, you give it one identity and federate that identity outward.

Federation versus the alternatives

Federation is not the only way a machine can authenticate. It is the option with the best properties for most modern deployments, and seeing it next to the alternatives makes the trade-offs concrete.

Approach	What is stored	Typical lifetime	Main weakness
Static API key or service account key	A long-lived secret, on disk or in a variable	Indefinite	Leaks silently, cannot be attributed, rotation is an outage
Client secret with the client credentials flow	A shared secret plus a client ID	Months to years	Still a secret to store and rotate, though tokens are short-lived
Certificate or mutual TLS	A private key, protected locally	Months	Strong, but issuing and renewing certificates at scale needs its own machinery
Workload identity federation	Nothing	Minutes	Trust rules can be written too loosely, and setup is per-platform
SPIFFE SVID	Nothing persistent, identity is attested locally	Minutes to hours	Requires running the issuing infrastructure yourself

M2M authentication without a shared secret

Machine to machine authentication (usually shortened to M2M authentication) is the general problem of one service proving its identity to another with no user present. For most of the last decade the default answer was the OAuth client credentials flow: the service holds a client ID and a client secret, trades them for an access token, and calls the API. The tokens are short-lived, which is good. The secret behind them is not, which is the whole problem back again one level down.

Federation is the same shape with the secret removed. The workload still ends up with a short-lived access token. It just proves itself with a signed assertion from a provider that already knows it, rather than with a string it had to be given. Under the hood this is still OAuth, and the baseline rules have tightened: see our guide to OAuth 2.1 for what changed and why it matters for non-human callers, and Frontegg's reference on managing machine-to-machine tokens for how the credential side is administered in practice.

The result on the receiving end is a credential that behaves the way access should behave: issued on demand, narrow, and gone shortly after. That property is worth understanding on its own, which is why we cover it separately in ephemeral credentials.

Where AI agents break the workload model

Here is the assumption federation rests on: a workload's identity is sufficient to decide what the request should be allowed to do. For a nightly batch job, that is true. The job is the whole story.

For an AI agent, it is usually false. An agent is a workload, so it needs a workload identity. But the agent is almost always acting for someone: summarizing a specific person's inbox, filing a ticket a specific employee asked for, moving money on a specific customer's instruction. A federated workload token answers "which service is calling." It contains nothing at all about on whose authority. Grant permissions to the workload identity alone and you have built a service that can do anything any of its users could do, for every user at once.

The working architecture is three layers, and each is a different question:

1. Workload identity answers which service is calling. Workload identity federation supplies this, with no stored secret.
2. Delegated user context answers on whose authority the agent is acting. This comes from a delegation flow, where the agent exchanges the user's token for a downstream token that keeps the user in the picture. The standard for this trade distinguishes delegation, where both parties stay visible, from impersonation, where the agent simply becomes the user.
3. Policy answers whether this action, on this resource, with this authority, is permitted right now.

Those three are the practical difference between an agent that is authenticated and an agent that is accountable. Deciding the third layer well is its own discipline, covered in agent authorization. If your agents reach tools through the Model Context Protocol, the identity problem takes a protocol-specific shape that we work through in MCP identity.

One practical note. The intuitive fix, giving each agent instance its own federated identity, helps with attribution and is worth doing. It does not solve delegation. Ten agent identities acting with unbounded authority are ten problems instead of one.

What workload identity federation does not solve

A page that only lists benefits is a brochure. These are the things federation genuinely leaves open.

• Authorization. Federation decides who gets a token. What that token may touch is a separate policy decision, and an over-permissive target role undoes everything federation gained.
• User context for agents. Covered above. Federation alone gives you a service identity with no notion of on whose behalf it acts.
• Intent in the audit trail. You get a clean record of which workload called what, which is a real improvement. You do not get a record of why, or of which human request set the chain in motion. Building that record is a deliberate effort, which is the subject of our guide to AI audit.
• High-risk actions. Some operations should not proceed on any token, however well minted. A wire transfer or a production deletion warrants a live human decision, which is what human in the loop controls exist for, and a fresh proof of presence, which is where step-up authentication applies.
• Everything above the token. Prompt injection, tool misuse, and a compromised agent runtime all operate on a perfectly valid credential. Federation makes the credential trustworthy. It does not make the caller's instructions trustworthy.

Zero trust guidance makes the same point in general terms: authenticate and authorize every request individually, and never infer permission from the fact that a caller already got in, a principle set out in NIST's zero trust architecture guidance.

Failure modes worth designing against

These are the ways real federation deployments go wrong, in roughly the order they show up.

• Subject matching that is too broad. A rule that accepts any subject from a trusted public CI issuer accepts tokens minted for repositories you do not own, which is why GitHub's own hardening guidance stresses matching the full subject claim. Match the full subject, including the specific repository and reference, not a prefix.
• Missing or unchecked audience. If the target does not require a specific aud value, a token issued for a different destination can be replayed at yours.
• Case and format sensitivity. Issuer, subject, and audience comparisons are exact string matches. A trailing slash on an issuer URL or a capitalized path segment produces a failure that looks like a permissions problem and is not.
• Signing-key set limits. Targets cache a bounded number of public keys from an issuer's key endpoint. An issuer that publishes an unusually large key set can cause intermittent verification failures that are painful to diagnose.
• Clock skew. Tokens live for minutes. A drifting clock on either side turns "not yet valid" and "already expired" into recurring, apparently random errors.
• Pool-wide grants. Granting a role to every identity in a pool is the federation equivalent of a shared password. Grant to a specific mapped attribute instead.
• Trust-domain sprawl. Each federation relationship is a standing trust decision that nobody re-reviews. Inventory them, name an owner, and re-read the conditions on a schedule.

An implementation checklist

1. Inventory what holds a static credential today. Sort by blast radius, not by how easy the migration looks. The oldest key usually has the widest permissions.
2. Confirm each workload has an issuer. A workload can only federate if something already attests to it: a CI platform, a Kubernetes service account, a cloud instance identity, or a SPIFFE deployment you run.
3. Register the issuer once per target. Use the issuer's published OIDC endpoint so key rotation is automatic.
4. Write the narrowest condition you can defend. Pin issuer, subject, and audience explicitly. Say the rule aloud; if it admits more workloads than you can name, tighten it.
5. Attach least-privilege permissions to the exchanged credential. Start from nothing and add what the workload actually calls.
6. Set the shortest workable token lifetime, and treat every credential as disposable by design. See ephemeral credentials for how short-lived access behaves in practice.
7. Add the delegation layer wherever a human is behind the request. Exchange the user's token so downstream services see both the agent and the person.
8. Verify the audit trail end to end. Make one call and confirm you can name the workload, the authority, and the resource from the logs alone.
9. Delete the old credential. Migration is not finished while the key still works. This step is the one teams skip.
10. Re-review trust rules on a schedule. Put the federation inventory in the same review cycle as privileged human access.

Frequently asked questions

What is workload identity federation?

Workload identity federation is an authentication method that lets a service, container, CI job, or AI agent prove its identity to its own identity provider and exchange the resulting signed token for a short-lived credential in another system. Trust is configured once between the two providers, so no long-lived secret is ever stored.

What is the difference between workload identity and workload identity federation?

A workload identity is the identity itself, the record that represents a non-human caller. Workload identity federation is the mechanism that lets an identity established in one trust domain be recognized in another. You can have workload identities without federation, typically by giving each one a stored secret.

Do you still need secrets with workload identity federation?

Not for authentication between the federated systems. The workload proves itself with a signed token obtained at runtime, so nothing long-lived is stored. You may still hold secrets for other purposes, such as database passwords or third-party APIs that offer no federation option, and those remain worth vaulting and rotating.

Is workload identity federation the same as OIDC?

No. OpenID Connect is the protocol that defines how an identity token is issued and verified. Workload identity federation is the pattern built on top of it, adding the trust configuration and the token exchange that turn an external token into a usable credential. Most implementations use OIDC, and some also accept SAML.

Can AI agents use workload identity federation?

Yes, and they should. An agent is a workload, so federation removes its stored credentials the same way it does for any service. It is only half the answer, though. Because agents usually act on behalf of a person, you also need a delegation layer so downstream systems see whose authority the agent is using.

What is the difference between a service account key and workload identity federation?

A service account key is a long-lived secret that must be distributed, stored, and rotated, and anyone holding a copy is indistinguishable from the legitimate service. Federation replaces that file with a runtime exchange: the workload proves itself, receives a credential that expires in minutes, and there is nothing to leak in between.

Where to go next

Federation is the right place to start, because removing stored credentials removes an entire category of incident. Finish the job by deciding, explicitly, what each workload identity is allowed to do and whose authority it carries when it does it. That second half is where agents make the difference between a clean architecture and an unpleasant surprise.

Agen.co treats every agent as a first-class identity with a traceable chain back to the person who authorized the work. If you want to see what that looks like applied to your own agents, start with our identity foundation for AI agents.