Agent Memory Is an Attack Surface

Memory gives an agent continuity. It also gives untrusted information a way to survive the interaction that introduced it.

Open the forensic memory trace at full size.

An agent reads a document, summarizes a conversation, retrieves a policy or receives an update from another agent. Some of that information may be stored for later. The next task begins, the original source is no longer visible, and the stored record returns as context.

That is useful when the record is accurate, current and properly scoped. It is dangerous when the record is malicious, misleading, stale or written under the wrong authority.

This is the security problem behind memory poisoning. The attack is not limited to the model response that handled the original input. A poisoned record can persist across sessions, reappear during later retrieval and influence planning or tool use long after the source has disappeared.

OWASP lists this as ASI06, Memory & Context Poisoning, in its Top 10 for Agentic Applications 2026. Its description covers summaries, embeddings, retrieval stores and other information an agent retains, retrieves or reuses. The important property is persistence.

A prompt injection changes one interaction. A poisoned memory write can change what future interactions begin by believing.

Memory is stored influence

It is tempting to treat memory as a convenience feature. The user does not need to repeat a preference. The support agent remembers an account detail. The coding agent keeps project conventions. The research agent carries forward useful findings.

Once remembered information affects decisions, memory is part of the system’s security state.

The important questions are no longer limited to “What did the user say?” They include:

• Who or what was allowed to write this record?
• Which source produced it?
• Was the source authenticated?
• Was the content checked before it was committed?
• Which user, tenant, task or agent can retrieve it?
• How long should it remain available?
• Can it be corrected, quarantined or revoked?
• Does retrieving it grant any authority, or does the downstream system still verify the action?

A memory system that cannot answer those questions has an attribution problem before it has a model problem.

The attack chain

The mechanism is easier to understand as a state transition:

untrusted source
    -> candidate memory
    -> write or promotion
    -> persistent store
    -> later retrieval
    -> context assembly
    -> plan or decision
    -> tool action

The vulnerable moment is often the change from candidate information to durable state.

An external document may be untrusted when it enters the system. If the agent summarizes it and stores the summary without source metadata, the next session may not see an external document anymore. It sees an internal memory record. The storage layer has changed the record’s location without proving its truth.

That can create a trust-laundering effect. Content that began outside the trust boundary returns through an internal retrieval path and may look more authoritative than it deserves.

OWASP’s ASI06 examples include poisoned RAG stores, shared-user context contamination, summaries that persist crafted content, long-term memory drift and propagation between cooperating agents. These are different implementations of the same failure: a later decision consumes stored information without enough evidence about where it came from or whether it should still be trusted.

Where poisoned memory can enter

The write path is wider than a chat box.

Uploaded documents and web content

A research or operations agent may read pages, PDFs, tickets, emails or files. Hidden instructions are one risk, but false factual claims and stale operational guidance matter too. If the system automatically converts everything it reads into durable memory, ordinary ingestion becomes a privileged state-change path.

API feeds and connected applications

Agents consume calendars, CRMs, logs, issue trackers and internal databases. An authenticated API proves which system responded. It does not guarantee that every field is correct, current or safe to promote into a different context.

Retrieval stores

RAG systems deliberately retrieve external knowledge to influence generation. The PoisonedRAG paper treats the knowledge database itself as an attack surface and demonstrates that injected texts can manipulate answers to targeted questions in its experimental settings.

This is not proof that every RAG deployment is compromised. It shows why retrieval stores need the same integrity, access and provenance controls as other production data systems.

Other agents

Multi-agent workflows create transitive trust. A message from another agent can feel internal even when that agent relied on an untrusted page, an over-scoped tool or a contaminated shared store.

The receiver still needs to know the original source, the task scope and the authority attached to the message. “Another agent said it” is not provenance.

The agent’s own output

Automatic self-ingestion is especially risky. An agent generates a summary, stores it, retrieves it later and treats the retrieved summary as evidence. A mistake can become self-reinforcing because each retrieval appears to confirm the stored record.

OWASP explicitly recommends preventing automatic re-ingestion of agent-generated output into trusted memory. Generated text can be useful working state, but it should not silently promote itself into ground truth.

Persistence changes the threat model

The dangerous word is persistent, not permanent.

Memory can expire, be deleted, be superseded or be rolled back. Good lifecycle controls limit how long a bad record can influence the system.

Without those controls, the window of influence extends beyond the original interaction. The agent may retrieve the record tomorrow, in a different workflow or for another user. The person reviewing the later action may never see the content that introduced the poisoned state.

That makes incident analysis harder. The visible failure may be a bad refund, a misleading security classification or an unsafe tool call. The cause may be a memory write several sessions earlier.

A useful audit trail therefore needs both sides of the lifecycle:

• the event that created or changed a memory record;
• every later retrieval that used it in a consequential decision.

Logging only the final tool call misses how the context was assembled. Logging only the memory write misses where the record later caused harm.

Tools turn bad context into consequences

Memory poisoning does not automatically create real authority. A remembered approval should not bypass a properly enforced authorization check. A false policy should not create a permission that the downstream service refuses.

The practical risk rises when a tool-enabled agent already has legitimate privileges.

A poisoned record can steer that agent into acting as a confused deputy. The action may be performed with valid credentials and through an allowed tool, even though the decision was based on corrupted context.

That is why memory controls cannot carry the entire security model. High-impact actions still need independent authorization, narrow credentials, policy checks and clear human approval where appropriate.

The rule is simple: remembered authority is not current authorization.

Defend the write, the read and the action

There is no single filter that solves memory poisoning. The useful design is layered and reversible.

Boundary	Control	What it reduces	What it does not prove
Before write	Validate candidate memory and restrict write authority	Obvious malicious, malformed or over-scoped records	That accepted content is true
At commit	Attach source, writer, timestamp, scope and integrity metadata	Anonymous or untraceable records	That a known source is correct
In storage	Segment by user, tenant, domain and task	Cross-user and cross-context contamination	That records inside one segment are safe
During retention	Expire, decay or review unverified memory	Long-lived influence from weak records	That recent memory is trustworthy
At retrieval	Filter by scope, provenance, age and trust state	Irrelevant or unqualified context	That retrieved context should control an action
Before action	Re-check intent, permissions and side effects	Tool misuse caused by corrupted context	That every harmful plan will be detected
During response	Log lineage and monitor anomalous changes	Silent persistence and untraceable spread	Automatic recovery
During recovery	Quarantine, revoke, restore snapshots and roll back	Continued use of suspected records	That all downstream effects were reversed

Provenance deserves a specific caveat. It supports attribution and audit. It does not establish truth.

A signed record can still be stale. A trusted source can be compromised. A verified employee can make a mistake. Provenance tells the reviewer where to look and which policy to apply. It should not become a decorative trust badge.

Give memory an explicit lifecycle

Many agent systems treat memory as an append-only convenience. Security improves when memory behaves more like governed state.

A candidate record can move through explicit stages:

observed
    -> candidate
    -> validated or quarantined
    -> committed with scope
    -> retrieved with lineage
    -> reviewed or expired
    -> revoked or archived

Each transition should have an owner and a reason.

A low-risk preference such as a formatting choice may be accepted automatically with a short retention period. A policy statement that could change payments, permissions or production systems should require stronger source validation and review. A record inherited from another agent should retain the original lineage rather than replacing it with the last agent’s identity.

This is where risk-based memory matters. Not every record deserves the same retention, retrieval weight or review burden.

What builders should record

A practical memory record needs more than text and an embedding.

Useful fields include:

• stable record ID;
• raw source or source reference;
• writer identity;
• creation and modification timestamps;
• user, tenant, task and domain scope;
• validation state and reviewer, if any;
• retention or expiry policy;
• superseded and revoked states;
• integrity hash or version;
• retrieval history for high-impact use;
• links to downstream actions influenced by the record.

Do not expose sensitive source data unnecessarily, but keep enough lineage to investigate a bad decision and revoke the responsible state.

The retrieval system also needs permission to abstain. If a record lacks the provenance or scope required for a high-impact task, the safe outcome may be to exclude it, request a current source or escalate for review.

A useful red-team question

Security testing often asks whether an agent will follow a malicious instruction now. Memory adds a second test:

If the agent rejects the instruction today, can any part of it still be stored and retrieved tomorrow?

The AgentPoison paper explores this persistence problem by poisoning long-term memory or knowledge bases so trigger-bearing instructions retrieve malicious demonstrations. Its results are specific to the tested agents and experimental setup, not a prevalence estimate. The important engineering lesson is that memory retrieval can become an attack mechanism even without modifying the base model.

A memory red-team should test at least four paths:

1. Can untrusted content reach a durable store?
2. Can the original source or warning disappear during summarization?
3. Can the record cross user, tenant, task or agent boundaries?
4. Can later retrieval influence a consequential tool call without fresh authorization?

The recovery test matters too. Quarantine a suspected record, revoke it, restore a prior snapshot and verify that future retrieval no longer surfaces it. Then inspect whether earlier downstream effects need separate rollback.

Memory should carry evidence, not borrowed authority

Memory is one of the features that makes agents useful. It gives continuity to systems that would otherwise start from zero every time.

That continuity should not be confused with trust.

Stored information needs a writer, source, scope, age and lifecycle. Retrieval needs to preserve that lineage. Consequential actions need fresh authorization that does not depend on the agent’s explanation sounding internally consistent.

The strongest memory architecture does not claim to make poisoning impossible. It limits who can write, narrows where records can travel, makes weak provenance visible, expires uncertain state and preserves a path to quarantine and rollback.

An agent does not become safer because it remembers more. It becomes safer when the system knows what that memory is allowed to influence.

Sources

1. OWASP Gen AI Security Project, OWASP Top 10 for Agentic Applications 2026, ASI06: Memory & Context Poisoning, December 2025.
2. OWASP Gen AI Security Project, Agentic AI - Threats and Mitigations, February 2025.
3. Zhaorun Chen, Zhen Xiang, Chaowei Xiao, Dawn Song and Bo Li, AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases, arXiv:2407.12784, July 2024.
4. Wei Zou, Runpeng Geng, Binghui Wang and Jinyuan Jia, PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models, arXiv:2402.07867v3, August 2024.