OWASP ASI06 Memory and Context Poisoning: Controls Guide

An agent that remembers can be taught the wrong thing once and act on it for months. OWASP lists this as ASI06 Memory & Context Poisoning in the OWASP Top 10 for Agentic Applications for 2026: attackers corrupt or seed the conversation history, summaries, embeddings and retrieval stores an agent relies on, so that later reasoning, planning and tool use are biased, unsafe or exfiltrating. This guide goes deeper than the OWASP Top 10 for Agentic Applications Guide: what the entry covers, how to design memory with write controls, provenance, segmentation and rollback, and how to detect and measure poisoning. It is written for engineers who build agent memory and RAG pipelines, and for security teams who assess them. It is defensive throughout and contains no attack payloads.

Key takeaways

Persistence is what makes ASI06 different. A prompt injection lasts one session; a poisoned memory or retrieval entry is reused in every session that retrieves it, by every user and agent that shares the store.
Memory writes are privileged operations. Treat every write to long-term memory or a shared knowledge base like a write to a configuration database: authenticated, validated, attributed and reversible.
Small amounts of poison are enough. Published research reports high attack success with a tiny fraction of poisoned entries, so volume-based anomaly detection alone will not catch it.
Segment by user, session, tenant and domain. Shared writable memory across trust boundaries turns one user's poisoning into everyone's problem, and loose namespace filters leak data across tenants.
Plan for recovery, not only prevention. OWASP asks for snapshots, version control and expiry of unverified memory so poisoned state can be found and rolled back.

What it is and who it applies to

OWASP defines the risk around the stored context agents depend on: conversation history, summaries, long-term memory, embeddings and retrieval-augmented generation (RAG) stores. The entry is separate from ASI01 Agent Goal Hijack and ASI08 Cascading Failures, although OWASP notes that poisoning frequently leads to goal hijacking. Appendix A maps ASI06 to LLM01 Prompt Injection, LLM04 Data and Model Poisoning and LLM08 Vector and Embedding Weaknesses in the OWASP Top 10 for LLM Applications 2025, to threats T1 Memory Poisoning, T4 Memory Overload, T6 and T12 Shared Memory Poisoning in the Agentic AI Threats and Mitigations taxonomy, and to the AIVSS factors for memory use and contextual awareness.

It applies to any agent that carries information forward:

Assistant memory features: saved facts and preferences that persist across a user's chats.
Agent long-term memory stores: vector or key-value stores where agents write observations, summaries and learned procedures.
RAG knowledge bases: document indexes built from wikis, tickets, CRM records, email and web content.
Shared memory in multi-agent systems: blackboards, shared scratchpads and policy stores that several agents read and write.
Business records agents read as context: a CRM lead, a support ticket or a form submission becomes memory the moment an agent retrieves it.

OWASP's six common examples are RAG and embedding poisoning, shared user context poisoning, context-window manipulation where injected content is summarised into persistent memory, long-term memory drift from gradual exposure, systemic misalignment and backdoors through trigger-based hidden instructions, and cross-agent propagation through shared memory. See the AI Agent Memory Poisoning Guide for the wider topic.

Structure and key requirements

The OWASP entry pairs six example scenarios with nine prevention guidelines. The table links each scenario to the memory layer it attacks and the control that breaks it.

OWASP scenario (paraphrased)	Layer attacked	Control that breaks it
Repeated false assertions (a fake flight price) are stored as truth and used to approve bookings	Long-term memory written from conversation	Facts that drive transactions come from authoritative systems, not memory; memory writes need validation
Attempts are split across sessions so earlier refusals fall out of context, eventually gaining admin access	Session context and summaries	Authorisation enforced outside the model on every request; cross-session risk signals tracked per identity
A security agent's memory is trained to label malicious activity as normal	Learned baselines and procedures	Human review of changes to detection memory; snapshots and drift comparison
Bogus refund policies inserted into shared memory are reused by other agents	Shared multi-agent memory	Policy content only from curated, authenticated sources; no shared writable memory across trust boundaries
Near-duplicate content exploits loose namespace filters to pull another tenant's data into retrieval	Vector store partitioning	Per-tenant namespaces or indexes enforced server-side, not by similarity filters
Indirect prompt injection implants instructions in a user's assistant memory, affecting future sessions	Assistant memory feature	Explicit user confirmation before persisting memory; no memory writes while untrusted content is in context

OWASP's nine prevention guidelines, grouped:

Protect the store: encryption in transit and at rest, and least-privilege access to memory.
Scan writes: check every memory write and model output for malicious or sensitive content before it is committed.
Segment: separate memory by user, session and domain.
Curate sources: accept only authenticated, curated sources, and minimise retention by sensitivity.
Attribute and watch: require source attribution for memory and detect suspicious update patterns.
Stop self-reinforcement: do not automatically re-ingest an agent's own outputs as trusted memory.
Test and recover: adversarial testing, snapshots and version control for rollback, per-tenant namespaces, and human review for high-risk actions.
Expire: unverified memory expires so poison cannot persist indefinitely.
Raise the bar for high-impact memory: require two signals, such as a provenance score plus human verification, before high-impact memory is surfaced, and decay low-trust entries over time.

What the research shows

AgentPoison (2024): a backdoor planted in an agent's long-term memory or RAG knowledge base reached an average attack success rate above 80% across three agents, with a poison rate below 0.1% and under 1% effect on normal tasks, and needed no model training.
PoisonedRAG (2024): five crafted texts per target question, inserted into a knowledge base of millions, achieved about 90% attack success; the defences the authors evaluated were insufficient.
Gemini long-term memory (Embrace The Red, February 2025): hidden instructions in an uploaded document caused false memories to be saved when the user later replied with an ordinary word, a technique known as delayed tool invocation. The planted values persisted across sessions. Google assessed it as low likelihood and low impact; the product shows an indicator when memory is written and lets users review saved information.

The practical conclusion: poisoning is cheap, quiet and durable. Controls must focus on who can write, what gets written, and how fast you can find and remove it.

Designing memory controls

The table compares memory designs by poisoning exposure. It is NHI Mgmt Group's summary to support design decisions.

Memory design	Poisoning exposure	When to use	Required controls
No persistent memory (session only)	Lowest; poison dies with the session	High-risk agents with write access to money, production or identity	Session isolation, state wiped between tasks
Per-user memory, user-confirmed writes	One user, mainly from injected content they read	Personal assistants	Confirmation before persist, review and delete interface, expiry
Per-agent memory written automatically	Anything the agent reads can become memory	Only with provenance tagging and write filtering	Write scanning, trust levels, no re-ingestion of own output, snapshots
Curated knowledge base (RAG) with an ingestion pipeline	Depends on source trust and ingestion checks	Policies, procedures, product documentation	Authenticated sources, change review, hidden-content detection, permission-aware retrieval
Shared writable multi-agent memory	Highest; one write reaches every agent	Avoid across trust boundaries	Per-domain write rights, signed entries, human approval for policy content

Provenance on every entry: record source (user, tool, document, agent), source identity, timestamp, session and trust level, and keep it with the entry so retrieval can filter or weight by trust.
Separate facts from instructions: memory should store data, not directives. Content that reads like an instruction to the agent is a strong signal for quarantine.
Authoritative data stays authoritative: prices, policies, entitlements and approvals are read from the system of record at decision time, never from memory.
Permission-aware retrieval: enforce tenant and user scoping in the store's access layer. See the Permission-Aware RAG Guide and the OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide.

Small teams should start with session-only memory or user-confirmed memory and a single curated RAG index with reviewed ingestion. Large organisations need a memory service with tenant isolation, provenance metadata, snapshotting and central logging, so each agent team does not reinvent the controls.

Identity and NHI requirements

Memory poisoning is an integrity problem, and integrity starts with knowing who wrote what.

Every writer is an identity: agents, ingestion pipelines and connectors that write to memory or a RAG index need their own non-human identities with write rights scoped to specific namespaces. A shared service account for all writers makes attribution and rollback impossible. See the OWASP NHI Top 10 NHI9 NHI Reuse Guide.
Separate read and write credentials: most agents need to read memory far more broadly than they need to write it. Issue read-only tokens by default.
Bind writes to the originating principal: record which user or upstream agent caused a write, so a poisoned entry can be traced to the session and source that produced it.
Memory can hold credentials: OWASP's ASI03 entry describes privileged data cached in memory being reused later. Scan writes for secrets and tokens and block them from persistence. See the AI Agent Memory Security Guide.
Protect memory components themselves: memory libraries are software dependencies with access to prompts and environment. The MemTensor MemoryOS supply chain attack shipped a credential stealer in a memory package that ran during memory recall; that is an ASI04 supply chain failure, but it shows the memory layer sits on a privileged path.

Implementation steps

Map every memory and context store. For each agent, list conversation stores, summaries, long-term memory, vector indexes, shared scratchpads and business records it reads, with who can write to each.
Classify by impact. Mark stores whose content can drive a high-impact action (payments, access, policy answers to customers) and apply the strictest controls there first.
Add provenance and trust levels to writes. Change the write path so every entry carries source, writer identity, session and trust level. Backfill existing entries as "unverified".
Put a filter in the write path. Scan for instruction-like content, hidden text, secrets and sensitive data before commit; quarantine rather than drop so analysts can review. Run it in log-only mode on one store for two to four weeks, tune false positives, then enforce.
Segment. Move to per-tenant and per-user namespaces enforced by the store's access control; remove shared writable memory across trust boundaries.
Block self-reinforcement and untrusted-context writes. Do not let agent outputs flow back into trusted memory automatically, and require confirmation for memory writes when untrusted content is in the current context.
Enable snapshots, expiry and rollback. Version the store, set time-to-live for unverified entries, and rehearse restoring a known-good snapshot. Rolling back the controls themselves means returning the write filter to log-only mode, not disabling provenance.
Test. Include memory poisoning, cross-session and cross-tenant retrieval cases in pre-release testing. See the AI Agent Security Testing Checklist.

Evidence and assessment

Design evidence: the store inventory, namespace and access control configuration, write path with filter and provenance fields, retention and expiry settings, and snapshot schedule.
Operational evidence: quarantine queue with review decisions, a completed rollback drill, and adversarial test results for the current release.
Log per memory operation: writer identity, originating principal, session, namespace, entry hash, trust level, filter verdict, and for retrieval the entries returned and their trust levels.
Alert on: bursts of writes from one source, writes containing instruction-like or hidden content, writes to policy or shared namespaces outside change control, retrieval returning entries from another tenant's namespace, and high-impact actions whose supporting context includes low-trust entries.

Metric	What it shows	Target
Percentage of memory and RAG entries with provenance and trust level	Ability to attribute and roll back	100% for new writes; legacy entries falling
Shared writable memory stores spanning trust boundaries	Propagation exposure	Zero
Quarantined writes reviewed within the agreed time	Filter is operated, not ignored	Above 95%
Time to identify and roll back a seeded poisoned entry in a drill	Recovery readiness	Hours, falling
Cross-tenant retrieval test failures	Segmentation strength	Zero
High-impact actions supported only by unverified memory	Decision integrity	Zero

Mapping to other frameworks

Framework	Relevant IDs	How it relates to ASI06
OWASP Top 10 for LLM Applications 2025	LLM01, LLM04, LLM08	OWASP's Appendix A mapping; LLM08 adds permission-aware vector stores, source validation and immutable retrieval logs
MITRE ATLAS techniques	AML.T0080 AI Agent Context Poisoning (AML.T0080.000 Memory, AML.T0080.001 Thread), AML.T0070 RAG Poisoning, AML.T0071 False RAG Entry Injection, AML.T0094 Delay Execution of LLM Instructions, AML.T0051.001 Indirect	Memory and thread poisoning, knowledge base poisoning and the delayed-trigger pattern used against assistant memory
MITRE ATLAS mitigations	AML.M0031 Memory Hardening, AML.M0025 Maintain AI Dataset Provenance, AML.M0024 AI Telemetry Logging, AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data, AML.M0032 Segmentation of AI Agent Components	ATLAS describes memory hardening as trust boundaries, validated memory updates, integrity checks on retrieved memories and remediation of poisoned memory
MITRE ATT&CK v20	T1565.001 Stored Data Manipulation	The closest enterprise technique: altering stored data to influence outcomes
NIST SP 800-53 Rev. 5	SI-7, SI-10, AC-3, AC-4, SC-28, SI-12, AU-10, SI-4, CM-5	Information integrity, input validation, access and flow enforcement, protection at rest, retention, non-repudiation of writes, monitoring and change restrictions
NIST CSF 2.0	PR.DS-01, PR.DS-10, DE.CM-09, DE.AE-02	Integrity of data at rest and in use, monitoring runtime data, analysing adverse events
NIST AI 100-2 E2025	Poisoning attack taxonomy	Shared terminology for data and knowledge poisoning

The NIST and ATT&CK mapping is NHI Mgmt Group's own; OWASP maps ASI06 only to LLM IDs, T-codes and AIVSS.

Common pitfalls

Treating stored business records as trusted. In SalesBleed, a lead submitted through a public web form sat in the CRM until an employee asked an agent about new leads; the agent read the record and followed hidden instructions to query and exfiltrate account data. Content from outside sources stays untrusted after it is stored.
Silent memory writes. Memory features that persist information without confirmation, or while untrusted content is in context, let a single document plant durable false facts.
Similarity filters as tenant boundaries. OWASP's cross-tenant scenario shows that near-duplicate content can defeat loose namespace filtering; isolation must be enforced by access control.
Agents learning from themselves. Re-ingesting summaries and outputs as trusted memory amplifies a single poisoned entry and makes drift hard to trace.
No way back. Without snapshots and provenance, a poisoned store can only be rebuilt from scratch, so teams tolerate known-bad content.
Memory as the source of truth for decisions. Prices, refund rules and entitlements read from memory rather than the system of record are exactly what OWASP's booking and refund scenarios exploit.

Practitioner checklist

Inventory every memory, summary, vector and shared context store and who can write to it.
Give each writer its own identity with namespace-scoped write rights; default agents to read-only.
Record provenance, writer, session and trust level on every entry.
Scan writes for instruction-like content, hidden text, secrets and sensitive data; quarantine for review.
Enforce per-tenant and per-user namespaces in the store's access layer; remove shared writable memory across trust boundaries.
Require confirmation for memory writes, and block them while untrusted content is in context.
Stop automatic re-ingestion of agent outputs into trusted memory.
Expire unverified entries, snapshot stores and rehearse rollback.
Read prices, policies and entitlements from systems of record at decision time.
Test memory poisoning and cross-tenant retrieval before every release.

OWASP Agentic Top 10 ASI06 Guide