Acting as an agent means the gateway treats the AI system as the operative identity for the request. On behalf of a user preserves the upstream user token, so the resulting action remains tied to the human context. That distinction matters when the same gateway must handle shared automation and user-scoped data access.
Why the distinction matters in practice
Acting as an agent and acting on behalf of a user are not just wording choices, because they change which identity is operationally authoritative. In an agent-mode flow, the system may evaluate policy, logging, consent, and downstream access as the agent’s own action. In an on-behalf-of flow, the human context remains part of the access decision and audit trail.
That difference becomes important when the same gateway supports both autonomous automation and user-scoped requests, because a single misclassification can change what data is reachable, what is logged, and which approvals are required. It is also why delegation standards such as RFC 8693: OAuth 2.0 Token Exchange matter here: they formalise when a system should carry forward user context versus when it should operate under a separate actor claim.
How the gateway should decide between agent identity and user context
The right choice depends on what the action is supposed to represent. If the gateway is performing a task that should be attributable to the software system itself, the agent identity should be the operative subject. If the action is a user-directed request, the gateway should preserve the upstream user token or an equivalent delegated assertion so the access decision still reflects the human principal.
That decision should be made at the boundary, not later in the workflow. Once the wrong principal is substituted, downstream services may authorize the request, expose data, or create side effects under the wrong trust assumption. For that reason, a guide such as Agentic AI Identity Guide is useful because it frames delegation, registration, authentication, and retirement as part of the identity model rather than as an implementation detail.
In environments where humans and automation share one platform, the operational question is not whether the system can act, but under whose authority it should act at that moment. The distinction is especially visible when a gateway supports token exchange, consent propagation, or sponsor-style administration, because those mechanisms are designed to preserve the difference between a delegated human request and a standalone machine action.
What breaks when the model is blurred
When agent and user contexts are mixed, the usual failure mode is confused deputy behaviour. The gateway or downstream service may receive a valid request, but the authority attached to that request no longer matches the intent that created it. That can produce overbroad access, incorrect consent handling, weak auditability, and difficult-to-explain incidents where a user appears responsible for automation they did not intend.
The risk is not limited to data exposure. A system that treats every request as user-scoped can accidentally let automation inherit human privilege, while a system that treats every request as agent-scoped can strip away legitimate user context and break approvals, entitlements, and audit evidence. The practical control point is to keep delegation explicit and narrow, which is the same issue highlighted by Confused Deputy in AI Agents Guide.
Where the control boundary is weak, the result is often privilege inflation rather than outright compromise. The gateway may not be “hacked” in the classic sense, but it can still become a proxy that performs actions with more authority than either the user or the agent should have individually.
Risk and Threat Considerations
Blurring agent identity and user identity creates a trust-boundary problem. Attackers and misconfigurations both benefit from that ambiguity, because a delegated flow can inherit permissions, audience scope, or consent in ways the operator did not intend. The main exposure is not only unauthorized access, but also incorrect attribution, overbroad tool use, and hidden lateral movement through shared automation paths.
Failure mechanism: The gateway or broker accepts a request without preserving the correct principal, so downstream systems authorize it under the wrong identity, wrong audience, or wrong delegation semantics.
Impact: Access decisions, audit logs, and consent records become unreliable, which can lead to data exposure, excessive privilege, and harder compromise investigation across both user-scoped and automated flows.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent vs user context determines whose authority is exercised. |
| Recommendation — Preserve the correct principal so tool and data access stay aligned with the intended actor. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Device Accounts) | The gateway may authenticate a non-human actor when acting as an agent. |
| IA-5 — Authenticator Management | On-behalf-of flows depend on safe handling of tokens and delegation material. | |
| Recommendation — Use service-account controls to separate autonomous agent authentication from user authentication. Manage delegated credentials so user-context tokens are issued, handled, and retired safely. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Delegated identity and token handling depend on identity assurance and federation semantics. |
| Recommendation — Apply digital identity guidance to keep delegated authentication and token exchange consistent. | ||
| MITRE ATT&CK | T1134 — Access Token Manipulation | Token substitution or misuse can change whether a request acts as user or agent. |
| Recommendation — Detect token manipulation that changes the effective principal or delegation scope. | ||
Practitioner Guidance
What to verify: Confirm that the gateway has a deterministic rule for when it issues a separate agent context and when it preserves user context. If the same endpoint serves both, the rule should be observable in logs and testable in pre-production.
Decision rule: If the action must be explainable as a user request, keep the user token or delegated assertion in the chain. If the action must be explainable as autonomous system behaviour, do not disguise it as user action to “make authorization easier.”
What good looks like: Operators can tell from the token lineage, audit trail, and approval record whether the request was executed as an agent action, a delegated user action, or a mixed flow with explicit delegation.
Practitioner takeaway: The key control is not choosing one identity model forever, it is making delegation explicit enough that authorization, logging, and accountability stay aligned with the real actor for each request.
Related resources from NHI Mgmt Group
- Who is accountable when an AI agent runs a query on behalf of a user?
- Who should own authorization when an AI agent queries internal data on behalf of a user?
- Why do agent user and on-behalf-of flows complicate IAM reviews?
- How do organisations decide whether an agent session is acting as a user or as an app?
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 November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org