Securing the Claude Enterprise M365 Connector: What the Permission Model Doesn't Tell You

Where the Permission Model Stops and the Risk Begins

The standard security review of the Claude Enterprise M365 connector goes roughly like this: the permission list is delegated, all read-only, bounded by the signed-in user's existing access. No application-level permissions, no write scopes. Review approved.

That framing is accurate as far as it goes. What it does not capture is that delegated and read-only still means verbatim meeting transcripts, Teams direct messages, every shared mailbox the user can access, tenant-wide SharePoint search, full audio and video recordings, and AI-generated meeting summaries. All on one token, all reachable from a single prompt. Each permission looks reasonable in isolation. The combination is a cross-surface aggregation capability most organisations have not threat-modelled before approving it.

I built this security review while running a pre-deployment assessment on a live enterprise M365 environment in early 2026. What follows covers the permission model gaps, the specific scopes that carry non-obvious blast radius, and the 10 security controls that exist because of those gaps. Several of them do not appear in standard Anthropic deployment documentation.

What the Connector Actually Gets

The full permission list is published across two Anthropic sources: the M365 Connector Security Guide and the Enabling and using the connector page. All permissions are delegated. The connector acts on behalf of the signed-in user and cannot access anything beyond their existing rights. No application-level permissions, no write scopes anywhere in the set.

The delegated constraint is real, but it is not the risk model most people carry when they approve this integration. The actual risk is aggregation across surfaces simultaneously. A single prompt can pull from email, Teams DMs, channel messages, SharePoint documents, calendar entries, and meeting transcripts in one query, all on one token, all sent to Anthropic's backend in one response. No individual permission creates that exposure. The combination does. That is the framing to carry into the controls that follow.

The first thing that enables all of it: offline_access. This scope causes the authorisation server to issue refresh tokens rather than short-lived access tokens alone. Every permission in the list persists on a sliding token window of up to 90 days per Anthropic's documentation. A user who connects once and is later offboarded does not lose access at the point of offboarding unless their session is explicitly revoked. This is not a Claude-specific behaviour. It is standard OAuth, but it is the mechanism that makes token hygiene a control in its own right.

Critical

Meeting content: OnlineMeetingTranscript.Read.All, OnlineMeetingRecording.Read.All, OnlineMeetingAiInsight.Read

The risk here is not that recordings exist. The actual exposure is that three simultaneous formats of the same sensitive conversation are accessible on one token. Verbatim transcripts, full audio and video, and AI-generated summaries distilled into decisions and action items. A single query against a senior employee's token can surface a board discussion in all three formats at once. Recordings for non-channel meetings are stored in OneDrive; channel meetings are stored in SharePoint. Access depends on storage location and file permissions, not the permission scope name alone.

These three are revoke-all-or-nothing. There is no supported way to permit meeting summaries while blocking recordings, or allow transcripts while restricting AI insights. The practical pre-pilot position is to revoke all three before any user connects and re-evaluate based on actual business need before production. An acceptable use policy prohibiting meeting content queries is the alternative control, but it is a behavioural constraint, not a technical one. Note also that Purview DLP does not intercept these reads. If the connector queries a meeting transcript and transmits the content to Anthropic's backend, DLP is not in that path.

High

Chat.Read + ChatMessage.Read: Teams direct messages

Most threat models for this integration focus on Teams channels. The DM surface gets less attention and carries more risk. Direct messages are where sensitive decisions get made informally: legal guidance, compensation conversations, board pre-discussions before formal record is created. ChannelMessage.Read.All covers channels. Chat.Read and ChatMessage.Read cover everything else. Together they give the connector the complete Teams signal: the formal record and the informal layer simultaneously.

Mail.Read.Shared: delegated mailboxes

The scope most likely to be approved without scrutiny. Mail.Read is expected. Mail.Read.Shared is not visible in most OAuth consent screens unless you are specifically looking for it. It silently extends mail access to every shared and delegated mailbox the signed-in user can reach. The blast radius is determined by who connects: for an executive assistant it is C-suite inboxes; for legal it is privileged correspondence. It is the only permission in this list with a clean granular mitigation: it can be selectively revoked in Entra without affecting any other mail functionality.

Sites.Read.All: tenant-wide SharePoint search

The permission itself is expected. The behaviour documented by Anthropic is not. The underlying SharePoint search operates tenant-wide by design. Sites.Selected, the narrower alternative listed in the permission set, is explicitly stated as unsupported for this integration. There is no scoping path. Every SharePoint site collection the user can access is reachable. For users with broad SharePoint permissions, that is the organisation's document layer in full.

ChannelMessage.Read.All + Files.Read.All

Channel messages across every team the user belongs to, including private channels. Combined with Sites.Read.All, Files.Read.All means the connector can retrieve documents referenced in emails, linked in chats, shared in meetings, or stored in SharePoint in one aggregated query. Neither permission is surprising in isolation. In combination with the full token they close the loop on the cross-surface aggregation risk described above.

One scenario that does not appear in most threat models: external guest access. If a pilot user is a member of Teams channels or SharePoint sites that include external guests, the connector can read messages and content from those channels, including messages posted by guest users from other organisations. Those guest messages are stored in your tenant, not theirs. The multi-tenant isolation Anthropic documents applies to token boundaries, not to guest content within your own tenant. Review the pilot group for users with guest-heavy Teams membership before connecting the integration.

Notable in aggregate

Calendars.Read.Shared is low on most permission review checklists. The security signal is not scheduling data. It is meeting patterns. Who meets with whom, how often, with which external parties. Board call cadences, investor meeting rhythms, recurring legal counsel slots. For an AI tool that can reason across time series, calendar access is organisational intelligence. User.ReadBasic.All provides display name, UPN, department, and job title for every user in the org. Combined with the full permission set it enables the connector to identify which users carry the broadest access scope. A targeting map if the token is ever compromised or misused.

The 10 Controls

Grouped by theme.

Group 1: Identity and Access (Controls 1, 2, 3, 4)

Control 1: Verify the organisation domain in Claude Enterprise. Without domain verification, SSO enforcement is not possible and any user with a domain email address can access the org via generic email login or Google SSO, bypassing Conditional Access entirely. The identity stack in this group runs in sequence: domain verification unlocks SSO configuration, SSO configuration unlocks Conditional Access enforcement. A CA policy scoped to an app that has not been configured yet enforces nothing. It is not a configuration detail. It is the prerequisite chain for the entire identity perimeter.

Control 2: Configure Entra SAML SSO and enforce it. The SSO enterprise application is a separate app registration from the M365 connector app. Two distinct objects in Entra, two distinct security surfaces. The non-obvious finding: if SAML provisioning is misconfigured, the first user who authenticates can land as Admin in Claude Enterprise rather than Member. That is a silent privilege escalation at the point of onboarding. Verify role assignment on the first test login before enabling SSO enforcement for the pilot group. Without Require SSO active, Google login and email magic links remain valid bypass paths regardless of what is configured in Entra.

Control 3: Conditional Access policy: MFA and compliant device. A Global MFA policy is not sufficient here. MFA alone does not enforce device compliance, which means a user on a personal or unmanaged device can satisfy MFA and still obtain a token with the full M365 permission set. The CA policy needs to require both, with Require ALL controls selected. The less obvious gap: a CA policy scoped only to the Claude SSO app does not cover the connector enterprise app, which is a separate object in Entra handling the Graph token exchange. Without a policy scoped to the connector app specifically, device compliance requirements may not apply to the token acquisition that gives the connector its M365 access. Both apps need their own policy.

Control 4: Lock and scope the Claude M365 connector app. This is the first action to take regardless of where everything else stands. Until Assignment Required is set on the connector enterprise app, any user in the tenant can authorise the integration and obtain a token with the full permission set against their M365 access. This is the active exposure window. Every other control assumes this one is already closed. Setting Assignment Required and immediately scoping the Users and Groups assignment to the pilot group must happen back to back. There is a brief window between the two steps where the app is restricted but has no valid assignees, which can block even authorised users. The order is: enable the restriction, then set the scope.

Setting Assignment Required does not revoke tokens already issued. Any user who connected before this step has a valid refresh token that persists on the sliding window. Those tokens must be revoked via Entra session revocation separately. This is the most common gap found in deployments where the connector was already live before scoping was applied.

Before expanding the pilot group beyond the initial security reviewer, establish a policy on privileged user inclusion. Users with Global Administrator, Exchange Administrator, SharePoint Administrator, or Security Administrator roles should not be added without a separate security review. Executive assistants with delegated mailbox access to senior leadership are in the same category. The delegated permission model means the connector inherits their full M365 access scope, which is disproportionately broad compared to a standard knowledge worker.

Group 2: Governance and Legal (Controls 5, 6, 7)

Control 5: DPA and data retention confirmation. Using the M365 integration without a signed DPA means the connector is transmitting organisational data to Anthropic's backend with no contractual data protection obligations in place. The Commercial Terms cover the key security-relevant clauses: data residency, sub-processor list, training opt-out confirmation, breach notification SLA, and retention period. All of these have direct security implications, particularly training opt-out, which determines whether conversation content enters model training pipelines.

The data retention period is not visible anywhere in the Claude Enterprise portal UI. There is no configurable setting, no displayed value. It requires direct confirmation from the Anthropic Enterprise account team. Ask specifically whether Zero Data Retention is available under the contract and whether retention can be customised. The answer affects the threat model for data exfiltration via prompt. Content sent to the backend and retained is a different risk surface from content that is discarded post-response.

Control 6: Tenant-level OAuth consent configuration. The scoping work in Control 4 restricts who can connect the Claude connector specifically. It does not close the broader OAuth consent surface. If UsersCanConsentToApps is unrestricted, any user in the tenant can authorise any OAuth application requesting broad Graph scopes, including lookalike apps or shadow connectors requesting the same permission set as Claude. The attack vector is not Claude itself; it is the consent model that Claude was approved under being available to other apps by default. Verify the User consent settings in Entra and restrict self-consent to verified publisher apps at minimum. Confirm an admin consent workflow is active so rogue consent attempts are reviewed rather than silently failing or silently succeeding.

Control 7: CAE verification and token revocation posture. As established in the permissions section, offline_access causes refresh tokens to persist on a sliding window. Actively used tokens extend beyond the 90-day default. The question this control answers is what happens when you need to revoke that access. A compromised token or an offboarded user with an active token both have silent M365 access until explicitly invalidated.

CAE is frequently misunderstood as the mechanism that makes session revocation work. It is not. Standard Entra revocation events (admin revocation, password reset, account disable) invalidate refresh tokens without CAE. What CAE adds is near-real-time enforcement of policy changes: location changes, device compliance drops, risk score increases. Without CAE, those policy changes only take effect at the next token refresh cycle, which for an actively used token could be hours later. The practical check: inspect a sign-in log entry for the connector app in Entra and look for a continuousAccessEvaluation field in Additional Details. If absent, CAE is not active. Also check for any Conditional Access policy with Disable resilience defaults set to On, which silently suppresses CAE and is easy to miss in a large tenant. When CAE is active, Microsoft intentionally extends access token lifetime to up to 28 hours, because reliable near-real-time revocation makes the longer window safe. Without CAE, you get the standard 60–90 minute window with no real-time policy enforcement.

Group 3: Detection and Org Controls (Controls 8, 9, 10)

Control 8: Sentinel alert rules. Detection coverage must be live before any pilot user is added, not after. An unmonitored window in the logs from the start of the pilot is a permanent gap. You cannot retroactively detect what happened before the rules existed. The OAuth consent rules in particular need to be running before user sessions begin. First verify that the Unified Audit Log is active and that OfficeActivity and AuditLogs are flowing into Log Analytics. UAL is not on by default in all tenants and is licence-dependent. Then create the following six analytics rules:

Route all High severity alerts to the security team via automated response. Logs without alert rules are just storage.

One telemetry source the Sentinel rules above do not cover: Anthropic logs authentication and tool execution events on the Claude side, separate from the M365 audit trail which captures downstream data access. Confirm with the Anthropic Enterprise account team whether the org-level audit log is active and visible in Claude Enterprise Settings. In some tenants it is not surfaced by default. Both telemetry sources are needed for a complete picture of what the connector is doing and when.

Control 9: Acceptable use policy and user acknowledgments. The meeting content permissions (transcript, recording, AI insight) cannot be removed from the app registration. The AUP is the only pre-pilot control for that exposure that does not require disabling the meeting tools entirely. It is a behavioural constraint, not a technical one, which is why the meeting permission revocation position in the permissions section is the stronger recommendation. The AUP exists for the gap between what can be technically enforced and what needs to be operationally bounded.

Control 10: Claude Enterprise org access controls. These toggles should be off before domain verification completes in Control 1. Once the domain is verified, the org becomes more discoverable to users with domain email addresses and an open Invite link becomes an active risk. Two toggles require explicit attention: Invite link and Member invites. By default in some tenants, Invite link allows any user with an allowed email domain to self-join the org using a shared URL. Member invites allows existing members to invite others without admin involvement. Both must be set to Off before domain verification is complete and before any pilot user is added. If either toggle has been active for any period, check the pending join requests queue and the member list for anyone who joined outside the formal onboarding process. Remove or decline any out-of-process access. Any token already issued to a self-joined user represents an unscoped connection with the full permission set. Revoke the session in Entra, do not just remove group membership.

What the Permission Model Leaves Out

The specific thing the permission model does not tell you is how the risk changes depending on who connects. The same integration, the same permission set, produces a fundamentally different risk profile depending on whether the user who connects is a standard knowledge worker, an executive assistant with delegated mailbox access to leadership, a finance director with broad SharePoint permissions, or a legal counsel whose Teams DMs contain privileged correspondence. The permission model is static. The blast radius is a function of who authorises it.

This is why scoping the pilot group is not a governance formality. It is the primary risk control. The controls in this blog (identity enforcement, token hygiene, OAuth consent governance, detection coverage) all exist to make that scoping decision deliberate and enforceable. Without them, the integration runs at the access level of whoever happens to connect first. And the pattern that follows is predictable: a successful pilot becomes the implicit approval for full rollout. The pilot was controlled. The rollout inherits those controls, applies them to a population ten times the size, and calls it done. The permission model does not change. The blast radius does.

A deployment that completes 9 of 10 controls is not 90% secure. The missing control determines the risk profile. Skip Control 4 and the access surface is uncontrolled regardless of everything else. Skip Control 7 and token revocation is unreliable for policy-change events. Skip Control 6 and the OAuth consent model is open tenant-wide even though the Claude app itself is tightly scoped. The controls are interdependent by design.