Extending Purview Into Enterprise Claude and Enterprise ChatGPT
Part 4: Extending Purview
Every Purview review I have run this quarter ends on the same slide. A DSPM for AI dashboard with ChatGPT Enterprise and Claude both lighting up, and someone in the room calling the AI data-protection item closed. The dashboard is real. The control it implies is not.
This is the fourth post in a series on extending Purview past the M365 boundary. The first three were about the access layer: Netskope at the network edge, Varonis on the data store, Defender for Cloud Apps on sanctioned SaaS. This one is different. Microsoft now connects Purview directly into the two AI platforms most of your users actually want, ChatGPT Enterprise and Anthropic Claude, through each vendor’s Compliance API. That is a genuinely new reach. It is also the most misunderstood integration Microsoft has shipped this year, because of what people assume it does versus what it does.
Here is the part the setup guide does not put on the first page.
The gap: visibility is not enforcement
Start with the thing that sits under both connectors, because if you miss it the rest of the post will not land.
A Purview connector to ChatGPT Enterprise or Claude is a read integration. It calls the vendor’s Compliance API on a schedule, pulls the interactions that already happened, and lands them inside Purview so your existing solutions can see them. Nothing in that path sits between your user and the model. The user types the prompt, the model answers, the conversation completes, and then, later, Purview gets a copy.
That is a fundamentally different control than the one your team has spent years building inside M365. Inside the tenant, Purview is inline. A DLP policy evaluates the action before SharePoint saves the file or Exchange sends the mail, and it can stop it. The connector has no equivalent moment. By the time the data arrives, the prompt was answered hours ago.
If you have been in this industry long enough, you have seen this exact shape before. It is the email journaling era. Compliance teams stood up a journaling rule, fed every message into an archive, wired the archive to eDiscovery and retention, and checked the box. The archive was excellent at telling you what was said. It never once stopped anyone from saying it. We learned, eventually, that the archive was a system of record and the gateway was the control, and they were not the same project.
The Compliance API connector is journaling for the AI era. It remembers everything and prevents nothing.
A connector is a camera, not a lock.
What “Enterprise AI apps” actually means in Purview
Purview now sorts AI into three buckets, and the bucket determines everything about what you can do.
Copilot experiences and agents: Microsoft 365 Copilot, Security Copilot, Copilot in Fabric, Copilot Studio. Full inline Purview, including DLP and sensitivity-label enforcement.
Enterprise AI apps: Microsoft Foundry, Entra-registered apps, ChatGPT Enterprise, and Anthropic Claude (Enterprise). Connected through the vendor’s API. This is the new category and the subject of this post.
Other AI apps: anything a user reaches through a browser that Defender for Cloud Apps tags as generative AI. Consumer ChatGPT, Gemini, DeepSeek, the public Claude site.
The trap is assuming the first bucket’s capabilities carry into the second. They do not. ChatGPT Enterprise and Claude land in the Enterprise AI apps bucket, and that bucket is built on connectors, which means it is built on after-the-fact ingestion. The control model changes the moment the app crosses out of Microsoft’s own runtime.
ChatGPT Enterprise: the deep integration
The ChatGPT Enterprise connector is the more mature of the two, and it is genuinely useful. Once the connector scan runs, Purview ingests the actual text of prompts and responses and makes them available to most of the compliance stack.
Supported for ChatGPT Enterprise through the connector:
DSPM for AI reporting and Activity Explorer
Auditing in the unified audit log
Data classification (your sensitive information types and trainable classifiers run against the ingested prompts and responses)
Insider Risk Management, including the Risky AI usage template for prompt-injection and protected-material signals
Communication Compliance
eDiscovery
Data Lifecycle Management (retention) under the Enterprise AI apps location
Compliance Manager regulatory templates
Not supported: sensitivity labels, encryption, and Data Loss Prevention. Hold that last one.
This is real value. If your legal team needs to place a hold on a departing employee’s ChatGPT Enterprise conversations, or your regulator wants evidence that you can produce AI interactions in discovery, or your insider-risk analyst needs to see that a flight-risk user pasted source code into a prompt, the connector delivers all of it. SITs run against the content, so you get sensitive-data detection inside the prompts, not just a count of how many chats happened.
⚠️ The first gotcha is timing, and it is structural. Microsoft’s own documentation states that, due to OpenAI’s current API limits, conversations are ingested 24 hours after they occur. Your detection, your insider-risk signal, your communication-compliance review, all of it operates on a one-day delay. For a forensic record that is fine. For anything you imagined as a same-day response, it is not.
⚠️ The second gotcha will eat a day if you do not know it. When you create the API key on the OpenAI platform portal, the key has no Compliance API scope by default, and there is no toggle for it in the UI. You have to email support@openai.com with the last four digits of the key, the key name, the creator name, and the scope you want (read, delete, or both), and wait for OpenAI to grant it. Purview needs at least read to scan. Plan the procurement clock around a human at OpenAI, not a self-service button.
Anthropic Claude Enterprise: the thin integration
Now the one that is brand new, and where the expectation gap is widest.
The Claude connector uses Anthropic’s Compliance API. You enable it as the Anthropic Enterprise primary owner under Organization Settings, Data and Privacy, generate a Compliance Access Key, and add the connector in Purview under Settings, Data connectors. You choose two data scopes: the Activity Feed (read:compliance_activities, covering logins, admin actions, config changes, and audit events) and Chat Conversations (read:compliance_user_data, the full message history including user prompts and Claude’s responses). Data shows up in DSPM after about a day.
Here is the full list of Purview capabilities supported for Claude today:
DSPM for AI reporting and Activity Explorer
Auditing
That is the list. Classification, sensitivity labels, encryption, DLP, Insider Risk Management, Communication Compliance, eDiscovery, Data Lifecycle Management, and Compliance Manager are all unsupported for Claude right now. There are no recommendations and no one-click policies for it. Claude agents are not covered and do not appear in AI observability.
So the Claude connector gives you visibility and an audit trail. You can see who is using Claude, watch interaction trends, and read the prompts and responses in Activity Explorer. You cannot put it on legal hold. You cannot retain it. You cannot run a communication-compliance policy against it. You cannot run your SITs across it to find the PHI someone pasted in.
ChatGPT Enterprise gets the whole compliance stack. Claude gets a dashboard and an audit log. Same API pattern, two very different depths.
⚠️ The gotcha that will burn the wrong buyer: the conversation content scope only exists for Claude Enterprise. Anthropic’s Compliance API explicitly excludes prompt and response bodies for Claude Platform, the API product your developers build on. If your Claude exposure is mostly engineering teams calling the API rather than people using the Claude app, the connector will show you the activity feed and none of the actual content. Confirm which Claude you are governing before you scope the work.
⚠️ One more, on status. Microsoft’s Learn page for the Claude connector says, in plain text, that it is currently in preview. The May 2026 “What’s new in Microsoft Security” coverage reads as though it shipped generally available. When the announcement and the Learn page disagree, the Learn page is the one that governs your tenant. Treat the Claude connector as preview and verify in your own environment before you make architectural commitments on it.
The capability matrix, side by side
This is the slide I now put in front of clients, because it ends the argument in one look.
CapabilityChatGPT EnterpriseClaude EnterpriseDSPM for AIYesYesAuditingYesYesData classification (SITs)YesNoInsider Risk ManagementYesNoCommunication ComplianceYesNoeDiscoveryYesNoData Lifecycle ManagementYesNoCompliance ManagerYesNoSensitivity labelsNoNoEncryptionNoNoData Loss PreventionNoNo
Read down the DLP row. It is an X in both columns. The connector, on its own, will not block a single prompt to either platform. Neither will it warn the user. Detection and compliance, yes. Prevention, no.
Copilot is the baseline. Here is what actually carries over.
The fastest way to set expectations with a leadership team is to put all three next to Microsoft 365 Copilot, because Copilot is what their mental model of “Purview protects our AI” is built on. Copilot runs inside Microsoft’s own data boundary, so it gets the full set, including the controls that prevent rather than record.
Purview capabilityM365 CopilotChatGPT EnterpriseClaude EnterpriseDSPM for AIYesYesYesAuditingYesYesYesData classification (SITs on prompts)YesYesNoSensitivity labels honoredYesNoNoEncryption honoredYesNoNoDLP (inline, preventive)YesNoNoInsider Risk ManagementYesYesNoCommunication ComplianceYesYesNoeDiscoveryYesYesNoData Lifecycle Management (retention)YesYesNoCompliance ManagerYesYesNoEnforcement modelInline, real-timeAfter the fact (24h)After the fact (~1 day)
Read it as two groups of controls, not eleven rows.
The detective and compliance controls, meaning classification, Insider Risk Management, Communication Compliance, eDiscovery, and retention, carry over to ChatGPT Enterprise. They carry over because the connector lands the actual prompt and response content in the user’s mailbox, where those solutions can already reach it. They do not carry over to Claude yet. On Claude you get DSPM visibility and an audit trail, and that is the whole list.
The preventive controls, meaning DLP enforcement, sensitivity-label honoring, and encryption, carry over to neither. This is the line that decides what you can promise. Inside the boundary, a DLP policy on the Microsoft 365 Copilot location can stop Copilot from ever processing a labeled document, and a label’s encryption is honored before a single token comes back. Outside the boundary, through a Compliance API connector, none of that travels. The connector cannot read your labels, cannot honor your encryption, and cannot block a prompt.
So when someone asks whether you can extend Purview DLP to Claude and ChatGPT, the honest answer has two halves. You can extend your detection, your insider-risk scoring, your communication-compliance review, and your legal hold to ChatGPT Enterprise, after the fact. You cannot extend DLP enforcement to either app through the connector, and you cannot extend any of it, detective or preventive, to Claude beyond a dashboard today. The blocking you are picturing lives on the edge plane, and it treats both apps as generic AI destinations rather than the governed enterprise workspaces the connector sees.
What crosses the boundary is the audit trail, not the controls.
Where enforcement actually lives
If the connector cannot block, what does? The same edge controls from the first three posts in this series, operating through the Other AI apps path rather than the connector.
To stop sensitive data from reaching ChatGPT or Claude, you have three enforcement planes, and none of them is the API connector:
Endpoint DLP on devices onboarded to Purview, which can warn or block a paste or upload of sensitive content into an AI site in the browser.
Browser DLP through the native Purview integration in Microsoft Edge, activated by an Edge configuration policy.
Network DLP at the SASE or SSE layer, inspecting sensitive information types on the wire.
These are inline. They sit between the user and the model and can stop the action. They are also app-agnostic. They see a generative-AI destination, not “ChatGPT Enterprise interaction 4471.” And they only catch the paths they cover. A managed laptop in Edge is well covered. A personal phone on a home network is not.
This is the architecture people miss. The connector governs the sanctioned workspace you hold an enterprise contract for, after the fact, for compliance. The edge controls govern the act of sending data, in real time, for prevention. You need both, and they are two separate projects with two separate owners. Enforcement did not move to the API. It stayed at the edge.
What you need before you deploy
Prerequisites that are not all on the feature page:
An enterprise Purview account with pay-as-you-go billing enabled. Both connectors are gated on it. Ingesting enterprise AI app interactions is a metered, consumption-billed activity, not something folded into your E5 entitlement. If your finance team has not consented to PAYG in Purview, the connector cannot scan. This is the cost line nobody budgets for.
A collection policy that captures prompts and responses. For ChatGPT Enterprise, stand up the one-click “Secure interactions from enterprise apps” policy (or a DLP collection policy scoped to enterprise AI apps) before the connector scan, or you ingest activity metadata without content.
For ChatGPT Enterprise specifically: a ChatGPT Enterprise plan, the workspace ID, an Azure Key Vault to hold the API secret, Data Source Administrator and Data Reader on the Purview Data Map, and the OpenAI support email to scope the key. Registration happens in the Purview governance portal Data Map, not the modern connector page.
For Claude specifically: an Anthropic Enterprise plan, the primary owner to enable the Compliance API and mint the Compliance Access Key, your Anthropic organization ID, and the Data Connector Admin role in Purview. Setup is in the modern portal under Settings, Data connectors.
A note on where the data goes. ChatGPT Enterprise interactions land in the user’s Exchange mailbox, which is the mechanism that makes eDiscovery and retention work for them. That is also why those capabilities exist for ChatGPT and not yet for Claude. The plumbing is the same lineage as the old third-party data connectors that journaled chat into mailboxes for 17a-4 compliance. The AI is new. The pipe is not.
How to actually put the protections in place
This is the part most coverage skips, so here is the real deployment, layer by layer. The whole job is to inspect the act of sending data to the AI site and act on it before the data lands. Everything below targets the access path, because that is the only place enforcement exists.
Prerequisites for the enforcement layer
Endpoint DLP needs Windows 10 or 11 devices onboarded to Microsoft Purview, which is the same onboarding Defender for Endpoint uses, pushed through Intune. Browser controls need Microsoft Edge for Business version 144 or later. To enforce in Chrome or Firefox, deploy the Microsoft Purview browser extension, because without it those browsers fall back to the operating-system path and lose the paste and upload hooks. Protecting a managed device sending to an unmanaged AI app in Edge is a pay-as-you-go feature, so the same billing consent the connectors need applies here too. The DLP policies themselves require Microsoft 365 E5 or the E5 Compliance add-on.
Step 1: define the AI destinations you want to govern
Endpoint DLP groups websites into sensitive service domain groups. Microsoft ships a prebuilt group called Generative AI websites that you cannot edit or delete, populated from the same supported-sites list DSPM for AI uses. Open the Purview portal, go to Data Loss Prevention, Endpoint settings, Browser and domain restrictions to sensitive data, and confirm that chatgpt.com and claude.ai are actually in your tenant’s group. If you want certainty, create your own sensitive service domain group with a URL match like *.claude.ai and *.chatgpt.com, because policies only act on the sites you name.
⚠️ The Edge for Business inline browser catalog and the endpoint domain group are not the same list. The Edge for Business unmanaged-app catalog that does real-time prompt inspection currently includes ChatGPT consumer, Gemini, DeepSeek, Perplexity, Copilot consumer Chat, and others, and it does not list Anthropic Claude. So inline prompt inspection in Edge does not cover Claude yet. For Claude, your reliable control today is endpoint DLP scoped to the claude.ai domain group, or network DLP.
Step 2: block the paste and the upload with Endpoint DLP
Create a DLP policy scoped to the Devices location. Add a rule using the condition that the user accessed a sensitive site from Edge, then attach your AI sensitive site groups. Two activities do the heavy lifting. Paste to supported browsers evaluates text at the moment it is pasted into the AI prompt and can audit, block with override, or block. Upload to a restricted cloud service domain does the same for files. Set the action to block with override on the first pass so you learn the false-positive rate before you hard-block.
⚠️ Paste to browser has limits that change your policy design. It evaluates the clipboard against sensitive information types only, not sensitivity labels, it ignores text under 30 characters, and it classifies the first 4 MB. So a label-based rule will not catch a paste. If you want to stop someone pasting a Highly Confidential paragraph into Claude, you need a SIT or a trainable classifier that matches the content, not a label condition.
Step 3: turn on inline prompt inspection in Edge for Business
For the apps in the Edge catalog, create a DLP policy that targets unmanaged app interactions in the browser. When you activate it, Purview automatically creates the Edge configuration policies and the Intune policies that switch the integration on, and it can force in-scope users out of unprotected browsers so they cannot route around it. This is the layer that reads the typed prompt in real time and blocks the submission before it leaves the browser. It is also the layer that does not yet cover Claude, per the gotcha above.
Step 4: catch the unmanaged paths with Network DLP
Endpoint and Edge controls cover managed Windows devices and the Edge work profile. They do not cover a personal phone, a Mac without the extension, or a random app calling an API. Network data security closes part of that gap by inspecting sensitive information types at the network layer through a non-Microsoft SASE or SSE integration, with iboss and Netskope as the named partners. This is how you extend the same sensitive-info-type rules to traffic that never touches Edge.
Step 5: make the protection travel with the file using labels
Endpoint and network DLP act on the moment of sharing. A sensitivity label with encryption acts on the file itself. If a user uploads a document that carries an encrypting label, the AI app cannot read the content without the EXTRACT usage right, regardless of which path the file took. This is the one control that protects the data after it has already left your device, which is why label coverage on your sensitive content is the foundation the DLP rules sit on top of.
Step 6: scale enforcement by risk with Adaptive Protection
A flat block on every user generates override fatigue and a queue of exceptions. Adaptive Protection ties the DLP action to the user’s Insider Risk level, so a minor-risk user gets a warning while an elevated-risk user gets a hard block on the same activity. The DSPM for AI one-click policies are built around this, and they are the fastest way to stand up a defensible baseline.
The one-click starting templates
From DSPM for AI, the Fortify your data security recommendation creates the policies you would otherwise build by hand: Block elevated risk users from pasting or uploading sensitive info on AI sites across Edge, Chrome, and Firefox, Block elevated risk users from submitting prompts to AI apps in Microsoft Edge, and Block sensitive info sharing to AI apps in Edge for inline SIT detection.
⚠️ Every one of these ships in test mode. Test mode audits and does nothing to the user. A policy you created from the recommendation and never moved to enforce is a policy that has blocked exactly zero prompts. Check the mode before you tell anyone the control is live.
The connector side, for the record
Once the access path is enforcing, turn on the visibility layer so you have the evidence trail. Run the Secure interactions from enterprise apps one-click policy to ingest ChatGPT Enterprise and, where supported, Claude interactions, and stand up the Insider Risk Risky AI usage template so prompt-injection and protected-material signals score against the same users. That gives you detection and a compliance record sitting behind the prevention, which is the full picture: block at the edge, record through the connector.
A query to start with
Once a connector syncs, the interactions surface in the unified audit log. Before you build detections, find out what the connector is actually writing, because these record types are new and the naming is still settling.
// Discovery query. Run in Sentinel or Defender Advanced Hunting after the first sync.
// Goal: learn the exact RecordType/Operation strings the AI connectors emit in YOUR tenant,
// then build IRM and hunting logic on what you find, not on what a blog assumed.
OfficeActivity
| where TimeGenerated > ago(3d)
| where RecordType has "AI" or Operation has "AI" or Operation has "Copilot"
| summarize Events = count() by RecordType, Operation
| sort by Events desc
Adjustment note: OfficeActivity is the unified audit log table in Sentinel. If you query Purview Audit directly, filter on the equivalent record type. Do not hard-code an operation string from anyone’s example, including this one, until you have seen it in your own results. A detection built on a guessed field name is a detection that silently returns nothing.
Tradeoffs to understand before you commit
You are paying per interaction for a read-only record. Consumption billing on a forensic archive is reasonable, but model it. High-volume Claude or ChatGPT Enterprise usage across thousands of seats is a recurring meter, and the value you get for it on the Claude side today is a dashboard. Decide whether visibility-only justifies the run rate before you turn it on broadly.
The Claude integration may not survive contact with your real use case. If your Claude footprint is developers on the Platform API, the content scope is not there, and the connector reports activity you mostly already knew about. Pilot it against the actual workload before you present it as coverage.
Two control planes means two ways to be wrong. A team that deploys the connector and believes it has prevention will let sensitive data flow uninspected. A team that deploys edge DLP and believes it has the compliance record will fail an eDiscovery request. The connector and the edge controls are not substitutes for each other, and treating either as the whole answer is the most common mistake I see.
Roadmap: what is coming for AI protection
If you are deciding what to deploy now versus what to wait for, here is the verified roadmap, sorted the same way as the two planes. Every item below is from the Microsoft 365 Roadmap, and I checked each ID rather than trusting the recap blogs, because at least one of those mapped the wrong feature to its number.
The enforcement items, the ones that actually block data heading to ChatGPT or Claude, are already live and they all sit on the edge. Inline DLP for file uploads to unmanaged generative AI apps in Edge for Business reached GA in January 2026 (Roadmap 518642). Inline protection for sensitive data over the network through non-Microsoft SASE platforms like iboss and Netskope went GA in November 2025 (Roadmap 522095). New policy configuration options for inline network and Edge for Business, including sensitivity-label scoping and “URL contains text” conditions, hit GA in April 2026 (Roadmap 557976). Inline controls for typed and pasted prompts to AI sites in Edge rolled out through the Message Center in early 2026 (MC1046161). If your goal is to prevent sensitive data from reaching these apps, this is the set, and most of it is GA today.
The visibility and detection items are mostly still in flight. The collection-policy option that targets enterprise AI app interactions, the control that governs what the connectors ingest, is GA (Roadmap 492623). Three Insider Risk Management updates land through mid-2026: app-level selection of which AI apps trigger generative-AI risk detection (Roadmap 559992, GA June 2026), the ability for analysts to read the actual prompt and response messages even when user anonymization is on (Roadmap 560599, GA June 2026), and a pay-as-you-go billing model for risky-prompt detection on other AI apps (Roadmap 557548, GA April 2026).
⚠️ The billing gotcha buried in that last one: detecting a risky prompt on a third-party AI app is now a metered activity, not a flat IRM entitlement. Model the run rate before you switch it on across every user.
The item to actually watch is Roadmap 558565, inline DLP for prompts in Microsoft Foundry apps and agents, in preview now with GA in June 2026. The next section is why.
Where is Microsoft heading with this?
Microsoft is making Purview the control plane for AI it does not own. The ChatGPT Enterprise and Claude connectors, sitting next to Foundry and Entra-registered apps in the Enterprise AI apps bucket, are the signal. The strategy is to be the single pane where a compliance team governs Copilot, the OpenAI stack, and the Anthropic stack from one console, regardless of whose model is underneath.
The depth gap between the two connectors tells you the sequencing. ChatGPT Enterprise has the full compliance suite because the OpenAI relationship and the connector are older and the demand was loudest. Claude shipped thin and will thicken. Expect classification, eDiscovery, and retention to reach the Claude connector over the next few release waves, and expect a third and fourth model provider to appear in that same bucket on the same Compliance API pattern. The pattern is the product. Each new model vendor that exposes a compliance API becomes another row Microsoft can light up without writing a bespoke integration.
Watch the DLP column specifically, because that is where the next move shows up. Today it is an X for every connector, since the connector only reads. But Microsoft is already shipping inline, preventive prompt DLP to Microsoft Foundry apps and agents through the Purview processContent API (Roadmap 558565, GA June 2026), and Foundry sits in the same Enterprise AI apps bucket as ChatGPT Enterprise and Claude. The mechanism that turns the X into a checkmark already exists. It needs the AI app to honor an inline Purview API call, which Foundry does because Microsoft builds it. The open question is whether OpenAI and Anthropic adopt the same processContent integration, or whether enforcement for their apps stays on the edge plane permanently. The first third-party app that honors inline Purview DLP is the moment this category changes.
What this displaces is the standalone AI-governance and AI-DLP startup category that spent the last 18 months selling a single console for visibility across ChatGPT, Claude, and Gemini. Microsoft is folding that console into Purview for the apps it can reach by API, and into the edge DLP planes for the apps it can only reach by browser. The independent AI-observability vendors now have to justify why a separate console beats the one already wired to your audit log, your IRM, and your eDiscovery.
The CISO question worth raising internally: when your team says Claude and ChatGPT are “covered,” ask which control they mean, because today the connector can prove what your people sent and cannot stop what they send next, and those are two different promises to your board.
What to do this week
Open DSPM for AI and check which bucket your AI apps are actually in. If ChatGPT Enterprise or Claude shows under Enterprise AI apps, confirm whether the connector is configured or whether you are only seeing browser-detected activity from the Other AI apps path. They look similar on the dashboard and mean very different things.
Confirm pay-as-you-go billing consent in Purview before you promise anyone a connector. No PAYG, no scan. Have that conversation with finance now, not after you have committed a date.
For ChatGPT Enterprise, start the OpenAI key-scoping email today. Send the request to support@openai.com with the key’s last four digits, name, creator, and the read scope. It gates the whole deployment and depends on a human at OpenAI.
For Claude, verify Enterprise versus Platform before scoping the work. If your real exposure is developers on the API, the connector will not capture conversation content, and you should set that expectation before you build the project plan.
Run the discovery KQL after your first sync and write down the real record types. Build your Insider Risk and hunting logic on what the connector actually emits in your tenant.
Separate the two work streams on your roadmap. One line item for the connector (the compliance record). One for endpoint, browser, and network DLP against AI sites (the prevention). Do not let either be mistaken for the other in your steering committee deck.
Sources
Microsoft Purview data security and compliance protections for generative AI apps: https://learn.microsoft.com/purview/ai-microsoft-purview
Manage data security & compliance for ChatGPT Enterprise: https://learn.microsoft.com/purview/ai-chatgpt-enterprise
Connect to and manage ChatGPT Enterprise AI interactions in Microsoft Purview (preview): https://learn.microsoft.com/purview/archive-chatgpt-interactions
Manage data security & compliance for Anthropic Claude (Enterprise): https://learn.microsoft.com/purview/ai-claude-enterprise
Set up a connector to manage Anthropic Claude data: https://learn.microsoft.com/purview/manage-anthropic-data
Manage data security & compliance for other AI apps: https://learn.microsoft.com/purview/ai-other-apps
Considerations for DSPM for AI: https://learn.microsoft.com/purview/dspm-for-ai-considerations
Learn about Microsoft Purview billing models: https://learn.microsoft.com/purview/purview-billing-models
Anthropic, Access the Compliance API: https://support.claude.com/articles/13015708-access-the-compliance-api
What’s new in Microsoft Security, May 2026: https://www.microsoft.com/en-us/security/blog/2026/05/21/whats-new-in-microsoft-security-may-2026/
Microsoft 365 Roadmap, enforcement (edge plane): 518642 (inline DLP for file uploads to GenAI in Edge), 522095 (network DLP via non-Microsoft SASE), 557976 (inline network + Edge policy options), MC1046161 (inline prompt controls for AI apps in Edge)
Microsoft 365 Roadmap, visibility and detection: 492623 (collection policies for Enterprise AI app interactions), 559992 (IRM AI app selection), 560599 (IRM view AI interaction messages), 557548 (IRM pay-as-you-go for other AI apps)
Microsoft 365 Roadmap, signal to watch: 558565 (inline DLP for prompts in Microsoft Foundry apps and agents)
Microsoft 365 Roadmap: https://www.microsoft.com/en-us/microsoft-365/roadmap
Caleb McDowell is a Microsoft Security evangelist and highly certified practitioner. He runs a Microsoft Security Services practice helping organizations deploy and operationalize the Microsoft E5 security stack. Follow on LinkedIn or subscribe at calebamcdowell.substack.com.