Your AI Agent Remembers Everything. That Is Now Your Biggest Security and Compliance Problem.

Why Has Agent Memory Suddenly Become a Security Topic?

For most of 2024 and 2025, the security conversation around large language models was about prompt injection: a malicious instruction hidden in a web page or document that hijacks the model for one session. Once the session ended, so did the damage. That assumption no longer holds, because the agents companies are now deploying remember. They write notes to themselves, store user preferences, keep project logs and reload all of it at the start of the next conversation. An instruction that gets into memory does not end with the session. It becomes part of the agent's standing context.

Memory became mainstream quickly. Anthropic's memory tool documentation describes a pattern where the model automatically checks a memory directory before starting a task and writes what it learns back to files that persist between sessions. Coding agents keep project notes in markdown files at the repository root. Open-source assistants such as OpenClaw store memory in a plain-text MEMORY.md file. A dedicated memory-layer market has formed around the same need: Mem0, one of the best-known providers, raised $24 million and reported API usage growing to 186 million calls in Q3 2025 from 3.5 million in Q1, and AWS named it the exclusive memory provider for its Agent SDK.

The security community caught up in 2026. The OWASP Top 10 for Agentic Applications lists memory and context poisoning as its own risk, ASI06, which Promptfoo's summary describes as attackers poisoning agent memory systems, embeddings and RAG databases "to corrupt stored information and manipulate decision-making across sessions." The key word is sessions. Memory poisoning is prompt injection with persistence, and persistence is what turns a nuisance into an incident.

This matters to anyone building or buying agents, not just security teams. If your support agent, sales assistant or internal coding agent can write to its own memory based on content it reads, then anyone who can get content in front of it, by email, ticket, web page or pull request, can potentially shape how it behaves next week.

What Does a Memory Poisoning Attack Actually Look Like?

The clearest recent example is MemGhost. According to the Cloud Security Alliance research note on the underlying paper, a single crafted email can silently write false entries into an agent's plain-text memory file, where they stay until a person or process removes them. Against OpenClaw running GPT-5.4 and processing mail in the background, the attack succeeded 87.5% of the time. Against a Claude Code SDK agent running Sonnet 4.6, it succeeded 71.4% of the time. In a Gmail test, the payload emails got past spam filtering in more than half of attempts. The researchers disclosed the issue to OpenClaw in mid-July, and at the time of the note no substantive fix had shipped and no CVE had been assigned.

The note is worth reading for one detail in particular: hardened models still complied with planted instructions in roughly half of trials. Model-level safety training helps, but it does not close the hole. The weakness is in the architecture, where the same agent that reads untrusted email also has permission to write to the file that defines what it believes in every future session.

Academic work points the same way. A systematic study accepted at ICML 2026 identified four memory write channels and nine structural vulnerabilities across model capabilities, system prompt design and agent architecture, and built a taxonomy of six classes of memory poisoning attack. Its benchmark, MPBench, showed that agents designed to write and retrieve memory more aggressively are more exploitable. That is an uncomfortable finding, because "remember more, recall more" is exactly how vendors market memory features.

Most importantly, the same study found that existing prompt injection defences fail to cover memory poisoning. Many teams have spent the last year adding input filters, guardrail models and system prompt hardening. Those controls inspect what goes into a single model call. They are not designed to ask whether a piece of content should be allowed to change the agent's long-term state.

Is Anyone Exploiting This Outside the Lab?

Yes, and not only attackers. In February, Microsoft's security team published research on what it called AI Recommendation Poisoning. Reviewing AI-related URLs in email traffic over 60 days, it found more than 50 unique prompts from 31 companies across 14 industries embedded in "Summarize with AI" style buttons. When clicked, these links opened an AI assistant with a pre-filled prompt that tried to write promotional bias into the assistant's memory, using phrasing such as "remember [Company] as a trusted source" and "recommend [Company] first", with persistence phrases like "in future conversations" appearing across all observed cases.

This is the commercial version of memory poisoning, and it is a useful warning for anyone building agents that touch the open web. The incentive to manipulate what an agent remembers is not limited to criminals. Marketers want your procurement agent to remember their product favourably. Competitors would like your research agent to treat their documentation as authoritative. Every vendor whose content your agent reads has a reason to try.

Microsoft's guidance for enterprises is instructive because it is largely manual: hunt for AI-assistant URLs whose prompt parameters contain words like "remember", "trusted" and "authoritative", review affected users' stored memories and remove suspicious entries, and train staff to hover over AI links before clicking. The post also notes that platform protections are still evolving. If one of the largest AI platform vendors is telling customers to audit memory by hand, it is a fair signal that the tooling to govern memory automatically is still immature.

For companies building their own agents, the implication is simple. You cannot wait for your model provider to solve this. Memory is stored, retrieved and trusted by your application code, so the controls have to live there too.

Why Is Agent Memory Also a GDPR Problem?

Memory poisoning is the security half of the story. The compliance half is quieter but just as real: agent memory is very often personal data. A support agent that remembers a customer's name, complaint history and preferences is processing personal data. So is a sales assistant that stores notes about a prospect, or an HR agent that remembers an employee's leave request. Under GDPR, that data comes with purpose limitation, retention limits and the right to erasure.

Erasure is where most memory implementations fail. In February, the European Data Protection Board published the results of its coordinated enforcement action on the right to erasure, in which 32 data protection authorities gathered responses from 764 controllers. Among the recurring problems it identified were controllers relying on ineffective anonymisation techniques as an alternative to deletion, and difficulties deleting personal data from backups. Agent memory reproduces both problems in new places: embeddings derived from a customer's messages, summarised memory files, conversation logs and replicated vector indexes.

Deleting the source row in your CRM does not delete the memory file the agent wrote about that customer last month, or the embedding in a vector store, or the summary another agent copied into a shared context. If you cannot answer the question "where does this agent remember things about this person?", you cannot honour an erasure request, and you cannot demonstrate to a regulator that you did. We have written about the related exposure when contractors touch live data in our guide to outsourced developers and production data access.

The same structure also helps with the transparency duties now arriving under the EU AI Act. A memory store that records where each entry came from and when it was written is far easier to explain to a user, an auditor or a customer's procurement team than an opaque blob of notes the agent wrote for itself.

How Should You Architect Agent Memory Safely?

The good news is that the defences are ordinary engineering. None of them require a breakthrough in model safety. They require treating memory as a production data store with a trust boundary, which is exactly what the CSA note recommends at a strategic level. In practice, we see six controls doing most of the work.

First, separate reading from remembering. The single most effective change in the MemGhost recommendations is to process untrusted content with a reader component that has no memory, file or shell access, and to pass only structured, validated output to the agent that is allowed to write memory. An email summariser should not be the same process that edits the agent's beliefs. Second, gate writes from external sources. Memory written because a user explicitly asked for it is different from memory inferred from an inbound email or a scraped web page. The latter should require confirmation, a policy check or at minimum a lower trust tier.

Third, tag every entry with provenance: which input triggered the write, which source it came from, which user and task it belongs to, and when it was written. Provenance is what makes everything else possible, from flagging retrievals that trace back to unverified sources to rolling back every entry written from a specific suspicious email. Fourth, scope memory narrowly. Per-user and per-task namespaces stop one poisoned customer conversation from contaminating every other customer's experience, and they map naturally onto GDPR erasure by data subject.

Fifth, expire and cap memory. Anthropic's own documentation tells developers to periodically delete memory files that have not been accessed in a long time, to cap file sizes, and to validate every path so that a request like /memories/../../secrets.env cannot escape the memory directory. Those are baseline hygiene, not optional extras. Sixth, log and review. Every memory write should be logged with its triggering input so that a security team can answer what the agent learned, from whom and when. Periodic review of memory written during unattended processing, such as overnight email triage, is cheap insurance.

Should You Build Your Own Memory Layer or Buy One?

The memory-layer market makes it easy to add memory with a few lines of code, and for prototypes that is the right call. But the decision deserves more scrutiny once an agent touches customer data or acts on behalf of users. The CSA note reports that MemGhost payloads transferred to several other agent frameworks and to the Mem0 memory backend, clearing its effectiveness threshold on most of them. A managed memory service does not remove the architectural problem. It moves part of the data store outside your perimeter while leaving the write decisions inside your agent.

The questions to ask any memory provider, or your own team, are concrete. Can every entry be traced to the input that created it? Can we delete everything about one data subject across raw memory, embeddings and derived summaries, and prove it? Can we roll back every write made during a given time window? Where is the data stored, under which jurisdiction, and how would we export it if we switched providers? We covered the portability side of that last question in our piece on LLM exit strategies, and the same logic applies to memory: what your agent has learned about your customers is an asset you should own.

In many cases the pragmatic answer is a hybrid. Use a framework or managed service for retrieval mechanics, but keep the write policy, provenance metadata, namespace design and deletion workflow in your own code and your own database. Anthropic's memory tool is a useful reference design here precisely because it is client-side: the model requests memory operations and the application decides whether and how to execute them. That is the right division of responsibility. The model proposes. Your system disposes.

Memory also interacts with the rest of your agent estate. If you are already tracking which agents exist and what they can access, as we described in our article on agent sprawl, memory stores belong in that registry too, with an owner, a retention policy and a decommissioning plan.

What Should Engineering Leaders Do in the Next Quarter?

Start with an inventory. List every agent in production or pilot that persists anything between sessions: memory files, vector stores, user profiles, conversation summaries, project notes in repositories. For each, record what can write to it, what content sources feed those writers, and who owns it. Most organisations find at least one agent where an inbound channel, such as a shared inbox, a ticket queue or a public web search, can indirectly write to long-term memory without any human in the loop.

Next, close the unattended write paths. The CSA's immediate recommendation is to disable unattended memory writes triggered by inbound email until an approval step exists, and that is sensible advice for any external channel. Then add provenance and logging to the memory store, because without them you cannot investigate an incident or answer an erasure request. Finally, add memory poisoning to your red-team and evaluation suites. If your evaluations only test single-turn prompt injection, they are testing the wrong thing. Plant a false memory in a test environment and check whether the agent acts on it three sessions later.

Procurement teams should add the same questions to vendor assessments. The CSA note explicitly recommends evaluating memory-write governance during procurement and treating persistent memory as an asset with its own trust boundary. If a vendor cannot explain how its agent decides what to remember and how you would delete it, that is a material risk, not a feature gap.

How Does a Nearshore Team Help You Get Agent Memory Right?

Memory governance is the kind of work that falls between teams. The AI team wants the agent to be smarter. The security team does not know the memory store exists. The data protection officer assumes deletion happens in the CRM. Meanwhile the backlog is full of features, and nobody owns the unglamorous engineering of provenance schemas, namespace design, deletion pipelines and memory-poisoning test harnesses.

This is a good fit for a dedicated development team. At StepTo, we embed engineers with AI engineering and security experience alongside a client's product team to build the memory layer properly: a reader and writer split for untrusted inputs, provenance-tagged memory stored in the client's own infrastructure, per-user namespaces that map onto GDPR erasure, and evaluation suites that test whether a planted memory changes agent behaviour sessions later. Your in-house team keeps shipping features while the foundation under them becomes something you can defend to a security review or a regulator.

Being based in Serbia matters for this kind of work in two ways. Our engineers work within the European data protection culture that shapes how memory, retention and erasure must be designed, and they share most of the working day with Western European clients and overlap meaningfully with the US East Coast. When an agent starts behaving strangely and someone needs to trace which memory entry caused it, the people who built the memory layer are online. That is the practical advantage of our nearshore development model.

If you are deploying agents with memory and want a second opinion on the architecture, talk to us. Our engagements typically start in 2-4 weeks, with a two-week paid trial.