User identity identifies whose intent the action represents, while actor identity identifies what actually executed the call. In delegated agent workflows, both are needed at once so downstream systems can enforce policy, preserve auditability, and avoid collapsing a human decision into an opaque machine action.
Why user identity and actor identity are not the same in delegated agent workflows
User identity is the accountable principal whose intent is being represented, while actor identity is the principal that actually performs the call. In agent delegation, those can be different on purpose, and the distinction is what lets a system preserve consent, enforce policy, and keep audit records truthful when automation executes a user-authorised action.
The difference matters because the downstream control decision should not be based on who clicked the button alone, nor on what runtime component happened to send the request. Delegated workflows need both identities so policy engines, logs, and reviewers can answer two separate questions: who authorised this, and what entity exercised the capability?
That separation is a practical extension of token exchange and on-behalf-of patterns such as RFC 8693: OAuth 2.0 Token Exchange, where one credential is transformed into another with explicit delegation context. It is also why agent identity models matter for workflows that move between human intent and runtime execution, as described in Agentic AI Identity Guide.
What each identity tells you about accountability, authorization, and audit
User identity answers the accountability question. It ties the action back to a human decision, business process, or approved workflow so reviewers can determine whether the request was legitimate, whether approval was in place, and whether the result should be attributed to the user’s intent rather than to automation.
Actor identity answers the execution question. It tells downstream systems which agent, service, or delegated principal actually used the API, which permissions were exercised, and which runtime environment produced the event. That is essential when multiple agents can act for the same user, or when one agent performs a call after another component enriched context, invoked tools, or exchanged tokens.
In practice, the actor identity is what makes least privilege and traceability enforceable at runtime, which is why guidance for AI Agent Authorisation Guide focuses on task-scoped access, per-action policy decisions, and human approval gates. Where teams treat user identity and actor identity as interchangeable, they usually lose one of two things: either the audit trail becomes misleading, or the runtime permissions become too broad to be safe.
How to model the boundary cleanly in delegated agent systems
The cleanest design is to keep intent, delegation, and execution separately represented. User identity should travel as the accountable source of intent, actor identity should travel as the executing principal, and the system should preserve the delegation chain so reviewers can reconstruct how the action moved from human request to machine execution.
That usually means logging both principals, retaining the delegation context, and making authorization decisions against the actor while preserving attribution to the user. When the same interface is used by both humans and agents, the policy layer needs to distinguish “who may request this action” from “which principal may execute it.” The distinction is a core theme in Top 10 Agentic AI Identity Issues, especially around overprivilege and shared credentials.
At scale, the practical test is whether you can answer a reviewer’s question without guesswork: did the user authorise this specific action, and did the actor have bounded authority to carry it out? If the answer requires inferring intent from logs or assuming the runtime principal was the same as the user, the model is too coarse for delegated execution.
Risk and Threat Considerations
The main risk is collapse of two different trust decisions into one. If user identity and actor identity are merged, an organisation can over-attribute actions to a human, over-trust an agent, or miss when a delegated principal used broader capability than the user actually intended.
Failure mechanism: A delegated workflow reuses a single identity for both consent and execution, or it omits the delegation chain from logs. That creates authorization drift, weak auditability, and a path for privilege abuse if the actor can do more than the user should have been able to trigger.
Impact: Security teams lose the ability to prove who authorised an action, incident responders lose execution provenance, and policy enforcement can no longer distinguish legitimate delegation from opaque machine activity. In abuse cases, a compromised agent or overprivileged runtime can make harmful actions appear user-driven.
Practitioner Guidance: Verify that your event records preserve both the initiating user and the executing actor, plus the delegation mechanism that connected them. If your logs cannot reconstruct the chain of authority, treat the workflow as non-auditable until that gap is fixed.
Practitioner takeaway: The right question is not “who did it?” but “who intended it, and who executed it under what authority?” If those answers are not separately recoverable, delegated control is already too ambiguous for safe operation.
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 and OWASP Non-Human Identity Top 10 address 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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service, Service Account, and Device Authenticators) | Covers authenticating the executing actor in delegated machine and agent workflows. |
| AU-2 — Event Logging | Supports preserving user intent, actor execution, and delegation context in audit records. | |
| AC-6 — Least Privilege | Applies because actor identity must be constrained to the minimum authority needed to execute delegated actions. | |
| Recommendation — Bind each actor to a distinct authenticator and enforce it at execution time. Log the initiating user, executing actor, and delegation path for each action. Limit actor permissions to the minimum authority required for the delegated task. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Directly addresses delegated agent misuse when execution identity and authority are overstated. |
| ASI09 — Human-Agent Trust Exploitation | Relevant because confusing user and actor identity can let agents abuse human trust and implied approval. | |
| Recommendation — Separate user intent from agent authority and restrict delegated privileges per action. Require explicit delegation evidence before treating an agent action as user-authorised. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Applies when the actor principal or its token exchange path is not strongly bound to the delegated workflow. |
| NHI-05 — Overprivileged NHI | Actor identity must not inherit more access than the delegated task requires. | |
| Recommendation — Use strong, sender-constrained authentication for the acting principal. Scope actor permissions to the minimum task-specific access. | ||
Related resources from NHI Mgmt Group
- What is the difference between agent identity and user delegation in API access?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between user identity and agent identity in enterprise AI workflows?
- What is the difference between an agent acting under a borrowed user session and an agent acting under its own identity?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org