Microsoft 365 Copilot: what Purview covers and what still needs evidencing

If you run a Microsoft-centric estate, Microsoft 365 Copilot is probably already woven into Word, Excel, Outlook and Teams for at least some of your people. The natural next question from audit, risk and compliance is: can we show what it did, on what data, and that our controls held? Much of that question is answered inside Microsoft's own stack. Some of it is not. This article sets out what Microsoft Purview covers for Copilot, where the gaps appear once you look beyond the Microsoft world, and how Evaident fits alongside Purview rather than on top of it.

What Purview already does well for Copilot

Microsoft Purview is the governance layer for the Microsoft 365 estate, and Copilot is a first-class citizen within it. If you have invested in Purview, you already have meaningful coverage for Copilot interactions that happen inside Microsoft apps.

In practice, Purview gives you:

• Data loss prevention (DLP) that applies to Copilot, so sensitive content can be kept out of responses and risky flows can be restrained.
• Data classification and sensitivity labels, so Copilot respects the labels and permissions already applied across SharePoint, OneDrive and Exchange.
• Audit logging of Copilot activity, captured alongside the rest of your Microsoft 365 audit trail.
• Real-time controls, including the ability to block or constrain Copilot behaviour as it happens.

That last point matters and is worth stating plainly. Real-time blocking of Copilot stays with Purview, and that is the right place for it. Copilot runs inside Microsoft's own applications and services. A third party cannot sit in the middle of that traffic and intercept it the way a proxy might intercept a browser-based tool. Microsoft is the only party positioned to enforce controls at the moment of interaction. Any vendor claiming to block Copilot in real time from the outside should be treated with caution.

If your control objective is to prevent something inside Microsoft 365, Purview is where that control lives. Evaident does not try to change that.

Where the gap opens up

Purview governs the Microsoft world thoroughly. The difficulty is that almost no organisation lives entirely inside the Microsoft world.

Most firms running Copilot are also running some combination of the following:

• ChatGPT, Claude and Gemini, used directly through their own web apps or APIs.
• Browser-based AI features embedded in third-party tools and websites.
• Personal accounts, where staff reach for consumer AI on the side because it is convenient.
• In-house agents built on top of one or more model providers.
• Shadow AI more generally — usage nobody formally signed off.

Purview, by design, does not see this activity. It governs Microsoft 365, not the wider estate of AI tools your people actually touch during a working day. So when an auditor, a regulator or your own board asks for *the* record of how AI was used across the organisation, you are left assembling it from several places that do not share a format, a timeline or a verification method. Copilot activity sits in one system; everything else sits in others, or in no system at all.

This is a record-keeping and evidencing gap rather than a control gap. The controls inside Microsoft 365 may be excellent. The problem is producing a single, credible, cross-vendor account of AI usage that you can hand over and defend.

How Evaident complements Purview

Evaident's job here is narrow and deliberate: detect and evidence, not block. It does not duplicate Purview's real-time enforcement, and it does not try to.

For Copilot specifically, Evaident reads interactions through the Microsoft Graph export API and brings them into one tamper-evident record that also holds your ChatGPT, Claude, Gemini, in-house agent and shadow AI activity. The same record, the same timeline, the same verification — across vendors.

In its current phase, the Copilot connector stores metadata only. That means:

• The app and the app context in which Copilot was used.
• Counts of referenced items.
• Risk flags raised against the interaction.

It does not store prompt text. The aim at this stage is a defensible usage record, not a transcript archive, which keeps the evidence footprint proportionate and lower-risk.

Because that record spans every AI surface rather than just the Microsoft one, you can produce evidence packs that cover the whole estate. Those packs are hash-chained and independently verifiable: anyone you give them to can confirm the records have not been altered after the fact, without having to trust Evaident or take your word for it.

The result is a clean division of labour:

• Purview classifies, applies DLP, audits within Microsoft 365, and blocks Copilot in real time.
• Evaident unifies the evidence across Copilot *and* every non-Microsoft AI tool into one tamper-evident, independently verifiable record.

Neither replaces the other. If you have Purview, keep it and keep investing in it. Evaident sits alongside it to close the cross-vendor evidencing gap that Purview was never meant to cover.

A practical way to think about it

A useful test is to ask two separate questions of any AI governance plan. First: *can we prevent the wrong thing happening inside Microsoft 365?* For Copilot, Purview is your answer. Second: *can we prove, across every AI tool in use, what happened and that our records are intact?* That second question is the one most Microsoft-centric teams find hardest, precisely because the answer lives in several disconnected places.

Evaident exists to make that second answer a single, verifiable artefact. It is built to support your compliance and audit obligations; it is not legal advice, and it does not stand in for your own regulatory judgement.

If you want to see where Copilot and your other AI tools are actually being used — and what that means for your evidence position — start with an exposure assessment.