Memory poisoning and Prompt Injection both sound like "feeding an agent something wrong to make it misbehave" — what's actually different?
The difference is timing and persistence. Prompt injection is a single event — the malicious content and its effect happen almost simultaneously within one interaction. Block it in the moment, and the attack is over. Memory poisoning splits into two separate moments: the plant and the trigger, which can be days or weeks apart, and the Trigger Condition may look completely unrelated to the planted content on its surface. That means even if you defend against prompt injection at every single interaction, an agent can still act on a poisoned judgment weeks later, rooted in an interaction that looked entirely harmless at the time — the defensive time window is fundamentally different.
Why did OWASP specifically break out memory poisoning as its own category (ASI06) instead of just folding it into existing Prompt Injection (LLM01)?
Because the two require fundamentally different defense logic, and merging them would dilute the defenses that actually matter for each. Prompt Injection Defense focuses on the input layer — filtering and validating every piece of content entering an agent. Memory poisoning's core problem sits at the storage layer and the cross-session access layer instead: even if every single input is perfectly filtered, if the agent's memory store itself lacks write-access controls, provenance tagging, or periodic cleanup, poisoning can still accumulate gradually through interactions that each looked completely legitimate. The point of a separate category is to signal to developers that this needs defenses designed at the memory architecture level — it's not something stronger input filtering alone can solve.
The high attack success rates cited in research like AgentPoison or MINJA — under what specific conditions were those numbers measured? Can they be applied directly to whatever DeFAI agent I'm using?
Those numbers come from controlled academic experimental settings: researchers target a specific agent architecture and a specific memory storage mechanism (a particular vector database retrieval design, for instance), craft specific poisoning samples, then measure what poisoning rate causes the agent to take a specific incorrect action under a specific Trigger Condition. AgentPoison measured over 80% success at under 0.1% poisoning; MINJA measured 76.8% to over 98%. Both are upper-bound figures measured under the specific scenarios each paper set up — not universal numbers that apply to every agent architecture. In practice, you can't assume the DeFAI agent you're using has the same degree of vulnerability. What these numbers do demonstrate is that this attack surface can be highly effective under specific conditions — not that it's equally easy to exploit on every system. Those are two different conclusions.
If I'm using a DeFAI agent with memory features, what can I actually do right now to reduce risk, rather than just waiting for the industry to ship defense standards?
A few practical things you can do yourself: first, check whether your agent offers a way to view or clear what it has stored in memory, and periodically review whether anything unfamiliar — content you never personally input — has shown up there. Second, for critical instructions involving fund operations, push the agent to show the raw source material behind a decision rather than accepting a summary-only conclusion. Third, if the agent supports separate memory spaces or session isolation, use an isolated mode for fund-related tasks rather than letting casual conversation and financial operations share the same memory store. Fourth, treat documents or links from unclear sources with the same level of caution you'd apply against Prompt Injection before letting the agent read them — that kind of content is the most common planting channel for memory poisoning.
A growing number of DeFAI agents now retain some form of long-term memory across conversations and tasks — remembering your preferences, past strategies executed, or information looked up previously. That capability makes an agent more useful, but it also opens an attack surface that single-turn AI systems didn't really have to worry about. OWASP formally classified this risk as ASI06 — Memory and Context Poisoning — in its 2026 Top 10 for Agentic Applications.
Prompt injection attacks typically play out within a single interaction: malicious instructions hidden in user input or in external content an agent reads try to hijack behavior immediately. Memory poisoning works on a fundamentally different timeline — the key mechanism is what researchers call temporal decoupling. An attacker's single interaction just plants malicious content into an agent's memory store, a shared vector database, or a conversation summary; the actual attack payoff may not detonate until days or weeks later, triggered by a completely unrelated event. That makes memory poisoning much harder to catch in real time than prompt injection — at the moment of poisoning, the system may show no abnormal behavior at all.
The attack pattern documented in the research literature centers on getting an agent to voluntarily write attacker-crafted content into its own long-term memory during otherwise normal operation — via a document that looks legitimate, an innocuous-seeming tool response, or a poisoned conversation summary. Later, when a specific condition is triggered (a user asking about a particular keyword, or the agent performing a particular category of task), the planted memory is retrieved and shapes the agent's subsequent judgment or actions — and neither the user nor the agent itself may have any awareness that the root cause traces back to an interaction days earlier. The AgentPoison research found attack success rates above 80% at a poisoning rate under 0.1% of stored memories; a separate MINJA study recorded success rates ranging from 76.8% to over 98%, depending on the attack scenario.
Security researcher Johann Rehberger publicly demonstrated a real case in September 2024 (commonly referred to as SpAIware) targeting ChatGPT's memory feature: a Google Drive document embedded with malicious instructions induced ChatGPT to write the attacker's instructions into its own long-term memory, which was later retrieved and shaped output in an entirely different, unrelated conversation. That demonstration wasn't aimed at a DeFAI agent specifically, but it proves memory poisoning isn't purely theoretical — any AI system with persistent cross-session memory is, in principle, exposed to the same category of problem, and a DeFAI agent using a similar memory architecture carries the same exposure.
If the DeFAI agent you're using retains preferences or past strategy decisions across conversations, that means it holds a continuously accumulating knowledge base that could be poisoned — and the poisoning source doesn't have to be your own input. It could be an external document the agent reads, data shared by another user, or anything that enters the agent's memory-writing pipeline. Defenses currently being discussed in the field include cross-agent isolation (avoiding multiple agents sharing one easily-poisoned memory store), trust scoring and provenance tagging for content written into memory, defaulting memory to ephemeral rather than persistent unless explicitly needed, and requiring agents to surface raw supporting evidence for critical actions rather than agent-authored summaries alone. Most of these defenses are still in early development and are not yet standard in deployed DeFAI products.