Teams should preserve both the workload identity of the agent and the authorization context of the user who initiated the work. That lets downstream services make correct decisions without flattening the chain of authority into one shared credential. If either side is missing, the organisation loses either attribution or permission fidelity.
Why preserving both identities matters when one actor is acting on behalf of another
Accountability breaks the moment a downstream service can no longer tell which entity is doing the work and under whose authority it is operating. For agentic workflows, the right pattern is to keep the agent as the executable subject and the initiating user as the authority source, so decisions, audit trails and policy checks remain precise instead of collapsing into a shared account.
This matters because responsibility, permission checks and incident review depend on different questions. The system needs to know what the agent is allowed to do, but it also needs to preserve who requested the action so that approvals, attribution and later challenge or review remain meaningful.
When teams treat “the agent” as the only identity, they often lose the ability to distinguish delegated action from independent action. That is where Agentic AI Identity Guide becomes useful, because it frames identity, delegation, registration and retirement as a lifecycle problem rather than a one-time login problem.
Where attribution fails in practice
Attribution usually fails in one of two ways. Either the agent acts through a shared credential and every request looks the same, or the user context is stripped away and the system can no longer tell whether the action was approved, proxied or merely initiated. In both cases, the organisation loses a critical link in the chain of authority.
The most common failure mode is convenience pressure. Teams give agents broad standing access because it is easier than designing per-action authorisation, then discover too late that logs only show the shared principal. Another failure mode is over-normalising delegation, where the user context is carried in prose or metadata but not in enforceable policy.
That is why AI Agent Authorisation Guide is relevant here, because it focuses on task-scoped and just-in-time access with per-action policy decisions, which is exactly what prevents authority from being flattened into a single reusable credential.
For systems that need a clearer operating model across autonomy levels, AI Agents vs Agentic AI helps teams separate simple automation from workflows where identity, access and risk need explicit handling.
How to design the chain of authority so services can trust it
The practical goal is not to make the agent “become” the user. It is to preserve two linked truths at once: the agent has its own workload identity, and the user supplied the authorisation context that bounded the action. Downstream services should receive enough evidence to evaluate both without having to infer intent from a shared token.
- Use the agent identity for authentication, logging and workload-to-service trust.
- Carry the user context as an explicit delegated authority signal, not as an informal label.
- Apply per-action decisions so the permission set is narrow, current and revocable.
- Retain an audit trail that can answer both “what executed” and “who authorised the execution”.
When this is done well, the chain remains reviewable even if the agent performs multiple steps across systems. The most durable design is one where a service can reject an action because the agent lacks permission, while still preserving the original initiator for accountability and investigation.
For broader governance and operational controls around this pattern, the Agentic AI Security Guide provides a layered view of identity, tools, orchestration and blast radius, while AI Agent Observability, Audit and Incident Response Guide shows how to attribute actions and investigate when the chain goes wrong.
Risk and Threat Considerations
When accountability is flattened, the organisation creates a high-value ambiguity zone for abuse, error and post-incident denial. If the agent can act through shared or overly broad credentials, attackers and careless operators both benefit from the same loss of attribution and permission fidelity.
Failure mechanism: Shared credentials, missing delegation context or weak per-action authorisation cause the system to treat multiple principals as one, which breaks auditability, complicates revocation and can hide unauthorised actions inside apparently legitimate agent activity.
Impact: Teams may be unable to prove who initiated an action, who approved it, or whether a downstream service made a correct authorisation decision, which raises fraud, compliance and incident response risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-on-behalf workflows depend on preserving delegated authority and avoiding privilege flattening. |
| ASI02 — Tool Misuse | Agents acting for users can misuse tools if execution is not tightly scoped and attributable. | |
| Recommendation — Enforce per-action authorization and preserve delegating-user context for every agent action. Scope tool access to the minimum action set and log the user context behind each invocation. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent workloads need distinct machine-to-service identity so downstream services can trust the executor. |
| AC-6 — Least Privilege | Preserving user authority while limiting agent capability requires least-privilege enforcement. | |
| AU-2 — Audit Events | Accountability depends on audit records that capture both the actor and the initiating authority. | |
| Recommendation — Authenticate the agent as a distinct service and bind requests to that workload identity. Restrict agent permissions to the smallest set needed for the delegated task. Log both the agent execution identity and the initiating user context for each sensitive action. | ||
Practitioner Guidance
What to verify: Confirm that every agent action can be traced to both a workload identity and a preserved user-authorisation context. If your logs can only show one of those, accountability is already degraded.
Decision rule: If an action can change data, state, money movement, access or customer-facing outcomes, do not rely on shared credentials or implicit delegation. Require an enforceable per-action decision point before execution.
What good looks like: A reviewer should be able to reconstruct the initiating user, the acting agent, the policy decision and the exact action taken without guessing from surrounding context.
Practitioner takeaway: Preserve both the actor and the authoriser, because accountability fails as soon as the system can no longer distinguish delegated execution from independent authority.