01 / The difference
Two facts that must stay separate
One Kubernetes worker hosts several agents. Its SPIFFE identity proves the workload but cannot by itself distinguish which agent requested a transfer.
Workload identity authenticates a service or runtime environment; agent identity names the autonomous actor and its owner within or across that environment.
Bind agent identity and task to authenticated workload context, validate the binding at tool access and avoid trusting a caller-supplied agent string.
- 01Owner
- 02Agent + workload
- 03Task context
- 04Action decision
02 / Decision boundary
Put the check where it can stop the effect.
Bind agent identity and task to authenticated workload context, validate the binding at tool access and avoid trusting a caller-supplied agent string.
Architecture review / negative test
Make the boundary testable.
SPIFFE-style workload identity proves a service instance or workload under a trust domain. The agent is a logical autonomous actor with potentially separate owner, task and lifecycle. A secure bridge binds the logical agent to the authenticated process without letting every process occupant borrow every other agent’s grants.
03 / Failure and evidence
What goes wrong, and what can be proven?
A shared workload credential is treated as permission for every resident agent and every task.
Record workload attestation and agent-to-task binding as separate decision inputs.
04 / Canonical scope
Why this reference stands alone
AI agent identity explains agent representation; this comparison owns the many-agents-per-workload boundary.
Primary references