Opsin raises $21M to secure the agentic enterprise.
Hear from our founders →
Microsoft Graph gives AI agents access to company data, but not every agent uses the same identity. Copilot works within what the signed-in user can view, so content from a SharePoint site opened to the whole company years ago can surface in a response. App-registered agents can work differently. Granted the Files.Read.All application permission, an agent can read files across SharePoint and OneDrive with no user present.
Microsoft Entra Agent ID adds another layer, since agent identities can receive permissions directly or inherit eligible grants from a blueprint. The same permission name therefore carries different reach, and delegated Files.Read.All stops at the files the signed-in user can open.
Microsoft Graph permissions are the privileges an app must be granted before the Microsoft identity platform authorizes it to access data through Microsoft Graph. Each permission controls access to a specific resource type, such as users, groups, files, or mail, and defines which operations the app can perform. Microsoft Entra role-based access control (RBAC) can also grant access, so Graph permissions are not always the only factor in what an app or agent can reach.
Microsoft Graph supports delegated and app-only access. The permission type determines whether an agent acts within a user’s access rights or independently.
Delegated permissions, also called scopes, let an app act on behalf of a signed-in user. Effective access is the overlap between the app’s granted permissions and the user’s rights. Delegated Mail.Read, for example, allows reading the signed-in user’s mailbox. Users can consent to permissions that don’t require admin consent, subject to tenant policies. All others need administrator approval.
Application permissions, also called app roles, let an app access Microsoft Graph without a signed-in user. Access follows the permission’s scope rather than a user’s rights. Application Mail.Read, for example, allows reading all organizational mailboxes by default. These permissions require admin consent. For Microsoft Graph application permissions, granting that consent requires at least the Privileged Role Administrator role, or a custom directory role with permission to grant permissions to applications.
The right type depends on whether a user is present when the agent runs.
In either case, grant only what the task requires, following the least privilege principle in NIST SP 800-53.
An agent’s identity and authentication setup determine whose access it uses and where to look for permission grants. Check these 4 aspects.
Permission risk grows as agents multiply, their tasks change, and unused access goes unreviewed. OWASP lists excessive permissions as a root cause of excessive agency in LLM applications.
Some Graph permissions reach far beyond what most agents need, especially as application permissions. Most carry the .All constraint, though application mail permissions can cover every mailbox by default even without it.
These options depend on the agent’s task, and they only reduce access once the broader grant is removed.
An audit has to cover every identity type, including grants that never appear on the agent itself. Work through it in 3 stages.
Start with a full inventory of agents and the grants attached to them.
With the inventory in hand, measure each agent’s reach against what it does.
Fix what the assessment surfaces, prioritizing unnecessary access to sensitive resources or privileged actions.
Most Graph authorization failures return a 403, though token, consent, and Conditional Access problems can surface as 401, 400, or Entra AADSTS codes. Check the response body and whether the failure occurred during token acquisition or the Graph request, since the status code alone doesn’t identify the cause.
Manual audits capture permissions at a single point in time, whereas agents and their access keep changing. Opsin Security brings each connected agent’s identity, permissions, data access, and original purpose into one continuously updated view.
An agent can stay within its Microsoft Graph permissions and still reach data its task never required. For every agent, security teams should be able to explain whose identity it uses, what access it has, and why that access is necessary. That includes inherited blueprint grants and maker-provided connections that a permission list alone can miss.
Opsin connects identity, access, purpose, and behavior to help teams prioritize those reviews as agents change. The goal is to give agents enough access to do their jobs and to catch the point where that access stops serving their purpose.
Yes, an AI agent using application permissions can access Microsoft 365 resources beyond an individual user's rights, depending on its granted permissions and resource-level restrictions.
For additional guidance on preventing unintended data exposure, explore Microsoft Copilot security.
No, administrator consent authorizes requested permissions but does not guarantee that those permissions are necessary, appropriately scoped, or safe over time.
Learn how to establish ongoing oversight through AI governance.
Security teams can identify inherited access by correlating agent identities with their blueprint principals, eligible permission grants, and inheritance configurations.
Explore how agent identity security helps organizations understand agent ownership, permissions, and exposure.
Organizations can reduce permission drift by continuously comparing each agent's effective access against its approved purpose and expected operations.
See how an actionable agent governance framework can support consistent controls across growing agent deployments.
Opsin helps teams prioritize agent risk by connecting permissions with agent identity, intended purpose, sensitive data exposure, and observed behavior rather than treating every broad permission as equally dangerous.
Discover how the Opsin platform brings together the context needed to assess and prioritize enterprise AI risks.
Microsoft Graph gives AI agents access to company data, but not every agent uses the same identity. Copilot works within what the signed-in user can view, so content from a SharePoint site opened to the whole company years ago can surface in a response. App-registered agents can work differently. Granted the Files.Read.All application permission, an agent can read files across SharePoint and OneDrive with no user present.
Microsoft Entra Agent ID adds another layer, since agent identities can receive permissions directly or inherit eligible grants from a blueprint. The same permission name therefore carries different reach, and delegated Files.Read.All stops at the files the signed-in user can open.
Microsoft Graph permissions are the privileges an app must be granted before the Microsoft identity platform authorizes it to access data through Microsoft Graph. Each permission controls access to a specific resource type, such as users, groups, files, or mail, and defines which operations the app can perform. Microsoft Entra role-based access control (RBAC) can also grant access, so Graph permissions are not always the only factor in what an app or agent can reach.
Microsoft Graph supports delegated and app-only access. The permission type determines whether an agent acts within a user’s access rights or independently.
Delegated permissions, also called scopes, let an app act on behalf of a signed-in user. Effective access is the overlap between the app’s granted permissions and the user’s rights. Delegated Mail.Read, for example, allows reading the signed-in user’s mailbox. Users can consent to permissions that don’t require admin consent, subject to tenant policies. All others need administrator approval.
Application permissions, also called app roles, let an app access Microsoft Graph without a signed-in user. Access follows the permission’s scope rather than a user’s rights. Application Mail.Read, for example, allows reading all organizational mailboxes by default. These permissions require admin consent. For Microsoft Graph application permissions, granting that consent requires at least the Privileged Role Administrator role, or a custom directory role with permission to grant permissions to applications.
The right type depends on whether a user is present when the agent runs.
In either case, grant only what the task requires, following the least privilege principle in NIST SP 800-53.
An agent’s identity and authentication setup determine whose access it uses and where to look for permission grants. Check these 4 aspects.
Permission risk grows as agents multiply, their tasks change, and unused access goes unreviewed. OWASP lists excessive permissions as a root cause of excessive agency in LLM applications.
Some Graph permissions reach far beyond what most agents need, especially as application permissions. Most carry the .All constraint, though application mail permissions can cover every mailbox by default even without it.
These options depend on the agent’s task, and they only reduce access once the broader grant is removed.
An audit has to cover every identity type, including grants that never appear on the agent itself. Work through it in 3 stages.
Start with a full inventory of agents and the grants attached to them.
With the inventory in hand, measure each agent’s reach against what it does.
Fix what the assessment surfaces, prioritizing unnecessary access to sensitive resources or privileged actions.
Most Graph authorization failures return a 403, though token, consent, and Conditional Access problems can surface as 401, 400, or Entra AADSTS codes. Check the response body and whether the failure occurred during token acquisition or the Graph request, since the status code alone doesn’t identify the cause.
Manual audits capture permissions at a single point in time, whereas agents and their access keep changing. Opsin Security brings each connected agent’s identity, permissions, data access, and original purpose into one continuously updated view.
An agent can stay within its Microsoft Graph permissions and still reach data its task never required. For every agent, security teams should be able to explain whose identity it uses, what access it has, and why that access is necessary. That includes inherited blueprint grants and maker-provided connections that a permission list alone can miss.
Opsin connects identity, access, purpose, and behavior to help teams prioritize those reviews as agents change. The goal is to give agents enough access to do their jobs and to catch the point where that access stops serving their purpose.
