Microsoft 365 Copilot Audit Logs: What a CopilotInteraction Record Actually Contains

Turn auditing on in a Microsoft 365 tenant and Copilot logging comes with it. Microsoft's documentation is explicit that Copilot audit records are part of Audit (Standard) and that "if your organization enables auditing, you don't need to take extra steps to configure auditing support for Copilot and AI applications." I want to walk through what one of those records holds field by field, because the fields it carries and the field it omits shape what a security team can prove after an incident.

TL;DR

• Purview writes an audit record with Operation: CopilotInteraction for every Microsoft 365 Copilot prompt, automatically, under Audit (Standard).
• The record carries AccessedResources with per-resource SensitivityLabelId and XPIADetected, plus AppHost, AppIdentity, AgentId, and ModelTransparencyDetails.
• The Messages property holds message IDs and boolean flags such as IsPrompt and JailbreakDetected, not the prompt text itself. Prompt and response content lives in the user's Copilot activity history, reached through Content Search or eDiscovery.
• Third-party AI apps log under AIAppInteraction on pay-as-you-go billing with 180-day retention, and only if you enable those features.

The fields inside a CopilotInteraction record

The single most useful property is AccessedResources. Microsoft describes it as "references to all resources (files, documents, emails, etc.) which Copilot accessed in response to the user's request," and each entry carries an ID, a SiteUrl, a Type, a human-readable Name, an Action such as read or modify, a Status of success or failure, and two fields that matter more than the rest.

SensitivityLabelId records the Purview sensitivity label on each resource Copilot pulled in, which Microsoft notes is "helpful in identifying whether Copilot accessed any sensitive information while generating its response." XPIADetected is a boolean flagging whether a cross-prompt injection attack was detected in that specific resource. A grounding document carrying injected instructions gets marked at the resource level, which is a genuinely well-designed piece of telemetry and the sort of thing I wish more vendors shipped.

AppHost identifies where the interaction happened, with values including BizChat, Word, Excel, Teams, Outlook, SharePoint, and around thirty others. AppIdentity follows a workloadName.appGroup.appName structure, so a first-party interaction reads Copilot.MicrosoftCopilot.Microsoft365Copilot and a Copilot Studio agent reads Copilot.Studio.<appId>. AgentId and AgentName name the declarative or custom-engine agent involved, with values like CopilotStudio.Declarative.8ad83f3e-b424-4d54-8ddb-15dc19247088.

ModelTransparencyDetails is newer and worth checking. Records can now include entries such as ModelProvider: OpenAI, ModelName: gpt-55-high or ModelProvider: Anthropic, ModelName: claude-sonnet-4-6 when a user picks a specific model rather than Auto. Under Auto, Microsoft notes the provider and model name "might not be available for every request."

The prompt text is not in the audit record

The Messages property is where people expect to find the conversation, and it holds something narrower. Microsoft's example shows the shape plainly: a Messages array holding two objects, the first with an ID of 1715186983849 and isPrompt set to true, the second with an ID of 1715186984291 and isPrompt set to false.

An ID, a boolean marking prompt versus response, and two flags: JailbreakDetected on the prompt message, and Size, which Microsoft says is "currently not used."

The content itself sits in the user's Copilot activity history. Microsoft stores the prompt and the response, including citations, encrypted, alongside the tenant's other Microsoft 365 content, and admins reach it through Content Search, Microsoft Purview, retention policies for Copilot, or the Teams Export APIs for Teams chats. Users can delete their own Copilot activity history from the My Account portal.

That separation matters operationally. Reconstructing a single incident means correlating an audit record from one system with content from another, under a different access process, with a retention policy set separately, and with the user holding a deletion button on one half of the pair.

Web grounding and plugin visibility

One detail worth putting in a runbook: to determine whether Copilot reached the public web for a given interaction, check the AISystemPlugin.Id property on the CopilotInteraction record. It contains the value BingWebSearch when the request used the public web through Microsoft Bing for additional data. AISystemPlugin more generally records the name, ID, and version of any plugin Copilot used to build the response.

Where the boundary ends

Three record types split the world. CopilotInteraction covers Microsoft-developed Copilot applications. ConnectedAIAppInteraction covers custom-built Copilots and third-party AI applications registered inside the organization, with AppIdentity values like ConnectedAIApp.Entra.AppId. AIAppInteraction covers third-party AI applications that are not deployed within the organization at all, audited through network or browser DLP, with values like AIApp.SaaS.AppName.

That third category is the one to read carefully. Microsoft states directly that "your enterprise subscription doesn't include audit logs for this type of user interaction," that it falls under pay-as-you-go billing, that retention runs 180 days, and that "you need to enable pay-as-you-go features to turn on these logs." Consumption is charged per audit record ingested.

An employee pasting a customer contract into an unmanaged consumer chatbot produces no record at all unless the tenant has enabled pay-as-you-go auditing and has network or browser DLP positioned to observe it. That is the same visibility problem covered in shadow AI detection and in how to find shadow AI across an enterprise, arriving through Microsoft's own billing model rather than through a missing feature.

What the record proves and what it does not

A CopilotInteraction record proves that a named user, in a named host app, prompted Copilot at a timestamp, that Copilot read a specific list of files carrying specific sensitivity labels, and that a specific model provider served the response. That is a workable evidentiary position inside Microsoft's own surface, with the per-resource SensitivityLabelId doing most of the work.

What the record cannot establish is whether the request should have been permitted. Copilot evaluated the user's existing Microsoft 365 permissions and proceeded. No policy decision, no policy version, and no allow-or-block outcome bound to a rule appears anywhere in the record, because no such evaluation happened on the request path. The same design shows up across the category, described in the post-authentication gap and visible in the equivalent Microsoft 365 Copilot data-loss controls.

DeepInspect

This is the gap DeepInspect closes. DeepInspect runs inline as a stateless proxy in front of HTTP AI traffic, so every request from an authenticated user or agent to an LLM endpoint gets evaluated against policy before it reaches the model, across Microsoft-hosted and non-Microsoft endpoints in the same tenant.

The record DeepInspect writes carries the authenticated principal, the role that principal held, the classification of the data inside the prompt, the policy version in force, and the allow-or-block decision, signed per decision. Purview keeps doing what it does well inside the Microsoft boundary, recording which files Copilot touched and which labels those files carried. DeepInspect covers the traffic Purview prices as pay-as-you-go or never sees, and adds the decision record that turns an activity log into audit evidence. Book a technical deep dive at deepinspect.ai.