Threat Model for Agents with Persistent Memory Stores

Persistent memory is what turns an AI agent from a chatbot into something closer to a colleague: it remembers what it tried last week, what worked, what the user prefers, and it builds on that record instead of starting cold every session. That same capability is also what creates a threat surface no legacy security tool was built to see. This piece maps that surface by the mechanism that produces it, write, store, retrieve, act, rather than borrowing categories from database security that were never designed for a system whose stored data doubles as its own reasoning.

A stateless agent forgets everything the moment a session ends. Each conversation is sealed off; nothing carries forward, nothing compounds. That has always been a limitation for anything resembling long-horizon work: software development automation, multi-step enterprise workflows, an assistant that's supposed to know a user's preferences without being told twice. Memory-enabled agents solve that problem by keeping a running record of past tasks, outcomes, and context. The record is the product.

But persistence changes what's actually at risk. Traditional data-store threat models worry about who can read a record and whether the system stays available. Agent memory does something a database record never does: it shapes what the agent decides to do next. Corrupt the record and you haven't just leaked or destroyed data, you've corrupted the decision-making process that reads from it. The data and the behavior stop being separable. Traditional intrusions tend to surface fast, through logs, alerts, anomalous traffic. A poisoned memory record can sit quiet for weeks before anything triggers it, which means the incident and its detection may be separated by more time than most response processes are built to bridge.

This is also why the standard toolkit doesn't transfer cleanly. SIEM platforms, EDR agents, conventional database access controls, all of it was built around patterns of human behavior and fixed application logic. An agent that retrieves a poisoned memory entry and acts on it isn't doing anything that looks abnormal to those systems; it's calling tools, executing tasks, doing exactly what it's supposed to do. The compromise lives in the content it's reasoning over, not in any signature those tools know to flag. A threat model for this class of system has to follow the mechanism, write, store, retrieve, act, instead of the old split between data at rest and data in transit.

The gap between how fast agentic AI is being adopted and how far security controls have caught up is not a hypothetical concern. Cisco's State of AI Security 2026 report documents it directly: deployment is accelerating across industries while agent-specific security investment lags well behind. And that gap isn't theoretical either. Organizations running agents in production are already reporting confirmed and suspected incidents at levels that suggest this is a live problem, not a future one.

How memory actually works in agents — the write, store, retrieve, act cycle that determines the attack surface

Four operations define where an agent is exposed. Write is the moment an agent ingests something, a tool output, a document, a piece of conversation, and decides it's worth keeping. Store is where that content lands: usually vector embeddings, sometimes structured records or key-value entries, sitting in a persistent backend. Retrieve is the lookup, typically a similarity search, that pulls relevant past context into the active prompt before the agent starts reasoning about the current task. Act is where retrieved context turns into behavior: tool calls, API requests, delegation to a sub-agent.

Each of those four steps is a place something can go wrong, and they don't go wrong in the same way.

The reason memory makes agents better is also the reason it makes them vulnerable. A memory-enabled agent improves with use because it stores what worked and recalls it the next time a similar task comes up. That loop is the whole point of the architecture. It's also exactly what attackers have started to target. MemoryGraft, documented in December 2025, exploited this directly: fabricated records of "successful experiences" get written into memory, retrieved later on semantically similar tasks, and followed as though they were the agent's own proven playbook. The agent isn't tricked in the moment. It's convinced, after the fact, that it already figured this out itself.

Not all memory behaves the same way, either. Episodic memory holds records of specific past interactions and outcomes. Semantic memory accumulates general knowledge about a domain or a user. Procedural memory captures patterns for how to complete a class of task. Each has its own write trigger, its own retrieval path, and its own failure mode when something gets in that shouldn't. A poisoned procedural memory entry, for instance, doesn't corrupt one decision, it corrupts a whole category of future decisions that look similar enough to retrieve it.

There's a tension running underneath all of this that no configuration change resolves. Write and retrieve policies that are more aggressive, meaning the agent stores more and pulls in more context more readily, make it noticeably better at long-horizon tasks. Those same policies also mean more surface for an attacker to reach: more gets written, more gets retrieved, more of what the agent does gets shaped by content nobody explicitly vetted at the moment it mattered. This isn't a bug to patch. It has to be managed with deliberate controls, not designed away.

Memory poisoning: how attackers corrupt the write and store operations

Memory poisoning is not a data breach in the conventional sense. The access controls on the memory backend can be entirely intact, untouched, doing their job. What's being attacked is the mechanism by which the agent forms its own experience: the poisoned entry becomes part of the agent's history, treated with the same weight as anything it actually did. Prompt injection, in the traditional sense, dies with the session. Memory poisoning outlives it, activates on its own schedule, and produces behavior the agent genuinely believes it chose.

There are a few ways in. Direct injection through ordinary queries requires no special access at all; research on the MINJA technique showed that an attacker interacting through completely normal user-facing input can achieve a high rate of successful injection into memory. Indirect injection is subtler and arguably more concerning: a malicious instruction sitting in a README file, or a document in a shared folder, gets read by the agent during a routine task, summarized, and stored, the poisoned content riding in on the back of something that looked like ordinary work. That's the exact pattern MemoryGraft used. And in retrieval-augmented systems, there's a third path: the AgentPoison research presented at NeurIPS 2024, from researchers at the University of Chicago, UIUC, UW-Madison, and UC Berkeley, showed that adversarially crafted backdoor triggers can be embedded in a RAG knowledge store, achieving high attack success with almost no cost to the agent's normal performance and at poison rates low enough to make detection genuinely hard.

That difficulty is the throughline. A poisoned memory entry doesn't look different from a legitimate one; it has the same shape, the same structure, the same plausible content as a real record of a real past task. The A-MemGuard research from 2025 found that even sophisticated LLM-based detectors miss the large majority of poisoned entries when tested against this problem. The agent's own confidence isn't a signal you can lean on either, because the agent treats retrieved memory as first-person experience. It has no internal skepticism toward its own past.

Timing makes this worse. A poisoned memory can sit completely inert until a task comes along that's semantically close enough to trigger retrieval, and that gap between the moment of injection and the moment of activation can stretch across weeks and multiple sessions, well past the window most incident response processes are built around. By the time the behavior surfaces, reconstructing how it got there is often incomplete at best.

There's a second consequence worth separating out: memory that accumulates sensitive user data over time becomes a target for extraction, not just corruption. LeakAgent research demonstrated that privacy leakage from agent memory isn't something an attacker stumbles into by accident, it can be systematically elicited and optimized as its own attack. Which means the agents doing the most valuable long-horizon work, the ones with the richest memory, are also carrying the most exposure on this front. The capability and the risk scale together.

Retrieval-time exploitation: how indirect prompt injection hijacks memory at the moment of recall

The problem at retrieval time is structural, not a matter of sloppy implementation. When a memory record gets pulled into the context window, it sits right next to the current task prompt, and the model has no reliable way to tell the difference between a retrieved memory and a live system instruction. That's the same flattening problem OWASP identifies as the root of prompt injection generally, catalogued as LLM01 in its 2025 guidance. Once content is inside the context window, its origin stops mattering to the model. Which means a malicious payload planted in memory doesn't need to succeed at the moment it's written; it just needs to eventually get retrieved.

Indirect prompt injection is the main way that happens. An attacker plants a payload somewhere the agent will eventually read on its own, a webpage, a document pulled through RAG, an API response, a file in a repository, and waits. The agent fetches it during normal work, and the payload lands in the context window carrying no marker that says "this came from somewhere untrusted." In agentic systems this is more dangerous than direct injection through a user interface, because the attacker never needs access to that interface at all. They just need to put something somewhere the agent is going to look.

It gets more complicated in multi-agent systems. Research covering 2025 and 2026 has tracked a marked increase in persistence and lateral movement across documented multi-stage attacks, suggesting single-turn injection is giving way to campaigns that unfold across sessions and across agent boundaries. The "Prompt Infection" paper (arXiv:2410.07283, 2024) lays out exactly how this propagates: one compromised agent passes a malicious payload to another agent downstream through a shared memory store or message channel, and the second agent has no reason to suspect the content came from anywhere adversarial. In architectures where multiple agents share a memory backend, that backend isn't just storage anymore. It's a transmission line.

Anthropic's system card for Claude Opus 4.5, published in November 2025, gives a useful sense of scale here. In agentic coding environments, the reported success rate for indirect prompt injection was low on a single attempt but climbed sharply by the tenth try and reached a substantial share of attempts by the hundredth. For a threat model, that escalation curve matters more than any single number: an attacker with persistent access to content an agent will eventually retrieve doesn't need to succeed once. They need to be patient.

Existing defenses against prompt injection were largely built for the direct, single-session version of the problem, something typed into a chat window in real time. Research on memory-mediated injection shows those defenses cover that case reasonably well and leave the retrieval-phase version largely untouched, because the payload already passed through write and store before it ever showed up at retrieval. Validating input at the point a user types it and validating input at the point memory gets pulled into context are different engineering problems, and right now, most systems are only solving the first one.

How corrupted memory translates into harmful tool calls and downstream action

None of this matters much while it's sitting in storage. Memory corruption becomes a real problem the moment it drives a tool call, an API request, or a decision to hand a task off to another agent. Agents with access to actual tools, shell access, database queries, the ability to move funds, credentials to authenticate with, turn a compromised memory record into something that happens in the world. And because the agent trusts what it retrieves as its own experience, it acts without pausing. There's no second opinion built into most of these architectures, no moment where the system asks whether this memory deserves the weight it's about to be given.

One consequence is a kind of privilege escalation that never touches an access control list. If an agent has a legitimate record of some past high-privilege action it was authorized to take, a poisoned or fabricated memory entry can manufacture the same kind of record for an action nobody actually approved. The agent retrieves it as precedent and proceeds, because as far as its reasoning is concerned, this is a thing it's done before with permission. The access control system was never touched. The reasoning layer was.

Scale matters here in a way it doesn't for a single leaked record. Agents move far more data than individual human users do in the course of normal operation, so a compromised agent acting on a poisoned memory entry isn't a contained incident, it's an exposure whose size tracks with everything that agent has access to, not with the size of the corrupted entry itself. A few sentences of fabricated history can authorize an action with consequences much larger than the memory record that triggered it.

Underneath all of this sits a gap nobody has closed yet: there's no standard way to check, at the moment a tool call executes, where the context behind that call actually came from. Whether the instruction driving an action originated in a verified system prompt or a retrieved memory record isn't something most execution layers can tell apart, absent deliberate provenance tracking built in from the start. That's the structural reason these attacks are hard to intercept in the moment; by the time the tool call fires, the distinction that would have mattered is already gone.

Tool and MCP ecosystem attacks that interact with memory-held state

The Model Context Protocol has become one of the standard ways agents connect to tools, data sources, and each other, and that makes MCP servers a pretty unusual point of leverage. They mediate both what tools an agent can reach and what context flows through it, which means a single compromised server touches the action layer and the memory layer at once. OWASP's MCP Top 10 lists risks across this exact territory, model misbinding, context spoofing, insecure memory references, covert channel abuse, and nearly all of them intersect with how a memory-enabled agent actually behaves day to day.

One pattern worth naming directly: the "rug pull." Microsoft's security team documented this in June 2026. A tool gets reviewed, approved, allowlisted. Later, the MCP server quietly changes what that tool's metadata says it does, and the agent keeps treating it as trusted, because the trust decision was made once, at approval time, and never gets re-derived. This pattern was first documented against GitHub and WhatsApp MCP integrations in 2025. Related techniques, schema poisoning and tool shadowing, work by corrupting the interface definition an agent relies on to understand what a tool even is. And here's where it connects back to memory: if an agent has a stored record of successfully using a given tool, that record becomes an endorsement. Every future retrieval of that memory tells the agent the tool is safe, right up until the tool itself has quietly changed underneath it.

The supply chain angle compounds this. Check Point Research disclosed critical vulnerabilities in Claude Code across 2025 and 2026 showing that repository-level configuration files now effectively function as part of the execution layer, meaning simply opening an untrusted project can trigger remote code execution before a user ever sees a consent prompt. The most severe vulnerability found in this space, in Gemini CLI, patched in April 2026, reached a perfect CVSS score, which tells you how serious supply chain exposure has become in agent tooling specifically. And any content an agent pulls in from a compromised part of that supply chain is a potential write event into memory. Supply chain compromise and memory poisoning aren't two separate categories here. In practice they're the same attack wearing different clothes.

Tool poisoning attacks the relationship between an agent and a tool, not the content of any one call the agent makes. Memory is what stores the trust decisions behind that relationship, which tools have worked before, which ones the agent has learned to reach for. That makes the tool-trust surface and the memory-trust surface effectively the same surface, viewed from two different angles.

Structuring the threat model: organizing

The mechanism gives the organizing principle: write, store, retrieve, act. Every attack class described above maps to one or more of those four points, and a threat model built around them, rather than around legacy categories like data at rest and data in transit, actually matches how these systems fail in practice.

Write-phase controls need to treat every ingestion event, not just user input, as a potential injection point: documents, tool outputs, and API responses all deserve the same scrutiny a direct user message gets, because MemoryGraft and MINJA both show that the write phase is exploitable through completely ordinary-looking channels. Store-phase controls need detection that assumes poisoned entries will look structurally identical to legitimate ones, since that's what the AgentPoison and A-MemGuard research both found, rather than betting on anomaly detection catching something that was designed not to look anomalous.

Retrieval-phase controls need a trust boundary that doesn't currently exist in most systems: some way to mark retrieved memory as distinct from verified instruction, even though the model itself flattens that distinction once content lands in the context window. And act-phase controls need provenance tracking that follows a piece of context back to its origin before a tool call executes on it, closing the exact gap that makes privilege escalation through fabricated memory records possible in the first place.

None of these four are solved by the same fix. That's the point of organizing the threat model this way instead of borrowing one built for a different kind of system. Agent memory doesn't fail the way a database fails. It fails the way judgment fails, quietly, gradually, and only once something comes along to test the belief the agent didn't know it had picked up.