OWASP ASI06: Memory and Context Poisoning Explained

June 12, 2026

OWASP ASI06 is the classification for Memory and Context Poisoning in the OWASP Top 10 for Agentic Applications. It names the attack class where adversarial content is written into an AI agent's persistent memory — RAG stores, vector databases, conversation history, shared context — so the agent acts on the poisoned content in future sessions. Unlike LLM01 (Prompt Injection), which resets when the session ends, ASI06 attacks persist across sessions and execute days or weeks after the initial write.

OWASP added ASI06 to its 2026 Agentic AI Top 10 because the persistent-state attack surface that agentic systems introduce doesn't exist in the LLM Top 10's threat model. Standard prompt injection controls don't catch ASI06 attacks. Across academic studies, attack success rates of 80% to over 99% have been reported against LLM-based agent implementations.

This article explains what ASI06 is, where it fits in the Agentic AI Top 10, the three attack vectors it names, how it differs from LLM01, the control set it prescribes, and how to evaluate vendors against it. If you've encountered ASI06 in a security review or procurement checklist and need the standards-aligned explainer, this is it.

What Is OWASP ASI06?

ASI06 is the sixth entry in the OWASP Top 10 for Agentic Applications, formally titled Memory and Context Poisoning. The classification was added in 2026 to recognize that agentic AI systems — agents that persist memory across sessions and reason from accumulated context — have a new attack surface that doesn't exist in pure-LLM applications.

The OWASP definition centers on three structural properties of memory poisoning:

Persistence — the attack writes content into memory that survives across sessions, agent restarts, and even redeployments if the underlying store isn't wiped
Temporal decoupling — the time the attack is planted and the time its effect manifests are decoupled. An attacker writes today; the agent acts on the poisoned content weeks later, triggered by an unrelated interaction
Privileged-input vector — anything that writes into the agent's memory becomes a privileged input. An attacker who can plant text into memory can override the agent's instructions, exfiltrate user data, or hijack future tool calls

The OWASP Gen AI Security Project's "Memory Is a Feature. It Is Also an Attack Surface" blog post (May 13, 2026) frames the classification motivation directly: "Agentic systems do not just respond in the moment. They retain context, reuse memory, and rely on persistent state to guide future reasoning and actions. That is what makes them useful. It is also what makes them vulnerable."

This is why ASI06 exists as a separate classification from LLM01. The control sets are different. The detection methods are different. The recovery processes are different.

Where ASI06 Fits in the OWASP Agentic AI Top 10

The OWASP Agentic AI Top 10 catalogs the highest-priority security risks specific to agentic AI systems. ASI06 sits in the middle of the list and addresses the memory layer specifically.

For context, the broader Top 10 covers (paraphrased — refer to OWASP for canonical wording):

ASI01–05: earlier entries covering goal hijacking, identity manipulation, tool misuse, etc.
ASI06: Memory and Context Poisoning ← this article
ASI07–10: subsequent entries covering downstream risks and operational concerns

ASI06's positioning matters because it's structurally distinct from the prompt-injection / instruction-override threats covered higher in the list. ASI06 is about what your agent reads from memory and acts on, not about what it's told in a single prompt.

The standard interaction pattern: agents combine LLM01 controls (LLM Top 10) with ASI06 controls (Agentic AI Top 10). Coverage of one doesn't imply coverage of the other.

The Three ASI06 Attack Vectors

OWASP's ASI06 documentation names three primary attack vectors. Understanding all three is what separates a credible defense story from a partial one.

Vector 1: Untrusted Pipeline Writes

Malicious or seeded entries enter the vector store via untrusted ingestion pipelines. An attacker submits content through whatever channel writes to the agent's memory — a chat session, a document upload, a connected data source, a tool output that gets summarized into memory.

The defense pattern: write-time screening. Every retain operation gets policy-evaluated before the content lands in storage. This is the layer that catches credential leakage, prompt-injection seeding payloads, oversized blobs, encoded-payload smuggling, and integrity tampering attempts.

Vector 2: Reused or Shared Session Context Spreads Injection Across Users

In multi-tenant or multi-user agent systems, session context that crosses user boundaries can spread an injection across users. An attacker poisons a memory at one scope; cross-scope promotion (without proper consolidation) leaks the poison to other users' contexts.

The defense pattern: scope isolation. Multi-scope memory architectures (user_id, agent_id, session_id, org_id) limit blast radius. Cross-scope promotion requires explicit consolidation logic that vets evidence across many observations before any user-scoped belief promotes to an org-scoped one.

Vector 3: Crafted Content Summarized into Memory Contaminates Future Decisions

The MINJA-style attack. An attacker submits content crafted to be summarized by the agent itself into memory — the agent does the writing on the attacker's behalf, via the auto-extraction pipeline that turns conversation traces into persistent observations.

The defense pattern: prompt-injection detection at the write path. Detect instruction-override and jailbreak markers as the agent tries to land them in memory, rather than relying entirely on downstream consolidation to challenge them later. Plus consolidation-layer contradiction reconciliation as the second line of defense.

All three vectors are real and documented. The academic literature (MINJA, AgentPoison, Sleeper Memory) demonstrates 80% to over 99% success rates against LLM-based agent implementations. The Agent Security Bench reports a highest average attack success rate of 84.30% across 27 attack and defense methods, with limited effectiveness shown in current defenses.

ASI06 vs LLM01: The Structural Distinction

The most common confusion in security review discussions. OWASP classifies the two attacks separately because the defense controls are different.

Dimension	LLM01 (Prompt Injection)	ASI06 (Memory and Context Poisoning)
Standards location	OWASP LLM Top 10	OWASP Agentic AI Top 10
Persistence	Session-scoped	Persistent across sessions
Attack/effect timing	Immediate (same session)	Temporally decoupled (write today, effect later)
Required infrastructure	Any LLM with prompt input	Agent with persistent memory layer
Detection difficulty	Session-bounded log analysis	Cross-session correlation needed
Defense surface	Model input/output	Memory layer (read + write paths)
Recovery	End the session	Audit, purge, rollback to snapshot
Attack volume	Higher	Lower volume, higher impact per success

A subtle and important point: ASI06 attacks often use LLM01 as the seed. The MINJA family of attacks demonstrates that an attacker can use query-only prompt-injection interactions to plant content that ends up in memory via the agent's normal auto-extraction. Defending one without the other leaves the chain intact.

For a deeper treatment of the comparison and the defense implications, see memory poisoning vs prompt injection.

The ASI06 Control Set

OWASP's ASI06 documentation prescribes a defense-in-depth control set. The Agent Security Bench finding — 84.30% highest average attack success against current defenses, with limited effectiveness shown by single-layer controls — is the empirical argument for layering rather than picking one control.

The five recommended control layers:

1. Input Moderation with Trust Scoring

Screen the write path. Every retain operation passes through a policy that evaluates the content against detectors for prompt injection markers, credential and PII leakage, protected-key modifications, size anomalies, and encoded-payload smuggling.

User input must never modify core behavioral rules. User-provided input should be blocked from direct write access to long-term memory; instead, an extraction pipeline with sanitization should mediate.

2. Memory Sanitization with Provenance Tracking

Every stored observation gets tagged with source metadata: which agent wrote it, which session it came from, which API key submitted it, what trust class the source belongs to. This isn't a standalone defense — it's the substrate that enables trust-aware retrieval (Layer 3) and audit attribution (Layer 5) to function.

Provenance also enables redacted-identifiable fingerprints in audit events — a credential fingerprint like ghp_AAAA...BBBB preserves enough signal for incident response without re-exposing the secret.

3. Trust-Aware Retrieval

When the agent queries memory, retrieval reranks results by source trust, not just semantic relevance. High-relevance memories from low-trust sources can be down-weighted or excluded. Quarantine workflows hold suspicious memories pending review.

This is the layer that catches what Layer 1 missed — content that was stored before a policy was added, or that came through a path that bypassed write-time screening.

4. Scope Isolation and Blast Radius Limits

Multi-scope memory architecture (user_id, agent_id, session_id, org_id scopes) limits the impact when a poisoning attack succeeds. A poisoned memory at user scope doesn't automatically promote to org scope without explicit consolidation evidence.

Time-to-live (TTL) policies on memories also fall in this layer — bounded retention limits the persistence window for any poisoned entry that evades detection.

5. Behavioral Monitoring with Audit Trail

Per-decision audit events route to SIEM (Splunk, Datadog, Slack, PagerDuty). HMAC-signed webhook delivery ensures tamper-evident routing. Behavioral anomaly detection catches agents acting on inconsistent beliefs — a signal that poisoning has succeeded somewhere upstream.

Forensic snapshots and rollback capability — restoring memory to a known-good state when poisoning is identified — round out the operational recovery story.

For the full walkthrough of all five layers with concrete implementation examples, see the defense-in-depth guide.

How to Implement ASI06 Controls

Two paths exist for organizations implementing the ASI06 control set in 2026.

Path 1: OWASP Agent Memory Guard

OWASP released Agent Memory Guard as the standards-aligned reference implementation for ASI06. It's open-source runtime middleware that sits between an agent and its memory store, screening every read and write through a pipeline of detectors with a YAML policy.

Built-in detector coverage:

Prompt injection markers
Secret and PII leakage
Protected-key modifications
Size anomalies
SHA-256 cryptographic baselines for tamper detection

Four dispositions: allow, redact, quarantine, block. Plus forensic snapshots with rollback to known-good states.

The pattern is framework-agnostic — Agent Memory Guard runs alongside any memory framework. The framework feature-request issues opened across Mem0, Letta, CrewAI, agno, Vercel AI SDK, and FlowiseAI confirm rapid developer adoption. Security buyers are increasingly using Agent Memory Guard as the procurement reference.

Path 2: Memory-Layer-Native ASI06 Implementations

The alternative path: choose a memory framework that ships ASI06 controls natively. Hindsight's Memory Defense is one example — a per-bank policy with two tiers (OSS Basic with 44-pattern regex; Cloud Enterprise with the 7-stage pipeline including llm_screen and prompt_injection detection). Memory Defense covers the write path with deeper credential detection and ships HMAC-signed SIEM webhooks for audit integration.

For deployments where Hindsight is the chosen memory layer, Memory Defense provides native write-path coverage with depth Agent Memory Guard's built-in detectors don't have on the regex side. For deployments where read-path screening, cryptographic baselines, or snapshot rollback are required, Agent Memory Guard is the answer Memory Defense doesn't cover today.

Many security-conscious deployments layer both. The Agent Memory Guard vs Memory Defense comparison walks through the side-by-side and the deployment patterns for using each alone or both together.

Vendor Compliance Checklist for ASI06

A buyer's checklist for evaluating memory frameworks against ASI06. Designed to be lifted into procurement reviews:

Write-Path Controls (Layer 1):

Pre-ingestion scanning for credential patterns
LLM-based detection of credentials in conversational prose
Prompt-injection / jailbreak detection at write time
Size anomaly blocking
Encoded-payload expansion (base64 etc.)
Protected namespace enforcement on resubmits

Sanitization and Provenance (Layer 2):

Source-class metadata on every observation
API key / agent attribution per write
Redacted-identifiable fingerprints in audit events (never plaintext)

Retrieval Trust (Layer 3):

Multi-strategy retrieval with trust-aware reranking
Quarantine workflow for suspicious memories
Read-path screening (in addition to write-path)

Scope Isolation (Layer 4):

Multi-scope memory architecture (user_id, agent_id, session_id, org_id)
Scope enforcement at write time
TTL / decay policies for time-bounded memories

Audit and Monitoring (Layer 5):

Per-decision audit event schema
HMAC-signed webhook delivery
SIEM integration recipes (not "build it yourself")
Forensic snapshots + rollback capability

Standards Alignment:

Integration with OWASP Agent Memory Guard, or native implementation of equivalent controls
Documentation explicitly mapping the vendor's controls to ASI06 layers
Open-source or auditable code so defense claims can be verified

A vendor that checks 15+ of these items is ASI06-credible. Below 10, there are gaps the buyer will need to fill in independently.

Common Misconceptions

Patterns we see in security review discussions:

"LLM01 controls cover ASI06." They don't. LLM01 addresses the model's input/output behavior; ASI06 addresses the memory layer. The control surfaces are different.

"ASI06 only matters if you have an explicit memory layer." False. Even agents without named memory modules accumulate context across sessions; that accumulated context is the persistence substrate ASI06 covers. Academic work on web agents demonstrates context-manipulation attacks against agents with no formal memory bank configured.

"Vector store + retrieval is enough." Not for ASI06. A vector store is the storage layer; ASI06 controls live above it — input moderation, sanitization, trust-aware retrieval, scope isolation, behavioral monitoring. Storage technology choice doesn't substitute for the control set.

"Agent Memory Guard alone covers everything." Agent Memory Guard is the OWASP reference and covers reads, writes, integrity baselines, and rollback. It uses pattern-based detectors; depth on credential detection (especially credentials embedded in conversational prose) varies. Pair with memory-layer-native deep detection where the threat model warrants.

"ASI06 isn't a real procurement priority yet." As of mid-2026, framework feature-request issues across Mem0, Letta, CrewAI, agno, Vercel AI SDK, and FlowiseAI explicitly ask for OWASP Agent Memory Guard integration. Security buyers are referencing ASI06 in procurement reviews. The standard has moved from "newly published" to "table-stakes for memory framework evaluation" in months.

Conclusion

ASI06 is OWASP's recognition that persistent agent memory creates an attack surface the LLM Top 10's prompt-injection controls don't cover. The classification matters because it forces defense architectures to address a class of attacks that's structurally different — persistent, temporally decoupled, with blast radius proportional to memory retention.

Three things to remember:

ASI06 is about the memory layer, not the model. LLM01 covers the model's input/output. ASI06 covers persistent memory state. Both apply to any agentic system; coverage of one doesn't imply coverage of the other.
The control set is five layers, not one. Input moderation, sanitization with provenance, trust-aware retrieval, scope isolation, behavioral monitoring with audit. Single-layer defenses show limited effectiveness; layered architectures multiply the attacker's effort.
Two implementation paths exist. OWASP Agent Memory Guard is the standards-aligned reference; memory-layer-native implementations (Hindsight Memory Defense is one example) offer different depth profiles. Many security-conscious deployments layer both.

FAQ

What is OWASP ASI06? OWASP ASI06 is the sixth entry in the OWASP Top 10 for Agentic Applications (2026), titled Memory and Context Poisoning. It classifies the attack class where adversarial content is written into an AI agent's persistent memory — RAG stores, vector databases, conversation history, shared context — so the agent acts on the poisoned content in future sessions. Unlike LLM01 (Prompt Injection), ASI06 attacks persist across sessions and execute days or weeks after the initial write.

What does ASI06 stand for? ASI06 is the identifier for Memory and Context Poisoning in the OWASP Top 10 for Agentic Applications. The "ASI" prefix denotes Agentic Systems Issues; "06" places it sixth in the Top 10 priority list. The classification was added in 2026.

How is ASI06 different from LLM01? LLM01 is Prompt Injection in the OWASP LLM Top 10 — it covers the model's input/output behavior. ASI06 is Memory and Context Poisoning in the OWASP Agentic AI Top 10 — it covers the persistent memory layer. LLM01 attacks reset when the session ends; ASI06 attacks persist across sessions. The defense control sets are different.

What are the three ASI06 attack vectors? (1) Malicious entries entering the vector store via untrusted pipelines, (2) reused or shared session context spreading injection across users, and (3) crafted content getting summarized into memory and contaminating future decisions. All three are documented in academic literature with attack success rates of 80%+ against LLM-based agent implementations.

What controls does ASI06 prescribe? Five defense-in-depth layers: input moderation with trust scoring, memory sanitization with provenance tracking, trust-aware retrieval, scope isolation, and behavioral monitoring with audit trail. The Agent Security Bench reports an 84.30% highest average attack success rate against current defenses; layered controls succeed materially better than single-layer ones.

Is OWASP ASI06 a regulation? ASI06 is an OWASP classification, not a regulation. It's a community-developed standard from the OWASP Foundation that security teams and procurement reviews increasingly reference when evaluating agentic AI systems. Compliance with ASI06 controls isn't legally mandated but is becoming a practical procurement requirement for security-conscious buyers.

Where can I read OWASP's official ASI06 documentation? The OWASP Agentic AI Top 10 documentation lives at genai.owasp.org. OWASP's own blog post "Memory Is a Feature. It Is Also an Attack Surface" (May 2026) is the canonical motivation framing. The reference implementation, OWASP Agent Memory Guard, is also documented on the OWASP Foundation site.

Does ASI06 apply to my agent if I don't have a memory layer? Yes, often. Even agents without explicit memory modules accumulate context across sessions; that accumulated context can act as the persistence substrate ASI06 covers. Academic work on web agents demonstrates context-manipulation attacks against agents with no formal memory bank configured. Persistence anywhere in the architecture creates an ASI06 surface.

How do I implement ASI06 controls? Two paths: OWASP Agent Memory Guard as standards-aligned middleware (framework-agnostic, covers reads and writes with SHA-256 baselines and snapshot rollback), or a memory framework that ships ASI06 controls natively (Hindsight Memory Defense is one example, with deeper credential detection on the write path and SIEM-ready audit). Many deployments layer both.

What's the difference between ASI06 and OWASP Agent Memory Guard? ASI06 is the classification (the standard that names the attack class and prescribes the control set). OWASP Agent Memory Guard is the reference implementation (the open-source middleware that ships those controls in concrete code form). ASI06 defines what controls should exist; Agent Memory Guard is one way to implement them.