# Agent Workload Identity and Service Accounts
Status: public
Confidence: medium (0.725) (verified)
Last verified: 2026-06-02
Generation: ai_structured


## TL;DR

Workload identity gives an agent a concrete chain from a running process to a cloud principal, so access decisions can be traced without copying long-lived keys.

## Core Explanation

Agents that change infrastructure or debug cloud access need more than a username. They need the workload identity that a process actually used at runtime: Kubernetes service account, namespace, projected token, cloud trust policy, IAM role, and audit log principal.

Service-account mapping is especially important for agent safety. A tool can look harmless at the prompt layer while still running with an overbroad workload identity. The evidence set should show the bound service account and the cloud role before an agent proposes privilege changes.

## Source-Mapped Facts

- Kubernetes documentation describes service accounts as identities for processes that run in Pods. ([source](https://kubernetes.io/docs/concepts/security/service-accounts/))
- Amazon EKS documentation describes IAM roles for service accounts as a way to associate an IAM role with a Kubernetes service account. ([source](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html))
- Google Cloud documentation says Workload Identity Federation lets workloads access Google Cloud resources without using service account keys. ([source](https://docs.cloud.google.com/iam/docs/workload-identity-federation))

## Further Reading

- [Kubernetes Service Accounts](https://kubernetes.io/docs/concepts/security/service-accounts/)
- [Amazon EKS IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)
- [Google Cloud Workload Identity Federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation)