system: OPERATIONAL
← back to all hacks
AGENTS MEDIUM NEW

GhostWriter: poisoning a personal AI agent's memory through an ordinary email

A July 2026 paper shows an attacker can plant a hidden instruction in a routine email, get a personal assistant agent to store it as memory, and have it act on that instruction days later — with a defense that stops it.

2026-07-10 // 7 min affects: llm-agents, memory-agents, email-assistants, rag-pipelines

What is this?

On July 6, 2026, researchers published a paper (arXiv preprint, cs.CR) describing GhostWriter, an attack that poisons the long-term memory of a tool-using personal assistant agent — the kind that watches your inbox, manages your calendar, and drafts email on your behalf. The novelty is not that memory can be poisoned; earlier work already showed that. The novelty is the entry point. Where prior attacks assumed the adversary could reach the memory store directly or drive the agent with their own prompts, GhostWriter needs nothing more than the ability to send the victim an email.

The paper frames a gap that has grown as agents gain persistent memory. To avoid ever-larger context windows, memory-enabled agents save what they see — summaries, extracted facts, useful workflows — and retrieve it later by semantic similarity. Almost all of them save everything, with no security check on what is being written. That “remember first, ask never” design is the vulnerability. The authors measured an average injection rate of roughly 98% and an average activation rate of roughly 60% across five state-of-the-art memory agents built on four different model families. This is a defensive, class-of-attack writeup; it contains no runnable exploit.

How it works

GhostWriter runs in two phases, and the gap between them is what makes it dangerous.

In the injection phase, the attacker writes an email that looks routine — a meeting note, a “my contact details changed” message — and buries a directive inside it aligned to a plausible future task. When the message lands in the inbox, the agent ingests it automatically and writes it to long-term memory, tagged for later retrieval. No user action is required, and nothing visibly wrong happens.

In the activation phase, the poisoned memory lies dormant until the user issues an ordinary request — “send the client the update,” “schedule the review.” The retrieval step pulls semantically related memories into context, the poisoned one among them, and the agent, treating its own memory as trusted, follows the planted instruction: adding a hidden recipient, redirecting a message to an attacker-controlled address, or leaking project details.

To make retrieval reliable, the attacker can optimize the payload in a pure black-box setting. Using a public email corpus (the paper uses the Enron dataset) clustered into topics, they rewrite the message so its embedding sits close to the phrasing a user would likely type, iterating until the similarity score clears a threshold. The adversary never touches the agent’s model or retrieval logic — only the content they send. The paper sorts the goals into four buckets: integrity corruption, sensitive-information leakage, covert exfiltration, and scope escalation. The core enabler throughout is the absence of security-focused memory governance, and the authors note that ordinary spam filtering does not help, because a targeted, semantically valid message — the same craft used in business email compromise — sails through aggregate classifiers.

Why it matters

The blast radius is the set of tools the agent holds. An email-and-calendar assistant that can send messages can be steered into exfiltration; a coding assistant with repository access is a heavier target. Two properties make this worse than a one-shot prompt injection. First, persistence: a single injected memory survives across sessions, so the attacker pays once and the trap waits. Second, laundered trust: once attacker text is inside the memory store, the agent stops treating it as untrusted input and starts treating it as its own recollection. The attack also fits realistic adversaries — an internal contact who knows your projects, or an external one working only from public LinkedIn and company pages — without any account compromise. It is a concrete instance of the broader risk catalogued under OWASP’s prompt-injection guidance, pushed into the memory layer.

Defenses

The paper pairs the attack with a defense, AM-Sentry, and its structure is the practical takeaway even if you never adopt that specific system. The principle: govern the memory layer as a security boundary, at both write time and read time.

  • Screen what gets written to memory. Do not persist every ingested item. Gate each candidate through a policy that scores it before admission — the paper’s judge rates origin, trust, type, and utility, and admits only entries that are useful and low-risk.
  • Model source trust explicitly. Weight a memory by where it came from: a direct user statement outranks an internal email, which outranks a message from an unknown external sender. Instructions arriving from untrusted origins should not become durable memory.
  • Screen again at retrieval. Before retrieved memories enter the model’s context, pass them through a filter that strips hidden directives — a second checkpoint that catches whatever slipped past the write-time policy.
  • Separate facts from instructions. Treat stored “do X when Y” workflows as far more sensitive than stored facts, since directives are what actually redirect behavior.
  • Keep the human in the loop for irreversible actions. Require confirmation before an agent sends money, emails confidential material, or adds an external recipient — the actions these goals ultimately need.
  • Log every memory write. A durable audit trail of what entered memory, and from which source, is what makes a poisoned entry findable after the fact.

The authors report that AM-Sentry sharply reduces GhostWriter’s success rate while preserving most of the agent’s usefulness — evidence that the security-versus-utility tradeoff here is favorable, not either/or.

Status

ItemValue
DisclosurearXiv preprint (cs.CR), July 6, 2026
AttackGhostWriter — indirect long-term-memory poisoning via untrusted tool inputs
Measured impact~98% injection rate; ~60% average activation rate
Scope tested5 memory-enabled agents across 4 model families
Proposed defenseAM-Sentry (write-time policy + retrieval screen)
Root causeNo security-focused governance of agent memory

Key dates: July 6, 2026 — GhostWriter and AM-Sentry preprint published. The work builds on earlier memory-poisoning research (AgentPoison, MINJA) that assumed stronger adversary access.

Sources