GhostWriter: One Email Can Poison Long-Term Agent Memory

GhostWriter shows a new risk class for agent systems: malicious content can enter long-term memory and later activate as trusted context.

2 min1 source

In one minute

  • GhostWriter shows a new risk class for agent systems: malicious content can enter long-term memory and later activate as trusted context.
  • The record is connected to 3 topics: agent-security, memory, prompt-injection.
  • 1 public source carries the evidence boundary.

Source ledger

Publishable sources attached to this record.

1 public source
#SourceRolePublic status
1arxiv.orgpaperprimary receiptsource_urls
On this page

Prompt injection is usually discussed as an attack in the moment: the model reads a hostile instruction, confuses priorities, and performs the wrong action. GhostWriter matters because it moves the risk through time. Crafted email content can write malicious memory, and the agent can activate it later when the original email is no longer visible.

That turns agent memory from a convenience feature into a privileged subsystem. If external content can write long-term memory, it gets a chance to influence future decisions.

What the work shows

GhostWriter demonstrates long-term agent-memory poisoning through a crafted email. The malicious fragment is stored as if it were useful knowledge, then retrieved in a later similar context and used to influence behavior.

The core problem is not only retrieval. Retrieval returns what was already written. The earlier mistake is treating memory writes almost as casually as reading inbound content.

Why it matters

Many agent products are built around a promise: the agent remembers preferences, projects, contacts, work style, and previous decisions. But memory mixes very different trust levels:

  • explicit user settings;
  • observations from documents and email;
  • model inferences;
  • temporary facts;
  • actions by other people;
  • potentially hostile external content.

If all of this lands in one layer, retrieved memory starts to look like trusted system context even when part of it came from an untrusted source.

New Runtime Read

Memory write is a privileged operation. Retrieved memory is not automatically trusted context.

Agent memory needs separate read and write policies. A write should include source, user intent, lifetime, scope, and rollback. Retrieval should return not only memory text, but provenance: who wrote it, where it came from, when it was checked, and whether it can be trusted for the current action.

Otherwise memory becomes a quiet channel for delayed prompt injection.

Open archive
  1. OpenAI's Hugging Face Incident Makes Agent Sandboxes a Production Riskagent-security · sandbox2 sources
  2. Coding Agent Sandboxes Break in Places Teams Do Not Expectagent-security · coding-agents1 source
  3. Language Models Need Sleepmemory · loop-engineering2 sources