MemGhost Turns One Email Into Persistent Agent Memory Poisoning
A new preprint demonstrates a delayed agent attack in which one malicious email silently becomes long-term memory and changes answers in a later session. The researchers' MemGhost payload generator reached 87.5% end-to-end success against OpenClaw with GPT-5.4 in background execution across 56 held-out cases. Success required all three stages at once: writing the false memory, avoiding a diagnostic user-visible response, and influencing a future task.
This is more than ordinary prompt injection with a longer context window. The original email is gone when the downstream probe arrives. The agent itself has converted untrusted content into durable state, and that state re-enters later conversations as reusable knowledge. The work gives concrete experimental weight to the architectural risks described in earlier memory-poisoning research.
WhisperBench tests the complete persistence chain
The researchers built WhisperBench around a real SMTP/IMAP workflow and an email command-line skill rather than inserting attack text directly into a model prompt. Each case includes benign inbox noise, one malicious message, a target false memory, and a separate downstream query with a case-specific scoring rubric.
The benchmark began with 200 candidate scenarios. The team retained 108 whose target memory could cause the intended behavior when directly placed into an OpenClaw agent's state. Those cases span health and safety, financial loss, information integrity, cybersecurity, and operational disruption, with both false facts and poisoned preferences. MemGhost used 52 cases for training and the remaining 56 for held-out evaluation.
The benchmark separates four measurements: injection into persistent state, conversational stealth during the email-processing turn, effect on a later response, and end-to-end success when all three conditions hold. That distinction prevents a payload from receiving full credit merely because a memory file changed; the poisoned state must survive into a new session and measurably alter behavior.
Background agents were often the more dangerous target
On OpenClaw with GPT-5.4, MemGhost recorded 96.4% memory-injection success, 100% stealth, 87.5% downstream effectiveness, and 87.5% end-to-end success in background mode. The same target in a foreground workflow produced 75% end-to-end success. On the Claude Code Agent SDK with Sonnet 4.6, the reported end-to-end rates were 71.4% in background mode and 48.2% in foreground mode.
The paper also reports transfer to other model, agent, and memory configurations, including NanoClaw, Hermes Agent, filesystem-backed state, and the vector-based Mem0 backend. Performance varied substantially by model and execution mode, so the headline rate should not be read as a universal compromise probability. It is evidence that a one-shot payload optimized against a proxy environment can transfer beyond that environment.
Simple handcrafted instructions were generally much weaker against the primary GPT-5.4 and Sonnet 4.6 targets. MemGhost instead trains an attacker policy using a simulated persistent-agent environment and rubric-based rewards for both memory adoption and silence. That methodology is important for defenders: evaluating only stock “ignore previous instructions” strings can badly understate what an optimized adversary may achieve.
The experiment has useful boundaries
The work is a preprint and its success labels rely in part on model-based rubric judges. It evaluates text-only email bodies in single-user, single-agent settings; it does not test attachments, images, multi-agent propagation, multi-tenant contamination, or memory decay over weeks. The experiment starts after a message has reached the mailbox, so it does not measure whether spam filters or secure email gateways would block a payload in production.
Those limits do not erase the trust-boundary failure. SPF, DKIM, and DMARC can authenticate a sender domain, but they do not establish that a message's claims should become durable agent memory. Legitimate accounts, attacker-controlled domains, forwarded mail, and third-party notifications can all deliver authenticated but untrustworthy content.
Defensive engineering guidance
- Make external content non-authoritative by default. Email, web pages, documents, tool output, and inter-agent messages should not directly update durable preferences, identity files, security policy, payment details, or operational instructions.
- Gate sensitive memory writes. Require explicit user confirmation for new or changed facts that can affect credentials, money, health, communications, access control, or destructive actions. Show the exact proposed memory and its source.
- Preserve provenance through retrieval. Store sender, channel, timestamp, authentication signals, and the original object reference with each memory. Do not flatten an unverified email claim into an unattributed “known fact.”
- Separate trust zones. Keep user-authored preferences and verified records apart from agent-generated summaries and externally derived notes. Apply stricter retrieval and action policies to the latter.
- Audit silent background writes. Background execution should not make state mutation invisible. Produce append-only memory-change logs and alerts for changes to high-impact state, even when routine task output is suppressed.
- Revalidate before consequential action. A retrieved memory is context, not authorization. Independently verify bank details, recipients, domains, commands, security exceptions, and other high-consequence facts at the point of use.
- Test persistence, not just the first turn. Red-team the sequence from untrusted ingestion to memory write to later retrieval. Check whether deleting the original message, starting a new session, or changing execution mode leaves the malicious influence intact.
The practical takeaway is that long-term memory needs its own security model. Sandboxing tools constrains what an agent can execute now; it does not decide what the agent is allowed to believe tomorrow. Persistent agents need provenance-aware write controls, reviewable state changes, and fresh authorization at action time, or a routine inbox check can quietly alter decisions long after the triggering message has disappeared from view.
Sources: