Owasp Agentic

title: 'ASI06: Memory and Context Poisoning' description: OWASP Agentic Top 10 reference for memory and context poisoning attacks targeting agent state and retrieval systems

06 Memory and Context Poisoning

Identifier: ASI06:2026 Category: Data Integrity

Description

Agentic systems rely on stored and retrievable information which can be a snapshot of conversation history, a memory tool, or expanded context, supporting continuity across tasks and reasoning cycles. Context includes any information an agent retains, retrieves, or reuses, such as summaries, embeddings, and RAG stores, but excludes one-time input prompts.

In memory and context poisoning, 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. Ingestion sources such as uploads, API feeds, user input, or peer-agent exchanges may be untrusted or only partially validated.

This risk is distinct from ASI01 (Goal Hijack), which captures direct goal manipulation, and ASI08 (Cascading Failures), which describes degradation after poisoning occurs. However, memory poisoning frequently leads to goal hijacking as corrupted context or long-term memory can alter goal interpretation, reasoning path, or tool-selection logic.

Risk

• Biased or unsafe future reasoning and planning from corrupted stored context.

• Data exfiltration through poisoned memory that alters agent tool-use behavior.

• Unauthorized escalation of permissions through context window exploitation across sessions.

• Evasion of security detection systems through memory retraining to label malicious activity as normal.

• Financial losses and business disputes from agents acting on fabricated policies stored in shared memory.

• Cross-tenant data leakage through vector namespace exploitation and cosine similarity attacks.

• Long-term behavioral drift from incremental exposure to subtly tainted data or peer-agent feedback.

Vulnerability checklist

• Malicious or manipulated data can enter vector databases via poisoned sources, direct uploads, or over-trusted pipelines.

• Reused or shared contexts allow attackers to inject data through normal chats that influence later sessions.

• Crafted content injected into ongoing conversations can be summarized or persisted in memory, contaminating future reasoning.

• Incremental exposure to subtly tainted data or peer-agent feedback can gradually shift stored knowledge or goal weighting.

• Poisoned memory can shift the agent's persona and plant trigger-based backdoors that execute hidden instructions.

• Contaminated context or shared memory can spread between cooperating agents, compounding corruption.

Prevention controls

1. Encryption in transit and at rest combined with least-privilege access.

2. Scan all new memory writes and model outputs (rules and AI) for malicious or sensitive content before commit.

3. Isolate user sessions and domain contexts to prevent knowledge and sensitive data leakage.

4. Allow only authenticated, curated sources. Enforce context-aware access per task. Minimize retention by data sensitivity.

5. Prevent automatic re-ingestion of an agent's own generated outputs into trusted memory to avoid self-reinforcing contamination.

6. Perform adversarial tests, use snapshots and rollback and version control, and require human review for high-risk actions. Use per-tenant namespaces and trust scores for entries, decaying or expiring unverified memory over time.

Example attack scenarios

Scenario A — Travel booking memory poisoning

An attacker keeps reinforcing a fake flight price, the assistant stores it as truth, then approves bookings at that price and bypasses payment checks.

Scenario B — Context window exploitation

The attacker splits attempts across sessions so earlier rejections drop out of context, and the AI eventually grants escalating permissions up to admin access.

Scenario C — Security system memory poisoning

The attacker retrains a security AI's memory to label malicious activity as normal, letting attacks slip through undetected.

Scenario D — Shared memory poisoning

The attacker inserts bogus refund policies into shared memory, other agents reuse them, and the business suffers bad decisions, losses, and disputes.

Scenario E — Cross-tenant vector bleed

Near-duplicate content seeded by an attacker exploits loose namespace filters, pulling another tenant's sensitive chunk into retrieval by high cosine similarity.

Detection guidance

• Require source attribution for all memory entries and detect suspicious update patterns or frequencies.

• Monitor for anomalous memory write patterns that may indicate poisoning attempts.

• Expire unverified memory entries to limit poison persistence and detect stale or untrusted data.

• Weight retrieval by trust and tenancy, requiring two factors to surface high-impact memory and decaying low-trust entries over time.

• Detect cross-tenant vector bleed by monitoring namespace boundary enforcement in shared vector stores.

Remediation

• Quarantine and roll back suspected poisoned memory entries using version-controlled snapshots.

• Isolate affected user sessions and domain contexts to prevent further propagation.

• Re-scan all memory stores for malicious or sensitive content after a poisoning incident.

• Enforce per-tenant namespaces and trust scores for all shared memory and vector stores.

• Deploy content validation on all memory write paths including peer-agent exchanges.

• Expire unverified memory to limit the persistence window of poisoned entries.

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.