AI Governance & Data Protection – Claude + Microsoft 365

Jonathan Blaue · May 2026 · Security / Compliance / AI

You’re deploying Claude Enterprise. You think you’re protected. Let’s check that assumption.

The demo was impressive. The use cases are real. The productivity gains are hard to argue with. Your team wants it, your executives are asking about it, and procurement is already in motion.

And somewhere in the process, someone said — or assumed — “we’re on Enterprise, so our data is protected.”

That statement isn’t wrong. But it’s also not complete.

There’s a version of Claude Enterprise where your data is genuinely well-governed. And there’s a version where sensitive data — SSNs, PHI, financial records, regulated IP — is transiting to Anthropic’s cloud infrastructure with no Purview policy touching it, no DLP rule inspecting it, and no audit trail capturing what Claude did with it.

The difference between those two versions isn’t the plan you bought. It’s whether you understood the architecture before you deployed it.

This post is for organizations that are deploying — or evaluating — Claude Enterprise in conjunction with M365 enterprise data. My goal is to give you the honest picture: what Anthropic protects, what Microsoft’s security stack actually does at the AI layer, where the real gaps are, and what you need to close them.

This post is intended to be both non-technical and technical in nature.

Let’s have a look.

🧠 Executive Preface: The Question You Need to Answer First

Before your IT team spends a single hour on connector configuration or DLP policy design, leadership needs to answer two questions — not one:

What data are your users going to bring into Claude — and what data is Claude going to retrieve on their behalf?

These are different problems with different solutions, and most organizations are only thinking about the first one.

This isn’t a theoretical question. When an employee opens Claude Desktop, connects it to Microsoft 365, and asks it to summarize their inbox or pull a SharePoint document into a prompt — that data travels from Microsoft’s infrastructure to Anthropic’s infrastructure. It crosses a boundary. And the security controls you’ve spent years building in Purview, Defender, and Entra were not designed with that boundary in mind.

Here’s the executive framing that matters:

Microsoft Copilot runs inside the Microsoft 365 boundary. Purview enforces. DLP fires. Everything is audited. Anthropic acts as a subprocessor under Microsoft’s Data Processing Agreement.

Claude Enterprise via the default MCP connector runs outside that boundary. Anthropic is the processor. Your data transits from Microsoft Graph to Anthropic’s cloud. Purview’s enforcement stops at the door. Your DLP policies — including the ones you specifically built for AI tools — do not apply to this path.

Both get you Claude. The governance architecture is completely different.

If your organization handles regulated data — healthcare, financial services, legal, government — this distinction is not a nuance. It is the compliance question. And right now, most organizations deploying Claude Enterprise are not clear on it.

Here’s the honest framing before we go deeper: the Microsoft security stack — GSA, Endpoint DLP, Purview, Restricted Apps — gives you strong, out-of-the-box protection for data going INTO Claude. What you type, what you paste, what you upload through the browser or desktop app — that’s where your existing E5 tooling has real enforcement options with proper licensing and configuration.

Data being RETRIEVED by Claude through the MCP connector is a different problem entirely. That’s a server-to-server path — Anthropic’s infrastructure calling Microsoft Graph — and none of your network or endpoint controls touch it. Closing that gap requires either strict permission scoping in Entra, RMS encryption on your most sensitive content, or a custom MCP server architecture that puts Purview in the retrieval path. The last option is powerful and technically available today, but it’s an engineering project, not a configuration.

That is what we’re going to fix.

🗂️ First, Let’s Talk About How Claude Actually Gets to Your Data

There’s a lot of confusion about how the M365 connector works, so let’s demystify it.

When you connect Claude to Microsoft 365, you’re authorizing two enterprise applications in your Entra tenant — the M365 MCP Server for Claude and the M365 MCP Client for Claude. These apps use OAuth 2.0 On-Behalf-Of (OBO) flow. In plain terms: Claude acts on behalf of the authenticated user, using that user’s delegated permissions to call Microsoft Graph API.

Think of it like giving a trusted assistant a key to your filing cabinet. They can only open drawers you gave them a key to — but once they have access, they can read the contents and take them wherever they go.

That “wherever they go” part is what matters.

The data flow looks like this:

User asks Claude → Anthropic’s MCP server calls Microsoft Graph on the user’s behalf → Graph returns the email, file, or message content → That content travels over HTTPS to Anthropic’s cloud → Claude processes it and returns a response

Microsoft Graph enforces your access control — Claude can only read what the user has permission to read. That part is real protection. But once the data leaves Graph and arrives at Anthropic’s servers, it is outside Microsoft’s compliance boundary. Purview has no enforcement point in that transit. Sensitivity labels are not evaluated as DLP conditions. The Copilot-location DLP policies you’ve built — specifically for AI tools — do not fire.

Anthropic’s documentation says: “Delegated permissions inherently respect your organization’s Microsoft 365 DLP policies.” That statement is technically defensible. But it describes access control — who can read what — not data loss prevention — what happens to what they read after they read it. Those are not the same thing. And treating them as the same thing is how organizations end up with a compliance gap they didn’t know they had.

What About Egnyte, Box, Dropbox or other unstructured data sources?

The same architectural reality applies. If Claude is connected to Egnyte, Box, or Dropbox via an MCP connector or OAuth integration, the data path is identical: file content leaves your cloud storage provider and travels to Anthropic’s infrastructure for processing. None of these platforms have a Purview enforcement point in that transit. The governance question is the same regardless of which content platform you’re using.

🔑 Claude Team vs. Claude Enterprise: What Actually Differs

This is the single most common question I hear from IT and legal teams. And the answer often surprises people.

On the training question, both plans are identical. Anthropic does not train Claude on inputs or outputs from any paid Claude for Work plan — Team or Enterprise. This has been a contractual commitment since both plans launched. The training concern is real, but it’s a consumer tier question. Free, Pro, and Max accounts on consumer terms were changed to opt-in training in October 2025. Claude for Work plans were explicitly excluded.

So if someone tells you “we need Enterprise to prevent training,” that’s not wrong, but it’s also not the distinguishing factor. Team protects you from training just as much as Enterprise does.

The differences that actually matter are about governance, compliance, and control.

Here’s what Enterprise adds that Team does not have:

Identity and provisioning: Team supports SSO via Google and Microsoft social sign-on. Enterprise adds SAML 2.0, OIDC, and SCIM. SCIM is the one that matters operationally — automated provisioning and deprovisioning as people join, move, and leave your organization. Without SCIM, every offboarding is a manual process. At scale, manual processes become security gaps. To me, this is one of the most important differences between Team and Enterprise. I would recommend Enterprise for this reason alone.

Data retention: Team locks you at 30 days. Enterprise lets you configure retention — including Zero Data Retention (ZDR), which deletes conversation data immediately after automated safety checks complete. For regulated workloads, ZDR is not optional. It’s the control that prevents sensitive data from persisting in Anthropic’s systems beyond the session.

Audit logging and the Compliance API: Team gives you basic admin activity logs. Enterprise gives you a full audit log — user actions, system events, data access — plus the Compliance API, which lets you programmatically query conversation content, activity logs, and file access by user and time range. This is what connects Claude to your SIEM. Without it, you cannot answer an eDiscovery request, an insider threat investigation, or an audit that asks “what did user X submit to Claude in Q1?”

HIPAA / BAA: Team has no BAA pathway. Full stop. If your organization handles protected health information, Team is off the table. Enterprise — specifically the sales-assisted path — includes a BAA. Read the fine print though: Claude Code is not covered under the BAA, and Cowork is not yet available on HIPAA-ready plans.

Network controls: Enterprise adds IP allowlisting and network-level access controls. Team has no equivalent.

The DPA: Team includes a standard Data Processing Agreement. Enterprise allows you to negotiate custom DPA terms. If your legal team is going to sign off on this deployment, they need to know which document they’re actually signing.

If your organization can answer “yes” to any of the following, you need Enterprise — not Team: We’re in a regulated industry. We need SSO with Okta or Entra ID. We need an audit trail that connects to our SIEM. We need to control how long data is retained. We need a BAA.

Team is the right starting point for a department pilot with modest compliance requirements. Enterprise is what IT and Legal need to sign off on an organization-wide deployment.

🌐 The Browser vs. the Desktop App: Two Very Different Security Profiles

This distinction is where I see the most confusion — and where the most real-world gaps exist. These are not two flavors of the same thing. They are architecturally different surfaces with different security properties, different controls that work, and different gaps to close.

When your users access Claude at claude.ai in a browser, your Microsoft security stack has real enforcement options. Purview Endpoint DLP’s browser extension on Edge can detect and block sensitive content being pasted into a prompt in real time. Global Secure Access can control who can reach claude.ai based on Entra group membership. GSA’s TLS inspection decrypts browser traffic and Purview’s inline web DLP can evaluate file uploads before they leave the device. The network path is inspectable. Your existing E5 compliance tooling is in the game.

When your users install and use Claude Desktop, you’re dealing with a different TLS stack — one that historically caused significant challenges for network inspection tools. The good news is that with deliberate configuration in Global Secure Access — specifically wildcard TLS inspection rules targeting Claude’s domains — it is possible to bring the desktop app’s API traffic into the GSA inspection path on managed Windows devices. This is achievable, but it requires intentional configuration work beyond GSA’s defaults and should be validated in your environment before you rely on it as a control.

Regardless of GSA inspection status, Endpoint DLP’s Restricted Apps capability provides a powerful and reliable control for Claude Desktop that operates entirely independently of the network layer — more on that below.

The key practical point for leadership: the browser is your lowest-friction governance path. The desktop app is governable — but it requires more deliberate configuration. For users handling regulated data, you can either invest in the additional configuration work, or require browser-only access for those segments while controls are being validated.

🛡️ Building the Security Harness: Layer by Layer

If you’re deploying Claude Enterprise and you want to do it right, you need to think in layers. No single control solves this. What you’re building is a defense-in-depth architecture designed specifically for the Claude access pattern.

Layer 1: Identity — Microsoft Entra

Identity is your first and most upstream control. Everything downstream depends on getting this right.

Enterprise App Assignment: The M365 MCP connector registers two enterprise apps in your Entra tenant. Scope these apps to a pilot group using Entra Enterprise Application assignment before granting organizational consent. Only users in the approved group can authenticate the connector.

Conditional Access on the MCP Apps: Target Conditional Access policies specifically at the MCP enterprise app IDs. Require compliant device, require MFA, restrict to known IP ranges. When GSA is in place, require the compliant network location as a Conditional Access condition — users can only authenticate the connector from a GSA-tunneled session.

SCIM: On Enterprise, provision and deprovision through your IdP. When someone leaves, their Claude access disappears automatically.

Permission Scoping: In Entra Admin Center, review the Graph API scopes granted to the MCP apps. Start with the minimum necessary. Don’t grant Chat.Read if Teams access isn’t needed. Permissions you haven’t granted cannot be exploited.

A critical gotcha on personal vs. corporate accounts: Unlike Microsoft 365, which separates consumer and enterprise traffic across different endpoints, Anthropic runs a single unified endpoint for all Claude traffic — personal accounts, Team, and Enterprise all hit the same claude.ai and api.anthropic.com infrastructure. There is no enterprise.claude.ai or tenant-specific URL that your network controls can use to distinguish a corporate session from a personal one.

This means the standard enterprise playbook — block the consumer endpoint, allow the corporate one — doesn’t apply here. A managed device user signing into a personal Claude Pro account and a managed device user signing into your Claude Enterprise workspace are making requests to exactly the same domain. From a network perspective, they look identical.

The mechanism Anthropic provides to close this gap is the anthropic-allowed-org-ids header. When this header is present on a connection to claude.ai, Anthropic’s backend checks whether the authenticating session belongs to the specified organization UUID. If it doesn’t match — personal account, wrong org, unapproved session — the request is rejected with a network policy error before authentication completes. This enforcement happens at Anthropic’s infrastructure layer, not yours.

The implication: getting this header onto every Claude-bound connection from your managed devices is not optional if personal account blocking is a requirement. Anthropic’s native tenant restriction (enabled in the Claude Enterprise admin console) handles the application layer for browser sessions where SSO enforcement is in play. But for Claude Desktop, for non-SSO paths, and for any scenario where a user might bypass the SSO prompt with a personal email, the header is the only control with teeth. That’s what makes the proxy or SSE-level header injection — whether through GSA EFP, a Squid deployment, or a third-party vendor — the enforcement mechanism this control ultimately depends on.

Layer 2: Device — Microsoft Intune

Claude Desktop Configuration via MDM: Intune can deploy Claude Desktop configuration centrally — approved MCP servers, feature restrictions, and critically, restrictions on local MCP configuration files that close the shadow IT path where a sophisticated user might configure their own M365 connection outside your governance controls.

Advanced Label-Based Protection for All Files: This Endpoint DLP setting lets users work with sensitivity-labeled files normally on the device, while automatically enforcing encryption at the point of egress — USB, cloud upload, any destination outside the managed endpoint. If Claude Desktop attempts to access a labeled file without the necessary usage rights, it receives ciphertext it cannot read. Windows-only, and only for labels configured to enforce encryption.

Layer 3: Endpoint DLP — Restricted Apps

This is the control that most organizations deploying Claude Enterprise haven’t fully explored — and it’s the most direct answer to the Claude Desktop governance question.

Restricted Apps operates at the OS file access level, completely independent of the network layer and TLS inspection. When you add Claude Desktop’s executable to the Endpoint DLP Restricted Apps list, the enforcement fires the moment that process attempts to open a DLP-protected file — before the app reads the contents, before anything is encrypted and sent over the network. Whether GSA inspection is working or not is irrelevant to this control. It operates below all of that.

Critically, Restricted Apps enforces against both SITs (Social Security Numbers, routing numbers, credit card numbers, custom patterns) and sensitivity labels — including labels that only apply visual markings, not just encryption-enforcing labels. This is materially broader than what RMS encryption protects in the server-to-server MCP path.

You can configure this as a blocklist (explicitly name Claude Desktop’s executable and set it to Block) or an allowlist (define approved apps, set the default to Block — Claude Desktop is implicitly blocked without being named). The allowlist model is operationally cleaner at scale.

Copy to Clipboard complements this: when a user copies content from a DLP-protected file, the action fires at the source — blocking the sensitive content before it ever reaches the clipboard, and therefore before it can be pasted into Claude Desktop.

Paste to Browser covers the browser surface: in Edge with the Purview extension, clipboard content is evaluated for SITs at the moment of paste into claude.ai, catching content from unprotected sources that Copy to Clipboard wouldn’t have seen. Current limitation: sensitivity labels don’t work as paste-to-browser conditions, and content under 30 characters isn’t evaluated.

The residual gap these controls don’t close: a user typing sensitive content from memory directly into Claude’s text box. No file, no clipboard event, no paste. That’s where the network layer (Layer 4) and governance controls — policy, training, acceptable use — take over.

Layer 4: Network — Global Secure Access

GSA applies differently across access surfaces, and the configuration details matter.

For browser-based access, GSA is your strongest network control. Web content filtering allows or blocks claude.ai by Entra group membership. TLS inspection decrypts browser HTTPS traffic and Purview’s inline web DLP evaluates file uploads before they leave the endpoint. Prompt Injection Protection evaluates browser prompt content in real time. Universal Tenant Restrictions prevent token replay and bind Graph authentication to compliant sessions.

For Claude Desktop, achieving TLS inspection coverage requires deliberate GSA configuration work beyond the defaults. With the right approach on managed Windows devices, it is possible to bring the desktop app’s API traffic into the GSA inspection path — which unlocks Prompt Injection Protection for Claude Desktop prompts, covering the typed-text scenario that Endpoint DLP can’t intercept. This is achievable and worth pursuing. It should be validated in your environment with your specific device fleet before being relied on as a primary control.

The combination of Endpoint DLP Restricted Apps (file access) and GSA Prompt Injection Protection (text prompt content) covers the two major input vectors into Claude Desktop. Neither control depends on the other — they’re complementary layers addressing different attack surfaces.

Compliant Network Location: A GSA capability worth enabling. Devices running the GSA client acquire a compliant network signal in Entra. Requiring this as a Conditional Access condition on the MCP apps means the connector can only be authenticated from a compliant, GSA-tunneled session — personal devices and unmanaged machines are blocked upstream.

Layer 5: Purview — What It Does and Does Not Protect in the MCP Path

In the browser, Purview is a genuine enforcement layer. Endpoint DLP paste-to-browser detection, inline web DLP file upload evaluation via GSA, and DSPM for AI visibility into browser-based AI interactions — all work in the browser path.

In the MCP connector’s server-to-server path, Purview’s enforcement boundary ends at Microsoft Graph. When the connector retrieves a file from SharePoint, that data flows server-to-server from Graph to Anthropic’s infrastructure. Your managed endpoints are not in that path. Endpoint DLP has nothing to inspect. GSA doesn’t intercept it. The Copilot-location DLP policies you built for AI tools don’t fire, because the MCP connector is not inside Microsoft’s Copilot orchestration pipeline.

The one Purview control with genuine enforcement in the server-to-server path: RMS encryption with no Extract right. If a file carries an encryption-enforcing label and the user lacks the Extract usage right, Graph returns ciphertext. Anthropic’s MCP server receives an unreadable blob. Real protection — but only for labels configured to enforce encryption, not visual-only labels.

This is why Entra permission scoping is so important. For regulated content you don’t want retrieved via the connector at all, don’t grant the Graph scopes that would allow it. That’s upstream of everything else.

🗃️ The MCP Connector: Capabilities and Limitations

The M365 MCP connector enables Claude to retrieve organizational data without users manually copying and pasting content. It calls Microsoft Graph on the user’s behalf and surfaces the results in Claude’s context.

What it can do today: Search and read SharePoint sites and pages, read OneDrive files, search Outlook email, search calendar events and find availability, search Teams chat messages, access Teams meeting transcripts and meeting artifacts.

What it cannot do today: Anything involving writing. No sending email, no creating or modifying files, no scheduling meetings, no posting Teams messages. The connector is read-only. “Have Claude create a PowerPoint from our SharePoint GTM strategy” — Claude can read the strategy and draft the content, but it cannot create the file or save it back to SharePoint.

The shadow IT risk: Claude Desktop supports locally-configured MCP servers. A technically sophisticated user can create their own MCP connection to M365 data using a personally registered Entra app — bypassing your organizational connector, with Graph calls appearing under an unfamiliar app registration ID that won’t match your monitoring rules. Intune restrictions on local MCP configuration files and Entra App Governance alerts on new OAuth registrations close this gap.

🔬 Advanced Option: Custom MCP Server with Purview in the Data Path

For organizations that need Purview DLP enforcement applied to the content the MCP connector retrieves — not just at the endpoint or browser layer — there is an advanced architecture that closes the server-to-server gap entirely.

Microsoft’s Graph API includes a Purview processContent endpoint that lets applications submit retrieved content for DLP policy evaluation before returning it to the requestor. Combined with a custom MCP server hosted in Azure Functions behind Azure API Management, this creates a data flow where every piece of content retrieved from M365 passes through your actual Purview DLP engine before it reaches Claude. If your policy says block — Claude gets a policy violation message instead of the content. SITs, sensitivity labels (encrypted or not), custom patterns — your full Purview policy set, applied to MCP retrieval.

This is the only architecture that puts Purview enforcement genuinely in the server-to-server path between Microsoft Graph and Anthropic’s infrastructure. It requires engineering investment: building and hosting the custom MCP server, configuring the APIM gateway for OBO token exchange, and creating the Purview DLP rules via PowerShell (the Purview portal doesn’t yet support this for Entra-registered apps). Once in place, you disable the native Anthropic connector in Entra and route all MCP access through your governed path.

This is the right option for organizations with regulated workload requirements, dedicated cloud engineering resources, and a mandate to enforce DLP at the data retrieval layer. For most organizations deploying Claude Enterprise today, the layered approach across Identity, Intune, Endpoint DLP, and GSA delivers a strong and practical security posture without this level of engineering overhead. The custom MCP server is the next level — and it’s available when you need it.

🔍 DSPM for AI: Your Visibility Layer

Microsoft’s Data Security Posture Management for AI gives you visibility into which AI tools your users are accessing, what sensitive data is flowing into them, and whether your policies are producing the intended outcomes.

For browser-based Claude access, DSPM surfaces interaction data in the Purview compliance portal — which users, which content types, which sensitivity labels — and feeds signals into Insider Risk Management.

For the desktop app and MCP connector path, DSPM’s browser-based signals don’t apply directly. The M365 audit log captures every Graph API call made by the connector and can be fed into your SIEM alongside DSPM data for a more complete picture.

DSPM for AI is not a replacement for enforcement. It’s the control panel — not the controls themselves.

✅ The Decision Framework: Which Version, Which Controls

Regulated industry (healthcare, financial services, legal, government): Claude Enterprise sales-assisted, BAA if PHI is in scope, custom DPA, ZDR configured, Compliance API to SIEM, RMS encryption on sensitive content classes.

Mid-to-large organization, existing M365 security stack: Enterprise if you need SSO with any non-Google/Microsoft IdP, audit logs, or Compliance API. Team for a departmental pilot with genuinely low data sensitivity.

For controls, build in this order:

Start with Entra permission scoping — that’s upstream of everything. Then RMS encryption on regulated content classes. Then Restricted Apps for the desktop. Then GSA configuration for network coverage. Use the browser as your best-governed access path while desktop configuration is validated.

🚀 Final Thoughts

Claude Enterprise is a genuinely impressive platform. The use cases are real, the model capability is real, and the enterprise controls — when correctly understood and configured — are legitimate.

But “correctly understood” is doing a lot of work in that sentence.

The organizations that will deploy this well go in with clear eyes about the architecture. They understand there are two distinct data protection problems here — not one. Data going INTO Claude through the browser and desktop app is where your existing Microsoft security stack has real, licensable, configurable controls today. GSA, Endpoint DLP, Restricted Apps, Purview paste-to-browser — these are mature capabilities that work with proper E5 licensing and deliberate configuration. That’s your out-of-the-box protection story and it’s a strong one.

Data being RETRIEVED by Claude through the MCP connector is a different problem that requires a different solution. The server-to-server retrieval path sits outside your endpoint and network controls entirely. For most organizations, the right answer is Entra permission scoping and RMS encryption on regulated content classes. For organizations that need full DLP enforcement on retrieved content, the custom MCP server architecture closes that gap — but it’s an engineering investment, not a checkbox.

Both problems are solvable. Neither one should catch you by surprise after you’ve deployed.

If you’re mapping this out for your organization and want to talk through the architecture, the Purview configuration, or the connector governance model — ping me on LinkedIn. This is the work.

Jonathan Blaue is a solution architect focused on the Microsoft cloud ecosystem. InfraBytes is his technical blog at jonathanblaue.com.

Tags: Claude Enterprise · Microsoft Purview · Endpoint DLP · Restricted Apps · Global Secure Access · MCP · Data Protection · Sensitivity Labels · Microsoft 365 · AI Governance · Security Architecture