You have spent the last however-many months getting Microsoft 365 Copilot under control. DSPM lights up with full visibility, policies are live, Insider Risk Management is watching, and eDiscovery can actually find the stuff legal asks for. Compliance is, for once, ahead of the business. Life is good.
Then marketing, or product, or whoever it is this quarter, shows up with a signed Claude Enterprise contract and a straight face: “It’s Enterprise, it has compliance built in, you’re covered.” And on paper that is a reasonable thing to believe. Anthropic does have a Compliance API. Purview does have a Claude connector. It does show up in the same DSPM dashboard as Copilot, right there next to it, looking equally green and equally governed. Except it isn’t. Whatever control you spent all that time building for Copilot does not just carry over to Claude because the two apps happen to share a dashboard.
Let’s walk through the three things you actually need to understand, in order: what Anthropic exposes on their side, what the Purview connector actually does with it, and what you are left with once it is running.
Part 1: Anthropic Compliance API
First we need to activate the Compliance API. This is done in the Claude Desktop app. Sign in as Organization Owner, go to Organization Settings, API and enable the Compliance API:
Then we need to create the API key. As we can see, four of the scopes in the list relate to the Compliance API. The rest of the list covers billing and organization administration and has nothing to do with compliance data:
Notice the pattern in the four that matter: three of them read data out, and only one does anything else. The API does let you permanently delete user data through the delete:compliance_user_data scope, but as we get to later in this article, deletion is not supported through the Purview data connector anyway. So we only need to activate the first three scopes in the list. Save the API key.
You will also want to set up SSO for your users, which means registering an Entra app for Claude so people can authenticate with the tenant ID. I recommend doing this first. Follow Anthropic’s own guide for that part, it has nothing to do with the Compliance API or Purview in itself.
Now that we the API key, we should test it. That confirms the key works, and we get insight into what data that is actually exposed from the Antropic side:
curl --fail-with-body -sS "https://api.anthropic.com/v1/compliance/activities?limit=1" --header "x-api-key: YOUR_COMPLIANCE_ACCESS_KEY"This call returns activity events: authentications, chat events, file uploads, admin actions, and audit events. It does not return the actual dialogues. An activity event is metadata about a chat, not the chat.
The actual dialogues live behind a separate family of endpoints. Normally you list chats for a user with GET /v1/compliance/apps/chats and then fetch one chat’s full content with GET /v1/compliance/apps/chats/{chat_id}/messages, but the activity event you just pulled already carries a claude_chat_id field, so you can jump straight to the content:
curl --fail-with-body -sS "https://api.anthropic.com/v1/compliance/apps/chats/CHAT_ID/messages" --header "x-api-key: YOUR_COMPLIANCE_ACCESS_KEY"That call returns a chat_messages array with the actual prompt and response text, message by message. The separation between the two endpoint families is deliberate, and it is a good design choice. Reading employees’ dialogues is a far more invasive than reading login events, and many countries have legislation that limits an employer’s access to exactly this kind of content. By putting the dialogues behind their own endpoint and their own scope, read:compliance_user_data, Anthropic makes the invasive level something you opt into explicitly rather than something that comes along with the activity feed. Keep that split in mind, because it maps directly onto a choice you are about to make on the Purview side.
Be aware that activities related to Claude Cowork is not available through the Compliance API. Anthropic states that plainly, so the connector will never see Cowork usage regardless of configuration. Claude Code runs on its own OpenTelemetry path. If your organization uses those, they need their own monitoring plan outside this connector. Not happy about that.
Part 2: The Purview data connector
The next part cover the Purview data connector. Let’s be clear about what this connector actually is, because a connector can be a lot of things. It’s not the kind of connector where an individual user links their own account to pull personal data out. It is an organization level, admin configured integration that calls Anthropic’s Compliance API on a schedule and pulls interaction data into Purview after the fact, and it is one directional by design, the same as every other data connector under Settings, Data connectors. Microsoft’s own connectors for HR data, Bloomberg, Slack, and Zoom archiving all work the same way: data flows in, nothing flows back out. There is no point in the flow where Purview can push a policy, a label, or a delete command back to Claude through this connector.
Also, before we configure the data connector, two prerequisites need to be in place. Pay-as-you-go (PAYG) billing needs to be enabled in Purview, under the DSPM solution, connected to an Azure subscription, since pulling Claude interactions into Purview runs on consumption based billing and the connector has nothing to bill the ingestion against without it. And whoever sets up the connector needs the Data Connector Admin role (if you are member of Compliance Administrator role group, you’re good to go).
With all that in place, setting it up is fairly straightforward:
In Purview, go to Settings, Data Connectors, All connectors. Select Anthropic Claude from the list and select Add connector.
Accept the Terms of service and give the connector a descriptive name.
Under Authentication, paste in the API key, select your organization ID and confirm the API Base URL (which defaults to https://api.anthropic.com):
Under Data scope, choose which data to import: Activity Feed and/or Chat Conversations, plus a sync frequency:
Remember when we explored the Compliance API endpoints? Well, here we see the data scope steps. Activity Feed maps to the activity endpoints, metadata only. Chat Conversations maps to the dialogue endpoints, full prompts and responses. Given the privacy weight of that second level, treat these as two separate decisions with two separate sign-offs: Activity Feed can reasonably be handled as an ordinary IT change, while Chat Conversations belongs with your privacy officer and possibly employee representatives before it is switched on.
Confirm that the connector shows a green status under Settings, My connectors. Now we wait. Data usually starts showing up in DSPM reports about a day after setup.
Part 3: What lands in DSPM
When data finally flows in, the Claude usage shows up in DSPM. The Reports page gives us total interactions over time and trends broken down by AI app, and Activity explorer, under the AI activities tab, holds the detailed events. Filter on AI app category equal to Enterprise AI apps and the app to isolate Claude activity. By the way, the Activity explorer in DSPM is far richer than the Activity explorer you find in other Purview solutions such as DLP, so this is the one to spend time in.
And the dataset is genuinely rich. With the Chat Conversations scope enabled, the actual dialogues show up in Activity explorer: the user’s prompt and Claude’s response, message by message, readable directly in the portal. Note that viewing the prompt and response text requires the right permissions on your Purview account, Microsoft’s own documentation is explicit about this, so if a colleague with the same setup only sees metadata, check their role before concluding the data is missing.
Interactions are also evaluated against sensitive information types, so you can see when a Claude conversation touched something that matches a SIT, credit card numbers, national ID numbers, or whatever your classifiers cover.
What you can regulate, and what you cannot
The insight is pretty good, but the regulation is a different story. Microsoft publishes a capability matrix for every AI app in Purview, and for the Claude connector it still looks like this:
The important thing is to read that table as a description of the connector, not of Purview as a whole. Every enforcement and compliance capability is a No: through the connector we can read the dialogues, but we cannot apply DLP to them, cannot flag the user in Insider Risk Management, cannot pull the conversation into a communication compliance review, cannot place it on eDiscovery hold, and cannot manage its retention.
A quick note on Data classification, because the table and the portal do not quite line up. Microsoft appears to have improved the integration during July, and in my own test tenant both the chat dialogues and SIT matches started showing up in DSPM on 22 July. So even though the matrix lists data classification as unsupported, you may well see sensitive information types surfacing on Claude interactions in Activity explorer. Treat the capability table as a snapshot rather than a fixed statement, verify what actually shows up in your own tenant, and expect the published matrix to lag behind what the integration does in practice.
So back to that colleague from marketing with the signed Enterprise contract. They were not wrong that Claude Enterprise has compliance features, but they were wrong about what that buys you inside Purview. The connector gives you real visibility: who is using Claude, when, the actual dialogues, and which sensitive information types show up in them. That is genuinely useful, and a year ago it did not exist. But visibility is not control. Every enforcement lever you built for Copilot, DLP, Insider Risk Management, communication compliance, eDiscovery, retention, stops at the connector’s edge.
The reason is architectural, not a matter of priority. Most of Purview’s compliance stack is built to operate on content that has been materialized inside a governed Microsoft 365 location, typically a mailbox item, so those tools can search, hold, and scan it the same way they already do for email and Teams chats. The Claude connector never creates anything like that. It authenticates straight to the Compliance API and writes into DSPM reporting and the unified audit log. There is no mailbox item and nothing for the rest of the compliance stack to attach to. Copilot gets the full stack because it runs natively inside the Microsoft 365 boundary. That is the honest baseline to measure Claude against.
That gap is not a reason to say no to Claude. It is a reason to have the honest conversation up front about what compliance actually means here. Seeing everything and being able to stop nothing is a defensible posture for some organizations and an unacceptable one for others, and that is a decision for the business and the privacy function to make together, not something a green checkmark on a dashboard settles on their behalf.