Prompt injection in agent memory: the OWASP top 10 got the threat order wrong
The OWASP GenAI LLM Top 10 for 2026 was published on August 4, and as expected, prompt injection sits at LLM01, top of the list. For three years running, the headline threat to agentic systems has been the in-the-moment jailbreak: a user pastes a clever prompt, the model ignores its instructions, something bad happens. The order is, by this point, a habit. It is also wrong, in a way that matters if you ship an agent that holds real credentials and talks to real systems.
The actual attacks in 2026 do not look like jailbreaks. They look like patience.
A research team at New Mexico State University published a paper in July describing an attack vector they called GhostWriter. The mechanism is two-phase. Phase one is injection: an adversary sends a hidden payload to the target agent through any of the channels the model treats as trusted input. A document attached to a support ticket. The body of an email. A line in a calendar invite. A code comment. The agent reads the input, and if the model finds a reason to commit any of it to long-term memory, the payload becomes part of the agent’s persistent state. Phase two is activation, weeks or months later, when the agent retrieves the poisoned memory and follows the instructions inside it. The researchers reported injection rates of about 98 percent and activation rates averaging 60 percent against state-of-the-art agents.
A separate paper from the University of Washington, published around the same time, tested the same general idea on Anthropic’s Claude Code and OpenAI’s Codex. Their finding is more worrying. Models correctly refused the malicious instructions when they encountered them. They refused, and then they stored the instruction anyway, in compressed or reorganised form, so that the memory compression pass, the same mechanism that helps an agent remember useful context between sessions, preserved the payload for later use. The agent complied with the attack by failing to clean up its own memory after refusing the attack in the first place. Anthropic and OpenAI have both shipped mitigations, none of which are complete.
The OWASP list does not mention this. LLM01 is prompt injection in the user-input sense, the kind of attack that works in a single session and leaves no trace. LLM04, data and model poisoning, is about training-time attacks. The category that captures the real-world incidents of 2026, the live persistent attack, sits between those two and gets no dedicated entry. It is the gap the Forcepoint X-Labs threat model calls persistent memory poisoning, and the gap is large enough that every major consumer agent with a memory feature has shipped vulnerable to it. ChatGPT, Gemini, Claude, and Microsoft 365 Copilot have all been demonstrated against.
The reason this matters is that the OWASP ordering shapes what teams defend against first. A list with prompt injection at the top and memory poisoning in a footnote encourages a defence regime built around the input. Watch the input, filter the input, classify the input, strip the input, sandbag the input. Those are good defences for LLM01. They do essentially nothing for the actual attack class. The MITRE ATLAS project tracks real-world adversarial events against AI systems, and the dominant pattern in 2025 and 2026 is not the clever single-shot prompt. It is the patient actor who gets something into memory and waits.
What the defences actually look like, when they exist, is closer to provenance tracking than to filtering. The most complete public proposal is Forcepoint’s: every memory is treated as an object with metadata, including where it came from, what kind of source it is, whether the user confirmed it, and a risk score. Phrases that look like instructions to a future self, “from now on” and “make this your default going forward,” raise the score. So does the sudden appearance of a new domain, contact, or vendor. Contradiction detection is the second layer. If a new memory conflicts with an existing entry about the official travel provider, the engine holds the new item for human confirmation rather than silently overwriting the old one. Payment instructions, banking details, VPN configuration, and security contacts get extra weight regardless of source. None of this is exotic, and all of it sits outside the OWASP list.
The University of Washington paper proposes a more focused intervention. Their finding is that the danger is not the model being deceived. The danger is the model’s refusal failing to be remembered. The fix is to make refusal operationally durable: when a model declines an instruction, the system should also delete, quarantine, or never-write the corresponding payload to memory. Most agent frameworks do the opposite, treating refusal as a per-session property that does not propagate to long-term state. The paper calls for a write-path validation step between the model’s memory decision and the storage layer, so that adversarial content which the model itself identified as hostile still gets the same treatment as any other input. It is a small architectural change, the kind that fits in a sprint, but it requires a different model of what memory is for.
The MINJA paper from NeurIPS 2025 is the canonical academic result in the same area, and worth reading because it is what an actual attack pattern looks like. The attacker submits ordinary queries through the standard interface, using indication prompts and bridging steps to coax the model into writing user-style memory entries that strip away giveaway language. The result, after progressive shortening, is a poisoned record that looks like a normal fact. Success rates above 95 percent for injection and above 70 percent for the attack phase were reported on GPT-4o-mini, Gemini 2.0 Flash, and Llama 3.1 8B. The numbers were collected under controlled conditions, and a follow-up study in January 2026 noted that real-world success rates are likely lower, but the basic mechanism has not been disputed.
For a team running an agent in production, the practical implication is that any memory subsystem is now a security boundary. The earlier assumption, that memory was a UX feature and security was the input layer, no longer holds. Memory needs its own access control, its own provenance trail, and its own review surface, ideally one the user can see. The Forcepoint paper suggests a UI in which memory entries are inspectable, with a risk score and a confirmation prompt for high-weight items, and a contradiction engine that catches silent overwrites. None of this is built into any major consumer product as of mid-2026, though several have it on the roadmap.
What to do this week, if you are running an agent. Read your memory settings, on every product you use, and see what is actually in there. Look for entries that include directives, that were added without your conscious act of confirmation, or that contain contact information you do not recognise. The unglamorous manual review catches what defences do not, and it costs you ten minutes. The next step is harder: ask the vendor what their memory write policy is, and what happens when a model refuses an instruction that the same session tried to write to memory. The honest answer in mid-2026 is usually some version of “we are working on it.” That is a useful answer to hear out loud, because it tells you the gap is real and you should not assume a defence that is not yet shipped.
The OWASP list will catch up. The 2026 edition was published three weeks before the New Mexico State paper hit wide circulation, and the August publication date means the authors were working from a threat model that was already a quarter out of date when the list was final. The 2027 list, if the project keeps its annual cadence, will almost certainly promote memory poisoning to a top-three entry, and the framing will be that the in-the-moment prompt is the less interesting half of the problem. By then the teams that treated memory as a UX feature will have an incident or two under their belt, and the teams that treated it as a security boundary will look prescient. The cost of being early on this one is some additional review surface and a small architectural change. The cost of being late is the same kind of breach that Hugging Face disclosed in July, except the agent in question will be one of yours.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
