Should organisations separate user-authorised scopes from app-level scopes for AI agents?

Why separating app-level and user-authorised scopes matters

App-level scopes and user-authorised scopes answer different questions, so they should not be collapsed into one permission model. The application’s grant describes what the agent can technically do, while the user’s consent describes what that person intended to delegate. Keeping them distinct prevents a broad integration permission from being treated as if it were personalised approval.

That separation becomes especially important when the agent can act across tools, tenants, or data sets. A scope that is acceptable for the app as a platform capability may still be too broad for a specific user request, and a user-approved action may need narrower bounds than the application’s default operating envelope.

In practice, this is the difference between platform authorisation and delegated authority. The first is about what the AI agent is allowed to use in general; the second is about what the user has authorised it to do on their behalf in a specific context.

How scope separation changes the control model

When organisations separate the two layers, they gain a clearer decision point at runtime. The app scope can establish the outer limit for the agent’s capabilities, but each user request still needs to be checked against the user’s intent, the task, and the data being touched. That makes it easier to apply least privilege without blocking legitimate automation.

This also improves revocation and review. If a user withdraws consent, you can revoke the delegated permission without redesigning the application grant. If the app itself is over-permissioned, you can shrink the platform scope without assuming every user approval must change. Those are different governance actions and should be managed separately.

For AI agents, this distinction is often the difference between safe delegation and hidden overreach. A clean design keeps consent, policy enforcement, and runtime action checks aligned so the agent cannot silently expand from one user’s permitted task into a broader platform entitlement.

Separating the layers also helps when you are integrating identity and access controls into an agent workflow. NHIMG’s AI Agent Authorisation Guide shows why per-action decisions and task-scoped access matter when an agent is acting under delegated authority.

Where organisations get this wrong

The common failure is to let the platform’s OAuth grant, service token, or integration permission stand in for user consent. That creates a false sense of precision, because the system can say “the app is authorised” even when the specific end-user action was never meant to be that broad. The reverse error is also dangerous: treating every user request as if it should inherit the full app capability set.

Another mistake is failing to preserve provenance between the two layers. If the system cannot show which actions came from app authority and which came from user delegation, it becomes hard to investigate misuse, explain access decisions, or prove that a sensitive action stayed within approved bounds.

That is why agent identity and authorisation need to be designed together. Agentic AI Identity Guide is useful here because it treats delegation, registration, authentication, and retirement as part of one lifecycle rather than as an afterthought.

For threat-driven readers, the pattern is also visible in consent abuse and token theft scenarios. CoPhish OAuth phishing via Copilot Studio illustrates how a platform permission can be abused if users and systems do not distinguish consent from application capability.

Risk and Threat Considerations

When app scopes and user-authorised scopes are merged conceptually, the main risk is over-privilege with a misleading consent trail. An attacker, or even an overbroad workflow, can exploit the gap between “the app may do this” and “this user intended this exact action.”

Failure mechanism: The application obtains a broad standing grant, then uses that grant to perform actions that exceed the user’s intended delegation because runtime checks do not preserve the distinction between platform permission and user consent.

Impact: The result can be unauthorised data access, excessive tool reach, weak auditability, and a larger blast radius if the agent or its token is compromised.

Practitioner Guidance

What to verify: Make sure your authorisation design can answer two separate questions for every sensitive action: “Is the app allowed to do this at all?” and “Did this user authorise this specific action?” If the answer is stored only once, you probably do not have a real separation.

Decision rule: If the app scope would still be acceptable after the user leaves, then it is a platform capability, not user consent. If the access should disappear with the user’s delegation, model it as user-authorised and enforce it at runtime.

Practitioner takeaway: The safest design is to treat app scopes as the ceiling and user-authorised scopes as the current permission boundary, because delegation can be narrower than capability and must remain independently visible.

Related resources from NHI Mgmt Group

• What is the difference between user-level and app-level integrations for AI agents?
• How should organizations approach the governance of AI agents?
• When should organisations use action-level approval instead of broad channel access for AI agents?
• Should organisations treat AI agents at checkout as a separate identity pattern?