COMMENTARY: A support assistant keeps sending employees to an unfamiliar service desk. The team deletes the suspicious document it processed last week, ends the conversation and opens a new session. The assistant recommends the same destination again.
The document is gone, but what it taught the assistant remains. This case is hypothetical, and teams will meet the recovery problem it illustrates as assistants carry information between sessions.
Varonis gave the problem a concrete shape in its August 2026 CoSnitch disclosure. Its researchers wrote attacker instructions into Copilot Personal's persistent memory, and the instructions outlasted password changes, session revocation, device re-enrollment and sign-out. Microsoft shipped patches on Aug. 18, and Varonis saw no sign of exploitation in the wild. That is one product's finding, not a verdict on every assistant.
Beyond patch status, responders need evidence that the context the assistant will use next is trustworthy.
Preserve the state before cleaning it
Limit what the agent can do first. Restrict its tools and writable stores, then preserve the suspect entries and any read, write and execution records.
Do not ask the affected agent to clean itself up. Its reading of the task may rest on the material under investigation. Inspect the store through an administrative interface or a separate, controlled process.
Record where each entry came from, when it changed and who could reach it, and note any gap in that history. A memory item's text rarely shows whether an attacker inserted it, the model inferred it wrongly or an authorized person wrote it.
Related reading:
Forcepoint's August research on persistent memory poisoning shows why timing matters: retained false information can shape later, unrelated tasks. Examine the whole period after the suspected write, not only the conversation where the bad content first appeared.
Identify the persistence mechanism
Memory covers very different things: text files, database summaries or, for a coding assistant, local configuration and executable hooks. Inventory the deployment in front of you.
Cisco's April 2026 Claude Code research chained memory files, hooks and shell configuration together, starting from a dependency installation the user approved. In version 2.1.50 Anthropic added a mitigation that removes user memories from the system prompt, which Cisco said significantly reduces that route. The finding applies to the version tested.
A poisoned note and an executable hook need different fixes. If an attacker ran code on the host, follow host-compromise procedures too, because editing the assistant's notes does nothing about malicious code or exposed credentials.
Hunt for whatever could rebuild the bad state. A scheduled ingestion job can pull a deleted document back in, and a local hook can rewrite a file you just cleaned. Deleting the visible entry helps only if the process that planted it is dealt with too.
Follow the contamination into derived context
Searching for the original phrase will miss a summary that restates the false rule in other words. Trace which summaries, shared stores and later tasks consumed the affected entries, using the records the application really keeps.
Let evidence set the scope. A shared store does not prove every agent reading it was influenced, and one normal answer does not prove an agent will ignore suspect context next time.
Where lineage is reliable, quarantine the affected items and everything derived from them. Where it is not, the service owner may have to rebuild more of the store from reviewed sources. Write that decision down with its cost, including the preferences and history users will lose.
Design decides how much control responders have. Anthropic's memory-tool documentation describes a client-side model in which the application executes file operations and controls storage, leaving safeguards such as path validation to the implementer. Teams building this way need their own procedures to inspect and restore that storage.
Require evidence before restoring authority
After cleanup, test in an isolated environment with synthetic data and restricted tools. Reuse the business questions that first exposed the bad guidance, vary the wording, start fresh sessions and watch which context is retrieved and which actions are attempted.
Test for recontamination too. Restart the ingestion or initialization process under controlled conditions and inspect the store again. If the suspect instruction returns, remediation is unfinished, however safe the next answer looks.
Return the assistant to service in stages. Allow read-only work first, assign someone to review new memory writes, and define in advance what triggers another pause.
The closure record should say why responders believe the assistant is ready, and where that belief stops. Behavioral tests cover only the scenarios you ran, and a restart timestamp answers nothing. For an assistant that retains context, recovery means examining what it will remember when the next employee asks for help.
