01 / The difference
Two facts that must stay separate
Five task agents share one service account to read and modify tickets.
Separate shared infrastructure credentials from the autonomous actor using them.
Bind each task agent to an attributable instance and originating grant before a ticket write; limit the backing account independently.
- 01Owner
- 02Agent + workload
- 03Task context
- 04Action decision
02 / Decision boundary
Put the check where it can stop the effect.
Bind each task agent to an attributable instance and originating grant before a ticket write; limit the backing account independently.
03 / Failure and evidence
What goes wrong, and what can be proven?
Audit logs identify only the service account and cannot explain which agent or user initiated a change.
Record service identity, agent instance, originator, task, authorization and ticket result.
04 / Canonical scope
Why this reference stands alone
Workload versus agent identity covers runtime identity generally; this page addresses shared service-account attribution.
Technical artifact
One service account, two autonomous actors
service account: ticket-service agent A: complaint T-11, may draft response agent B: complaint T-12, may issue refund ≤ USD 50 A invokes refund(T-12) → DENY audit must name A, not just ticket-service
Run the denial test
Log a refund only under the shared service account. An incident reviewer cannot identify the initiating agent; require signed agent/task context at the tool boundary.
Primary references