The Signal

It’s common practice for automation to run under a single shared service identity: one account, broad permissions, used by every script and job that needs to touch infrastructure. That pattern works when automation executes fixed instructions. It breaks down once automation starts making decisions, because the question “who is responsible for this action” no longer has a clean answer — only “the automation account did it.”

The Problem

Autonomous systems act on behalf of specific people, for specific reasons, in specific sessions. If the infrastructure can’t preserve that context as the request moves through the system, attribution collapses at exactly the point where it matters most.

Brian
  ↓
Agent
  ↓
Tool
  ↓
Infrastructure

Each arrow in that chain is a place where identity can be preserved — or lost. Losing it at any step means the infrastructure at the bottom of the chain can no longer answer who, ultimately, asked for this.

The System Question

Preserving identity through an execution chain raises concrete engineering questions:

  • Delegation — how is “acting on behalf of” represented, and can it be verified rather than just asserted?
  • Impersonation risk — what prevents a compromised or misconfigured step in the chain from acting as someone it shouldn’t?
  • Authorization context — does each step know not just who the original requester was, but what they were authorized to ask for?
  • Attribution — can any action be traced back to the person who ultimately caused it, not just the service that executed it?
  • Audit trails — is the chain of delegation itself recorded, or only the final action?
  • Shared automation identities — where they still exist, what is the plan for replacing them?

The Tradeoffs

Preserving identity through every layer costs engineering effort at every layer — each system in the chain has to be built, or retrofitted, to carry and verify that context instead of treating the previous step’s request as sufficient authorization on its own. Shared identities are simpler to build and simpler to break.

Business Impact

Enterprises cannot meaningfully govern autonomous systems if every action eventually becomes “the automation account did it.”

Preserving identity through the execution chain makes automation compatible with existing concepts of accountability.

What We’re Watching

Incident postmortems are the clearest signal here. When an automated action causes a problem and the root-cause investigation can only get as far as “the service account,” that’s a sign the identity chain was broken somewhere upstream — and a sign the organization will hit the same wall again.