Copilot Now Remembers Your Users — and Purview Retention Is How You Prove What It Forgot

Picture the litigation hold email landing in your inbox. Legal wants to know what Microsoft 365 Copilot “knew” about a departing employee three months ago — the inferred preferences, the project associations, the saved facts that shaped every answer Copilot gave them. You go looking. And there’s nothing to find, because Copilot memory is a living document that overwrites itself as it learns. The version that mattered is gone.

That gap is what Microsoft is closing. Roadmap item 569612 — “Data Lifecycle Management: Retention for Copilot Memory” — reaches general availability in September 2026, and it turns Copilot’s memory from an ephemeral personalization cache into something you can retain, version, and produce in an investigation. If you’ve rolled out Copilot at any scale, this is not optional housekeeping. It’s a new data class that just became discoverable.

What Copilot memory actually is, and where it hides

Copilot memory is the feature that makes Copilot feel less like a goldfish. It has two flavors. There are saved memories — things a user explicitly tells Copilot to remember (“I’m the PMO lead for the Helsinki migration,” “always summarize in bullet points”). And there are inferred details — facts Copilot derives from a user’s chat history to personalize future responses. Together they let Copilot stop asking the same context questions on every prompt.

Here’s the part that matters for compliance: those memory items don’t live in some opaque AI service. They’re stored as items in a hidden folder in the user’s Exchange Online mailbox — the same substrate model Microsoft already uses for Teams messages and Copilot interaction history. That’s deliberate, and it’s good news, because anything in the mailbox substrate is reachable by Purview’s retention and eDiscovery machinery.

Until now, though, memory has been managed entirely by the Copilot experience. Active memory changes as the model learns, and the previous state simply disappears. The GA feature adds retention and versioning for inactive memory items: when a memory item is superseded or removed, a retained copy is preserved according to your policy, while active memory keeps being managed by Copilot itself. You get the audit trail without freezing the feature.

Why this surfaces now

Memory shipped as a personalization win. Nobody in the Copilot product team was thinking about the poor eDiscovery admin who’d eventually have to explain, under oath, why an AI made a decision. Regulated tenants — financial services, healthcare, legal, public sector — flagged the obvious problem: if Copilot’s behavior is shaped by stored data about a person, that stored data is discoverable, and “we don’t keep it” is not a defensible answer to a regulator. Retention for memory is Microsoft catching the governance story up to a feature it already shipped.

My read: the interesting word in the feature description is inactive. You are retaining the tombstones, not snapshotting live memory on a schedule. That’s fine for “prove what changed,” weaker for “reconstruct exactly what Copilot believed at 2pm on a Tuesday.” Set expectations with legal accordingly.

The bigger picture: this is one piece of Purview’s Copilot governance stack

Don’t treat memory retention in isolation. It slots into a set of Purview capabilities for Copilot that have landed over the past year, and if you’re planning, plan for all of them together:

• Retention for Copilot interactions (prompts and responses) — already GA, configured as its own location in retention policies. Memory retention is the companion piece.
• eDiscovery (Premium) for Copilot — Copilot interactions are collectable; memory items become collectable content under the same model once retained.
• Communication Compliance for Copilot — policy scanning of prompts and responses for risky content.
• DSPM for AI (Data Security Posture Management for AI, in the Purview portal) — the dashboard that shows you which users are using Copilot, what sensitive data they’re touching, and where your governance gaps are. This is where you should start your Copilot data-risk conversation.
• Purview Audit for Copilot — interaction events flow to the unified audit log.

The practical benefit versus the old world is straightforward. Before, Copilot memory was a black box you couldn’t retain, search, or defend. After, it’s a governed data class with a retention timeline you set, a version history for “what changed,” and a production path into eDiscovery. You’re trading an unbounded liability for a bounded, documented one. That’s the whole game in compliance.

Find out who’s exposed before you write a single policy

Scope first. Only Copilot-licensed users generate memory, so start by inventorying who actually has the license. This uses the Microsoft.Graph module — install with Install-Module Microsoft.Graph -Scope CurrentUser if you haven’t.

Connect-MgGraph -Scopes "User.Read.All","Organization.Read.All"

try {
    # Copilot SKU part number; confirm against your tenant's Get-MgSubscribedSku output
    $copilotSku = Get-MgSubscribedSku -All |
        Where-Object { $_.SkuPartNumber -eq 'Microsoft_365_Copilot' }

    if (-not $copilotSku) { throw "No Microsoft 365 Copilot SKU found in this tenant." }

    # -All handles paging automatically; do NOT roll your own $top loop here
    $licensedUsers = Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AssignedLicenses |
        Where-Object { $_.AssignedLicenses.SkuId -contains $copilotSku.SkuId }

    $licensedUsers |
        Select-Object DisplayName, UserPrincipalName, Id |
        Sort-Object DisplayName |
        Export-Csv .\Copilot-Licensed-Users.csv -NoTypeInformation

    Write-Host "$($licensedUsers.Count) Copilot-licensed users exported." -ForegroundColor Green
}
catch {
    Write-Warning "License inventory failed: $($_.Exception.Message)"
}
finally {
    Disconnect-MgGraph | Out-Null
}

That CSV is your review set. Everyone on it is generating memory items right now, retained by nothing.

Now check what retention already exists. Retention compliance policies still live in Security & Compliance PowerShell — Graph doesn’t fully cover retention policy objects yet, so this is the correct modern module for the job (it ships in ExchangeOnlineManagement, not the retired MSOnline/AzureAD modules).

Connect-IPPSSession -UserPrincipalName [email protected]

try {
    Get-RetentionCompliancePolicy -DistributionDetail |
        Select-Object Name, Enabled, Mode,
            @{N='Locations';E={ ($_.ExchangeLocation.Name) -join '; ' }} |
        Format-Table -AutoSize

    # Rules carry the retention duration and action
    Get-RetentionComplianceRule |
        Select-Object Name, Policy, RetentionDuration, RetentionComplianceAction |
        Format-Table -AutoSize
}
catch {
    Write-Warning "Could not enumerate retention policies: $($_.Exception.Message)"
}

Building the policy — dry-run first, always

The retention location for Copilot memory surfaces in the Purview portal as a Copilot workload alongside interactions. In PowerShell, the exact location parameter for the memory scope is being finalized as the feature reaches GA, so confirm the parameter name in your tenant against the current cmdlet help before you run this for real. What must not change is the discipline: never point a creation cmdlet at the output of a live query and let it rip.

# SAFE BY DEFAULT: -WhatIf shows what would happen and changes nothing.
# Remove -WhatIf only after you have reviewed the plan and the scope CSV.

$policyName = "Copilot Memory Retention - 7yr"

try {
    New-RetentionCompliancePolicy `
        -Name $policyName `
        -Comment "Retains inactive Copilot memory items for investigation/compliance." `
        -ExchangeLocation "All" `
        -WhatIf

    New-RetentionComplianceRule `
        -Name "$policyName-Rule" `
        -Policy $policyName `
        -RetentionDuration 2555 `      # ~7 years, in days
        -RetentionComplianceAction Keep `
        -WhatIf
}
catch {
    Write-Warning "Policy planning failed: $($_.Exception.Message)"
}

Scope tightly. -ExchangeLocation "All" is a blunt instrument; for a phased rollout, target a reviewed group or an explicit list of the mailboxes from your CSV rather than the entire tenant. And decide Keep versus KeepAndDelete deliberately — retaining memory tombstones forever is its own liability. Match the duration to your existing records schedule, not to a round number that felt safe.

Where this lives in the portal

Everything configures in the Microsoft Purview portal (purview.microsoft.com) under Data Lifecycle Management → Policies → Retention policies. Create or edit a policy and you’ll pick the Copilot workload as a location; the memory scope appears there as it rolls out. For the risk picture that should drive your scoping decisions, go to DSPM for AI in the same portal first — it tells you who’s actually using Copilot and against what data.

What will bite you in six months

Two things. First, retention makes memory discoverable, which cuts both ways: you’re preserving evidence you’ll be obligated to produce. If legal hasn’t blessed a duration, don’t set one long by reflex. Second, memory retention interacts with mailbox lifecycle. When a user leaves and their mailbox becomes inactive, retained memory items ride along under the same rules as the rest of the substrate — so your leaver process and your Copilot retention policy need to agree on how long that data lives, or you’ll discover a five-year cache of AI-inferred details about ex-employees nobody signed off on.

Do this before September

1. Run the license inventory above. Know your exposed population.
2. Open DSPM for AI and read the Copilot usage/risk report. That’s your scoping input.
3. Get legal to commit to a retention duration for memory — align it to your existing records schedule.
4. Build the policy in -WhatIf, scoped to a pilot group, and verify against your reviewed CSV before you go tenant-wide.

Copilot memory is a genuinely useful feature and a quiet new liability at the same time. September is when you get the controls. Have the policy drafted before then, not after the first eDiscovery request lands.