Because the security decision is not just who the agent is, but who is driving it and what that user is allowed to do. User claims, roles and group memberships let the policy engine narrow access so the agent cannot exceed the current human or role boundary during the session.
Why user context changes the agent’s effective authority
Workload identity proves what the agent is, but it does not by itself answer a larger policy question: who is using it, on whose behalf, and with what current authority. If the agent only carries its own identity, policy tends to default to the agent’s standing capabilities. Adding user context lets the policy engine evaluate the human principal, not just the software principal, so the session stays bounded to the user’s live roles and group membership.
This matters most when the agent can trigger actions that would be safe for one user but not another. The same task may be legitimate for an analyst and inappropriate for a contractor, or allowed in a read-only workflow but blocked when it would expose data, move money, or change records. User context gives the policy decision enough signal to distinguish those cases without giving the agent broad, permanent authority.
When the user context is carried through the session, the agent can be treated as a constrained delegate rather than an independent actor with blanket access. That is the practical difference between “this agent may use the system” and “this agent may use the system only within the scope of this user right now.”
How policy narrows access at runtime
The useful pattern is to combine a stable workload identity with ephemeral user claims. The workload identity answers authentication and service trust, while the user claims supply the session-specific policy input that determines what the agent may request, invoke, or disclose. In practice, the authorization layer can compare the requested action against the user’s role, group, approval state, and any session constraints before issuing a decision.
That separation helps avoid a common failure mode: a well-identified agent that is still overpowered because it inherited a service token with more privilege than the user should have had. The policy engine should be able to downscope the agent’s effective permissions to the user’s current boundary, rather than letting the agent act at the maximum privilege of the underlying workload.
AI Agent Authorisation Guide is the most direct NHIMG reference for this pattern, because it focuses on task-scoped access, per-action decisions, delegated authority and human approval. For the identity mechanics behind the agent itself, the Agentic AI Identity Guide explains how agent identity, delegation and retirement fit together. For the underlying machine-to-machine foundation, Guide to SPIFFE and SPIRE covers workload identity, attestation and trust bundles.
What goes wrong when user context is missing
Without user context, the agent can become a privilege amplifier. It may still be authenticated as a valid workload, yet the policy layer has no way to tell whether the current human should be allowed to see a record, approve an action, or reach a downstream system. That creates overreach, especially where agents chain several low-risk tool calls into one high-impact action.
Missing user context also weakens auditability. If every decision is attributed only to the agent, teams lose the ability to explain whether an action came from the user’s authority, an inherited service entitlement, or an implicit default. For response and review, that distinction matters: it changes whether you investigate a user mistake, an authorization design flaw, or a compromised workload path.
The external references reinforce that split. SPIFFE workload identity specification describes the workload side of the trust model, while OpenID Connect Core 1.0 supplies the user identity layer that policy can consume when it needs session-aware claims. Used together, they help keep the agent’s technical identity distinct from the user authority it is allowed to represent.
Risk and Threat Considerations
When user context is absent or stale, an agent can act with more authority than the current human should have, especially in workflows that combine retrieval, tool use and write actions. The risk is not just unauthorized access, but unauthorized delegation, where a valid agent identity hides an access decision that should have been tied to the user session.
Failure mechanism: The policy engine evaluates only the agent’s workload identity, or it consumes user claims that are too coarse, expired, or detached from the current session. The result is excessive effective privilege, confused authorization, and a larger blast radius if the agent is prompted, misused, or compromised.
Impact: The agent may read data, invoke tools, or complete transactions that exceed the human’s real authority, creating disclosure, integrity, and non-repudiation problems. In a compromise, the attacker inherits a higher-value execution path because the policy boundary was anchored to the workload, not the user.
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, 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 |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent authority must be bounded by the driving user and session context. |
| Recommendation — Bind each agent action to the current user boundary and block privilege escalation across sessions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | The question depends on authenticating the user context alongside the workload identity. |
| AC-6 — Least Privilege | User context lets the policy engine reduce the agent's effective permissions to the minimum needed. | |
| IA-5 — Authenticator Management | Session-bound user context depends on managing credentials, claims and tokens that carry authority. | |
| Recommendation — Use user and workload authentication together so policy can distinguish the human principal from the agent. Constrain the agent to the minimum permissions justified by the current user session. Rotate and validate the credentials or tokens that convey user-scoped authority to the agent. | ||
| NIST Zero Trust (SP 800-207) | Policy Engine and Continuous Verification | Zero trust logic fits the need to verify the workload and current user context before each action. |
| Recommendation — Evaluate each agent request against fresh user context before granting access. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The answer relies on user claims, roles and session-bound identity assertions. |
| Recommendation — Use strong identity proofing and federation signals to ensure the user claims driving the agent are trustworthy. | ||
Practitioner Guidance
What to verify: Check that the authorization decision is session-aware and that the policy engine can evaluate the current user principal, role and group membership at the moment of action, not just at login. If the user context cannot be refreshed or asserted reliably, treat the session as higher risk and narrow the allowed tool set.
Decision rule: If the action would be safe only for a subset of users, require the agent to carry user context into the decision path and scope the grant to that user’s current boundary. If the action is safe for the workload regardless of who is driving it, user context can be lighter, but the default should still be least privilege.
Practitioner takeaway: The key design choice is to make the agent’s authority a function of both its workload identity and the current human session, so policy can prevent the agent from outgrowing the user who is driving it.