An attacker doesn’t need to keep a foothold if your AI agent will remember their lie for them. That’s the practical shape of memory poisoning, and OWASP just shipped a reference implementation, Agent Memory Guard, to give defenders something to deploy against it. The cybersecurity industry has spent two years debating whether prompt injection is solvable in the model layer. The memory layer wasn’t waiting for an answer.

Help Net Security’s weekly roundup led with the project alongside an actively exploited Cisco SD-WAN zero-day and the June Patch Tuesday forecast. The three stories sit next to each other for a reason. One is a vendor-managed bug in a perimeter box. One is a recurring monthly cycle that defenders already know how to staff. The third is a class of failure that doesn’t show up in a CVE feed and doesn’t get patched on the second Tuesday of the month. Guess which one is going to ruin somebody’s quarter.

Memory Poisoning Breaks Cybersecurity’s Patch Reflex

Memory poisoning is OWASP’s ASI06 risk in the Agentic AI catalogue. The mechanic is simple. An agent receives untrusted text, summarizes or stores it as a “fact” in long-term memory, and then retrieves that “fact” later as authoritative context for a downstream decision. The original input is gone. The lie persists.

Compare that with a traditional intrusion. You evict the attacker, you rotate credentials, you patch the box, you move on. With memory poisoning the attacker leaves nothing behind that your EDR will hunt. The persistence sits in your vector store, your retrieval index, your conversation history, your agent’s “notes to self.” The bad instruction is now part of the agent’s working memory, and the agent treats it the same way it treats anything else you have asked it to remember.

If your incident response plan ends at “we removed the attacker’s access,” congratulations, you have just left the payload in production.

This is why a memory-layer defense matters. You can screen what goes into memory, screen what comes out, and refuse to act on writes that fail policy. That is the bet Agent Memory Guard is making, and it is a defensible one. Threat detection that lives in the prompt and response telemetry alone is going to miss this class entirely, because the malicious content arrives long after the attacker session is closed.

Your Agent’s Memory Store Is An Unowned Attack Surface

Walk into most enterprises that have shipped an agentic feature in the last twelve months and ask who owns the memory store. The answers are uncomfortable. The product team picked the vector database. The ML platform group runs it. The security team has never been briefed on it. Nobody has written a data classification policy for what an agent is allowed to remember. Nobody logs a memory write the way they would log a privileged user action. Nobody has rehearsed an incident where a “fact” in retrieval turns out to be an attacker plant.

This is the same pattern the industry watched play out with OAuth grants, browser extensions, and CI/CD runners. A new control plane shows up, it gets adopted faster than governance can catch up, and it becomes the unowned attack surface that wins the next year of incidents. The Cisco SD-WAN zero-day is bad. It is also a known shape of bad. Patch the box, restrict the management plane, watch the logs. Memory poisoning is the unknown shape. No CVE, no patch, no signature, and a half-life measured in weeks.

Defense in depth here means treating the memory store as Tier 0 data with its own access controls, audit trail, and integrity checks. Treat retrievals like privileged reads. Treat writes like privileged writes. Apply the same security hardening you would apply to any other system that can change the behavior of a downstream actor.

What To Do Before Your Agent Trusts A Lie

Here is a concrete set of moves any team running an agent with persistent memory can start this quarter, without buying anything new. The goal is to make memory poisoning observable, contained, and recoverable.

• Inventory every agent in your environment that writes to a memory store or vector index. Name an owner per agent. If nobody owns it, it goes off until somebody does.
• Separate write paths from read paths. Memory writes triggered by tool output or retrieved web content should pass through a screening layer with deny-by-default policy, not flow straight into long-term storage.
• Tag every memory entry with provenance: who wrote it, which session, which tool, which source URL. You cannot quarantine what you cannot attribute.
• Log memory reads and writes with the same fidelity you use for identity provider events. This is your forensic surface when something goes wrong, and it is where useful threat-protection signals will live.
• Put rate limits and anomaly detection on bulk memory writes. A single session writing hundreds of “facts” is one of the cheapest signals of a poisoning attempt you will ever get.
• Rotate or quarantine memory by default after sensitive operations. Long-lived memory across privilege boundaries is a self-inflicted persistence vector for any attacker who lands one foothold in one tenant.
• Write an incident response playbook for “we believe a memory entry is poisoned.” Specify how you snapshot, how you roll back the index, how you re-derive trusted state, and how you notify customers whose sessions touched the poisoned entry.

If you run internet-facing auth surfaces for the agent or its admin console, the older cyber security checklist still applies. Firewall rules tight to known ranges, brute-force controls on every login path, MFA on the admin console, and IP reputation enforcement at the edge. Tools like IPBan or IPBan Pro will throttle credential spraying against those surfaces while you build the memory-layer controls on top. Both layers earn their keep; neither one substitutes for the other.

Patch Tuesday will be Patch Tuesday. The Cisco SD-WAN holes will get closed and the next ones will open. Memory poisoning is the failure mode that doesn’t get cleaned up on a monthly cadence, and the teams who treat it that way are the ones who will find out the hard way that an agent’s “memory” is just a database their attackers can also write to.

Sources

• Week in review: Cisco SD-WAN 0-day exploited, Patch Tuesday forecast