Skip to main content
LLM Security Database
Skip to research details
Back to Vulnerability List
LMVD-ID: e9cd87a8
Paper published July 6, 2026
Entry analyzed July 20, 2026
Severity: Not rated
Confidence: Source-linked

The LMVD-ID is an internal research identifier, not an official CVE identifier.

GhostWriter Persistent Memory Poisoning in Tool-Using Agents

The paper describes GhostWriter, a reproducible two-phase attack against tool-using agents with persistent memory: untrusted email or calendar content is admitted into long-term memory, then later retrieved during a…

BibTeX citation

Paper-evaluated models(4)

  • GPT-5.4-mini
  • DeepSeek V4 Flash
  • Gemini 2.5 Flash
  • Llama 3.1 8B

Research context and confidence

Evidence and verification
Paper-reported; independent reproduction is not documented.
Primary source plus a dedicated evidence section.
Severity
Not rated by this catalog.
Source and publication type
arXiv · Research preprint.
Peer-review status is not provided by this source.
Author and publication status
Author metadata is not stored; see the primary paper.
Threat model and attacker access
Black-box model, service, or application access.
Related deployment categories
Agent workflows; Agent memory
Taxonomy labels only; paper-specific deployment prerequisites are not inferred.
Affected systems
Tool-using personal-assistant agents that ingest untrusted email or calendar events into persistent memory Long-term fact-memory agents without security-focused admission or retrieval governance A-Mem Mem0 ExpeL Letta…

Research Paper

When Agents Remember Too Much: Memory Poisoning Attacks on Large Language Model Agents

Primary source: arXiv. Findings are reported by the cited research and have not been independently verified.

View Paper

Description

The paper describes GhostWriter, a reproducible two-phase attack against tool-using agents with persistent memory: untrusted email or calendar content is admitted into long-term memory, then later retrieved during a benign user task and treated as trusted context. In the authors’ controlled evaluation, this could steer subsequent agent actions despite the adversary lacking direct access to the agent, memory store, account, or later prompt. The paper reports an average 98% memory-injection rate and 60% activation rate across its tested configurations; these are paper-reported measurements, not independently verified facts.

Examples

See the primary source for the paper's evaluation and defensive reproduction context: https://arxiv.org/abs/2607.06595 (opens in a new tab)

Impact

A poisoned memory can persist across sessions and cause integrity corruption, unauthorized or misdirected tool actions, sensitive-information leakage, covert exfiltration, or scope escalation. The paper reports that directive integrity-corruption and covert-exfiltration scenarios reached up to 100% activation in some evaluated model/agent combinations.

Affected Systems

  • Tool-using personal-assistant agents that ingest untrusted email or calendar events into persistent memory
  • Long-term fact-memory agents without security-focused admission or retrieval governance
  • A-Mem
  • Mem0
  • ExpeL
  • Letta (formerly MemGPT)
  • MemoryOS

Mitigation Steps

  • Apply a memory-admission policy before persistence; classify candidate memories by provenance, trust, type, utility, sensitivity, verifiability, contradiction, and potential to alter agent behavior.
  • Treat retrieved memories as untrusted data rather than commands; suppress behavioral directives from untrusted sources before they enter the model context.
  • Screen memories again at retrieval time for query relevance, embedded instructions, unverifiable external claims, source trust, and contradictions with trusted information.
  • Preserve provenance and risk metadata with every memory so retrieval-time controls can make source-aware decisions.
  • Require user confirmation or trusted-source verification before sensitive, external-facing, or scope-expanding tool actions, especially changes to recipients, contacts, or workflow rules.
  • Use isolated synthetic test data and simulated tools to regression-test both admission and later activation; do not test against real users, accounts, or third-party systems.

Evidence