Workload Identity Federation
How can an agent obtain access without storing a permanent cloud key?
Reference notes by Min · Reviewed October 15, 2026
Definition
Workload identity federation allows a service to rely on identity evidence issued by another trusted system when obtaining access to resources. For an agent, it can replace a stored service-account key with a controlled exchange based on its running environment.
Federation moves part of the security question from secret storage to trust configuration. An attacker who can satisfy an overly broad identity mapping may obtain legitimate credentials. Review the conditions under which access is issued as carefully as the permissions attached to it.
What it covers
- Issuer
- Which system may assert identity.
- Subject
- Which workload the assertion identifies.
- Mapping
- How verified attributes map to local access.
- Lifecycle
- How trust and issued credentials end.
Identify who controls the external assertion and its attributes. Repository, environment or tenant claims have different meanings across providers. A field supplied by untrusted application code should not become authoritative merely because it appears inside an otherwise valid identity flow.
In practice
Practical design patterns by Min.
- Restrict accepted issuers, subjects and environments.
- Review attribute mapping with the resource owner.
- Exercise an untrusted workload and a changed deployment identity.
Keep an inventory of trust relationships, accepted subjects, resource roles and owners. Confirm how token lifetimes and revocation work in the chosen integration. A short credential lifetime limits some exposure but does not remove the need to terminate unwanted issuance.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Trust configuration replaces a stored key
Google Cloud describes access through federated identities instead of service-account keys. This is a concrete implementation reference; other platforms use different trust and mapping mechanisms.
Working example
A hosted agent reads cloud reports
A worker outside the cloud needs access to one reporting dataset.
- Trust only the intended workload identity from the external platform.
- Map that identity to the reporting permission.
- Reject a worker from a different project even if it uses the same application name.
Why the controls matter
The reporting worker should not obtain production write access because its source platform is trusted. Check the resulting service permissions directly. The same platform may host development workers, unrelated customer jobs and privileged production workflows.
Common pitfalls
- Trusting every subject from an accepted issuer.
- Using mutable display names as the sole identity condition.
- Assuming keyless access eliminates credential theft.
Federation failures can tempt teams to add broad fallback keys. If a fallback is necessary, document its narrower permissions, custodian and retirement condition. Otherwise the organization may retain the original secret risk while adding a second access path.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Who can influence the mapped identity attributes?
- Can development workloads obtain production access?
- How is a compromised trust relationship disabled?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- Google Cloud: Workload Identity Federation ↗Accessed October 15, 2026
- SPIFFE: Concepts and verifiable workload identity ↗Accessed October 15, 2026