AI Agent Memory Poisoning Needs Full-Lifecycle Defenses

AI agent memory poisoning turns one untrusted input into durable state. Once an agent writes attacker-controlled content to persistent memory, that content can return days or sessions later as apparently trusted context. Defend the full lifecycle: gate every write, attach provenance and expiry, isolate records by user and agent, re-screen retrieval, keep action authorization outside the model, and preserve an influence log that supports rollback.

Table of contents

What is AI agent memory poisoning?

AI agent memory poisoning is the insertion or modification of persistent records so that later retrieval changes an agent's answer, decision, or tool use. The original input may be gone when the effect appears. That time gap makes the attack harder to notice and reconstruct than a visible prompt injection in the current conversation.

Memory can live in several places:

The storage technology is not the defining issue. Persistence plus later influence creates the security boundary.

This differs from three neighboring risks. Prompt injection manipulates the current model context, although it can become the delivery channel for poisoned memory. Training-data poisoning changes model behavior through the training corpus. Retrieval poisoning targets content selected for a request. Agent-memory poisoning persists a record that the system may later treat as part of the user's history, preferences, or operating state.

Three attack patterns matter in practice:

Microsoft's current guidance describes the same structural concern in defensive terms: persistent memory stores sensitive data and also influences model behavior and tool selection. It should therefore be governed as both a data system and a control plane. Microsoft Learn

What three recent studies measured

Three July 2026 preprints examined different parts of this threat. Read together, they show why a single memory filter is a weak release criterion.

GhostWriter tested injection now and activation later

When Agents Remember Too Much introduced GhostWriter, a two-stage attack against tool-using personal agents. An adversary first places hidden content in an untrusted source. The agent processes that source and writes attacker-influenced memory. A later task retrieves the record and activates its effect.

Across the paper's tested agents and models, GhostWriter reached an average injection rate of about 98% and an average activation rate of about 60%. The authors also tested AM-Sentry, which combines a stricter memory-saving policy with a retrieval screen. The paper evaluates both attack success and task utility in its custom simulated workweek; the defense results vary by model and configuration.

The boundaries matter. The work covers five agents, four model families, and email or calendar workflows. Its utility test is custom, the attackers are non-adaptive, and the results do not estimate how often deployed agents are attacked.

MemPoison separated direct, compositional, and dormant failures

MemPoison assembled 1,227 hand-validated cases across four attack types, three injection channels, and three memory substrates. The evaluation included seven open-weight and three closed-weight model families.

The paper's useful contribution is its three-level taxonomy. L1 is direct single-record corruption. L2 becomes harmful when multiple records are retrieved together. L3 remains dormant until a later context activates it. The authors report that baseline write-time defenses suppress direct attacks more reliably than L2 or L3 cases. Their mechanistic influence analysis attributes the gap to records that look benign when stored but become harmful under composition or a trigger.

That does not prove every production write filter will fail. The benchmark covers three representative memory substrates and standard text-based channels. The authors call for broader work on decay, summarization, access controls, and other memory ecosystems.

MemGhost tested a one-shot email delivery path

When Claws Remember but Do Not Tell introduced WhisperBench, a 108-case benchmark using a real IMAP/SMTP workflow and an email-agent skill. Its attack framework, MemGhost, generates one email payload without runtime feedback. Success requires the agent to adopt poisoned memory, avoid alerting the user in its immediate response, and alter later behavior.

On 56 held-out cases, the paper reports 87.5% end-to-end success on OpenClaw with GPT-5.4 and 71.4% on the Claude Code SDK with Sonnet 4.6.

Those figures belong to the authors' benchmark, proxy environment, reward design, and model versions. The evaluation starts after a message reaches the inbox. It does not model mail-provider controls such as spam filtering, SPF, DKIM, or DMARC. The paper is a first-version preprint, so its results deserve replication.

Why write-time filtering is not enough

A write gate sees the proposed record and the evidence available at that moment. It may not see the future task, the other records that will be retrieved beside it, or the tool the agent will later call.

That creates four blind spots:

Write-time checks still matter. They reduce the amount of unsafe state that reaches persistence. The mistake is treating storage approval as permanent trust.

Retrieval should return candidate context, not authority. Before inserting a record into the model context, the system can check its source, age, task relevance, contradictions, sensitivity, and requested effect. A high-risk record can be withheld, summarized, or routed to review. Microsoft's current guidance recommends this write-and-retrieval split, along with deterministic isolation and full lifecycle visibility. Microsoft Learn

A secure agent-memory architecture

The system needs a traceable chain from source to action:

`source → write decision → stored version → retrieval decision → model context → policy decision → tool result`

*Caption: A memory record becomes candidate context only after write and retrieval checks. Independent policy still authorizes every consequential action, while the influence chain supports investigation and rollback.*

1. Require explicit intent for durable writes

Do not let every message, document, or tool response become long-term memory. Define which events may create durable state. User-confirmed preferences and explicit “remember this” actions are easier to justify than an autonomous summary of an untrusted attachment.

Record who or what requested the write. If a tool or subagent initiated it, preserve that identity rather than collapsing everything into the end user's name.

2. Store provenance, scope, and expiry with the record

A useful memory record needs more than text and an embedding. Store at least:

A signature can protect record integrity. It cannot prove that the original content was true, safe, or authorized.

3. Enforce isolation in code and storage

Tenant, user, agent, and workspace boundaries belong in access-control lists, scoped tokens, row-level policies, and encryption boundaries. Prompt instructions are not access control. Shared memory should be an explicit product feature with named writers and readers, not a convenient default namespace.

4. Quarantine low-trust writes

Create a state between “discarded” and “trusted memory.” External files, email, web pages, indirect tool output, and records with unclear intent can enter quarantine. They should not appear in normal retrieval until a deterministic rule or authorized reviewer promotes them.

Quarantine also gives incident responders a place to preserve evidence without continuing the influence.

5. Re-evaluate records at retrieval time

Retrieval risk depends on the current task. Evaluate the selected set, not only each record:

6. Keep tool authorization independent

Memory may supply parameters. It should never expand permissions. The tool gateway must enforce the current identity, allowed action, resource boundary, destination, budget, and approval requirements. Treat memory-derived arguments as untrusted input and validate them against current policy.

Human approval also needs fresh context. Show the proposed action, affected resource, data destination, and the memories that influenced it. “Approve?” without that chain hides the relevant decision.

7. Log influence and support rollback

Log memory create, read, update, and delete operations with identity and provenance. For consequential actions, retain the IDs and versions of the records injected into context. That makes it possible to answer three incident questions:

Deletion should remove active influence, not only hide a row in the user interface. Test indexes, summaries, caches, replicas, and derived records. OWASP's agent guidance recommends validated and isolated memory plus adversarial tests and release evidence; its broader memory analysis maps persistent prompt injection to the agent-memory threat surface. OWASP Agent Security Cheat Sheet OWASP GenAI Security Project

Choose a policy for each memory class

One retention policy is too coarse. Start with classes that have different write and retrieval rules.

This table is a starting policy, not a compliance claim. A medical agent, coding assistant, sales agent, and personal assistant have different harm models. The invariant is narrower: persistence must not silently convert untrusted content into permission.

A reproducible memory-poisoning test workflow

Build the test harness around benign markers and disposable accounts. You do not need real credentials or exfiltration payloads to detect persistence and policy failures.

Step 1: Capture a clean baseline

Run a fixed task set with an empty memory store. Record answers, retrieval results, tool proposals, policy decisions, latency, and user-visible explanations. Repeat enough times to separate system changes from normal model variance.

Step 2: Define paired clean and poisoned cases

For every case, keep the user task constant and change only the candidate memory path. Cover at least:

Use a canary action such as writing `TEST_BLOCKED` to a disposable log. The test fails if the agent performs or proposes that action outside the expected policy path.

Step 3: Observe every boundary

Capture four separate outcomes:

An end-to-end pass can hide a weak layer. For example, authorization may block the canary action even though a poisoned record was stored and repeatedly retrieved. That is useful containment, but the memory defect still needs a fix.

Step 4: Measure utility and false positives

Run benign memory cases through the same pipeline. Track task completion, accepted user preferences, incorrect quarantines, retrieval precision, latency, and review volume. A filter that blocks all durable memory has low attack success because it removed the feature.

Step 5: Set release gates by risk

Useful gates include:

OWASP's open-source Agent Memory Guard project is one implementation signal for memory scanning and test tooling. Its repository and self-reported evaluation can help teams inspect patterns, but they are not a substitute for testing the actual agent, model, memory backend, and policy stack.

Re-run the suite after changes to memory extraction, summarization, embeddings, retrieval, prompts, models, tool schemas, authorization, or deletion logic. These layers interact.

What the evidence does and does not support

The papers measured attack success inside constructed benchmarks. They did not measure the population-wide rate of AI agent memory poisoning in production.

They support three narrower conclusions:

The papers infer that memory governance needs context-sensitive defenses. Microsoft and OWASP independently recommend defense in depth across writes, isolation, retrieval, user control, observability, and testing.

The practical interpretation is to make every transition testable. A team should be able to explain why a record was stored, why it was retrieved, how it influenced an action, which policy authorized that action, and how to remove the record's downstream effects.

Questions teams ask

Is AI agent memory poisoning the same as prompt injection?

No. Prompt injection is one way to introduce hostile instructions. Memory poisoning adds persistence: manipulated content is stored, retrieved in a later context, and may influence future reasoning or tool use after the original input has disappeared.

Can signed memory records prevent poisoning?

No. Signatures can prove that a record was not altered after creation. They do not prove that the original content was true, safe, or authorized. A secure design also needs provenance, explicit write intent, scope, expiry, retrieval checks, and independent action authorization.

Should memory poisoning defenses run at write time or retrieval time?

Both. Write gates reduce unsafe persistence. Retrieval checks catch stale, contradictory, compositional, or trigger-dependent risks that were not visible when individual records were stored. Neither layer should be allowed to grant tool authority.

Claim checks

Sources