Poisoning Memory: Attacks That Outlast the Session

A false value written to an AI memory store is recalled as established fact in every future session, by any user who queries it, with no signal that it was ever attacker-supplied.

Every other attack in this series operates within a session. The injection happens, the model responds, and when the session ends, the attack ends with it. Memory poisoning is different. The injection happens once. The effect persists indefinitely β€” across every future session, for every user or system that accesses the poisoned memory store.

We confirmed the full chain: inject a document, watch false values get written to the memory store, open a fresh session with no connection to the original attack, and retrieve those false values as established organizational facts. The recall session has no way to know.

100% recall anchor rate once value is in memory
4 phases: inject, write, wait, recall
0 provenance markers surviving to recall

The Finding

We ran the full memory poisoning chain using Gemini Flash as the extraction model, targeting a memory store that subsequent sessions draw from. False values injected during document submission were written to memory and recalled with 100% anchor rate β€” once a value is in the store, it faces no competing signal during retrieval. The recall session reasons from false premises as if they were established knowledge, because from its perspective, they are.

We also confirmed the direct-store variant with Claude Haiku as the writing model.

The most operationally significant characteristic is the temporal decoupling: the injection event and the recall event are fully separated in time and context. The attack completes in the past. The consequences arrive in the future.

The Mechanism

The attack has four phases.

In phase one, an attacker submits a document containing injected false assertions to an AI pipeline that extracts content and writes it to a memory store. The document might be a contract, an invoice, a vendor profile, a compliance filing β€” anything the pipeline is designed to process.

In phase two, the extraction model anchors to the injected values and writes them as extracted facts. With Gemini Flash in the upstream role, this produces clean, well-structured memory entries with no injection artifacts.

Phase three is time. The session ends. The original document may be archived or deleted. Logs may roll off. The attacker’s access may have been temporary. The attack surface closes.

In phase four, a recall session β€” a different user, a different context, potentially weeks or months later β€” retrieves the stored memory. It sees only the extracted values. There is no injection syntax, no source document link, no audit trail pointing back to phase one. The system reasons from the stored values as it would reason from any other established knowledge.

Why Attribution Fails

A security team investigating a wrong decision downstream of a poisoned memory would need to trace the decision back through the recall session, back through the memory store, back through the extraction pipeline, and back to the original document submission. At each step, logs may be absent, retention windows may have expired, and the document itself may no longer be accessible. The poisoned memory contains no internal indication that anything is wrong.

Shared memory systems amplify the blast radius. A single injected document can influence every session that draws from the same store β€” different users, different teams, different use cases β€” indefinitely.

The Asymmetry

The attacker needs one window of access to the document submission pipeline. The defender needs to audit every memory write that ever occurred and validate it against a source that may no longer exist. These are not comparable positions.

By recall time, there is nothing to detect. Detection requires catching the attack at write time or preventing it through extraction-layer validation. After phase two completes, the attack has already succeeded. What follows is just execution.

Operator Note

Validate extracted values against authoritative sources before writing to memory. Do not treat AI-extracted facts as established organizational knowledge without provenance records that survive independent of the memory entry itself.

For high-consequence memory writes β€” anything involving authorization levels, financial records, compliance status, or access control β€” require human-in-the-loop confirmation before the write is committed. Retain extraction source references alongside memory entries. Implement write-time anomaly detection rather than relying on downstream review.

The defense window is narrow. It closes when the session ends.

↑