Persistent Memory Injection: Security Risks of AI Agent Memory-Write Tools

Persistent memory injection is SSA descriptive wording for a security-relevant write to an agent's own durable memory store, made through the agent's memory-write tool rather than through direct database access, where an adversary causes the agent to record attacker-controlled content as if it were a legitimate, user-approved fact or instruction. The defining consequence is that the write outlives the session in which it happened and is read as trusted history in every session that follows, by the same agent, until someone finds and removes it.

What it is

The defining object is a durable memory record: a fact, preference, or instruction an agent's memory feature stores and later re-injects into context automatically, without the user re-stating it. The defining cause is adversarial: untrusted content, usually delivered through a document, webpage, image, or tool result the agent processes, manipulates the agent into invoking its own memory-write tool on the attacker's behalf. The defining consequence is durable state that the user never approved but that the agent treats as if they had, because the memory system does not distinguish a write triggered by user intent from one triggered by injected content reaching the same tool call.

This differs from a single-turn prompt injection mainly in lifespan. A one-off injected instruction can be undone by ending the conversation. A memory write survives that boundary by design, since surviving the boundary is the entire purpose of a memory feature.

What it is not

Prompt injection that ends when the session ends and never reaches a memory-write tool call.
User-authored memory entries, including ones a user later regrets or forgets they added.
Accidental memory drift, where a model misremembers or blends prior turns without any adversarial write path.
Model-weight attacks, training-data poisoning, and product-specific exploit procedures or reproducible payloads.

In scope

Untrusted content (documents, images, web pages, tool results, or other agents' output) that causes an agent to call its own memory-write tool.
Delayed or conditional memory writes, where the injected trigger and the actual write happen in different turns.
Memory records that function as durable instructions rather than durable facts.
Propagation of an injected memory record into later sessions, other tools, or exported memory data.
Defensive controls for write-time confirmation, storage-time validation, monitoring, containment, and recovery.

Target state and trust boundaries

The target state is the agent's persistent memory store: whatever object survives across sessions and is automatically re-read into context on a later turn, without the user restating it. The relevant trust boundary sits at the memory-write tool call itself, not at the conversation that preceded it. A memory system that treats every write reaching that tool call as user-approved, regardless of what triggered the call, extends implicit trust across a boundary the user never actually crossed. The gap is between "the agent called its memory tool" and "the user asked it to remember this," and most current memory features do not verify the second claim before acting on the first.

Preconditions and impact

Three conditions are usually present: the agent must process untrusted content as part of normal operation (a document, image, page, or tool output); that content must be able to influence tool selection, meaning the agent's memory-write tool is reachable from content the agent merely reads rather than from content the user directly typed; and the memory system must promote the resulting write to durable state without independent confirmation.

Resulting effects include false-belief insertion, where an unsupported claim about the user or task becomes part of the agent's working assumptions in every future session; durable instruction insertion, where the injected content functions as a standing directive rather than a stored fact, for example steering the agent toward a specific action or destination in later turns; and, in the more severe documented cases, staged data exfiltration, where a memory write establishes a channel or condition that a later, separate step uses to move data out.

Persistence

A single injected memory record can influence every session that follows until it is found and deleted, which is a materially longer persistence window than a compromised summary confined to one session's rolling context. Persistence here is a property of the memory store's retention policy, not of any one conversation's length. If the memory feature exports, syncs, or feeds records into other tools, the same record can also propagate beyond the agent instance that first wrote it.

What the research establishes

Independent security researcher Johann Rehberger disclosed the first widely reported case against ChatGPT's memory feature in 2024, showing that a prompt injection delivered through untrusted content could cause the model to store false, attacker-chosen memories that persisted into later conversations (Embrace The Red, ChatGPT: Hacking Memories with Prompt Injection). A related disclosure, which Rehberger named SpAIware, combined a persistent memory write with the ChatGPT macOS app's browsing tool to establish a channel for continuous data exfiltration across future sessions until OpenAI shipped a partial fix (Embrace The Red, Spyware Injection Into Your ChatGPT's Long-Term Memory).

The pattern is not specific to one vendor. In 2025, Rehberger reported a comparable technique against Google Gemini's memory feature, using delayed tool invocation so an untrusted document plants a conditional trigger that fires on a later, unrelated user reply (Embrace The Red, Hacking Gemini's Memory with Prompt Injection and Delayed Tool Invocation). In 2026, a separate disclosure against Claude's memory tool used an adversarial image containing hidden text to manipulate Opus 4.7 into storing false information about the user, succeeding in five of ten initial trials before the specific technique stopped working within 24 hours (Embrace The Red, Breaking Opus 4.7 with ChatGPT). Three major vendors' memory features have each had at least one documented case, which is evidence that the write-time trust gap is a property of the memory-write tool pattern itself rather than one product's implementation bug.

Academic work reaches the same surface from a different angle. MINJA, presented at NeurIPS 2025, demonstrates that an attacker with only ordinary query access to an agent, no direct access to its memory store, can inject malicious records by crafting bridging steps that link an innocuous victim query to a malicious reasoning pattern, then progressively removing the scaffolding so the poisoned record is retrieved naturally in later interactions. The paper reports 98.2 percent injection success and a 76.8 percent attack success rate across the agent architectures tested (arXiv 2503.03704, Memory Injection Attacks on LLM Agents via Query-Only Interaction). A more recent preprint evaluates both the attack and defense side under realistic conditions: it finds that an agent's pre-existing legitimate memories substantially reduce attack success compared to idealized empty-memory test setups, and proposes composite trust scoring on input and output plus memory sanitization combining temporal decay with pattern-based filtering (arXiv 2601.05504, Memory Poisoning Attack and Defense on Memory Based LLM-Agents). Both papers study memory poisoning as a research problem rather than proposing product-specific exploit payloads, and this article does not reproduce either technique.

Detection: observable signs

A memory-write tool call occurs in a turn where the user did not ask the agent to remember anything.
A memory-write tool call is triggered by processing a document, image, or page rather than by a direct user instruction.
A stored memory record contains a directive, condition, or destination rather than a simple fact about user preference.
A memory record's content does not match anything the user said earlier in the same session.
The same injected claim reappears across multiple unrelated sessions after one contaminated write.
A later session's behavior changes in a way traceable to a memory record the user does not recall approving.

Useful telemetry includes the triggering turn's input source (user-typed versus ingested content), the full tool call and its arguments, a diff between session-visible user statements and what was actually written to memory, and a mapping from each memory record to every session that later read it.

Defenses, containment, and recovery

The table below is SSA editorial guidance. It is neither a standard requirement nor a measured effectiveness ranking, and the composite-trust and sanitization row reflects the mitigations proposed in arXiv 2601.05504, not an independently verified result.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Explicit write-time confirmation | Injected content reaching the memory-write tool without user awareness | Chat and agent products with a memory feature | Confirmation fatigue can push users to approve without reading; test with realistic prompt volume, not a single demo write. | | Source-aware tool gating | Memory writes triggered by ingested content rather than direct user text | Agents that process documents, images, or pages in the same session as memory tools | Requires reliably distinguishing user-typed from ingested input; verify the distinction holds across all input modalities the product supports. | | Composite trust scoring and memory sanitization | A poisoned record surviving retrieval and reuse | Memory-augmented agents with an existing record base | Threshold calibration trades false positives against missed attacks; verify against both an idealized empty-memory test and a populated, realistic memory base. | | Periodic memory review surfaced to the user | A silent record persisting unnoticed across sessions | Any product with durable, cross-session memory | Users may not review regularly; pair with automated anomaly flags rather than relying on manual audit alone. | | Least-privilege scoping of what memory can influence | A poisoned record becoming an unauthorized action, not just a false belief | Agents where memory content can affect tool selection or destinations | Limits blast radius but not the false belief itself; exercise deny paths with a poisoned-record scenario. |

Prevention should treat every memory-write tool call as requiring evidence the user actually intended it, not merely that the model decided to make it. Detection should compare the triggering input's source against the tool call it produced, and flag records that read as instructions rather than facts. Containment should freeze the suspect record's influence on new sessions before deleting it, since deletion alone does not undo actions already taken while it was live. Recovery should enumerate every session that read the record, revalidate any resulting action, and restore the memory store from the last point confirmed clean.

Boundaries with similar concepts

Compromised summaries, covered separately, involve a compactor deciding what survives from a session's own history; persistent memory injection involves a distinct write path, an explicit tool call, that adds content never present in the original session at all. A summary can become a memory-injection case once its output is fed into a memory-write call, but a session-only summary that never reaches durable storage stays outside this article's scope. Shared state poisoning targets objects multiple agents or sessions read as ground truth; this article targets one agent's own durable memory, which becomes a shared-state case only once another agent or session also reads that same store as authoritative.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | Embrace The Red (2024, 2025, 2026) | "Hacking memories," "SpAIware," "delayed tool invocation" | Documented cases across three vendors' memory features; direct evidence for this entry path. | | arXiv 2503.03704 (v5, 2026-02-12) | MINJA, Memory Injection Attack | Academic evidence that query-only interaction can poison agent memory without direct store access. | | arXiv 2601.05504 (v2, 2026-01-12) | Memory poisoning attack and defense; composite trust scoring; memory sanitization | Evidence that realistic pre-existing memory reduces attack success, plus proposed defensive controls. | | OWASP Agentic Top 10 2026 | `ASI06 Memory & Context Poisoning` | Broader risk category for poisoned durable state. | | MITRE ATLAS v2026.06 | `AML.T0080 AI Agent Context Poisoning`; `AML.T0080.000 Memory` | Attacker-behavior classification for poisoning an agent's memory sub-technique. | | Agent State Attack | Persistent memory injection | SSA descriptive phrase, not attributed to the sources above. |

Related terms

Agent state attack: the SSA Working Term this article's scope sits under.
Compromised summaries and context compaction: the adjacent state surface for session-scoped compaction rather than an explicit memory-write tool call.
Shared state poisoning in multi-agent systems: the boundary case where a durable memory store is read by more than one agent or session.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping.

FAQ

Does this require the user to have a "memory" feature turned on?

Yes. The entry path requires a durable, cross-session memory store the agent can write to on its own initiative. Agents without persistent memory cannot be targeted by this specific write path, though they remain in scope for session-only prompt injection and compromised summaries.

Is this the same as prompt injection?

Prompt injection is usually the delivery mechanism, but it is not the target state. Prompt injection describes how untrusted content reaches the model; persistent memory injection describes what happens when that content causes a durable, cross-session write. The same injected instruction that has no lasting effect in a memory-less agent becomes a standing directive once it reaches a memory-write tool.

Can turning off memory eliminate the risk?

It removes this specific entry path, at the cost of the feature's utility. For products where memory stays on, the more durable fix is verifying that a write reflects user intent before it is promoted to durable state, not merely that a tool call happened to fire.

Is a single suspicious memory record proof of an attack?

No. Treat it as a lead. Confirm by tracing the triggering turn's input source, checking whether the content matches anything the user actually said, and checking whether the same claim propagated into later sessions before concluding the record is adversarial rather than an ordinary model error.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30); arXiv 2503.03704, v5 (2026-02-12); arXiv 2601.05504, v2 (2026-01-12).

Last verified: 2026-08-11. The Embrace The Red post dates, techniques, and reported outcomes were read from the source articles; the arXiv titles, authors, and dates from their abstract pages; the OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entries.

Change history: 2026-08-11, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** "SpAIware" is an industry term coined by the disclosing researcher (Embrace The Red). "MINJA" and "Memory Injection Attack" are Research Terms owned by arXiv 2503.03704. `ASI06` and `AML.T0080` (with sub-technique `AML.T0080.000`) are Standard Terms owned by OWASP and MITRE. "Persistent memory injection" is SSA descriptive wording, not a standard term.