Purview DLP Isn’t Just Watching Copilot Anymore
For a while now, Microsoft has been steadily improving the visibility organizations have into how employees are using AI. The Microsoft 365 admin center provides reporting around Microsoft Copilot adoption and usage, including active users, prompts submitted, and usage across Microsoft 365 applications. But the broader, and arguably more interesting, picture emerges when you look across Microsoft DLP and the entire security and compliance stack.
Microsoft Defender for Cloud Apps can help organizations discover which generative AI applications employees are using, assess those applications, and designate them as sanctioned or unsanctioned. Microsoft Purview Data Security Posture Management for AI goes deeper into the data side of that equation, providing visibility into user interactions and whether sensitive information is being sent to AI apps.
That visibility becomes particularly important as organizations try to get their arms around shadow AI, which Microsoft describes as the use of AI tools without the knowledge, approval, or governance of IT or security teams. But visibility and control are two very different things. Knowing which AI tools employees are using is helpful. Understanding the information they’re sharing with those tools, and being able to do something about it, is where this conversation gets much more interesting.
I posted this evening about Microsoft Purview DLP being able to inspect what people type into Microsoft 365 Copilot and block sensitive prompts before Copilot processes them. Someone responded with exactly the question I should have anticipated: Does this extend to other GenAI services like Grok, Claude, Perplexity, etc.?
The short answer is yes, but with an important asterisk.
From visibility to enforcement
Microsoft’s own guidance for addressing shadow AI essentially follows a progression from discovery to enforcement. Organizations can discover and monitor AI application usage, identify potentially sensitive interactions, block access to unsanctioned AI apps, and prevent sensitive information from being sent to sanctioned ones.
That’s an important distinction because discovery tells you which AI applications people are using, while DLP helps determine what information they’re allowed to give them. Knowing that employees are experimenting with an external AI service is interesting, but knowing whether they’re pasting customer information, source code, contracts, financial information, or other sensitive data into it is much more important. You need to be able to take action. Being able to intervene is where AI governance starts becoming operational rather than observational.
Copilot gets the native treatment
With Microsoft 365 Copilot, Microsoft has the advantage of controlling much more of the experience, which creates opportunities to integrate Purview controls directly into those AI interactions. The larger point is that the potential data-loss path has changed. DLP has traditionally focused on information moving through documents, email, applications, and endpoints. AI introduces another path: the prompt itself.
Someone doesn’t have to email a spreadsheet or deliberately upload a sensitive document anymore. They can simply copy information into an AI conversation and ask the model to analyze, summarize, rewrite, or otherwise work with it. That makes the conversation itself another surface organizations need to consider as part of their information protection strategy.
What about ChatGPT, Claude, Gemini, and everything else?
This is where the answer becomes more nuanced. Microsoft’s shadow AI guidance brings together Microsoft Defender for Cloud Apps, Microsoft Purview, Microsoft Entra, and Microsoft Intune as part of an approach for discovering AI use and reducing the risk of data leakage. But that doesn’t mean every third-party AI service receives exactly the same native integration as Copilot.
Instead, Microsoft can create other enforcement points. Its guidance describes using Microsoft Purview Endpoint DLP to identify sensitive information pasted or uploaded to AI application websites, while Microsoft Purview Browser Data Security can detect sensitive information shared in AI prompts within Microsoft Edge.
I think that’s the architectural shift worth paying attention to. The policy doesn’t necessarily have to reside inside the AI application. Organizations can potentially protect the data interaction as information moves through the endpoint or browser into an AI service.
Supported doesn’t mean identical
It’s tempting to turn this discussion into a chart of AI services with green checkmarks next to Copilot, ChatGPT, Claude, Gemini, Grok, and Perplexity. But that would oversimplify what is actually happening. Support for third-party AI shouldn’t automatically be interpreted as feature parity with Microsoft 365 Copilot.
Instead, organizations need to ask which AI service is being used, which Purview capability applies, where enforcement occurs, and which policies have been configured. It’s a more complicated answer than simply asking whether Purview supports a particular AI tool, but it’s also a much more useful governance conversation.
However, it does give me an idea for a new infographic…
This is bigger than Copilot governance
For the past couple of years, many organizations have framed AI governance primarily as a Copilot deployment problem: How do we secure Microsoft 365 Copilot? Increasingly, I think that’s the wrong question.
Employees aren’t going to use just one AI assistant. They’ll use Copilot, but they’ll also experiment with ChatGPT, Claude, Gemini, Perplexity, Grok, specialized AI applications, agents, and whatever comes next. Trying to build an entirely separate governance strategy around every new AI tool doesn’t scale.
What Microsoft’s emerging approach suggests is something much more sustainable: govern the data interaction, not just the AI application.
Discovery can tell you which AI tools are appearing in the environment. DSPM for AI can provide visibility into sensitive interactions, while DLP and related controls can provide ways to enforce policy around those interactions. The strategic question therefore starts shifting from“Which AI tools do we allow?” to“What information are we willing to let leave our control, regardless of which AI tool someone is using?”
It still comes back to classification
There’s a catch, of course. None of this eliminates the information governance work organizations have been putting off. If anything, AI makes that work considerably more important.
Sensitive information types, sensitivity labels, DLP policies, endpoint protections, application governance, and device management increasingly provide the foundation for deciding what information requires protection. AI hasn’t replaced those disciplines. It has created another increasingly important destination for the information they were designed to protect.
Which brings me back to my original point. If you haven’t reviewed your sensitive information types lately, now would be a very good time.
Because the next generation of DLP isn’t simply watching your files. It’s starting to watch the conversations we have with AI, and those conversations are quickly becoming another way that enterprise data moves.
