01 / The operating case
What changes in a real workflow?
An agent runs in a container with a SPIFFE workload identity and calls a payment API.
- 01Owner
- 02Agent + workload
- 03Task context
- 04Action decision
02 / Decision contract
What the executor must check
Authenticate the workload and bind the running agent and task to it; separately decide payment action and parameters.
InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome
03 / Failure and evidence
What goes wrong, and what can be proven?
Failure mode
The service identity is accepted as permission for every agent hosted in the container.
Evidence to retain
Record workload ID, agent instance, task grant, decision and downstream call.
04 / Canonical scope
Why this reference stands alone
Workload versus agent identity compares principals; this page explains workload issuance and binding.
Technical artifact
Bind agent instance to its host
host identity: spiffe://org/ns/finance/sa/worker agent A: task invoice-I42, read only agent B: task invoice-I43, prepare only A requests prepare(I43) → DENY valid host identity is insufficient
Run the denial test
Start two agents on one authenticated worker and swap their task references. Reject the mismatch before the protected API runs.
Primary references