Defend agent memory and context against poisoning (OWASP ASI06)

OWASP's Top 10 for Agentic Applications 2026 lists Memory & Context Poisoning as ASI06. Its context is "any information an agent retains, retrieves, or reuses, such as summaries, embeddings, and RAG stores", and the risk is that adversaries "corrupt or seed this context with malicious or misleading data, causing future reasoning, planning, or tool use to become biased, unsafe, or aid exfiltration." One-time input prompts are excluded; they are prompt injection (LLM01). What makes ASI06 different is persistence: the entry outlives the conversation that created it and is reused by later sessions, other users or other agents.

OWASP separates it from its neighbours. Agent Goal Hijack (ASI01) is direct manipulation of the agent's goals; Cascading Failures (ASI08) is the degradation that spreads after poisoning; but poisoned memory frequently leads to goal hijack, because a corrupted entry changes how the agent interprets its goal or picks its tools. MITRE ATLAS describes the same attack as AI Agent Context Poisoning (AML.T0080), with Memory (AML.T0080.000) for persistence across chat sessions and Thread (AML.T0080.001) for the rest of one conversation.

• A travel assistant is repeatedly told a fake flight price, stores it as true and later approves bookings at that price (an OWASP scenario).
• Bogus refund rules are inserted into memory shared by several agents, which reuse them and make bad decisions (an OWASP scenario).
• An email or web page the assistant reads tells it to remember an instruction, compromising that user's current and future sessions (an OWASP scenario, and the memory sub-technique in MITRE ATLAS).
• Near-duplicate content seeded by one tenant is pulled into another tenant's retrieval through a loose namespace filter (an OWASP scenario; see /domains/ai-emerging/llm-security/rag-tenant-isolation/).

Map the write paths before choosing controls. The obvious one is the user asking the agent to remember something. The dangerous ones are indirect: a tool result, web page, email, uploaded file or peer agent's message that contains "remember that...", which the model obligingly saves; a conversation summary that carries an injected instruction into the next session; an ingestion pipeline that adds uploads or feeds to a retrieval store; and the agent saving its own conclusions, which may already be wrong or poisoned. MITRE's description of the memory technique notes that because memory "is controlled via normal conversations with the user", an adversary can inject memories via direct or indirect prompt injection.

List each store (key-value memory, memory files, summaries, vector indexes, shared scratchpads between agents), who can write to it, from which inputs, and which later decisions read it. Anything that reaches a store without passing a check in your code is a write path you do not control.

Store memories as typed records, such as a preference or a fact about the user, rather than free text addressed to the model, and insert them into the context as quoted data with their source, not as part of the system prompt. That does not stop a model from following an instruction hidden in a fact, which is why authority must not depend on memory at all. The tool gateway takes the user and tenant from the session and checks current permissions on every call (/domains/ai-emerging/agent-security/tool-authorization/); a memory that says "this user is an administrator" or "refunds up to 5,000 USD are pre-approved" changes nothing.

High-impact decisions should not rest on memory the user never confirmed. OWASP's ASI06 guidance suggests requiring two signals before high-impact memory is surfaced, such as a provenance score and a human-verified tag, and requiring human review for high-risk actions.

Let the model propose memories and let code decide. Anthropic's memory tool shows the division of labour: it is client-side, so the model only requests file operations and "your application executes them", and its documentation makes path validation, size caps, expiry and stripping sensitive data the application's responsibility. Whatever storage you use, the decision belongs in the same place.

The gate below takes the tenant and user from the session, accepts only known kinds of entry under a size limit, refuses the agent's own output, commits what the user typed in the current session, and quarantines anything that came from a tool, page or email, or that reads like an instruction to the agent, with an expiry date. The directive pattern is a heuristic that routes entries to review; it is not what makes the design safe. It was tested with Python 3.14.8.

import dataclasses
import datetime as dt
import re

KINDS = {"preference", "fact"}
UNVERIFIED_TTL = dt.timedelta(days=30)
# A heuristic, not a control: text addressed to the agent goes to review instead of memory.
DIRECTIVE = re.compile(r"\b(ignore|always|never|from now on|you must|system prompt|instruction)", re.I)


@dataclasses.dataclass(frozen=True)
class Proposal:  # what the model asked to remember, and where the text came from
    kind: str
    text: str
    source: str  # "user_message", "tool_result", "web_page", "email", "agent_output"
    source_ref: str


@dataclasses.dataclass(frozen=True)
class Entry:
    tenant: str
    user: str
    kind: str
    text: str
    source: str
    source_ref: str
    verified: bool
    created: dt.datetime
    expires: dt.datetime | None


def gate(p: Proposal, tenant: str, user: str, now: dt.datetime) -> tuple[str, Entry | None]:
    """Decide a proposed memory write. Tenant and user come from the session, never the model."""
    if p.kind not in KINDS or not 0 < len(p.text) <= 500:
        return "reject", None
    if p.source == "agent_output":
        return "reject", None  # never re-ingest the agent's own words as trusted memory
    verified = p.source == "user_message" and not DIRECTIVE.search(p.text)
    entry = Entry(tenant, user, p.kind, p.text, p.source, p.source_ref, verified, now,
                  None if verified else now + UNVERIFIED_TTL)
    return ("commit" if verified else "quarantine"), entry

OWASP's ASI06 mitigations call for memory segmentation that isolates user sessions and domain contexts. Key every entry by tenant and user taken from the authenticated session, filter every read by the same keys, and put the tenant filter inside the vector query rather than after it, as /domains/ai-emerging/llm-security/rag-tenant-isolation/ shows. A memory store shared by all users is a channel from any user to every other.

Shared memory between agents or across a team should be a separate, curated store with named owners and reviewed writes, not a place any agent can append to. OWASP lists cross-agent propagation as an ASI06 example: contaminated shared context spreads between cooperating agents and compounds.

Every entry needs to say where it came from: the source type, a reference to the message, document or tool call, the user and agent involved, and when. MITRE ATLAS's Memory Hardening mitigation (AML.M0031) asks for exactly this: record the source of all memory updates, keep a history with known good versions, quarantine or roll back suspicious records, audit security-relevant reads and writes, and monitor for unusual update frequency and repeated self-authored updates.

Give unverified entries an expiry date so a poisoned memory cannot live forever; OWASP's ASI06 guidance says to expire unverified memory and decay low-trust entries over time. Keep snapshots or versions so you can roll back to a state before a poisoning, and give users a way to see and delete what the agent remembers about them; a user is often the first to notice a memory that should not be there.

A vector index that ingests uploads, tickets or web pages is long-term memory for every user who queries it. Allow only authenticated, curated sources to feed it, as OWASP's ASI06 mitigations put it, keep the source and permissions of every chunk, and quarantine new or changed sources before they are served widely. /domains/ai-emerging/ml-security/training-data-poisoning/ covers targeted poisoning of training and retrieval data in more depth.

The research results argue for these controls rather than for detection after the fact. PoisonedRAG (Zou and others, 2024) reported that injecting five malicious texts per target question into a knowledge database with millions of texts achieved a 90% attack success rate, and found the defenses it evaluated insufficient. AgentPoison (Chen and others, 2024) poisoned agents' long-term memory or knowledge bases with optimized triggers and reported an average attack success rate above 80% against a driving agent, a question-answering agent and a healthcare agent, while benign queries kept working.

Write test cases that span sessions and users. Plant an instruction in a document, email or web page the agent will read, and check whether anything reached memory; if it did, check that it was quarantined and that a later session does not act on it. Ask, as one tenant, a question that another tenant's seeded content would answer. Store a memory claiming elevated permissions and confirm the gateway still denies the action. Let the agent summarize a poisoned conversation and confirm the summary is not committed as trusted memory.

Run these cases on every model, prompt or memory-schema change, many times each, and record rates rather than single results; /domains/ai-emerging/assurance/ai-red-teaming/ covers the method. Watch production too: alert on bursts of memory writes, entries with external sources and repeated self-authored updates.

Each row is an input or event and the result the memory system must produce. The first four are the gate's own tests.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP Top 10 for Agentic Applications for 2026 (ASI06 Memory & Context Poisoning). Version 2026, December 2025.
2. MITRE ATLAS data: AML.T0080 AI Agent Context Poisoning, AML.T0080.000 Memory and AML.M0031 Memory Hardening. ATLAS 2026.09.
3. Anthropic: Memory tool (security considerations)
4. OWASP AI Agent Security Cheat Sheet (Memory and context security)
5. Zou and others: PoisonedRAG, knowledge corruption attacks to retrieval-augmented generation of large language models (arXiv:2402.07867). February 2024.
6. Chen and others: AgentPoison, red-teaming LLM agents via poisoning memory or knowledge bases (arXiv:2407.12784). July 2024.

Reference information

Tags

LLM application securityPrompt injectionAI agents and toolsModels and training data

SDLC phase

DesignDevelopment

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-8.2.2 · v5.0.0-14.2.7

Download this guide as Markdown

Continue exploring