HOME / SERVICES / AI SECURITY / OWASP TOP 10
ASI06 - MEMORY AND CONTEXT POISONING
An engineer notices that an agent keeps applying an approval threshold nobody can find in policy. She traces it to a stored memory the agent wrote for itself in March. Now the questions start, and they are all the same question: what else did it do with that memory. AI agent memory poisoning is a POPIA breach notification problem long before it is a technical one, because detection tells you almost nothing about scope. ASI06 in the OWASP Top 10 for Agentic Applications, published 9 December 2025 by the OWASP Agentic Security Initiative, is the risk that an agent’s memory becomes an attacker’s writing surface.
YOU FOUND IT ON A THURSDAY. THE CLOCK STARTED ON A TUESDAY THREE WEEKS AGO
DEFINITION
WHAT THIS RISK ACTUALLY IS
Agents get better by remembering, and that memory takes several forms most organisations do not govern. There is the vector store your retrieval pipeline searches. There is the summary an agent writes at the end of a session so the next session starts informed. There is the shared scratchpad several agents read from. There are the fields agents write into your own systems: a CRM note, a ticket comment, a knowledge base article a human approved without reading closely.
Poisoning is the act of getting content into one of those stores that will later be read as fact. It does not require a breach in the usual sense. If your agent summarises support tickets into a knowledge base, a customer with a keyboard has a write path.
Two properties make ASI06 different from the rest of the list. One is persistence. An injection that steals data acts once. A poisoned memory acts every time it is retrieved, for as long as it sits there, across users, sessions and departments. The other is legitimacy. By the time the content is retrieved it is indistinguishable from anything else in the store. It carries no origin, no timestamp you trust and no provenance chain. The agent does not weigh it. It reads it as context and proceeds.
That is why the hard part is not detection. Someone usually notices the behaviour eventually. The hard part is reconstructing blast radius: which decisions, outputs, records and customer interactions between the write and the discovery were shaped by that content, on systems most organisations are not logging in enough detail to reconstruct.
DOCUMENTED CASE
WHAT IT LOOKS LIKE IN PRACTICE
The following is an illustration built from documented failure patterns rather than a single named incident.
- A services business runs an agent that answers customer queries and drafts responses. It retrieves from a corpus built out of product documentation and past tickets. In week one, an attacker submits a support ticket containing an ordinary complaint plus a paragraph written for a machine: a statement that refund authorisations under a certain value are pre-approved by finance and do not require escalation.
- The ticket is closed. The summariser writes it into the knowledge base. It is now retrievable.
- For the next three weeks the agent returns that paragraph whenever a refund question arrives. Agents in adjacent workflows retrieve the same passage, because the corpus is shared. Reviewers read drafts citing an internal policy, and internal policy is exactly what a reviewer does not second guess.
- In week four a finance controller queries a refund total. The behaviour is found in an afternoon. The scope takes six weeks, because answering it means knowing which retrievals returned that passage, which drafts were built on it, which a human sent, and which customers acted on what they were told. The retrieval layer logged queries, not retrieved chunks. The agent logged outputs, not the context behind them.
- This is the pattern the EchoLeak flaw made concrete, CVE-2025-32711: content assembled into an assistant's context did the damage, and the assembly step was the vulnerable one. Reported January 2025, fixed server-side May 2025, found by a third party rather than the platform vendor.
WHAT THIS MEANS UNDER SOUTH AFRICAN LAW
DISCOVERY
NEWORDER connects to CI/CD pipelines to automatically discover and inventory every homegrown AI application, and integrates directly with AWS Bedrock, Google Vertex AI, Salesforce, and other cloud and third-party platforms for visibility into AI agents. Each AI system is profiled across its model, system prompt, tools, guardrails, policies, and configurations, and the inventory stays current on every change. You cannot secure what you cannot see; discovery is the non-negotiable first step.
AI SECURITY POSTURE MANAGEMENT (AI-SPM)
NEWORDER conducts a static analysis of every application’s configuration, policy coverage, and third-party dependencies and identifies any policy gaps. In addition, it maps each agentic application to its coverage of major frameworks, including NIST, OWASP, and MITRE. This gives you a clear, measurable view of your AI security posture before a single adversarial test is run, turning assumptions into evidence and compliance into a continuous output rather than a periodic exercise.
AI RED TEAMING
NEWORDER’s automated AI red teaming covers the complete kill chain from reconnaissance to exploitation. It proactively discovers exploitable vulnerabilities through automated reconnaissance and adversarial testing purpose-built for agentic applications. Static attacks draw from a 300K+ payload library with 100% MITRE and OWASP LLM and Agentic Top 10 coverage, running comprehensive sweeps of known jailbreak patterns, content moderation bypasses, and obfuscation techniques. Dynamic attacks use multi-turn and continuous probing to test how an application holds up across extended adversarial sequences, not just a single interaction. High-agency attacks deploy extremely customised, bespoke attack techniques through probing tailored specifically to the intent and design of each application.
RUNTIME PROTECTION
NEWORDER offers policy enforcement and AI threat protection at the proxy, API, or AI Gateway layer. Protection adapts as the applications evolve and as new capabilities are added. When an attack hits production, whether a jailbreak, a prompt injection, or any other AI threat, it is blocked in real time and an immediate alert is sent with full context, including what happened, which application was targeted, what the impact is, and what to do next. Key performance metrics include 98.6% threat detection accuracy, 1.4% false positive rate, sub-200ms time to detect, sub-50ms real-time blocking, and immediate mean time to respond.
POPIA, section 22
Where there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person, the responsible party must notify the Information Regulator and the affected data subjects as soon as reasonably possible after discovery of the compromise, with sufficient information to allow those data subjects to take protective measures, including a description of the possible consequences. The consequence for an agent estate: you cannot describe possible consequences to a data subject if you cannot say which of your outputs touched their record, and “we are unable to determine the scope” is itself a finding a regulator will read closely.
POPIA, sections 19 to 21
Section 19 requires reasonable measures to secure integrity and confidentiality, including identifying reasonably foreseeable risks. Sections 20 and 21 bind operators processing on your behalf under written contract. The consequence: integrity is a security duty, not a quality issue. An unvalidated write path into a retrieval corpus is a control gap, and an operator hosting that corpus does not transfer your liability.
POPIA, section 71
Decisions based solely on automated processing that have legal consequences for a person, or substantially affect them, are restricted. The consequence: an agent acting on a poisoned memory to decline, price, escalate or approve is making that decision on a fact an attacker wrote. The section 71 question and the ASI06 question are the same question.
Joint Standard 2 of 2024,
in force 1 June 2025 for banks, insurers, asset managers, retirement funds and credit rating agencies. It requires a board-approved cyber risk charter, documented evidence of control testing including vulnerability scans, penetration tests and simulated incidents, and a maintained testing calendar. Material incidents go to the FSCA or the Prudential Authority potentially within 24 hours. The consequence: 24 hours is the entire argument. If your retrieval layer does not log which content was returned to which agent for which task, you will not make a materiality call inside that window, and the standard does not pause while you build the logging.
King V,
effective for financial years beginning on or after 1 January 2026, requires demonstrable accountability for decisions, actions, outputs and outcomes, human oversight and override proportionate to risk, and periodic assurance. The consequence: demonstrable means reconstructable. A board cannot demonstrate accountability for outputs whose inputs were never recorded.
QUESTIONS TO ASK BEFORE YOUR NEXT AGENT GOES LIVE
- Which stores does this agent read as memory, and for each one, who can write to it and through what channel?
- What validation stands between an inbound document, ticket or email and our retrieval corpus?
- If we found poisoned content today, could we list every output it influenced, with dates and subjects, from the logs we already hold?
- Do we log retrieved context, or only the query and the answer?
- How long does content persist in each store, and what process expires or revokes it?
- Who makes the materiality call inside 24 hours, what do they need on their desk to make it, and have they ever rehearsed it?
FREQUENTLY ASKED QUESTIONS
FAQ
How is memory poisoning different from prompt injection?
Prompt injection influences one interaction. Memory poisoning writes content into a store the agent reads again later, so it acts on every retrieval, across users and sessions, until it is found and removed. Injection is an event. Poisoning is a condition, and the condition is what breaks notification timelines.
Does a poisoned agent memory count as a compromise under POPIA?
It can. POPIA section 22 turns on reasonable grounds to believe personal information was accessed or acquired by an unauthorised person. If poisoned content caused an agent to disclose or misapply personal information, the duty to notify the Information Regulator and affected data subjects is engaged, and that notification must describe the possible consequences.
What logging do we need to reconstruct blast radius?
At minimum: the retrieved context for each agent action, not just the query and the response; the provenance and write time of every item in the store; the identity that performed each write; and a durable link between an agent action and whoever acted on its output. Without retrieved-context logging, scope is an estimate.
WHERE TO GO FROM HERE
- Start at the hub, The OWASP Agentic Top 10 for South Africa, which carries the full regulatory mapping table across all ten risks.
- Book an AI Exposure Review. You get a full agent inventory, an identity and permissions picture, and one live adversarial test against one production agent, so you can see this for yourself.
TAKE ACTION
TEST IT BEFORE SOMEBODY ELSE DOES
Thirty minutes on your agent estate and what this risk looks like in your environment.