MemAudit: forensic auditing to find poisoned entries in agent memory

What is this?

Persistent LLM agents remember. They write summaries, “lessons learned”, and retrieved facts into a long-term store, then pull those entries back into context on later turns — often for different users and tasks. That store is an attack surface. Memory poisoning injects crafted content that looks like an ordinary memory but, once retrieved, steers the agent toward an attacker’s goal: leaking data, calling the wrong tool, or endorsing a malicious instruction. Because the payload arrives through the normal write path and fires much later, it never touches model weights or code and slips past defenses that only inspect the current prompt.

Most published defenses are preventive — they try to stop bad entries from being written or retrieved. MemAudit, posted to arXiv in May 2026, takes the opposite stance: assume some poison already landed, and give responders a way to audit the memory store after the fact. It sits alongside a fast-growing literature — a 2026 survey on long-term memory security maps the whole lifecycle, and attack work such as MemoryGraft shows how a single poisoned “experience” can persistently compromise an agent.

How it works

MemAudit is built around two ideas named in its title: causal attribution and structural anomaly detection.

Causal attribution answers the forensic question “which memories caused this?” When an agent produces a harmful or unexpected action, an auditor needs to know which stored entries pushed it there. Rather than eyeballing thousands of notes, the approach traces the influence from the observed action back to the specific memory entries that shaped the decision — turning “the agent misbehaved” into “these three entries, retrieved together, drove the behavior.” That is the difference between knowing you were breached and knowing what to delete.

Structural anomaly detection works in the other direction. A healthy memory store has regularities — how entries relate to each other, how they cluster, how they are phrased and referenced. Poisoned entries tend to sit oddly against that background: an instruction dressed as a fact, a note that connects to far more retrievals than its peers, content whose structure does not match how the agent normally writes to itself. Flagging those structural outliers surfaces candidates for review even when no single entry looks malicious in isolation.

Used together, the two signals cross-check each other. Anomaly detection narrows the field to suspicious entries; causal attribution confirms which of them actually influenced a given bad outcome. No exploit payloads are needed to run the audit, and none are reproduced here — the point is triage and cleanup, not attack.

Why it matters

Memory poisoning is one of the harder agentic threats precisely because of the time gap. The write and the damage are separated by hours, days, or many sessions, so classic input filtering and per-turn guardrails see nothing wrong. In multi-user deployments the blast radius grows: one poisoned entry written during your session can be retrieved into someone else’s later. Certified preventive defenses exist — see SMSR, a June 2026 proposal with a robustness bound — but prevention is never perfect, and teams still need an answer to “we think the memory is contaminated; now what?” Forensic auditing is that answer. It also raises the cost of stealthy, slow-burn poisoning: an attacker who assumes their entry will live forever now has to survive an audit that can trace effects back to causes.

Defenses

Treat the memory store as security-relevant state, not a convenience cache. Concretely: bind every entry to its origin (who wrote it, from which session and source) so causal attribution has something to trace; keep an append-only log of writes and retrievals so incidents are reconstructable; and separate memory by trust and tenant so a poisoned entry cannot cross into another user’s context. Run periodic audits — structural anomaly scans plus attribution on any surprising action — rather than trusting a one-time filter. Require provenance and, where possible, a human check before a memory can authorize a sensitive tool call, so a single retrieved note can never be the sole basis for an irreversible action. Finally, make deletion real: when an audit fingers an entry, purge it and everything derived from it, then re-test.

Status

Item	Reference	Notes
MemAudit (post-hoc auditing)	arXiv 2605.23723, May 2026	Causal attribution + structural anomaly detection
Threat landscape	arXiv 2604.16548, 2026	Survey of long-term memory security across the lifecycle
Representative attack	arXiv 2512.16962 (MemoryGraft)	Persistent compromise via poisoned experience retrieval
Certified prevention	arXiv 2606.12703 (SMSR), June 2026	Complementary preventive defense with a robustness bound

The broader shift is from “can we keep poison out?” to “can we find it once it’s in?” Both questions matter: prevention lowers the odds, forensic auditing bounds the damage when prevention fails. For any agent that writes to durable memory, plan for both.