What is workload identity federation?

Workload identity federation is the mechanism by which a workload, meaning software that runs with no person at the keyboard, obtains short-lived cloud credentials by presenting a token issued by an identity provider that already recognizes it, instead of keeping a permanent key. It covers a CI/CD pipeline, a service or an AI agent, all non-human identities that used to carry an access key around. The token, usually in OpenID Connect format, is a signed statement of who is asking, such as "the release job of repository X on the main branch". The cloud checks the signature, compares the token with the conditions the organization has configured and, if they match, hands over credentials that expire quickly. No secret sits in the pipeline anymore for anyone who breaches it to copy. The risk, though, shifts to the trust conditions: a rule that is too broad hands the credentials to someone else's workload.

See also: Non-Human Identity (NHI) · A digital identity that belongs to software, not a person: service accounts, pipelines, bots and now AI agents acting on company systems.

How the exchange works

OpenID Connect, according to the OpenID Foundation specification, is an identity layer on top of OAuth 2.0. Its token carries assertions called claims: who issued it (issuer), whom it is about (subject) and whom it is meant for (audience). The specification notes that a subject is unique only within its issuer. Trading the token for a cloud credential follows patterns such as the OAuth 2.0 Token Exchange (RFC 8693), which Google Cloud states it adheres to; AWS IAM and Microsoft Entra Workload ID offer equivalent mechanisms, and GitHub Actions generates a fresh token for every job. In effect, it is single sign-on for machines.

Where the risk moves

The first risk is the shared issuer. In its best-practices guide, Google Cloud notes that GitHub uses a single issuer address for every organization, so checking the issuer only proves the token came from someone on GitHub. AWS is blunt: without a subject condition limited to an organization or repository, workflows in other organizations can assume the role, and IAM now rejects trust policies where the subject condition is missing or consists only of wildcards. The OWASP cheat sheet adds that federation does not make a compromised job trustworthy, and that a tight trust rule does not make up for a role with administrator permissions.

An enterprise example

A manufacturing group with three hundred repositories on GitHub removes the AWS keys stored in its pipelines, but rather than write three hundred rules it configures one: any repository in the organization may assume the production release role. The keys are gone, yet now even an abandoned prototype can obtain production credentials. The fix has three parts: narrow the rule to the application's repository and its production environment, protected by required reviewers; revoke the old keys; and give the AI agent that queries the database its own read-only federated identity. Immutable identifiers should also replace names, which can change hands: GitHub uses them in the subject of repositories created after July 15, 2026, and older ones can opt in.

Why it matters for decision makers

The question for the team or the vendor is no longer "where are the keys?" but "who has been trusted, and on what conditions?". There are four decisions: which identity providers to accept and who may add new ones, keeping them, as Google suggests, in one dedicated project with a policy that blocks their creation elsewhere; how narrowly to scope each condition, never to a whole organization for a production role; who configures the rules and permissions, a job OWASP recommends separating from release roles; and for AI agents, a separate federated identity for each, with permissions limited to the task, in line with least privilege.