Because downstream services need to know who the agent is, who delegated the action, and what scope was approved. Without both pieces of context, policy enforcement falls back to coarse perimeter checks or static grants, and the system cannot distinguish legitimate delegated action from overreach.
Why autonomous agents need both an agent identity and user context
An autonomous agent is not acting as a generic API client. It is operating with delegated authority, so downstream services need two facts at once: which agent is calling, and which user approved the action. That separation is what allows policy engines, audit logs, and runtime enforcement to distinguish legitimate delegation from overbroad execution.
What each token claim contributes to access decisions
Agent identity tells the service the technical actor, its registration, and its standing privileges. User context tells the service whose intent, approval, or workflow scope is being exercised. When those are combined, the service can apply different rules for the agent's own capabilities, the user's entitlements, and the exact action being attempted.
This is especially important when the agent can chain tool calls or move across systems. The token must support decisions such as whether the agent may act only for one user, whether the request is allowed in the current workspace or tenant, and whether the action exceeds the delegated scope even if the agent itself is authenticated.
Why context separation prevents overreach
Without user context, policy often collapses into a single machine-to-machine grant, which is too coarse for delegated automation. Without agent identity, the platform may know a user approved something but not which autonomous actor is actually executing the request, making accountability and containment much weaker.
That gap matters because the same agent can be reused across many sessions, users, or integrations. If the token does not bind the agent to a specific delegation context, a valid credential can outlive the approval that justified it, and the service has no clean way to tell whether the current action still matches the original intent.
In practice, the most useful design is to treat the agent as the executor and the user as the authorizer. The token should carry enough structure for resource servers to make an allow or deny decision without guessing from network location, static role membership, or a shared service account.
Risk and Threat Considerations
When agent identity and user context are collapsed, delegation becomes hard to verify and easy to overextend. That creates exposure to confused-deputy behaviour, privilege spillover, and audit ambiguity, especially when the same agent can act for multiple users or invoke sensitive tools.
Failure mechanism: The service sees a valid token but cannot tell whether the current operation is within the approved delegation boundary, so it falls back to broad trust in the agent credential or coarse perimeter logic.
Impact: An attacker who steals or abuses the token can potentially replay legitimate authority, expand the blast radius of a single approval, or make harmful actions look authorized after the fact.
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 API Security 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 |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Autonomous agents need bounded identity and delegated scope. |
| Recommendation — Bind agent identity to user-approved scope and enforce least privilege at runtime. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Token context must prove both the agent and the delegated user for access decisions. |
| Recommendation — Require audience-bound tokens and reject requests lacking delegated context. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents and downstream services need mutual, attributable authentication. |
| AC-6 — Least Privilege | Delegated agent actions should be limited to approved scope and task. | |
| AU-2 — Event Logging | Audit trails must preserve who the agent is and whose action was delegated. | |
| Recommendation — Authenticate services and agents with credentials that support delegation-aware authorization. Limit each agent to the minimum permissions needed for the approved user action. Log both agent identity and delegated user context for every material action. | ||
Practitioner Guidance
What to verify: Check that the token separates the actor claim from the delegated subject or user claim, and that downstream authorization rules consume both rather than inferring one from the other. If a control decision cannot be explained from token contents alone, it is probably too weak for autonomous execution.
Decision rule: If the agent may perform privileged, cross-system, or long-running actions, require explicit delegation context and audience restriction; if the action is low impact and tightly scoped, a simpler token may be acceptable but should still remain attributable.
Common mistake: Treating the agent as if it were either a pure human proxy or a normal backend service. That shortcut usually produces tokens that are authentic but not meaningfully bounded.
Practitioner takeaway: The goal is not just to authenticate the agent, but to preserve who it is acting as, under what approval, and within what exact scope so authorization can remain precise as autonomy increases.
Related resources from NHI Mgmt Group
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 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org