Auditing and Cleaning Agent Memory

You cannot clean what you cannot list. Before you touch a single record, build a table of what your memory store actually holds. Export the store or query it, and classify each entry along four axes: content type, source, write channel, and age.

Content type matters because the kinds of memory fail differently. The taxonomy most frameworks have converged on splits memory into working memory (the current context), episodic memory (records of past sessions and outcomes), semantic memory (facts and preferences distilled from experience or ingested from outside), and procedural memory (explicit rules, playbooks and skills) as this design guide summarizes.

Write channel is the security-relevant field. The systematic study names four channels through which long-term memory gets written: explicit instruction-executed writes, system prompt-driven writes, compaction-driven writes (where a summarizer condenses a conversation into memory), and experience-to-procedure writes (where a successful run becomes a reusable rule) per the arXiv paper. Compaction and experience-to-procedure are the dangerous two, because in both cases the agent writes its own summary of untrusted content and then later reads that summary as trusted.

A minimal inventory schema looks like this:

{
  "entry_id": "mem_01J8...",
  "content": "Customer escalation path is Slack #tier2",
  "memory_type": "semantic",
  "source_uri": "confluence://runbooks/oncall",
  "source_trust": "internal_signed",
  "write_channel": "system_prompt_driven",
  "written_at": "2026-03-11T09:14:00Z",
  "written_by": "agent:ops-assistant/v4",
  "last_retrieved_at": "2026-05-02T16:40:12Z",
  "retrieval_count": 37,
  "supersedes": null,
  "review_status": "unreviewed"
}

If your store cannot produce source_uri, write_channel and written_at for an entry, that entry is already a finding. Mark it unknown_provenance and move it to the quarantine pass. Provenance records are also what let you trace an incident backwards from anomalous behavior to the entry that caused it: without them, when odd behavior appears you cannot determine which prior document introduced the problematic context per Trussed's recommended controls.

The second pass is scoring, not deletion. Two flag rules cover most of the risk.

Rule A, untrusted write. Flag any entry whose source is external (web pages, retrieved documents, third-party APIs), any entry whose source is another agent, and any entry whose write channel is compaction or experience-to-procedure while its source is external. Cross-agent writes deserve their own flag because in orchestrated graphs one agent's output becomes another's input and may be written to shared memory without additional scrutiny per WorkOS's breakdown of entry points.

Rule B, contradiction. Flag entries that conflict with a newer entry about the same attribute. This is harder than it sounds, and the research explains why. The STALE benchmark defines "implicit conflict": a later observation invalidates an earlier memory without ever negating it. Someone mentions setting up utilities in Portland; the stored fact says they live in Seattle. Someone mentions a broken leg; the stored routine says they cycle to work daily. In both cases nothing in the conversation says "I moved" or "I stopped cycling," and the agent must infer it. Across frontier models, the best evaluated system reached only 55.2% overall accuracy on these conflict scenarios per the STALE benchmark.

That number should shape your design decision: do not rely on the model to notice implicit contradictions. Detect them at write time with structured consolidation. When a new fact arrives about an attribute, adjudicate it against the existing value explicitly and record which one supersedes which, rather than letting both coexist and hoping retrieval sorts it out. The same paper's prototype, CUPMem, takes exactly that approach, structured state consolidation plus propagation-aware search per the STALE abstract.

A worked example. Suppose the inventory returns 12,400 entries: 4,100 episodic, 7,600 semantic facts, 600 preferences, 100 procedural rules. Rule A flags 1,700 entries with external or cross-agent provenance. Rule B flags 480 semantic entries where two records claim the same attribute with different values. You now have 2,180 flagged items, roughly 18% of the store, and zero deletions so far. That is the correct state to be in at the end of pass two.

One more reason not to trust retrieval alone: vector similarity degrades as the store grows. A reported benchmark cited in this analysis of vector versus file-based retrieval found vector RAG accuracy dropping by up to 12% when scaled to 100,000 pages, while an alternative approach lost only 2% at the same scale per the discussion of the EyeLevel.ai research. A large, uncleaned memory store does not just carry poison; it gets worse at fetching the right record.

Quarantine means the entry stops being retrievable but still exists. Move flagged records to a separate partition, keep their provenance, and write a removal reason. Your retrieval layer filters quarantine out by default; only an auditor can read it.

This mirrors how emergency privileged access is governed in identity systems. Break glass accounts are a recognized necessity and a recognized liability at the same time, and the guidance is consistent: isolate them from normal accounts, monitor every use, and review them regularly, rather than leaving them as unmonitored backdoors as the Cloud Security Alliance puts it. The same principle applies to memory. Permissions to delete should not sit with the agent. If an agent can silently erase its own memory, you lose both the audit trail and the ability to detect that an attack happened.

Practical approval rules I would start with:

• An agent may move an entry to quarantine on its own. It may never delete.
• A human approves deletions in batches grouped by source and write channel, so a reviewer sees "these 340 entries all came from compaction of web fetches" rather than 340 unrelated records.
• Any procedural or instruction-shaped entry requires approval from the owner of the process it affects, not just a security reviewer.
• Deletions are soft for a defined retention window, then purged. The approved decision and the approving identity are logged with the entry.

One caution on approval design: keep recovery paths independent of the thing being repaired. Emergency access guidance is explicit that an emergency account must not rely on the same identity provider that could fail, otherwise it loses its purpose per Bitwarden's setup guide, and that the credentials and their release procedure need to be documented and physically or logically secured as the IDS Alliance's overview stresses. Your memory admin console should not require the same agent gateway that the poisoned memory might be influencing, and the approval log should live outside the memory store itself, in append-only storage the agent cannot write to.

Cleaning is the backstop; write-time filtering is the cheaper control. Three checks catch most injected instructions:

1. Instruction-shape detection. Content that says "remember that", "for future reference", "always", or "important context for later sessions" is a known injection pattern per Christian Schneider's writeup. Route it to quarantine rather than writing it.
2. Trigger-word flagging. Some attacks wait on trigger words that appear in nearly every conversation, like "yes" or "sure," so that retrieval and invocation are near-certain. An entry whose only apparent purpose is to fire on a common token is not useful memory.
3. Retrieval-anomaly scoring. Watch for entries that are retrieved disproportionately often, or that spike in retrieval count right before a behavior change. High retrieval on a single low-provenance entry is a signal.

Be honest about limits. Optimized backdoor triggers in memory have been shown to transfer across embedding models and to survive paraphrasing, so swapping your vector store is not a defense, and defensive filters that rely on rewording the input did not stop them as this walkthrough of the AgentPoison and MINJA research describes. A separate thread of work makes the same point from the other end: the agent's own recorded "successful experiences" can be planted through benign-looking content and imitated later as if they were a proven playbook as WorkOS describes the MemoryGraft attack. Filtering removes the lazy injection, which is most of it. Provenance and quarantine handle the rest.

For teams whose agents run outside a single cloud, the same isolation logic applies to the credentials the agent uses to reach memory at all. Long-lived static keys for a memory backend are exactly the kind of asset that gets copied into a pipeline, forgotten, and then used from somewhere you did not expect; workload identity federation exists so workloads authenticate with short-lived, scoped tokens instead per this AWS builder walkthrough. If your memory store accepts a static key from any process that has it, your provenance field is only as good as that key's hygiene per this overview of federation models.

Once the store is clean, keep it clean with expiry rules. Treat forgetting as a feature with an owner, not a defect to be patched as this memory design guide argues.

Two decision rules make this enforceable. First, anything that came from a tool output should not be persisted as memory at all; cache it with a short TTL and re-fetch. Second, if a piece of content would change what the agent is allowed to do, it is an instruction, not a fact, and instructions need a signed source: version control, a config system, an approval record. That single rule removes the entire class of "remember to always approve refunds" poisoning.

Review the retention table whenever identity or policy changes, not just on a calendar. The break glass guidance makes the same point about emergency accounts: configuration drifts after significant changes unless someone explicitly re-checks it per Bitwarden's configuration checklist. Memory policies drift the same way, and faster, because agents keep writing while you are not looking.

For teams running several agents across several model vendors, this work gets easier when memory sits behind one gateway rather than five SDKs. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API with a single key, which means one place to attach provenance and one place to enforce quarantine filters. You can read the details at Quanta Inference.

A cleaning cycle is an operational routine, not a project. A cadence that works:

• Weekly: run the automated inventory diff. New entries without provenance get quarantined automatically.
• Monthly: review flagged batches. Target under two hours by grouping by source.
• Quarterly: test the deletion path end to end, including the approval console, and confirm the retention table still matches what the agents actually do.
• On any behavioral anomaly: freeze writes to the affected memory partition, then run pass two scoped to that partition.

That last step matters more than it looks. If you detect odd behavior and keep accepting writes, you are cleaning a bucket with the tap running. Freezing writes is cheap and reversible.

Two operational details make the cycle survive contact with reality. First, record every deletion decision with the identity of the approver and the evidence they saw, because "we deleted 400 entries last quarter" is not an audit trail but "reviewer X approved the removal of these 400 entries from these three sources on this date" is. Second, keep the quarantine readable by humans. A quarantine partition that only an engineer can query will be reviewed once and then ignored. A quarantine view that shows the entry, its source URL, its write channel and its retrieval count is something a process owner can actually adjudicate.

When the plan needs a second opinion on scope, particularly if you are running agents against customer accounts or regulated data, a short consulting call is usually faster than guessing at your own threat model.