TL;DR: AI agents acting for a named user should use delegated Microsoft Graph permissions, not application permissions, because delegated access keeps the agent within the user’s own reach while lowering consent friction and avoiding tenant-wide privilege creep, according to Agentic Fabriq. That assumption fails when teams treat admin consent as an obstacle instead of a governance boundary.
At a glance
What this is: This article explains why AI agents that act for one identifiable Microsoft 365 user should request delegated Graph permissions, start with minimal scopes, and design for tenant-specific consent and admin review from day one.
Why it matters: It matters because identity teams have to govern agent access as a bounded user delegation problem, not a tenant-wide application grant, or they will turn routine onboarding into avoidable privilege expansion.
Context
Microsoft 365 agent integrations fail most often at consent, not at API mechanics. The governance problem is that an AI agent may be acting for one named user, but Microsoft Entra still requires tenant-specific approval, consent classification, and a precise separation between delegated access and tenant-wide application access.
In practical terms, the article is about how to keep a user-scoped AI agent inside the access boundary of the person it represents. That means designing for incremental consent, restricted user consent policies, and admin review as normal parts of the deployment model rather than exceptions.
Key questions
Q: What should teams do first when an AI agent needs Microsoft 365 access?
A: Start with delegated permissions, request only the minimum scopes needed for the first user journey, and assume some tenants will require admin approval. That approach keeps the agent bounded to the signed-in user and reduces the chance that the first release becomes a tenant-wide access review rather than a routine consent event.
Q: Why do AI agents need delegated permissions instead of application permissions in Microsoft 365?
A: Because delegated permissions cap the agent at what the signed-in user can already do, while application permissions can open tenant-wide access that is far broader than a person-scoped task requires. For most user-facing assistants, the security model should follow the user, not the tenant.
Q: What happens when Microsoft Entra consent fails during an AI agent onboarding flow?
A: The connection may be blocked by missing consent, a redirect URI mismatch, or a tenant policy that does not allow the requested scope. Teams should treat those errors as expected states, explain the reason in plain language, and route the user toward the right approval path instead of retrying the same request.
Q: How should teams handle scope expansion after an AI agent is already connected?
A: Use incremental consent so the agent starts with basic sign-in and gains additional permissions only when the user activates a new feature. That reduces upfront friction, keeps the grant aligned to actual use, and makes later review easier for tenant administrators.
Technical breakdown
Delegated permissions versus application permissions
Delegated permissions let the application act on behalf of a signed-in user, so the effective access is the intersection of the grant and that user’s own permissions. Application permissions operate without a signed-in user and can reach tenant-wide data tied to the scope, which changes the risk model completely. For an agent that performs one person’s work, delegated access preserves user boundedness while application access removes it. That distinction is not cosmetic. It determines whether the security team is approving a person-scoped assistant or a broad administrative capability. See the AI Agent Authorisation Guide.
Practical implication: Use delegated permissions whenever a human is present in the flow and reserve application permissions for genuinely tenant-scoped workloads.
Consent flows, error codes, and tenant review
Microsoft Entra surfaces consent as a governance state, not just an OAuth transaction. AADSTS65001 signals that the user or administrator has not consented, while AADSTS90094 indicates admin consent is required, and AADSTS50011 points to redirect URI mismatch. These failures often look like product bugs to users, but they are usually policy outcomes. The operational lesson is that the onboarding path must anticipate a tenant reviewer, a missing delegation record, and the possibility that the tenant blocks user consent for anything beyond low-impact scopes.
Practical implication: Treat consent errors as expected states and build explicit admin-approval and scope-missing screens into the product.
Incremental consent and scope minimisation
The article’s strongest design pattern is to request only the scopes needed at each step, then add more later when the user activates the related feature. That matters because a scope like Mail.Send is materially different from Mail.ReadWrite, and Sites.Selected is very different from Sites.ReadWrite.All. Incremental consent reduces the size of the first decision, while scope minimisation keeps the eventual grant aligned to the actual workflow. This is especially important in multi-tenant SaaS, where each tenant may evaluate low-impact permissions differently and may never accept a wide initial ask.
Practical implication: Start with the smallest workable scope set and expand only when feature use justifies the added access.
Threat narrative
Attacker objective: The attacker objective is to turn a user-scoped connection into broad Microsoft 365 access that survives tenant oversight and exceeds the intended delegation boundary.
- Entry occurs when a user starts the connect flow and the application requests Microsoft 365 access on their behalf.
- Credential access occurs only after consent is granted and the app receives delegated tokens tied to the user and tenant.
- Escalation happens if the product switches from delegated scopes to application permissions, expanding from one person’s access to tenant-wide reach.
- Impact follows when overbroad consent or a mis-scoped grant allows the agent to read, send, or file far more data than the user intended.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Delegated consent is the correct baseline for AI agents that act for one person. The article is right to treat the signed-in user as the boundary condition, because delegated permissions keep the agent inside the user’s existing authority instead of turning the assistant into a tenant-wide principal. That is the only model that preserves proportionality between task and privilege. The practitioner takeaway is simple: if a named user is present at call time, the grant should be person-scoped first and tenant-scoped only when the workflow truly requires it.
Consent friction is a governance signal, not a product defect. A tenant admin who refuses an overbroad ask is functioning as a control, not blocking innovation. That matters because many AI agent programmes still assume access will be approved if the feature is useful. The better design assumption is the opposite: the product should remain usable when the answer is no, and should degrade cleanly until delegated or incremental consent is granted.
Least privilege fails when teams confuse capability with entitlement. The article’s comparison between Mail.Send, Mail.ReadWrite, and Files.ReadWrite is a useful reminder that a feature request is not a privilege request. In NHI governance, the scope should map to the specific action, not the convenience of the implementation path. Practitioners should judge every requested permission by the data it truly needs, not by the fastest way to make the demo work.
Admin consent workflows are part of agent identity design, not an afterthought. The repeated AADSTS50011 and AADSTS65001 cases show that onboarding, approval, and retry behavior belong in the core control plane. If a product cannot explain why it needs a scope, route the request to the right reviewer, and handle a denied grant without breaking the workflow, then its identity model is incomplete. The implication is that identity architecture must include consent UX, not just token handling.
From our research library:
- According to PwC, 79% of organizations have already adopted AI agents to some degree.
- Read next: Zero Trust for AI Agents
What this signals
Identity review has to move to issuance time for AI agents. Access review cadences assume a privilege persists long enough to be certified, but a delegated agent can gain, use, and relinquish access inside one task boundary. That means the control question shifts from who still has access to who should be allowed to request it in the first place.
Over-scoping is the real control failure in Microsoft 365 agent design. When 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, the governance issue is not novelty, it is privilege inflation according to the 2026 Infrastructure Identity Survey. Teams should expect tenant admins to reject wide initial asks and design the product around that reality.
Scope choice now determines incident probability. Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey. The practical signal is that delegated Microsoft Graph design is not only easier to approve, it is materially less likely to produce downstream security incidents.
For practitioners
- Implement delegated permissions first Use delegated Graph permissions whenever the agent is acting for one signed-in user, and avoid application permissions unless the workflow is genuinely tenant-wide.
- Start with the smallest viable scope set Request only basic sign-in scopes on first connect, then add Mail.Send, Calendars.ReadWrite, or Sites.Selected later through incremental consent when the feature is actually used.
- Build explicit consent-state screens Create separate flows for consent needed, admin approval pending, and connected but scope-missing so users and reviewers can see what failed and why.
- Register for multi-tenant operation up front Set the app for accounts in any organizational directory, use the /organizations authority, and wire the admin consent endpoint before your first customer asks for it.
- Keep tenant grants separate from user connections Store consent per user per tenant so an admin’s approval does not get mistaken for an individual user’s ongoing connection.
Key takeaways
- AI agents that act for one identifiable Microsoft 365 user should stay inside delegated permissions, because that keeps privilege tied to the person rather than the tenant.
- The article’s core governance message is that consent friction is expected and should be designed into onboarding, not handled as an exception after launch.
- Teams that minimise scopes and separate user connection state from tenant approval state are better positioned to avoid overbroad access and repeated onboarding failures.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on Microsoft Entra consent and delegated sign-in for AI agents. |
| NHI-05 — Overprivileged NHI | The main risk is an AI agent requesting more Microsoft 365 access than the task needs. | |
| NHI-10 — Human Use of NHI | The agent is acting on behalf of a human user and must stay inside that user's authority boundary. | |
| Recommendation — Use delegated, user-scoped authentication flows and reject broad app-only access for person-bound agent tasks. Minimise scopes and avoid converting person-scoped workflows into tenant-wide grants. Tie each agent grant to a named user and review whether the permission could be reduced to delegated access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about granting the right permissions to the right identity at the right scope. |
| Recommendation — Map each agent capability to the minimum entitlement needed and verify tenant policy before granting it. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Consent abuse and token harvesting are the likely abuse paths discussed around delegated Microsoft 365 access. |
| Recommendation — Monitor consent events and token issuance for signs of unauthorized access expansion. | ||
Key terms
- Delegated permissions: Delegated permissions are access rights granted through another identity, application, or administrative relationship rather than directly to the end user. They matter because revoking the visible account does not always remove the underlying authority, which can preserve access after offboarding.
- Application Permission: An application permission is an access grant that lets an app act without a signed-in user present. In practice, it can be far more powerful than delegated access because the permission persists independently of a human session and can be abused if the app is over-consented or orphaned.
- Incremental Consent: A consent pattern where an application starts with a minimal permission set and asks for additional scopes only when the user reaches a feature that needs them. For identity programmes, it reduces initial friction and makes privilege growth visible and reviewable over time.
- Admin Consent: Admin consent is the approval step that authorizes an application to access tenant resources under defined permissions. It is a governance control, not just a technical setting, because it determines what the app can do and for whom. Weak consent handling can turn a harmless integration into a persistent access path.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org