When AI actions are only attributed to a generic service account, teams lose accountability, investigation speed, and compliance quality. Security staff cannot reliably answer who approved the action, what tool was used, or why the change happened. Identity propagation preserves the human context behind each agent action, which is essential for audit trails and incident review.
Why the Human Requester Must Stay in the Audit Trail
When an AI agent can act without preserving the initiating human context, the organisation loses more than convenience. It loses the ability to explain who requested the action, whether the action was expected, and whether the agent was operating within its intended authority. That gap affects accountability, incident review, and the quality of every downstream control decision.
The issue is not simply that a service account exists. The problem is that the action becomes detached from the decision that triggered it, which makes the event harder to interpret after the fact. For security teams, that means weaker forensic value, slower triage, and a reduced ability to distinguish legitimate automation from misuse.
What Breaks When Attribution Collapses
Once request context is lost, several controls become less reliable. Audit logs may still show that an agent performed the action, but they no longer show the approval chain, the business reason, or the person who should answer for the outcome. That weakens change traceability, complicates exception handling, and makes compliance evidence less persuasive.
This also changes how investigators work. If the agent touched a production system, accessed a sensitive tool, or issued a destructive command, teams need to know whether the action flowed from an authorised human request or from a compromised workflow, prompt injection, or overbroad delegation. Without that linkage, the investigation starts with ambiguity instead of evidence.
Identity propagation preserves the chain of responsibility across the full action path. In practice, that means the agent should carry enough context to connect execution back to the requester, the intended scope, and the tool or system used, without collapsing everything into one opaque machine principal. Ultimate Guide to NHIs — What are Non-Human Identities is useful background on the wider identity and governance problem, while Touchpoints Between AI and Non-Human Identities helps frame where AI agent authority and identity propagation intersect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Requester attribution supports governance over accountable automation decisions. |
| PR.AA-01 — Identity Management, Authentication, and Access Control | Human-requester linkage affects how agent actions are authenticated and authorized. | |
| DE.AE-02 — Anomalous Activity Detected | Detached agent actions are harder to distinguish from misuse or compromise. | |
| Recommendation — Define ownership and accountability for agent actions and preserve human decision context in logs. Bind agent execution to the initiating human identity and approval context. Correlate agent activity with requester context to spot anomalous or unauthorized actions. | ||
| CIS Controls v8 | 5 — Account Management | Shared machine execution without requester context weakens accountable account use. |
| 6 — Access Control Management | The question centers on preserving who was allowed to trigger a privileged action. | |
| 8 — Audit Log Management | Audit trails lose investigative value when actions cannot be tied back to a requester. | |
| Recommendation — Require unique, traceable account context for agent-driven actions. Enforce least-privilege authorization for agent actions and preserve the initiating user context. Log the initiating human identity, action, and target in a tamper-resistant audit trail. | ||
| NIST Zero Trust (SP 800-207) | 3 — Continuous Diagnostics and Mitigation | Continuous verification depends on preserving the context behind each privileged action. |
| Recommendation — Continuously verify each agent action against the initiating user and policy context. | ||
| NIST SP 800-63 | 5.2 — Assertion Requirements | Attributed assertions are needed when identity context must survive delegation. |
| Recommendation — Carry authenticated identity assertions through delegated agent workflows. | ||
Practitioner Guidance
What to verify: Before trusting an agent workflow, verify that each meaningful action can be linked back to a specific human request, approval path, and execution context. If the only durable record is a shared service account, treat the workflow as operationally fragile even if it is technically functional.
Decision rule: If the action can change state, expose data, or invoke another privileged tool, preserve requester attribution as part of the design requirement, not as an optional logging enhancement. If you cannot answer who initiated it and why, the control is incomplete.
Common mistake: Teams often optimise for agent throughput and assume generic system logging is sufficient. That is enough for activity volume, but not for accountability, approval reconstruction, or defensible incident review.
Practitioner takeaway: The goal is not to make every agent action look human, it is to keep the human decision visible enough that authority, intent, and responsibility survive the automation layer.
