01 / The operating case
What changes in a real workflow?
Three agents share one worker process and service credential. A risky account change must still be attributable to the specific agent and assignment.
- 01Owner
- 02Agent + workload
- 03Task context
- 04Action decision
02 / Decision boundary
Put the check where it can stop the effect.
Register agent identifier and owner, bind it to workload attestation and task context, and propagate the distinction through tool calls.
Architecture review / negative test
Make the boundary testable.
An inventory record should distinguish agent ID, owner, runtime, credential, initiating user and task. The same agent may run in several workloads, while one workload may host several agents. Identity binding must be issued by a trusted control plane; a string supplied inside a tool argument is not sufficient proof.
03 / Failure and evidence
What goes wrong, and what can be proven?
A generic service account appears in every audit log, obscuring the actor and granting broad persistent access.
Correlate agent, runtime, initiating user, task, tool and decision without conflating them into one principal.
04 / Canonical scope
Why this reference stands alone
The existing agent identity versus authority resource owns the conceptual contrast; this page owns identity representation and attribution.
Implementation review
Identify the autonomous actor separately from its host.
A workload identity can prove which process is running, but several agent tasks may share that process. An agent identity should provide an attributable principal, owner and lifecycle binding for the autonomous actor. Neither identity carries blanket permission to change customer data. Bind the agent instance to its workload attestation and task grant; preserve that relation after the short-lived runtime terminates.
human originator: analyst-U7 agent instance: investigation-agent/A42 workload: spiffe://example.org/ns/ops/sa/agent-host task: incident-88 requested effect: disable account C-42 required: workload authentication + agent attribution + action grant
Run the denial test
Run two agents in the same host with different tasks, then make one request under the other task ID. The executor must reject a task/agent mismatch even though the workload SVID is valid.
Evidence to examine
Keep agent instance and owner, workload identity, binding attestation or issuance record, task grant, call ID and protected action result. Retire credentials while preserving audit references.
Primary source: SPIFFE Workload Identity Overview ↗
Related: Workload versus agent identity.
Architecture field test
Host, agent and origin are distinct principals
Which actor is attributable to this action?
- 01Authenticate hosting workload
- 02Bind agent instance and owner
- 03Bind originating task or grant
- 04Authorize the concrete action
Work the boundary
A shared Kubernetes worker runs a reconciliation agent and a remediation agent. SPIFFE identifies the worker, while the protected API needs to distinguish which agent and task requested a customer lock. Host identity alone cannot answer that.
| Required facts | Workload credential, agent instance ID, accountable owner, task, grant and final action context. |
|---|---|
| Allow only when | A verified workload hosts the named agent, and that agent has a live task-bound grant for this effect. |
| Deny when | One agent reuses the host credential and claims another agent’s task. |
Break the assumption
Swap only the claimed agent ID while keeping the same workload credential. Reject a missing or untrusted binding, and preserve both host and agent references for the audit.
Design tradeoff
An agent identifier improves attribution only if issuance, binding and retirement are trustworthy. It does not replace policy, nor should a caller-supplied string be accepted as proof.
For host, agent and origin are distinct principals, consult SPIFFE workload identity overview. This worked decision and negative test are ProofGrid analysis.
Continue with Workload versus agent identity.
Primary references