Deploy, Secure, and Govern CopilotAdvanced16 min

Audit, Compliance, and Zero Trust

Read Copilot audit records for exactly what they support, remove data without guessing the purge contract, remember that disabling memory doesn't delete it, and test access with a positive control.

What you'll learn

  • Match Audit, eDiscovery, retention, and Communication Compliance to the exact question each one answers
  • Turn a Copilot audit record into a bounded, defensible conclusion instead of an assumption
  • Plan an eDiscovery purge within the 10-item-per-mailbox limit without inventing the request contract
  • Explain why disabling personalization doesn't mean deleting memory
  • Interpret a Zero Trust access test only when a positive control has passed

Before you start

On this page

A manager forwards a Copilot conversation and asks three questions at once: what did it use, can we delete it, and does it raise a compliance issue? Each question belongs to a different control. A review goes wrong when the controls are run out of order or evidence from one is used to answer another.

Four Microsoft Purview controls divide the work. Audit shows recorded activity. eDiscovery finds stored items that match an approved case. Retention sets the rule for the data lifecycle. Communication Compliance sends matched interactions to a person for review. The audit record isn't the item you purge. Retention isn't an immediate delete action. A flagged message does not authorize removal. For every control, keep the conclusion within the evidence it directly supports.

What can an audit record prove?

Purview Audit covers Copilot activity through documented record types, including AIAppInteraction, AIApp, and ConnectedAiAppInteraction, with properties like AccessedResources, AgentName, Messages, and ModelTransparencyDetails. One useful signal: web search was involved when AISystemPlugin.Id reads BingWebSearch.

The discipline is bounding each conclusion to what the property directly supports. If AccessedResources names a document, you can say that document was an associated resource. You can't say it was the only source, that the answer was correct, or that the interaction was compliant. If the plugin ID shows BingWebSearch, you can say web search was detected. You can't say a useful public fact was found. An audit record is strong evidence for narrow statements and no evidence at all for broad ones, and the gap between those is where over-claiming happens. (For non-Microsoft AI apps, auditing needs pay-as-you-go billing, and that audit data carries a documented 180-day retention.)

Write a bounded audit note· copilot-chat
Bad example

Summarize this Copilot audit record and say whether the interaction was compliant.

Good example

Turn this Copilot audit record into an evidence note that states only what the populated properties support. For each line, cite the property it comes from. Explicitly list what the record does NOT establish (that the resource was the only source, that the answer was correct, or that the interaction was compliant). Record: AccessedResources = "Atlas Q2 steering notes.docx", AgentName = "Atlas Status Assistant", AppHost = "Microsoft 365 Copilot", AISystemPlugin.Id = "BingWebSearch". Do not add any conclusion the properties don't directly support.

Why this works: A note that names the associated resource and reports web search as detected, with an explicit boundary listing the conclusions the record cannot support.

Removing Copilot data without guessing the contract

When removal is required, eDiscovery follows a fixed sequence: create a case, run a search, review results, remove the holds that block removal, send the Microsoft Graph purge request, verify, and reapply the holds. Copilot conversation items use classes beginning IPM.SkypeTeams.Message.Copilot.*, and Copilot memory uses IPM.Contact. Removal is capped at 10 items per mailbox. That's per mailbox. Nothing rolls up per tenant, so an overall result count is never enough. You batch each mailbox on its own: fourteen items in one mailbox is a batch of 10 and a batch of 4, with every candidate accounted for.

Two guardrails keep this safe. First, a hold preserves data for a legal or compliance purpose, so changing one is an authorized decision: a legal or records owner signs off, and you record the original state before touching it. A manager saying "just purge it" is not that authorization.

Second, the corpus establishes the purge endpoint pattern only. The current request body and the Graph permissions it needs stay unconfirmed, so you do not send the request from a plan. Verify the exact contract first, or stop.

Retention has its own honest limits: Copilot data lives in a hidden SubstrateHolds mailbox folder, retention runs on timer jobs with 1-to-7-day intervals (a scheduling fact that doesn't guarantee processing finishes within seven days), and organization-configured Purview retention policies and labels do not apply to Copilot memory.

Never invent a purge request or change a hold casually

You know the purge endpoint pattern. You don't know the current Graph request body or permissions. Treat the operation as blocked until an authorized operator supplies and verifies the full contract. A hold change is a compliance decision. Treating it as a workaround for a stuck purge skips the required steps: record the original state, get the legal or records owner's authorization, and restore every changed hold afterward with evidence.

Build the eDiscovery batch plan· copilot-chat
Bad example

Plan how to purge these 14 Copilot conversations from the mailbox.

Good example

I have an approved eDiscovery search returning 14 Copilot conversation candidates in one mailbox ([email protected]), and a hold currently applies. Build the mailbox-specific batch plan using the documented 10-items-per-mailbox limit, list each batch and its count, and confirm every candidate is accounted for. Then list the conditions required before any purge runs: hold authorization, the verified Graph request body and permissions, and post-purge verification. Mark the purge status "Not executed." Do not invent the request body or assume the hold can be removed.

Why this works: A batch plan of 10 and 4 with the purge marked "Not executed," plus a checklist of the authorization and contract evidence a future operation would require.

Disabling personalization is not deleting memory

Copilot memory includes three categories with different behavior. Saved memories remain until the user deletes them. Chat-history-derived details are deleted 30 days after the admin control is turned off. The evidence does not establish a retention rule for custom instructions. All three are stored in the hidden CopilotMemory folder in the user's Exchange mailbox under IPM.Contact.

Suppose enhanced personalization is disabled and a later response no longer follows a formatting preference. That shows a setting changed. Saved memories still remain until the user removes them, and the 30-day rule applies only to chat-history-derived details. One response cannot reveal what a hidden folder contains because an explicit prompt may change the output regardless of memory state. Administrative disablement, user deletion of a saved memory, and compliance deletion through eDiscovery or Graph are three operations, each with its own proof. Purview retention labels do not apply to this data.

Zero Trust: a denied test only counts with a positive control

Zero Trust turns "is Copilot secure?" into a set of validation gates, seven of them: data protection, identity and access, App Protection policies, device management, threat protection, secure Teams collaboration, and minimum user permissions to data. The first trap is calling a screenshot an enforcement test. A picture of a policy assignment is a configuration review: it proves the policy exists. Whether that policy changed a Copilot request is a separate question the screenshot can't answer. Record those rows as Not tested unless you have an approved procedure that exercises them.

The second trap is subtler, and it's the heart of the lesson. You give a restricted identity a prompt for a file it shouldn't reach, it returns nothing, and you mark minimum-permissions Pass. But a "nothing" can mean the boundary held, or that the file was misnamed, unshared, or undiscoverable for a reason that has nothing to do with permissions.

A negative result is only decisive when a positive control proves the resource is findable in your test: a permitted identity retrieves the same file with the same prompt. When the positive control retrieves it and the restricted identity doesn't, that's a real pass. When the positive control also fails, the test is inconclusive, and you fix the control before you trust the denial. Write the expected result before you run it, so you can't redefine success after seeing the outcome.

Positive control first, expectation written down

Before any minimum-permissions test, write the expected result, then run the positive control first. If the authorized identity can't retrieve the file, stop: the negative result is inconclusive. A pass requires the resource to be findable in your setup first, and a failed positive control means it wasn't. Only a passing positive control lets a restricted identity's "no access" mean the boundary held.

Frame the Zero Trust access test· copilot-chat
Bad example

Test whether the restricted user can access Restricted-HR-Plan.docx and report pass or fail.

Good example

Design a minimum-permissions Copilot test for a restricted synthetic file "Restricted-HR-Plan.docx" that a control identity may read and a restricted identity may not. Give me the single prompt to run for both identities, the expected result for each written before the run, and a four-outcome interpretation table (control retrieves / restricted retrieves) that marks an inconclusive case when the positive control fails. Judge by whether the synthetic HR facts were disclosed, not by any refusal wording.

Why this works: A paired test where a passing positive control is required before the restricted identity's denial counts as a real permission-boundary pass.

Where this lands

These four investigations and the Zero Trust gates all feed one decision surface. The Secure and Govern deployment blueprint reduces a rollout to three explicit gate outcomes: ready for pilot, blocked, or not enough evidence. A failed source-boundary test or a failed permission test makes the honest answer blocked. The AB-900 Copilot and Agent Administration Fundamentals certification asks for the same discipline: name the object, name the evidence, and stop short of turning an observation into an approval. A rollout only holds up if each audit note and permission test behind it holds up on its own.

Try it yourself

Run a paired permission test

Practice the positive-control habit on a single restricted file, using supplied observations so you can focus on the reasoning.

  1. 01

    Set up two identities and one restricted synthetic HR file that only the control identity may read. Write the expected result for each identity before running anything.

  2. 02

    Run the positive control first. The control identity returns all three dated HR facts. Record that the resource is findable in your setup.

    Hint: If the positive control had failed, you'd stop here and mark it inconclusive.

  3. 03

    Run the restricted identity with the exact same prompt. It returns two of the three restricted facts.

  4. 04

    State the minimum-permissions result and the next step, judging by whether restricted facts were disclosed rather than by any wording.

A failed minimum-permissions result (restricted content was disclosed) that is decisive precisely because the positive control passed. A reviewer investigates sharing and membership next, and decides separately whether it becomes an incident.

Key takeaways

  • Audit, eDiscovery, retention, and Communication Compliance answer four different questions, and none substitutes for another.
  • An audit property supports only narrow statements: a named resource or "web search detected," never correctness or compliance.
  • eDiscovery removal is capped at 10 items per mailbox, and you never send the purge without the verified Graph contract and hold authorization.
  • Disabling enhanced personalization changes a setting. It does not delete saved memories, and Purview retention doesn't reach Copilot memory.
  • A denied-access test is decisive only when a positive control proves the resource was findable in your setup.

Check your understanding

  1. 1. Which Purview control answers the question "what activity was recorded?"

  2. 2. A Copilot audit record shows AISystemPlugin.Id = BingWebSearch and AccessedResources = one document. What does the record support?

  3. 3. An approved search returns 14 Copilot items in one mailbox and a manager asks you to purge them all immediately. What's correct?

  4. 4. An admin disables enhanced personalization and a later Copilot response no longer uses a saved formatting preference. What can they conclude?

  5. 5. A restricted identity can't retrieve an HR file, so you record minimum-permissions as Pass. What's the problem?

  6. 6. Will your organization's Purview retention policy delete Copilot memory?

Frequently asked questions

Terms used in this lesson

AIAppInteraction
A documented Purview audit record type capturing a Copilot or AI-app user interaction, with properties you interpret within strict bounds.
positive control
An authorized identity used to prove a test resource is findable, so that a restricted identity's denial can be read as a real permission boundary.
SubstrateHolds
The hidden Exchange mailbox folder where governed Copilot and AI-app data is retained. Retention runs on 1-to-7-day timer-job intervals.
enhanced personalization
The Copilot setting, controllable in the admin center or via Graph, whose disablement changes configuration but does not delete stored memory.

Further reading