Auditing Microsoft 365 Copilot: What's Logged and Kept

“Can we actually see what Copilot did?” is a question I hear often from security and compliance teams. The short answer: yes — for supported experiences, when auditing is on (it’s on by default for E3/E5). The catch: the controls live in Microsoft Purview, not the Microsoft 365 admin center where most people look first.

Here’s what I could piece together from the current Microsoft documentation — what’s logged in a single Copilot interaction, where to find it, how agents and apps show up, who’s actually allowed to read prompts, and how long audit records are kept.

Quick links: TL;DR · The big picture · What’s in one record · Where to look · Apps & agents · Beyond audit · Where the data lives · Before you search · Privacy · Troubleshooting · FAQ

TL;DR

• Supported Copilot interactions are logged to the Microsoft Purview audit log as CopilotInteraction records by Audit (Standard) — when auditing is on (on by default for E3/E5).
• It lives in Microsoft Purview (purview.microsoft.com), not the Microsoft 365 admin center.
• The record identifies a lot — the prompt and response messages, the files and sites Copilot used (with sensitivity labels), the app and any agent, and whether it used the web. The prompt/response text is stored separately and needs extra permissions to read.
• Three related Purview workflows help — not one datastore: Audit searches the events, DSPM for AI shows a dashboard, and eDiscovery searches — and can delete — the mailbox-backed content.
• Agents are audited too, and Purview can also audit supported non-Microsoft AI apps (ChatGPT, Gemini) once the required collection is set up.
• Reading prompt/response text needs extra Purview permissions — being a manager, or a general admin, doesn’t grant it by itself.
• Retention follows your licence: E3 = 180 days, E5 ≈ 1 year.

The big picture

Here’s the mental model I use. A single Copilot interaction isn’t just “a chat message” — it’s a rich record that can surface across several Microsoft Purview tools, each answering a different question.

The rest of this guide walks each of those boxes.

What’s captured in a single interaction

When a user interacts with Copilot, Purview writes a CopilotInteraction audit record. The record includes more than a timestamp — these are the fields I found most useful:

• The prompt and the response. The Messages field identifies the prompt and response messages by ID, marks each with IsPrompt, and can carry a JailbreakDetected flag when a prompt looks like a jailbreak attempt. (The message text isn’t stored in this record — it’s retrieved separately, behind the permission gate covered below.)
• The files and sites Copilot used. AccessedResources lists every resource Copilot touched to answer — file, email, meeting — including its SensitivityLabelId, the Action (read/create/modify), whether a policy blocked it (PolicyDetails, Status), and XPIADetected (a flag for potentially malicious instructions — a cross-prompt-injection attempt — detected in that content).
• Where the user was. Contexts records the file, Teams chat, or meeting the interaction happened in.
• The app. AppHost tells you the surface (more on that below).
• The agent. AgentId, AgentName, and AgentVersion when an agent was involved.
• Web + plugins. AISystemPlugin — for example an Id of BingWebSearch — tells you web grounding was used. The exact generated query isn’t in this field; it’s surfaced separately in supported Purview experiences.
• DLP signals. DLPEvaluationDeferred is a bitmask showing which data-loss-prevention evaluations couldn’t complete immediately and were deferred for later — Prompt, Response, Grounding, or WebGrounding.
• Model & record classification. ModelTransparencyDetails identifies the model provider, and Operation / RecordType / Workload distinguish first-party Copilot (CopilotInteraction / Copilot) from connected apps (ConnectedAIAppInteraction) and unmanaged third-party AI (AIAppInteraction).

You can see the raw shape of this in the audit log itself. Here’s a single record opened up, and its expandable CopilotEventData:

One Copilot interaction, opened in the audit log. (Lab demo data — identifiers redacted.)

Inside CopilotEventData — the app, the resources Copilot accessed, and the message data. (Lab demo data — user and URLs redacted.)

Where to look in Purview

Three surfaces. They can each investigate the same interaction, but they play different roles — Audit searches the audit events, DSPM for AI presents AI activity, and eDiscovery searches the stored prompt and response items (which live in user mailboxes, under their own retention).

1. Purview Audit — search the audit trail

This is the searchable Microsoft Purview audit log — the record that an interaction happened. Go to Purview → Audit → Search, filter by the CopilotInteraction record type (or the Copilot activities group), set a date range, and run it.

Microsoft Purview → Audit. This is the home of Copilot’s audit records — not the Microsoft 365 admin center. (Lab demo data.)

Audit results filtered to CopilotInteraction. (Lab demo data — user and IP columns redacted.)

Prefer the command line? You can pull the same records with Search-UnifiedAuditLog in Exchange Online PowerShell and export them for analysis.

2. DSPM for AI — the friendly dashboard

If reading raw records isn’t your idea of fun, Purview’s DSPM gives you the same story as a dashboard. Depending on your tenant you’ll open DSPM or DSPM for AI (classic) → Activity explorer → AI activities, with filters for web search, agents, app, and sensitivity.

DSPM for AI → Activity explorer. Note the Web searched and Agents involved filters. (Lab demo data.)

Open a single AI interaction and you get a clean, readable view of the app, the plugins it used, the user’s risk level — and, if you’re permitted, the prompt and response themselves:

A single interaction. The BingWebSearch plugin tells you this answer used the web. (Lab demo data — Client IP redacted.)

DSPM can display the prompt, the response, and the files Copilot used to viewers who have the required permissions. Note the “permissions to view prompts and responses” link. (Lab demo data — SharePoint URL redacted.)

Open a whole app rather than a single interaction, and DSPM rolls the same data up — including the sensitivity labels and file types Copilot referenced over the last 30 days. It’s a quick way to spot when Copilot is reaching into sensitive content.

The per-app “Referenced content” rollup — the sensitivity labels and file types Copilot touched. (Lab demo data.)

3. eDiscovery — for legal and investigations

For legal hold and investigations, Purview → eDiscovery can search Copilot interactions — and, when you need to, delete them (for example to clean up a data-spillage event). It’s a proper workflow with its own storage, roles and hold behaviour, so I’ve given it its own section below.

How apps and agents show up

One detail I found genuinely useful: it isn’t only “Copilot Chat” that’s logged — supported apps and agents show up too. Here’s a real activity list from a lab tenant:

One list, many surfaces: Business Chat, Word, Copilot Studio — and named agents like a Word Drafting Agent. (Lab demo data — user column redacted.)

Want the bird’s-eye view instead? DSPM → Discover → Apps and agents lists the AI apps and agents Purview has found, each with a protection status — first-party Copilots, the agents your team builds, and third-party tools, all in one place.

In this configured lab tenant the inventory shows Microsoft Copilots, custom agents, and ChatGPT Enterprise as Monitored — third-party coverage depends on the required connector or browser collection plus pay-as-you-go setup. (Lab demo data.)

Which app? AppHost identifies the host category, but not always the exact client — BizChat and Bing, for instance, can each map to several clients:

Which agent? When an agent is involved, the record carries AgentId, AgentName, and AgentVersion. Copilot Studio agents show identifiers like CopilotStudio.Declarative.<guid> or CopilotStudio.CustomEngine.<guid>. For Microsoft Agent 365, Microsoft’s guidance is simply: “audit an agent instance as you would a user” — covering human-to-agent, agent-to-human, agent-to-tool, and agent-to-agent interactions.

Which Copilot? The AppIdentity field distinguishes first-party Copilots (Copilot.MicrosoftCopilot.Microsoft365Copilot, Copilot.Security.SecurityCopilot, Copilot.Fabric.CopilotforPowerBI), Copilot Studio apps, and third-party apps — so Copilot in Fabric or Security Copilot are audited too, not only Microsoft 365 Copilot.

It’s not only Microsoft’s AI

Purview groups AI apps into three buckets, and can audit across all of them:

• Copilot experiences & agents — Microsoft 365 Copilot, Security Copilot, Copilot in Fabric, Copilot Studio.
• Enterprise AI apps — Microsoft Foundry, Entra-registered apps, ChatGPT Enterprise, Anthropic Claude (Enterprise).
• Other AI apps — third-party tools detected through browser activity (via Microsoft Defender for Cloud Apps), such as ChatGPT, Google Gemini, consumer Copilot, and DeepSeek.

Those non-Microsoft interactions land under the ConnectedAIAppInteraction and AIAppInteraction record types, billed pay-as-you-go with 180-day retention. The unmanaged apps in particular rely on browser-activity detection through Microsoft Defender for Cloud Apps, so this isn’t automatic — it needs the right connector or collection set up first. With those prerequisites in place, Purview can extend the same auditing to supported non-Microsoft AI apps in scope.

Beyond audit: the other Purview tools

Auditing is the front door, but Microsoft 365 Copilot interactions are supported across a whole set of Purview solutions (they don’t all use one datastore). Each is supported for Copilot:

One detail worth calling out: admin activity is audited too. Changes to Copilot settings, plugins, and promptbooks (operations like UpdateTenantSettings, CreatePlugin, EnablePromptBook) are logged alongside user interactions — handy for change tracking and investigations.

Where the data lives — and can you delete it?

If you’re in legal, compliance or security, the audit trail is only half the question. The other half is: where does the actual prompt-and-response content sit, who can pull it, and can we remove it? Here’s the honest picture.

Where it’s stored. Every Copilot prompt and response is kept in a hidden folder in the user’s own Exchange Online mailbox — the same substrate that holds Teams messages. In Microsoft’s words: “Data from generative AI messages is stored in a hidden folder in the mailbox of the user who runs the AI app.” That folder isn’t meant for users or admins to open directly; it exists so compliance tools can reach it. Each turn is stored as an individual message-class item (for example IPM.SkypeTeams.Message.Copilot.BizChat).

What eDiscovery shows. In Purview → eDiscovery, you create a case, search the user’s mailbox, and add a condition — Type → Copilot activity, or a specific item class. Copilot turns come back looking like little emails: a prompt item (from the user, to the Copilot app identity) and a response item (from the Copilot app, back to the user), including the citations to whatever grounded the answer. You can preview, review and export them (as PST, individual messages, or via Microsoft Graph) — much like mail.

Here’s that whole path in my lab, end to end — from finding eDiscovery to reading a stored Copilot turn:

1) eDiscovery lives in Purview → Solutions — not the Microsoft 365 admin center. (Lab demo.)

2) Create a case — it’s just a container. Flip on eDiscovery (Premium) to unlock searchable query conditions. (Lab demo.)

3) Every case has the same tabs: Searches finds the data, Hold policies preserve it, Review sets and Exports get it out. (Lab demo.)

4) Point the search at the user’s mailbox — that’s where their Copilot turns live. (User details redacted; lab demo.)

5) The KeyQL condition itemclass:IPM.SkypeTeams.Message.Copilot* returns only Copilot turns — “0 errors detected” means it’s valid. (Data-source names redacted; lab demo.)

6) The payoff: each turn is stored like a little email — a prompt item and a response item — and opening one reveals the actual prompt and response text. (Content redacted; lab demo.)

Can it be deleted? Yes — three ways, all generally available:

• On a schedule — a retention policy for the Microsoft Copilot experiences location expires the data automatically. (That’s a newer, separate location — Copilot used to share the Teams chats one.)
• By the user — people can clear their own Copilot history from the My Account portal (myaccount.microsoft.com).
• By an admin — the eDiscovery search-and-delete workflow (built for data-spillage cleanup) removes matching items via Microsoft Graph, up to 10 per mailbox at a time.

The scheduled route is worth seeing, because it shows Copilot has its own place in retention now:

Retention policy → locations: Microsoft Copilot experiences is its own toggle, separate from Teams chats. (Lab demo.)

Set a period, then Delete items automatically — that’s the scheduled expiry that eventually clears the stored Copilot turns. (Lab demo.)

And the user’s own delete looks like this — first the compliance-facing route in the My Account portal, then the everyday one inside the Copilot app:

A user’s self-service delete: My Account → Settings & Privacy → Privacy → Copilot activity history → Delete history. (Profile details redacted; lab demo.)

The everyday version: inside the Copilot app, the ⋯ → Delete on a conversation clears that chat. Handy to know — but remember, neither of these wipes the compliance copy if a hold applies. (Lab demo.)

But holds win. Deleting isn’t always gone-for-good. Removed Copilot items move to a hidden SubstrateHolds folder and wait there for a timer job to purge them (roughly 1–7 days) — unless a retention policy, Litigation Hold or eDiscovery hold is in force, in which case permanent deletion is suspended and the content stays discoverable. Even when someone leaves and their account is deleted, held Copilot data moves to an inactive mailbox and remains searchable. So a user “clearing their history” does not wipe the compliance copy.

Who can actually get to it. Reading and exporting Copilot content in eDiscovery needs real eDiscovery roles, not a general admin hat: the eDiscovery Manager role group to create a case and search, Reviewer / Preview rights to read content in a review set, and the Search And Purge role (in Organization Management or Data Investigator by default) to delete. It’s a small, deliberate set of people.

Purview → Settings → Roles and scopes → Role groups: eDiscovery Manager and eDiscovery Reviewer are dedicated role groups — reading Copilot content isn’t something a general admin can just do. (Lab demo.)

One licensing note. Content search, hold and export of Copilot interactions is available from Microsoft 365 E3 + the Copilot add-on upward; the richer premium eDiscovery search for Copilot needs E5 + Copilot (or the Purview add-ons). The Copilot add-on is the key that unlocks the Copilot-specific rows.

Before you search

A short checklist so your first search actually returns something:

• Auditing must be on. It’s on by default for Microsoft 365 E3 and E5. On Business plans it may be off — open Purview → Audit and select Start recording user and admin activity if you see that banner. (PowerShell equivalent: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true.)
• The user needs access to the relevant Copilot experience and must have generated activity in your date range — otherwise there’s no record to find.
• You need the right role — the Audit Logs role to search the audit log, and additional roles to read prompt/response content (see below).
• Retention follows your licence — E3 keeps 180 days; E5 / E5 Compliance keeps about a year with more options.
• Give it a little time — new activity can take a while to appear.

Privacy: who can actually read prompts?

This is the question employees quietly worry about, and it deserves a straight answer.

The fact that an interaction happened is in the audit trail — but reading the actual prompt and response text needs additional, specific Microsoft Purview permissions. Those permissions exist for auditing, eDiscovery, and compliance work, and being someone’s manager doesn’t by itself provide them. You can see the guardrail in the product: the interaction view links out to “permissions to view prompts and responses.”

So a fair summary for your users: your Copilot activity is logged for compliance; the prompt and response content is stored separately and can be read only by people with the required Purview permissions — and being your manager isn’t one of them.

Troubleshooting: why you see nothing

If a search comes back empty, it’s usually one of these:

• If only the web-query results are empty: Copilot only writes a web query when it actually used the public web — many prompts won’t have one.
• If the whole search is empty, work through these: auditing may be off (common on Business plans — turn it on, then wait); the user may not have used the relevant Copilot experience in your date range; the date range may be too narrow; or the data may simply not have propagated yet.
• DSPM for AI needs time — allow at least 24 hours for new DSPM policies and reports to collect data.

A reply you can copy

If someone asks you the short version:

Supported Copilot interactions are logged in Microsoft Purview (not the M365 admin center), as long as Purview Audit is on — which it is by default on E3/E5. The CopilotInteraction record identifies the prompt and response messages, the files/sites Copilot used, the app, and any agent; the actual prompt/response text is retrieved separately and needs extra Purview permissions. Read the records in Purview → Audit (filter CopilotInteraction), or in DSPM for AI → Activity explorer for a friendlier view. Agents are covered too, and supported non-Microsoft AI apps can be audited once set up. Retention is 180 days on E3, about a year on E5.

Common questions

How can I prove logging works — a quick smoke test? Generate one test interaction, then in Purview → Audit search by that user, a narrow date range, and Copilot activities. Open the event and check Messages, AppHost, and any AccessedResources. If they’re there, logging is working.

Does “supported” mean it’s included in my licence? Not necessarily. “Supported” means a capability works for Copilot interactions; whether you have it depends on your licence. Basic audit comes with E3; advanced eDiscovery, longer retention, DLP for prompts, and Insider Risk generally need E5 or the E5 Compliance add-on.

Are the audit record and the prompt/response content kept and deleted together? No — they’re separate. The audit event follows audit retention (E3 180 days, E5 ≈ 1 year). The prompt/response content is mailbox-backed and follows its own retention and hold policies — that’s what eDiscovery searches.

Where is the actual prompt/response content stored? In a hidden folder in the user’s own Exchange Online mailbox — the same place Teams messages live. It’s not meant to be opened directly, but compliance tools like eDiscovery can search it.

If a user clears their Copilot history, is it gone? Not from a compliance point of view. It moves to a hidden SubstrateHolds folder, and while any retention policy, Litigation Hold or eDiscovery hold applies, it stays preserved and discoverable — even in an inactive mailbox after the person leaves.

Can my manager read my prompts? Not by default. Reading prompt/response content needs specific Microsoft Purview permissions, meant for auditing and compliance — being a manager doesn’t itself grant them.

What about ChatGPT or Gemini? Purview can audit connected and unmanaged third-party AI apps too (ChatGPT, Gemini, DeepSeek — the unmanaged ones detected via Defender for Cloud Apps), with 180-day pay-as-you-go retention. It isn’t automatic — it needs the right connector or collection first.

Related reading

• Copilot Control System — the complete guide — which admin portal owns which control.
• SharePoint oversharing controls for Copilot — what Copilot can and can’t surface.
• Copilot deployment best practices — the checklist — where auditing fits in a rollout.

Sources

• Audit logs for Copilot and AI applications — the record schema, AppHost, AgentId, AccessedResources, record types.
• Microsoft Purview data security and compliance protections for Copilot and generative AI apps — the AI app categories.
• Use Microsoft Purview to manage data security & compliance for Microsoft 365 Copilot — the capabilities-supported table.
• Use Microsoft Purview to manage data security & compliance for Microsoft Agent 365 — auditing agents.
• Data Security Posture Management (DSPM) for AI
• Audit log activities — Copilot activities
• Search for and delete AI application data in eDiscovery — where Copilot data is stored, and how to search or delete it.
• Learn about retention for Microsoft Copilot — storage, holds, and the SubstrateHolds lifecycle.
• Turn auditing on or off
• Data, privacy, and security for web search in Microsoft 365 Copilot