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.
Why delegated permissions fit user-scoped AI agents
Microsoft 365 agents usually act as extensions of a person, not as independent tenant operators. delegated permissions preserve that boundary by constraining the agent to the signed-in user’s existing rights, so the agent can complete tasks without silently inheriting broader access than the user already has.
This matters because many assistant-style workflows are narrow, contextual, and reversible. If the agent only needs to read a mailbox, draft a response, or fetch a document the user could already reach, delegated permissions keep the authority model aligned with the real business task rather than the platform’s maximum technical capability.
That alignment is especially important when the agent is exposed to prompts, chat content, or external inputs. A user-scoped permission model reduces the chance that a compromised or tricked agent can act beyond the user’s normal reach, which is one reason practitioners should treat permission choice as part of the agent design, not just an admin setting.
Why application permissions create a different risk profile
Application permissions are granted to the app itself, so the agent can operate without a signed-in user and can potentially act across the tenant in ways that exceed a person’s ordinary task boundary. That is useful for background automation, but it is a very different trust model from a user-facing assistant.
For AI agents, the main concern is blast radius. If the agent, its token, or its control plane is abused, application permissions can turn a local productivity issue into broad data exposure or unintended action across many mailboxes, sites, files, or APIs. The problem is not only malicious abuse, but also overreach from a buggy workflow or an overly broad default consent.
Current guidance suggests reserving application permissions for cases where the workflow truly needs tenant-level autonomy, such as scheduled jobs, service integrations, or back-end orchestration that cannot be tied to a user session. If the task can be meaningfully expressed as “do what this user could do right now,” delegated permissions are usually the safer fit.
Choosing the right model in practice
The practical decision is to start from the action the agent must perform, then ask whether that action must survive outside a user session. If the answer is no, delegated permissions are the cleaner design because they preserve user context, limit privilege, and make authorization easier to reason about during review and incident response.
If the agent genuinely needs unattended access, separate that use case from interactive assistant behavior and treat it as a service automation problem. That usually means tighter scoping, explicit ownership, stronger monitoring, and a clear process for consent, review, and revocation because the security consequences are materially different from those of a person-assisted workflow.
When the permission model is unclear, test the smallest viable scope first. If delegated permissions can support the workflow, they give you a better default for least privilege, simpler user expectation, and less painful containment if the agent is abused or misconfigured. If they cannot, the need for application permissions should be obvious and documented, not assumed.
Risk and Threat Considerations
Application permissions expand the attack surface because a single compromised app identity can reach resources across the tenant. That increases the value of token theft, consent abuse, configuration mistakes, and malicious tool use, especially when an AI agent can chain actions quickly once it has broad access.
Failure mechanism: A user-facing agent is granted tenant-wide app rights when delegated rights would have been sufficient, so a prompt injection, token leak, or logic flaw can convert a narrow task into broad unauthorized access or action.
Impact: The result can be cross-tenant data exposure, overbroad mailbox or file access, unintended writes or deletions, and a much larger incident response scope than the business task justified.
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 Non-Human Identity 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 | Agent permissions and delegated authority are central to this question. |
| Recommendation — Restrict agent authority to the minimum user-scoped access needed for each action. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Application permissions for agents rely on service-to-service authentication and authorization. |
| AC-6 — Least Privilege | The core issue is choosing the smaller authority set for an AI agent. | |
| IA-5 — Authenticator Management | Token and credential handling matter when agents use delegated or application access. | |
| Recommendation — Authenticate service identities separately and bound their permissions tightly. Grant only the minimum permissions needed for the agent’s task. Manage agent credentials and tokens with rotation, protection, and revocation controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | An AI agent with app permissions can become overprivileged beyond its task. |
| Recommendation — Scope non-human access to the smallest feasible set of resources and actions. | ||
Practitioner Guidance
What to prioritise: Classify every Microsoft 365 agent by whether it is interactive and user-scoped, or autonomous and service-scoped. That classification should drive the permission model before implementation, because permission choice is one of the biggest determinants of blast radius.
What to verify: Confirm that the agent’s permission set matches the minimum resource set needed for the exact workflow, and verify whether the same result can be achieved without tenant-wide rights. If the answer is yes, delegated permissions are usually the better control boundary.
Decision rule: If the agent acts on behalf of a person in real time, use delegated permissions. If it must run without user presence and the business case truly requires tenant-level operation, then treat application permissions as an exception that needs stronger governance, logging, and revocation discipline.
Practitioner takeaway: For most Microsoft 365 assistants, the right question is not “can the app do more?”, but “should the agent be allowed to outlive or outrange the user’s own authority?”
Related resources from NHI Mgmt Group
- Guide: Entra ID Applications and Consent Guide
- How should security teams manage permissions for AI agents?
- What is Microsoft Agent 365 in AI agent governance?
- Why is defining permissions important for AI agents?
- Why do delegated AI agents create less risk when permissions are recalculated on refresh instead of being frozen at session start?
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 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org