Because the token often carries far more privilege than the agent needs for one task. If the agent can act across the full breadth of the user’s access, a narrow automation step can become a broad authorization exposure. Scoping the agent to a specific resource subtree limits that mismatch.
Why flat roles fail when an agent is holding a user token
A flat role assumes the human user and the automation step are interchangeable. They are not. When an AI agent inherits a user access token, the effective authority is the full user role, not the narrower task the agent is actually performing. That mismatch is what turns routine delegation into broad exposure, especially when the token can reach unrelated resources.
Flat roles also hide the real trust boundary. The user may be allowed to browse, edit, and administer across a domain, but the agent may only need to read one record, update one object, or call one API. If the access token is not constrained to the resource subtree the task requires, the agent can legally act far beyond the intended action.
That is why task-scoped authorization matters more than role labels. In practice, the safer model is to separate task-scoped access from the user’s standing permissions, so the agent can complete one bounded operation without inheriting the user’s entire access surface.
How the mismatch becomes an authorization problem
The core issue is not that the token is valid, it is that validity alone says nothing about intent. A token issued for a user role usually represents a broad set of permissions, while an agent acts as a narrow, automatable principal. If the agent can reuse that token unchanged, authorization collapses from “can this step happen?” into “does the user broadly have access?”
That creates a classic over-delegation pattern. One prompt, tool call, or workflow step may only need access to a single mailbox, repository, tenant object, or subtree. Yet the token may also authorize writes, exports, administration, or cross-resource traversal. The practical result is that one successful agent action can expose more data or perform more change than the operator expected.
Well-designed agent authorization uses a narrower permit than the user’s general role and checks it at action time. The AI Agent Authorisation Guide is useful here because it frames the control problem as least privilege, delegated authority, and per-action policy rather than static role inheritance.
What actually reduces the blast radius
The safest boundary is not “the agent may use the user token,” but “the agent may use a token constrained to this resource set, for this action, for this time window.” Resource restriction matters because it prevents one successful token from being reused as a general-purpose credential. Time restriction matters because it limits replay and latent misuse. Action restriction matters because read access and write access are not equivalent.
That is why scoping to a specific resource subtree is such an effective control. It aligns the credential with the minimum object set needed for the job, which means the agent cannot wander into unrelated records even if it is otherwise acting correctly. This is especially important when the parent user role is naturally broad, such as in admin, support, or shared-service workflows.
For teams designing these flows, RFC 8707: Resource Indicators for OAuth 2.0 is directly relevant because it supports audience-restricted tokens, and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession helps prevent a stolen token from being replayed elsewhere.
Risk and Threat Considerations
Flat roles become dangerous because they let one compromised or over-permissioned token carry the user’s whole authority surface into an automated flow. The immediate risk is overreach, but the larger threat is abuse of trust: a benign-looking task can become a path to unauthorized reads, writes, exports, or privilege chaining.
Failure mechanism: the agent receives a token that is valid for the user, but not bounded to the specific resource, operation, or lifetime the task requires. Any mistake, prompt injection, or maliciously influenced tool call can then exercise permissions that were never intended for that automation step.
Impact: a single delegated action can become broad data exposure or unintended change, and incident response becomes harder because the activity appears to be performed under legitimate user authority rather than a clearly separate automation identity.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Flat roles let an agent reuse user authority too broadly. |
| Recommendation — Constrain agent privileges to the minimum action and resource scope required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle and scope control are central to limiting delegated access. |
| AC-6 — Least Privilege | The question is fundamentally about excess authority in delegated use. | |
| AC-3 — Access Enforcement | Resource subtree scoping is an access enforcement problem. | |
| Recommendation — Issue, bound, rotate, and revoke tokens so delegated access stays narrow. Limit each agent call to the least privilege needed for the task. Enforce resource- and action-specific checks instead of inheriting broad user access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Continuous verification and reduced standing access fit agent token delegation. |
| Recommendation — Verify each agent action explicitly and remove standing privilege wherever possible. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Agents using broad user tokens can cross function boundaries the task never needed. |
| Recommendation — Bind each agent operation to an explicit function-level authorization check. | ||
Practitioner Guidance
What to prioritise: treat the agent as a distinct decision point, not as a transparent extension of the user. The right question is not whether the user can do it, but whether this agent invocation needs the same breadth of access.
Decision rule: if the task can be completed against one object, subtree, tenant segment, or API scope, issue credentials that stop there. If you cannot express the task at that granularity, the workflow is probably too coarse to delegate safely.
What to verify: confirm that the token scope, resource audience, and expiry all match the exact operation the agent will perform, and that the token cannot be reused for adjacent resources simply because the user could access them.
Common mistake: assuming the user’s role is a safe proxy for the agent’s authority. In practice, that choice often turns a narrow automation use case into a broad authorization exposure.
Practitioner takeaway: Flat roles are risky because they erase the difference between user permission and task permission; safe agent design narrows both the resource set and the action set so one delegated step cannot become an unrestricted one.