Privileged Accounts and the Claude M365 Connector: Why "User-Scoped" Has Limits Anthropic Didn't Document

Context

Anthropic's Claude M365 Connector Security Guide makes a clear promise: "Users cannot access other users' private files or emails." For most licensed users in a typical enterprise tenant, that statement holds. What it doesn't account for is how Microsoft's delegated permissions model behaves when the authenticated user holds an administrative Entra ID role. The rest of this post is about that gap.

In short: under delegated authentication, "user-scoped access" becomes "role-scoped access" for privileged accounts. The connector doesn't change this. The Security Guide doesn't mention it.

The Intersection Model

Microsoft's delegated permissions operate on what they call the intersection model. When an application uses delegated permissions to access the Graph API on behalf of a signed-in user, the effective access is the intersection of two factors:

1. The permissions (scopes) consented to the application
2. The privileges of the signed-in user, including those assigned through Entra ID RBAC roles

For a standard licensed user with no admin roles, this intersection is restrictive. The app can only reach the user's own mailbox, their own OneDrive, SharePoint sites they have access to, and Teams channels they're a member of.

For a user holding an administrative role, the user-side of that intersection is broader. The app's consented scopes don't change, but the data accessible within those scopes expands.

Microsoft's own documentation confirms this. Their permissions overview states that user permissions include those "assigned through a role-based access control system (RBAC) such as Microsoft Entra RBAC." The identity platform documentation distinguishes between "directory resources by Microsoft Entra role-based access control (RBAC)" and "mail and calendar resources by Exchange Online RBAC."

That last distinction is doing real work. Exchange and SharePoint don't behave the same way under the same delegated permission, which is why this finding is scoped to specific surfaces rather than the full M365 suite. I'll get into where the boundary sits for each resource type below.

SharePoint and OneDrive

This is the strongest and most concrete scenario.

The Claude M365 connector requests Sites.Read.All and Files.Read.All as delegated permissions. The Security Guide itself notes that "site-specific permissioning (using *.Selected permissions) is not supported because the underlying search is tenant-wide."

SharePoint Administrators and Global Administrators have the ability to access all site collections through administrative override paths. This isn't the same as having site ACL membership by default. What it means in practice is that SharePoint-backed Graph APIs honour those override paths when evaluating access under a delegated token. The causal chain is specific: the delegated token carries the user's identity and role assignments, SharePoint evaluates those roles through admin override paths rather than standard ACL membership, and Graph returns results consistent with that elevated access. The connector doesn't do anything special here. It's a standard delegated call, and the admin's role does the rest.

Under the intersection model:

• Standard user authenticates the connector with Sites.Read.All can search and read documents from SharePoint sites they have access to and their own OneDrive
• SharePoint Admin / Global Admin authenticates the connector with Sites.Read.All can search and read documents from SharePoint sites and OneDrive-backed personal sites accessible via administrative override paths, which in most tenant configurations covers the full tenant

Those two bullets have identical scopes. The access they produce is not the same. That's the finding.

Why Exchange Behaves Differently

Being precise about scope here matters, and I want to spend time on it because the Exchange claim is where a lot of AI security writing overstates the finding. The strongest case here is SharePoint-specific, and claiming Exchange behaves the same way would be wrong.

Exchange-governed resources tell a different story. The Exchange Administrator Entra ID role maps to the Organization Management role group in Exchange Online. This role grants administrative management capabilities but does not include implicit Full Access to mailbox content. Microsoft's documentation for Organization Management states that members of this role group can't perform mailbox searches by default.

So a Global Administrator or Exchange Administrator authenticating the connector with Mail.Read can't read another user's mailbox through the Graph API. Accessing another user's mail via delegated permissions requires either application-level permissions or explicit Exchange Online mailbox delegation granted via Add-MailboxPermission. The connector reflects what the user can access. For Exchange, that boundary holds.

Teams, Partially

Under the intersection model, a Teams Administrator's broader role permissions mean that ChannelMessage.Read.All delegated access likely extends to standard and shared channels across teams they don't belong to. This is less clearly documented than the SharePoint case and worth treating as provisional in your environment.

Private channels enforce a harder boundary. Teams Admins attempting to list private channel messages for channels they aren't members of receive a 403 Forbidden error. Anthropic's own connector documentation aligns with this: "If you're a member of a private channel, Claude can search for that content. If you're not a member, Claude can't access it."

The Chat.Read scope shows minimal expansion with admin roles, as chat APIs are generally scoped to the signed-in user's own conversations.

Per-Scope Summary

The Documentation Gap

The connector is working exactly as designed. Microsoft's intersection model is documented, intentional, and well-understood by identity security teams. What I'm describing isn't code behaving incorrectly. It's a documentation gap with real deployment consequences.

The Security Guide's statement that "Users cannot access other users' private files or emails" is unqualified. It doesn't distinguish between standard licensed users and those holding SharePoint Administrator or Global Administrator roles. A CISO reading that statement during a procurement evaluation could reasonably conclude the connector is safe for all user populations without additional controls, and the Security Guide gives them no signal otherwise.

There's a framing that comes up as pushback: "Admins already had that access, so the connector is just reflecting it." That's true at the permission layer. It misses what the connector actually changes, which I'll describe in the next section.

Usability Escalation

What's happening here is effectively usability escalation. The connector doesn't introduce new access paths. It operationalizes existing ones, collapsing the effort required to exercise them from deliberate multi-step administrative action to a conversational prompt.

The part that changes most concretely is the audit trail, and this is the piece I'd want any detection engineer reading this to focus on. The same action produces meaningfully different telemetry depending on which tool an admin uses to perform it:

When an admin reads another user's files through SharePoint admin tools or initiates eDiscovery workflows, the tooling appears in audit logs with administrative context that signals intent. When the same access happens through a Claude conversation, it shows up as a Graph API call from the connector's service principal. Without specific custom detection rules, a Global Admin reading another user's private files through Claude looks identical in logs to a standard user performing a routine search. That's the detection gap worth building a rule for, and I'll put the specific query in the recommendations section below.

The insider threat surface expands for a simpler reason. The friction was the control. An admin who wanted to read another user's files had to open PowerShell, navigate admin portals, or initiate a formal workflow. Most never did, not because they couldn't, but because the effort wasn't proportionate to casual curiosity. A conversational prompt removes that entirely.

The risk model implication follows from both of those: most enterprise assessments for admin accounts assume cross-user data access requires deliberate action. It no longer does.

The Permission Discovery Problem

The admin account scenario is the sharpest edge of this finding, but not the only one. The same connector dynamic applies to standard users, through a different mechanism.

SharePoint sites are routinely overshared. Users accumulate access to sites and document libraries over years of project work, team changes, and group-inherited permissions. Most of this access is never exercised because the users don't know the sites exist. Before AI connectors, latent over-permission was inert. Nobody stumbled across sensitive files in a site they didn't know they had access to through normal working patterns.

A tenant-wide AI search changes that. Claude will surface content from every SharePoint site the authenticated user has permission to read, including sites they've never visited, document libraries they didn't know existed, and files shared through group membership they've long forgotten. The connector doesn't create the oversharing problem. It makes every existing permission mistake immediately discoverable.

Treating this as a post-rollout cleanup task is a mistake. Once the connector is live, the discovery surface is active.

The Pattern Is Broader Than This Connector

This post focuses on the Claude M365 connector because that's the specific system I tested and disclosed against. The behavior itself isn't Anthropic-specific. Any system that uses delegated permissions to access M365 or similar enterprise platforms inherits the same dynamics if three conditions hold: effective access reflects the signed-in user's role, the interface is low-friction and search-driven, and the audit context produced is weaker than what legacy admin tooling generates for equivalent access. Claude's M365 connector satisfies all three. So does Microsoft Copilot. So will most AI assistants with enterprise data connectors built on Graph or similar delegated APIs.

The practical question for any AI assistant evaluation isn't just "what data can it read?" It's "what happens to that access when a privileged account authenticates it?", "what does the audit trail look like compared to the tools it replaces?", and "does the documentation tell the whole story?" The Claude connector is a concrete instance of a pattern that will repeat.

Anthropic's Response

I reported this finding on April 8, 2026, via email to disclosure@anthropic.com and through Anthropic's HackerOne VDP (Report #3657431). The core of their response (paraphrased):

The Microsoft 365 Connector uses delegated permissions, and users can only access Microsoft 365 data they already have permission for. An account holding a privileged Entra ID administrative role already has access to other users' data via Microsoft's permission model, so the connector reflecting that access is consistent with how delegated permissions work, not a gap in the connector.

That's a technically defensible position. The connector is behaving as designed. The question was never whether the connector is broken. It was whether the documentation accurately communicates the design to the people making deployment decisions.

What I'd Recommend

1. Block privileged accounts from authenticating the connector

The connector has no built-in mechanism to distinguish a Global Admin session from a standard user session. The fix is two-layered: restrict the connector's enterprise app to a security group of standard user accounts via Enterprise App Assignment Required, then back that up with a Conditional Access policy targeting the MCP Client and M365 Connector service principals for accounts holding admin roles. One important nuance: Conditional Access evaluates at authentication time only and does not constrain downstream Graph query behaviour once a token is issued. This means CA alone is insufficient. The Enterprise App assignment is the primary control. The CA policy enforces it at the authentication layer so it can't be bypassed by direct OAuth flows. If SharePoint access isn't needed for the use case, revoking Sites.Read.All and Files.Read.All eliminates the expansion path at the scope level entirely.

2. Layer Purview DLP as a backstop, not a primary control

DLP policies operate at the content level, not the identity level. That distinction matters: DLP works even if a privileged account authenticates the connector, and it covers the oversharing scenario for standard users surfacing content they have access to but shouldn't be reading through an AI interface. Configure information type policies for SSNs, financial records, and health data. This is defense-in-depth, not a substitute for the identity-layer restrictions above.

3. Audit SharePoint permissions before rollout

AI-powered tenant-wide search will surface every permission mistake in your environment immediately. Sites overshared years ago and never cleaned up become discoverable through Claude the day the connector goes live. Run a SharePoint access governance report and remediate orphaned permissions and over-scoped group memberships before rollout. Treating this as a parallel track rather than a prerequisite is how organisations end up with an unplanned disclosure event.

4. Monitor connector sign-ins from privileged roles

When a privileged account authenticates the connector, the event appears in Entra sign-in logs. The Graph API calls that follow show up attributed to the connector's service principal without the contextual fingerprint that would appear if the same admin had used PowerShell or eDiscovery tooling. Detecting the authentication event is the cleaner signal. The following Sentinel query surfaces sign-ins to the MCP service principals from accounts holding admin roles:

let PrivilegedUsers = IdentityInfo
    | where AssignedRoles has_any (
        "Global Administrator",
        "SharePoint Administrator",
        "Exchange Administrator",
        "Teams Administrator"
    )
    | project AccountUPN;
SigninLogs
| where AppId in ("<MCP_CLIENT_APP_ID>", "<M365_CONNECTOR_APP_ID>")
| where UserPrincipalName in~ (PrivilegedUsers)
| project TimeGenerated, UserPrincipalName, AppDisplayName,
          IPAddress, ResultType, ConditionalAccessStatus
| order by TimeGenerated desc

Replace the app ID placeholders with the actual service principal IDs from your tenant, visible in Entra under Enterprise Applications. Note that IdentityInfo requires Sentinel UEBA to be enabled via the Microsoft Defender for Identity or Entra ID connector. Without it the table is empty and the query returns no results.

5. Evaluate Restricted SharePoint Search and Restricted Content Discovery

Microsoft built both controls because Copilot was surfacing overshared SharePoint content. Restricted SharePoint Search limits AI tools to a curated allow-list of up to 100 sites. Restricted Content Discovery is a per-site control that prevents content from appearing in AI and organisation-wide search results at the search index level. Three caveats: Microsoft describes Restricted SharePoint Search as a temporary measure, not a permanent security boundary. Both features were designed for Copilot. Restricted Content Discovery also requires SharePoint Advanced Management licensing beyond standard M365. Validate applicability to Claude in your environment before relying on either as a control.