Hands testing audit log setup on laptop

Copilot Audit Logs: Where to Find and Read Them


Copilot audit events land in Microsoft Purview’s Unified Audit Log (UAL) by default, and prompt/response content becomes visible separately through Purview DSPM for AI once your team enables that capture layer. If you administer Microsoft 365 Copilot, GitHub Copilot, or Security Copilot at a law firm, accounting practice, or consulting shop, this is where your investigation starts, and where most gaps get discovered too late.

Before anything else, run two checks:

  • Confirm Audit (Standard) is capturing Copilot activity in your tenant and hasn’t been quietly disabled.
  • Verify you hold the Purview Audit or DSPM role needed to actually view CopilotInteraction records, not just the license to run Copilot itself.

Retention on many Business plans defaults to 180 days, and non-Microsoft AI auditing runs on a pay-as-you-go billing model. For SIEM-bound teams, Microsoft Sentinel is the common downstream target once records are exportable.

Pro Tip: Generate one throwaway Copilot prompt right now, then search Purview for that user and the last hour. If AccessedResources, Messages, and AppHost all show up, your logging pipeline works. If any field is missing, you have a configuration problem, not a Copilot problem.

Key Takeaways

Copilot audit visibility depends on enabling the right Purview and DSPM configurations before an incident forces the question, not after.

Point Details
Check Purview access first Confirm Audit Standard is capturing CopilotInteraction events and that your role can view them.
Prioritize AccessedResources This field proves exactly what files or sites Copilot touched during an interaction.
Enable DSPM for prompt content Standard audit rows don’t include prompt/response text without separate DSPM or eDiscovery setup.
Map fields into your SIEM Route AppHost, ClientRegion, and AccessedResources into Sentinel for correlation and alerting.
Get a governance baseline from Gozera An audit sprint pairs logging configuration with adoption telemetry to show real Copilot ROI.

Table of Contents

Where Copilot Audit Logs Live and How to Get In

Four surfaces matter, and most admins only know about one of them.

  1. Microsoft Purview Audit (UAL) captures CopilotInteraction events for Microsoft 365 Copilot automatically once Audit Standard is on.
  2. Purview DSPM for AI surfaces the actual prompt and response text, but only after you configure it separately. Purview UAL alone shows that a conversation happened, not what was said.
  3. Security Copilot requires an explicit opt-in in owner settings before Microsoft Purview even receives its audit data. Miss this toggle, and you have zero visibility, not partial visibility.
  4. Copilot Studio and GitHub Enterprise’s audit log run on their own tracks. Copilot Studio activity flows into Purview audit, while GitHub Copilot events live in the GitHub organization or enterprise audit log, searchable with action:copilot filters.

To read your first record: sign into the Purview audit search portal, open Audit, filter activities to “Interacted with Copilot,” set a date range, and run the search.

Role What it unlocks Typically granted by
Compliance Administrator Full Purview Audit search access Global admin
View-Only Audit Logs Read-only search results Compliance admin
DSPM for AI Data Access Prompt/response visibility Purview admin
eDiscovery Manager Legal hold and mailbox-backed content retrieval Global admin

Two things trip up mid-market IT teams every time: Security Copilot’s toggle sits buried in owner settings and is off by default, and non-Microsoft AI auditing (things like third-party AI plugins) bills on a pay-as-you-go basis with its own retention clock, separate from standard Copilot events.

What the Copilot Audit Schema Actually Tells You

A single CopilotInteraction record carries more forensic value than most admins realize, but only if you know which fields to read. The Copilot audit schema documents dozens of properties; a handful do the heavy lifting.

Field What it shows Investigative value
AccessedResources Files/sites Copilot pulled from, with SensitivityLabelId and action type Proves exactly what data was exposed or read
Messages / MessageIds Prompt and response identifiers Links a conversation thread to its content (via DSPM)
AppHost Surface Copilot ran in (Word, Teams, admin console) Flags unexpected usage contexts
ThreadId Groups related interactions Reconstructs a full conversation sequence
ModelTransparencyDetails Which model/version handled the request Useful for model-behavior audits
ClientIP / ClientRegion Origin of the request Detects anomalous geography or shared credentials

A sanitized event looks something like this:

{
  "Operation": "CopilotInteraction",
  "AppHost": "Word",
  "ThreadId": "b3f1...",
  "AccessedResources": [
    {"Name": "Q4_Client_Contract.docx", "SensitivityLabelId": "highly-confidential", "Action": "Read"}
  ],
  "Messages": [{"MessageId": "msg-0091", "IsPrompt": true}]
}

You can also query this schema directly through the Office 365 Management API or Microsoft Graph, useful when you need programmatic pulls rather than one-off UI searches. The AccessedResources array is worth reading closely: it separates content Copilot used to “ground” its answer from content the user typed directly, a distinction that matters when you’re deciding whether a data leak originated from Copilot’s retrieval or from the person prompting it.

AccessedResources is the single highest-value field in the entire schema, because it names the exact file or site Copilot touched, alongside its sensitivity label. That’s the difference between suspecting a data exposure and proving one.

Watch for XPIADetected and PolicyDetails too. Both flag potential prompt injection or policy-blocked actions during triage, often before a human reviewer would catch the pattern manually.

Running Targeted Searches and Pulling Exports

Start in the Purview UI: Audit → Workload filter set to Copilot → narrow by user and date range → run search.

For repeatable or scripted work, use PowerShell against the Office 365 Management API or Graph endpoints, including the Copilot usage report APIs for adoption metrics alongside security queries.

  • Search by user + Copilot workload for individual incident review.
  • Filter by SensitivityLabelId inside AccessedResources to surface high-risk file touches.
  • Export results to CSV directly from the Purview search results pane for evidence packages or audit committee reports.
  • Route prompt/response retrieval through DSPM or eDiscovery when the standard audit row isn’t enough.

A community-documented smoke test that works well: pick one user, generate a single interaction, search a narrow window, and confirm AccessedResources, Messages, and AppHost all populate. If they don’t, fix the pipeline before you trust it for a real investigation.

Pro Tip: Run your smoke test against a test account, not a partner’s mailbox. Real client data has no business in a configuration check.

Roughly 180 days is the default retention window on many Business plans before records age out, which is exactly why export-and-archive habits matter more than most teams assume.

Retention Windows, Sensitivity Labels, and Privacy Boundaries

Audit Standard keeps Copilot and AI application events for a default 180 days on many Business plans, while E5 tenants often carry longer or configurable retention. Non-Microsoft AI auditing runs on separate pay-as-you-go billing, with its own retention behavior for AIAppInteraction and ConnectedAIAppInteraction events, distinct from standard CopilotInteraction records.

  • Sensitivity labels travel with AccessedResources, so a blocked or restricted access attempt shows up in PolicyDetails and Status.
  • Prompt and response content lives in a hidden folder inside the user’s Exchange Online mailbox, and retrieving it properly requires Purview eDiscovery permissions, not just DSPM viewing rights.
  • Legal hold on a mailbox preserves that hidden content the same way it preserves email, which matters the moment litigation or a regulatory inquiry touches a client matter.

Pro Tip: If your firm handles privileged client communications, set legal hold policies before an incident, not during one. Retroactive holds can’t recover what already aged out.

Feeding Copilot Logs Into a SIEM

Once logging is confirmed, the real value comes from correlation, not isolated searches. Purview export flows, Office Management API pulls, or Graph reports can feed a blob store that Microsoft Sentinel or another SIEM ingests, a pattern Microsoft’s own guidance describes for Security Copilot specifically.

SIEM field Copilot schema source
event.time CreationTime
host.application AppHost
asset.resource AccessedResources[].SiteUrl
user.id UserId
geo.region ClientRegion

Alert rules worth building early:

  1. Copilot accessed a resource carrying a “highly confidential” sensitivity label.
  2. AppHost shows Copilot running somewhere unexpected, like an admin console rather than Word or Teams.
  3. Messages flags XPIADetected or JailbreakDetected as true.
  4. A single user’s AccessedResources count spikes well past their normal baseline.

Tune thresholds against your firm’s actual usage pattern before going live. A litigation team pulling dozens of documents a day looks nothing like a bookkeeper doing the same, and treating both the same way just buries you in false positives.

What Copilot Audit Logs Won’t Show You

Standard audit rows don’t include prompt or response text. That lives behind DSPM or eDiscovery, not in the row you first pull. Third-party or unmanaged AI tools that resemble Copilot may also bill and log differently, and won’t necessarily surface in a default Copilot search.

GitHub Copilot’s local IDE plugin is the biggest blind spot. Prompts typed directly into VS Code often never reach the enterprise audit log without additional endpoint telemetry, meaning a developer could paste proprietary code into a local Copilot session and leave no organizational trace.

  • Instrument endpoint telemetry where local Copilot usage is a realistic exposure path.
  • Enable DSPM capture before you need it, not after an incident forces the question.
  • Correlate CopilotInteraction events against DLP, proxy, and endpoint logs rather than treating any single log as complete on its own.

When AccessedResources points to an internal URL with no clear owner, or MessageIds exist but content is gated behind permissions you don’t hold, escalate rather than guess. Ambiguous entries are exactly where governance teams either catch something real or waste a week chasing a dead end.

A Short Playbook for a Suspected Data Exposure

Sample queries worth keeping on hand: search CopilotInteraction by user across a 24-hour window, filter by SensitivityLabelId set to your highest classification, and pull all events where AppHost doesn’t match expected applications.

  1. Triage. Validate the event and pull the full AccessedResources list.
  2. Contain. Revoke access where warranted and snapshot the evidence before anything changes.
  3. Investigate. Cross-reference with DLP and endpoint logs to build the full picture.
  4. Remediate. Correct permissions and notify affected clients or partners if required.
  5. Review. Document what happened and adjust policy so it doesn’t repeat.
Escalation trigger Threshold
Sensitivity label Highest classification touched
Resource count Unusually high AccessedResources volume for that user
Security flag JailbreakDetected or XPIADetected = true

When to Bring In a Specialist

Most firms can run the smoke test and basic searches internally. Bring in outside help when you’re facing multi-user exposure of sensitive data, a regulatory inquiry, or an inability to retrieve prompt/response content that a court or client demands.

A focused engagement typically delivers: a full audit of your current Purview logging configuration, a SIEM connector with field mapping already built, an incident playbook tailored to your firm’s data types, DSPM policy configuration, and a documented evidence-export procedure for legal requests.

  • Audit sprint: 1 to 2 weeks to assess current state.
  • Integration sprint: 2 to 6 weeks for SIEM and DSPM buildout.
  • Optional monthly retainer for ongoing monitoring and adoption metrics.

Gozera works specifically with mid-market law, accounting, and consulting firms on exactly this kind of engagement, pairing governance configuration with the adoption telemetry that shows whether Copilot licenses are actually earning their cost.

Why this matters more at professional-services firms

Client confidentiality isn’t abstract in a law or accounting firm. Every AccessedResources entry pointing at a client matter file is also a billable-hour and malpractice exposure question. Run the smoke test today. Export a CSV of AccessedResources for one high-sensitivity user and confirm the coverage is real before you assume it is.

Turn Audit Visibility Into Measurable Copilot ROI

Knowing where your Copilot audit logs live solves a compliance problem. It doesn’t solve the bigger one most mid-market firms actually have: licenses sitting idle while partners assume adoption is happening. Gozera builds on the same telemetry this article walks through to show exactly which Copilot licenses are earning their cost and which ones aren’t.

Gozera

A typical audit sprint delivers:

  • A usage and audit-log baseline showing real Copilot activity by user and practice group.
  • Identification of dormant licenses draining budget with zero adoption.
  • SIEM and DSPM policy configuration mapped to your existing security stack.
  • A workflow rebuild plan targeting the highest-value use cases in your firm, not generic AI use cases.

If your firm has 50 to 500 employees and Copilot licenses that may or may not be paying for themselves, start with a Copilot audit and adoption consulting engagement built around exactly the logging and governance groundwork covered here.

Sources


← Back to all articles

© 2026 Zera Consulting. gozera.ai