Workload Identity Federation
A pipeline proving what it is with a short-lived signed token from its own platform, so no long-lived cloud credential is ever stored.
The traditional arrangement stores a cloud access key in the CI system's secret store. That key is long-lived, broadly scoped, and sits in the single most attractive target in the estate — a system that by design executes arbitrary code from every repository.
Federation removes it. The CI platform issues a signed token asserting facts about the run: which repository, which branch, which workflow, which environment. The cloud provider is configured to trust that issuer and to exchange such a token for short-lived credentials, but only when the claims match a specific condition — this repository, on this branch, targeting this environment.
The condition is the whole control and it is where the mistake happens. A trust policy that accepts any token from the issuer accepts one from any repository in the organisation, including a fork or a newly created one, which converts a supply-chain foothold directly into production access. The subject claim must be pinned narrowly, and pinning it to a branch or environment rather than only to a repository is what makes the difference.