Agent memory as an attack surface

Agentic systems implement memory in three distinct ways, each with different characteristics and different vulnerabilities:

• In-context memory— the conversation history and context accumulated within the current session. It exists in the model's context window and is discarded when the session ends. It includes the system prompt, all user messages, all model responses, and all tool call results.
• External memory — information stored outside the model, in vector databases, relational stores, or document stores, and retrieved by the agent via search or query. It persists across sessions and is accessible to any session that queries the store.
• Episodic memory — summaries of past sessions stored by the agent itself, used to provide context about past interactions when starting a new session. It is generated by the model (which introduces its own risks) and retrieved at session start.

Each type has a distinct attack surface, a distinct poisoning method, and distinct controls. A complete memory security review must address all three that are present in the assessed system.

In-context memory is the most visible memory type because it is bounded by the session. Everything in the context window is available to the model for this session and gone when the session ends.

The security concern for in-context memory is prompt injection: an attacker who controls any content that enters the context window can influence the model's behavior for the duration of the session. This includes direct user input, tool return values, retrieved documents, and any other content the agent reads.

In-context memory also accumulates across the session. Early in a session, the model might correctly follow the system prompt's constraints. As the context grows — with retrieved content, tool results, and multi-turn conversation — the model's effective reasoning can shift. Injected content early in the session remains in context and can influence decisions made much later in the same session.

Controls for in-context memory poisoning: treat all non-system-prompt content as untrusted data, not as instructions; implement goal anchoring in the system prompt that resists displacement by context growth; and for long-running agents, periodically re-evaluate whether the agent's current behavior is consistent with its original goal.

External memory — vector stores, document databases, relational stores used for agent context — is what allows an agent to access knowledge that would not fit in a single context window. It is queried at session start or during the session to retrieve relevant context, which is then added to the model's context window.

The attack surface is the write path to external memory. An attacker who can insert content into the external memory store can influence any future session that retrieves that content. This does not require compromising the agent or the agent's infrastructure — it requires compromising whatever process writes to the memory store.

In RAG-style systems, the external memory store is typically populated from documents: internal wikis, email archives, customer records, support tickets. Any process that can write to these source documents can indirectly write to the agent's memory. This is a larger attack surface than teams typically account for.

Controls for external memory: restrict write access to the ingestion pipeline to authorized sources only; validate and sanitize content before ingestion; implement source attribution so the model knows the trust level of retrieved documents; and review the full ingestion pipeline as part of the memory security assessment.

Episodic memory is the most dangerous memory type from a security perspective, because it combines the characteristics of external memory (persistence across sessions) with the characteristics of model-generated content (the memory was written by the model, not by a controlled ingestion pipeline).

When an agent creates an episodic memory entry — summarising a past session and storing it for retrieval — the model is writing to a persistent store. If the session being summarised contained injected content, that content may be incorporated into the summary. The injected instruction survives the session in the memory store and is retrieved in future sessions as context.

Episodic memory poisoning is the agentic equivalent of a stored cross-site scripting attack. The payload is stored in a trusted location — the agent's own memory — and executes in future sessions without requiring ongoing attacker access. The injection happens once; the effect is persistent.

The mechanism: in session one, an attacker provides a carefully crafted input that contains an instruction formatted to survive summarization. The agent processes the session and generates a summary. The summary includes the instruction in a form the model will recognize and act on. In session two — with a different user — the summary is retrieved as context, and the instruction executes in session two's context.

Controls for episodic memory: validate episodic memory entries before storage (do they look like summaries of user interactions, or do they contain instruction-like content?); implement signed or provenance-tracked memory entries that distinguish model-generated summaries from injected content; and apply the same untrusted-input treatment to retrieved episodic memories that you apply to retrieved documents.

The general pattern of a memory poisoning attack has three phases: injection, storage, and execution.

Injection phase: The attacker introduces malicious content into the system through whatever channel is available — user input, a document ingested into the knowledge base, a web page retrieved by the agent, or a forged tool return value. The content is crafted to survive processing and be stored in memory.

Storage phase: The agent processes the malicious content and, as a side effect, stores some form of it in memory. For external memory, this is direct: the malicious document is indexed into the vector store. For episodic memory, this requires the model to summarise the malicious content in a way that preserves the injected instruction.

Execution phase:A future session retrieves the stored content — because it is relevant to the new session's query — and the model acts on the injected instruction in the new session's context. The new session has no awareness that the content it retrieved was attacker-influenced.

The gap between the injection and execution phases is what makes memory poisoning attacks difficult to detect. By the time the injected instruction executes, the original session that introduced it may be long gone. Without a complete audit trail that links retrieved content to its source and tracks what was stored and when, attributing the behavior to a memory poisoning attack is very difficult.

Session isolation is the primary structural control for memory-based attacks. It means that memory accessible in one session is not accessible to other sessions — the memory is scoped to the specific user, session, or context that created it.

Full session isolation prevents the execution phase of a memory poisoning attack from affecting other users: even if the attacker's session plants something in memory, that memory is not accessible to other sessions. It does not prevent the injection or storage phases, and it does not prevent a re-attack in the same user's future sessions.

In practice, most agentic systems implement partial session isolation: some memory is session-scoped (in-context), some is user-scoped (episodic memories associated with a specific user), and some is system-wide (shared knowledge base, shared vector store). The review must identify which memory type has which scope and assess the controls appropriate for each.

For system-wide shared memory, session isolation is not available as a control — the memory is intentionally shared. The controls here shift to: strict ingestion validation, source attribution and trust tagging, and review of the write access controls on the ingestion pipeline.

A complete set of memory security controls covers all three phases of a poisoning attack:

Injection prevention:

• Treat all non-system content as untrusted data, regardless of source
• Implement goal anchoring that resists displacement by injected content
• Restrict write access to external memory stores to authorized ingestion pipelines only
• Validate and sanitize content before ingestion into external memory

Storage prevention:

• Validate episodic memory entries before storage — flag entries that contain instruction-like patterns
• Implement human review for episodic memory entries that deviate from the expected summary format
• Track the provenance of all stored memory entries (source session, source document, storage timestamp)

Execution mitigation:

• Tag retrieved memory with trust level based on source; treat retrieved documents as lower-trust than system prompts
• Implement session isolation for user-specific memory
• Build an audit trail that links agent actions to the memory content that influenced them, enabling post-incident analysis

The memory security review must produce the following evidence for the assessed system:

• Memory architecture map — which memory types are present, what is stored in each, how each is populated, and how each is accessed
• Session isolation scope — what memory is session-scoped, user-scoped, or system-wide; and the access controls for each scope
• Ingestion pipeline review — the write path for external memory stores, the access controls, and the validation steps applied before storage
• Episodic memory review — whether episodic memory is present, how entries are generated and stored, and what validation occurs before storage
• Control gap assessment — which controls from the control set above are present, which are absent, and the residual risk from absent controls

This evidence supports the memory security section of the agentic AI risk disposition. For the full review framework, see the agentic AI security review hub.