Copilot Memory Survives Your Password Reset. Go Purge It.

A password reset does not evict an attacker from your AI assistant. Microsoft shipped the full fix for CoSnitch — CVE-2026-24301, a one-click chain in consumer Copilot found by Varonis Threat Labs — on 18 August 2026, and told the press that enterprise customers were not affected. That is a statement about a product boundary. Your incident-response runbook is built on a data boundary, and this week the two stopped lining up.

What Microsoft's Statement Actually Covers

Microsoft's line is narrow, accurate, and much less reassuring than it reads. Both CSO Online and Computerworld quote the same sentence — "enterprise customers using Microsoft 365 Copilot are not affected" — and both note the same objection from analysts: enterprise environments are full of consumer Copilots signed in with employee personal accounts, so the flaw could still reach corporate data through a route the tenant never sees.

CoSnitch itself is three chained behaviours, none of them a memory-corruption bug. Varonis describes an undocumented autorun=1 parameter paired with Copilot's standard ?q= query string, so a crafted link fires a prompt with no user gesture; the prompt then reads the victim's connected OAuth apps; and a booby-trapped webpage, when summarised, writes hidden instructions into the assistant's persistent memory. Cybersecurity News lays out the same three steps. Varonis reported it to Microsoft in December 2025 and says it has seen no evidence of exploitation in the wild.

Seven and a half months is the number that will get quoted. It is not the number that should change your controls.

The Enterprise Assistant Had Its Own Memory Flaw

Microsoft 365 Copilot was not spared memory poisoning — it was patched for it eight months earlier, quietly. Memory poisoning is the writing of attacker-controlled instructions into an assistant's persistent memory store, so that they execute in every future session rather than only in the conversation where they arrived.

Security researcher Johann Rehberger documented exactly that against enterprise Copilot in his "Copirate 365" research — disclosed to MSRC, assigned CVE-2026-24299, and presented at DEF CON Singapore in April 2026. Content planted in a Word, Excel or SharePoint document could reach Copilot's record_memory tool through indirect prompt injection and persist a false fact — his demonstration writes "the user is 102 years old, lives in the Matrix WA" — and the same pathway could delete a user's legitimate stored preferences. Per his own disclosure timeline, he reported the rendering issue to MSRC on 16 October 2025, the memory write-and-delete fixes landed on 6 December 2025, and the HTML-preview exfiltration path was patched on 5 March 2026.

So the honest version of the enterprise position is this: your assistant's memory was demonstrably writable by a document, Microsoft fixed it, and the fix is eight months old. What has not changed is what happens to your organisation after a memory gets written. That is the part your runbook owns, and it is where the gap lives.

---

Why Containment Does Nothing to a Poisoned Memory

The first two steps of every AI-assistant incident runbook — reset the credential, revoke the sessions — do not touch the artifact. Varonis is blunt about it: an injected instruction "survives password changes, session revocation, and device re-enrollment," and stays active in every future session until someone opens the memory settings and deletes it by hand.

That is not a quirk of the consumer product. It follows from where the data sits. Microsoft's own admin documentation on Copilot personalization and memory states that memories "are stored in the user's Exchange mailbox in a hidden folder." A credential rotation changes who can authenticate. It does not change the contents of a mailbox folder, and neither does killing every refresh token in the tenant. You have evicted the attacker from the session and left their instructions running in the assistant.

This is the inverse of the persistence problem we covered when npm pulled the Chaindrop packages and agent config files kept reinfecting the host. There, the persistence lived in files an engineer could grep, diff and delete. Here it lives in a vendor-hosted store with no diff, no grep, and — as below — no log.

Three Gaps Microsoft Documents Itself

You do not need a researcher to find the enterprise exposure. Microsoft publishes it. The feature is still in preview — it ships under the Frontier program and the page says so at the top — but it is on by default and reaches Copilot Chat users with and without a Copilot licence. The same admin page states, in three separate answers:

Question	Microsoft's documented answer
Is there audit logging for Copilot memory?	"Memory and personalization actions don't generate audit log entries in Purview."
Do retention policies apply?	"Retention policies and retention labels configured in Purview by organization admins don't apply to Copilot memory."
Can an admin restrict what goes into memory?	"No, admins can't restrict what type of information is added to Copilot memory."

Read those together and the incident-response consequences are concrete. With no audit entries, you cannot establish when a memory was written or by what content, which means you cannot scope the incident or date the breach for a regulator. With no retention coverage, a memory outlives the chat that created it and every policy you thought governed it. With no admission control, "don't let it learn secrets" is not a setting you can enforce short of turning memory off altogether — it is a hope.

One more line from the same documentation set deserves to be printed and taped to the runbook. In the eDiscovery guidance for AI application data, Microsoft states: "Deleting a conversation or message from Microsoft Purview or eDiscovery doesn't delete the associated Copilot memory." If your remediation step today is "purge the Copilot chat history for the affected users," you have not remediated anything.

The Purge Actually Works, If You Query It Right

There is real containment available on the enterprise side, and almost nobody has rehearsed it. Copilot memories are discoverable and deletable — but only if you search for the right thing.

Per Microsoft's documentation, Copilot memory is stored under the item class IPM.Contact, the same class as a user's contacts, inside a folder named CopilotMemory. Copilot's prompts and responses live under IPM.SkypeTeams.Message.Copilot.* instead. The eDiscovery guidance is explicit that memories "match as contacts in the eDiscovery condition builder" — a different query from the one that collects the chat history, which is precisely why the "delete the chats" reflex fails. Deletion runs as a purgeData POST through Graph Explorer against an eDiscovery search, and it requires the Search And Purge role, not just eDiscovery Manager.

Two operational details will bite you mid-incident. First, the workflow removes up to 10 items per mailbox at one time — Microsoft frames the cap as an event-response guardrail, but it means a wide poisoning event is an iterative job, not one button. Second, you must remove holds and retention policies from the target mailboxes first, or the data you are trying to delete is retained; then reapply them afterwards. Anyone under legal hold — which in most regulated firms is the executive population most worth poisoning — needs a documented exception path written before the incident, not during it.

Custom instructions, meanwhile, are not discoverable in eDiscovery at all. Microsoft says they "aren't accessible, but can manually be exported by the user." For that slice, deletion is something only the user can do — though, as below, an admin can stop Copilot applying them tenant-wide without deleting anything.

The Two Controls You Actually Own

Everything above is cleanup. Two preventive controls are genuinely yours, and they cover different assistants.

The first is the memory feature itself. Enhanced personalization — the tenant control that gives end users Copilot memory at all — is on by default, and an admin can switch it off for the whole organisation or exclude an Entra group through the Graph enhancedPersonalizationSetting resource (isEnabledInOrganization, disabledForGroup) — Microsoft's own description of the control confirms that "the option to disable all linked features for the tenant or a group of users ... is available anytime". Two caveats keep it honest. The API is still Graph beta, which Microsoft's own notice says is "not supported" in production applications. And switching it off stops Copilot applying saved memories and custom instructions without deleting them — it neutralises a poisoned memory rather than evicting it. That is still more than a password reset achieves, and it is the only lever that reaches custom instructions at all.

The second control is the OAuth grant, and it is the only one that reaches a personal assistant holding a route into your data, because that grant decides whether a consumer Copilot can read corporate data at all.

Microsoft's consumer connector documentation lists what Copilot can attach to: OneDrive, Outlook.com mail, calendar and contacts, Google Drive, and Gmail, Google Calendar and Google Contacts. Microsoft services require the personal account to match the Copilot sign-in. Google services do not — they connect through a standard Google OAuth grant. That asymmetry is the whole exposure: if your company runs Google Workspace, an employee can attach their work Gmail and Drive to a consumer assistant your tenant has no visibility into, and Varonis notes that once Copilot holds that grant it reads full message bodies, not summaries or metadata.

The corresponding admin control is real and blunt. Google Workspace admins can, under Security → Access and data control → API controls, set Gmail and Drive to restricted and mark individual apps Trusted, Limited or Blocked. Google's own admin guidance says that when access to Drive or Gmail is restricted, "any previously installed apps that you haven't trusted stop working and tokens are revoked." That sentence is the eviction your password reset was not.

On the Microsoft side, the equivalent lever is Entra's user consent setting. By Microsoft's consent documentation, "all users are allowed to consent to applications for permissions that don't require administrator consent" by default — a user can consent to an app reading their mailbox without an admin in the loop. The recommended posture is the microsoft-user-default-low policy: consent only for verified publishers, only for permissions you have classified as low impact. The caveat that catches teams out is in the same page — changing the setting "only affect[s] future consent operations." Existing grants survive it, and have to be reviewed and revoked separately. If that sounds familiar, it is the same lesson as the credentials that leaked through supposedly encrypted reasoning blocks: the control change is not the remediation.

For the consumer side there is simply no admin surface. Microsoft's Copilot privacy controls page documents only user-driven actions — Profile → Memory → Delete all Memory, or asking Copilot to forget something — and points work and school accounts elsewhere. No tenant admin, no eDiscovery, no export. If a personal Copilot holding a grant into your data gets poisoned, your entire remediation is an email to the employee.

The Boundary Microsoft Is Now Moving

The reason to fix the grant inventory this quarter rather than next is that the wall the "not affected" claim rests on is being taken down on schedule. Microsoft began folding its consumer and commercial Copilot apps into a single unified app in the week of 13 August 2026, per Fortune, with mobile and web following in mid-August and Windows and Mac in mid-September, according to PYMNTS. The Microsoft 365 Copilot app becomes "Microsoft Copilot," with a new icon and a new web address. Commercial users, Microsoft says, see mostly cosmetic change.

The detail worth staring at is how the two worlds will be told apart. Fortune reports "a color-coded cue to help users identify whether they are logged into their business or personal accounts." The identities stay separate. The surface does not. For an employee toggling between a work account governed by Purview, DLP and eDiscovery and a personal account governed by nothing, the boundary between those two regimes becomes a colour in the corner of the same window.

CoSnitch was Varonis's third Copilot finding this year, after Reprompt and SearchLeak, per GBHackers. The Hacker News records how it was found: the researchers extracted the undocumented parameter by repeatedly asking Copilot about its own restrictions — "Copilot wasn't breached; it was played." That method does not respect a product boundary either, and it is a reminder that assistant flaws now arrive at the pace of prompt experiments, not exploit development. Google's own warning about indirect prompt injection against enterprise agents said the same thing from the other side of the industry.

Your Next Three Moves

This Week:

1. Run the eDiscovery search you have never run. Create a case, search item class IPM.Contact scoped to the CopilotMemory folder across your highest-risk mailbox population, and read what is actually stored. You are not looking for an attacker yet — you are proving the query works and finding out how many memories your executives are carrying.
2. Pull the Entra consent report. Identify every third-party grant against Mail.Read, Files.Read and Calendars.Read, and confirm which of them a user granted themselves. Remember that tightening the setting does not revoke what already exists.
3. If you run Google Workspace, list every OAuth client with Gmail or Drive scopes and check whether Microsoft Copilot's client is among them. That is your shadow-assistant count, and it is the one number nobody in the room will be able to guess.
4. Check whether Enhanced personalization is still on in your tenant — it is, unless someone changed it. A Graph GET on enhancedPersonalizationSetting answers it in a minute and tells you whether every Copilot Chat user in the organisation is carrying a memory store you now know you cannot audit.

This Month:

1. Add a memory-purge step to the AI-assistant section of the incident runbook, above the credential reset rather than below it, and note the two constraints in the step itself: ten items per mailbox per pass, and holds must come off first and go back on after.
2. Assign the Search And Purge role to the on-call security population now. Discovering mid-incident that your responder has eDiscovery Manager and cannot purge is a wholly avoidable hour.
3. Decide your consumer-Copilot position and write it down. Blocking it outright is defensible; so is allowing it with connectors restricted at the Workspace or Entra layer. What is not defensible is the current default, where the decision is made one employee at a time. This is the same shape as the shadow AI problem we have covered repeatedly — the difference is that here the asset being exposed is your mail store.

Before Renewal:

1. Put a disclosure-to-patch commitment in the contract. Seven and a half months on a critical assistant flaw is the datapoint; ask for a stated maximum for critical AI-surface vulnerabilities, and a notification obligation even where the vendor judges your SKU unaffected. That second clause is the one that matters here.
2. Ask for admin-visible memory telemetry as a roadmap commitment, in writing. "No audit log entries" is a supportable answer for a preview feature and an unsupportable one for a control plane you are being asked to standardise on. Agent governance tooling like Microsoft's own Agent 365 is being sold on inventory and oversight; memory is part of that inventory or the oversight is incomplete.

The Bottom Line

Every previous generation of identity compromise ended at the same two commands: rotate the credential, kill the sessions. Those commands worked because the attacker's foothold was the session. In an assistant with persistent memory, the foothold is a row in a hidden mailbox folder that no audit log recorded, no retention policy governs, and no admission control filtered — and it is still there on Monday, being helpful. We saw the same pattern when one agent escalated another and every call was authorized: the security model assumed the attacker had to break something, and nothing was broken.

Microsoft is right that CoSnitch did not hit Microsoft 365 Copilot. Take the win, and then go and check what your assistant remembers — because "not affected" describes a SKU, and the thing you are actually defending is a mailbox.

Continue Reading

npm Pulled the Packages. Your Agent Config Reinfects You. One Agent Escalated Another. Every Call Was Authorized. 182 Credentials Hid in 'Encrypted' Reasoning. Go Rotate. Capsule Security: Why Copilot and Agentforce Both Leaked Web Pages Are Hijacking AI Agents — Google's IPI Warning CISA Gave 3 Days to Patch Ray. Auth Is Still Off by Default. Fable 5 Needs Retention On. ZDR Was Never Zero. 90% of AI Usage Is Invisible to IT. The Breach Has Started.