Agent Memory Architecture and Data Persistence Risks

Agents don't store data the way software has stored data for the last fifty years. A developer used to decide, line by line, what gets written to a database and what gets thrown away. Agents accumulate memory as a side effect of doing their job, the same way you accumulate lint in your pockets just by walking around. Nobody asked for it, but there it is, and eventually it becomes a problem. This piece is about where that memory lives, who controls it, and how it turns into an exposure risk that most security teams haven't been trained to see.

The distinction that matters isn't just that agents remember things. It's that they act on what they remember, autonomously, often with nobody standing between the retrieval and the action. A human who sits in on a meeting and hears something sensitive will forget most of it by Friday. An agent that ingests the same information can pull it back out and act on it six months later, at 2am, without asking anyone first.

Credentials make this worse. Agents typically inherit the same API tokens and permissions scoped for the human employees they're supposed to help. Those permission structures were built assuming a person clicks around a dashboard a few times an hour. Nobody stress-tested them for a system that can query five SaaS platforms a second and never logs off.

The market data says this isn't a hypothetical problem waiting for a hypothetical future. Adoption of AI agents has already reached the large majority of enterprises, yet only a small fraction of those deployments have made it into production. That gap is the tell. Organizations are building agents fast and deploying them slow, and the hesitation usually comes down to the same worry: nobody's fully sure what these things remember, or why. Spending in this space is projected to grow roughly sixfold by the end of the decade. Whatever memory risk looks like today, it scales with the money.

The three-tier memory model that underlies almost every production agent

Strip away the vendor branding and nearly every production agent architecture reduces to the same three layers. A December 2025 academic survey out of Tsinghua landed on this taxonomy independently of what practitioners had already converged on, which suggests it's describing something structural rather than a naming convention someone made up for a conference talk.

Working memory, sometimes called in-context memory, is the conversation history and state loaded into the model's context window on every call. It's supposed to be temporary: it vanishes when the session ends or the window fills up. But "temporary" undersells how dangerous this tier is. Anything sitting in context can be acted on immediately, at full machine speed, before it ever disappears. Context windows keep getting bigger, and some models now ship with windows large enough to hold entire codebases, but stuffing the full history into every single prompt is still too slow and too expensive to do at scale. So teams manage it with sliding windows, summarization, or selective retrieval, each of which quietly decides what gets thrown out and what survives.

Semantic memory, the external long-term store, is where facts and past interactions live outside the model entirely: vector stores, key-value stores, graph databases. This is the tier that persists across sessions, and it's where data really piles up over an agent's lifetime. Vector search finds things that sound similar to your query; graph-style retrieval walks entity relationships instead. Both show up in production systems today, and both share the same quirk: what gets surfaced depends on the semantics of the query, not on what a programmer explicitly told the system to fetch. Nobody wrote a line of code saying "return this specific record." The system decided, on its own, that this record was close enough to what you asked for.

Procedural memory is the strangest tier and the hardest to pin down. It's the learned behavior an agent picks up from past task trajectories, the workflow patterns it settles into over time. Changes in how an agent behaves often can't be traced back to one specific stored record; the behavior is distributed, baked in, diffuse. It's a lot like human muscle memory: you can't point to the exact moment you learned to parallel park, you just can now. Hard to inspect, hard to audit, nearly impossible to revoke cleanly.

Weaviate's "Context Engineering" framework makes a point worth repeating here: each tier calls for a different kind of retrieval logic. Episodic memory should weigh how recent something is. Knowledge should weigh how relevant it is. Working state should weigh how fresh it is. Mixing these up isn't just sloppy architecture, it's a security mistake, because each tier carries a different exposure window and a different (often nonexistent) set of controls.

How production memory frameworks decide what gets kept, retrieved, and forgotten

Look at what today's memory systems actually do, and a pattern jumps out immediately: control over persistence sits with the agent or the framework, not with a person.

Letta, the production version of the MemGPT research project, splits memory into core, archival, and recall tiers. The detail that should raise an eyebrow: the agent decides, through its own function calls, what to keep and what to drop. Not an administrator. Not a policy engine sitting off to the side reviewing decisions. The agent. Letta raised a $10 million seed round in September 2024, so this isn't some lab demo, it's a company building toward real deployment with real customers.

Mem0 is the memory layer most teams have actually heard of, with over 48,000 stars on GitHub and $24 million raised across a seed and an October 2025 Series A. It writes to three backends at once, a vector store, a key-value store, and a graph database, and it scopes memory hierarchically across user, session, and agent levels. The same fact about you might exist in three places simultaneously. Retrieval blends semantic similarity, keyword matches, and entity matches, which makes it powerful and also makes it a black box: you generally can't tell which signal was the deciding vote. As of early 2026 it integrates with 21 different frameworks and platforms, meaning whatever memory it holds doesn't stay in one place; it flows downstream into whatever else your stack touches.

Zep takes a different angle, building temporal knowledge graphs so an agent can reason across weeks or months of history instead of just the current session. That's genuinely useful for anything long-running. It also means the system is explicitly built to resurface old information as if it were current, which is exactly the property that makes stale or poisoned data dangerous later on.

A-MEM tries to solve a related headache: memory going stale. It flags outdated entries and links newer ones that supersede them. Picture an enterprise where the VP of Sales changes twice a year, or a vendor contract gets renegotiated. Without something like A-MEM's supersede detection, an agent will happily act on a fact that was true last spring and hasn't been true since.

And then there's MemOS, which treats memory units the way an operating system treats processes: schedule them, layer them, expose them through APIs. Its very existence is a tell. The field has noticed that memory left to accumulate unmanaged is a liability, but the governance tooling to actually manage it is still early, closer to a first draft than a finished product.

Across all five of these, the decision about what persists is made inside the system, by the agent or the framework logic. It is not made by a security team. It is not made by a data governance policy. Nobody in IT signed off on it.

Where data actually leaks: the exposure surfaces each memory tier creates

Each tier leaks in its own particular way, and it helps to walk through them one at a time rather than treating "memory risk" as one big blur.

In-context memory leaks in plaintext. Sensitive input, names, account numbers, credentials pasted into a prompt by accident, sits unencrypted in a context window that may get logged, cached, or shipped off to a third-party model API somewhere else entirely. Summarization is supposed to help by compressing history down, but a summary can still preserve a fragment nobody meant to keep. And in multi-agent setups, context handed from one agent to another crosses a trust boundary that often goes unexamined: what Agent A treats as harmless internal scratch space becomes external input the moment Agent B reads it.

External memory has a different problem: it doesn't expire. There's no built-in TTL, no equivalent of a browser clearing cookies when you close the tab. It's designed to survive indefinitely, which is the entire point of the tier, and also exactly why it's risky. Access controls at the storage layer tend to be coarser than what a company's actual data policy requires; a vector database has no idea that one document is HR-confidential and another is fine for anyone to see. It just stores vectors. Because retrieval is non-deterministic, an unrelated workflow can accidentally surface a sensitive record that got stored months before, purely because the semantic distance happened to be close enough. And in systems like Mem0 that scope memory across users, agents, and sessions, a boundary drawn incorrectly means something written in your session could theoretically surface in someone else's.

Procedural memory is the quiet one. An agent that has absorbed thousands of past interactions may start behaving in ways that reflect sensitive data it once saw, without that data ever showing up in a retrievable record anywhere. You can open a vector store and read an entry. You cannot open a learned behavioral pattern and point to the exact input that caused it. And deleting the record that supposedly caused a behavior doesn't undo the behavior; the influence already baked itself in.

Then there's accumulation across sessions, which on its own is almost more worrying than any single leak. One session might look completely fine in isolation. Add up a hundred sessions and you've built a detailed profile of a person, a vendor relationship, or an internal process, piece by piece, with nobody ever writing that profile down in one place. Traditional data-loss-prevention tools watch data in motion or data at rest. They have no concept of data that gets synthesized gradually, across dozens of separate retrieval events spread over months.

Underneath all of it sits the credentials problem. Agents run on long-lived API tokens and service accounts, often with broad access across systems like Salesforce, Microsoft 365, or Slack. Steal the token, and you inherit the agent's access. Steal the token from an agent with a well-stocked memory, and you inherit everything it knows, too.

How memory poisoning turns persistence from a feature into a weapon

Prompt injection targets a single session and dies when that session ends. Memory poisoning is worse because it targets the agent's persistent state, and persistent state survives everything: session resets, context window resets, even model upgrades. A poisoned entry doesn't just linger, it gets treated, in future sessions, as the agent's own prior experience. That gives it more credibility in the model's eyes than a brand-new instruction would get. The agent isn't following an attacker's command; as far as it's concerned, it's recalling something it already knew.

The numbers here are not speculative. The MINJA attack, published at NeurIPS 2025, achieved an injection success rate above 95 percent against LLM-based agents across multiple datasets, with an attack success rate over 70 percent on most of them, and it pulled this off through ordinary query interactions, no privileged access required. Across the broader academic literature, attack success rates against LLM-based agents have ranged from 80 percent up into the high 90s. These numbers matter because they shut the door on the "sure, but is this actually exploitable" objection. It is.

Indirect prompt injection is the delivery mechanism in a lot of these cases. Malicious instructions get buried in an email, a webpage, a document, sometimes just in metadata, not in anything the user typed directly. The agent reads the content while doing something completely routine, and treats the embedded instruction as legitimate because nothing about the interface distinguishes "data" from "command." Palo Alto Networks' Unit 42 team demonstrated this concretely: a compromised webpage planted instructions into an agent's memory that survived a session restart and later got folded into the agent's own orchestration prompts, quietly exfiltrating conversation history in the process.

Sleeper poisoning is the version that should worry security teams the most, because it breaks the assumption that cause and effect happen close together in time. The attacker doesn't want an immediate reaction. They want the corrupted memory to sit quietly and cause trouble weeks later, in a session that has nothing obviously to do with the original attack. The MemoryGraft attack, published in December 2025, showed durable behavioral drift with no trigger needed at all, and it slipped past defenses built for ordinary prompt injection or standard RAG manipulation. Picture an attacker who slips a fake payment routing rule into an agent's memory through an innocuous support ticket. Three weeks pass. A completely legitimate invoice comes in, the agent recalls the rule it "learned," and the funds go to the wrong account. The invoice processing itself looks totally routine. Nobody ever reviews the memory entry that caused it, because nobody knew to look.

This has already happened outside a lab. CVE-2025-32711, known as EchoLeak, was a real exploit against Microsoft Copilot in 2025: a carefully engineered email triggered automatic data exfiltration with zero user interaction. That's the line between research paper and production incident, and it's already been crossed. Separately, work on AgentPoison and PoisonedRAG has shown that slipping a small number of malicious records into a knowledge base is enough to reliably steer an agent's answers toward whatever the attacker wants, no brute force required.

Why access controls and logging built for humans don't catch these failures

Every access control model in wide use today assumes a human is on the other end of the login. Someone authenticates, does a thing, logs out, and the session is the unit that security tools use to hold someone accountable. Agents break that assumption completely. They act continuously, they build up context across interactions that span days or weeks, and they often hold credentials that never expire in the first place, because nobody built the equivalent of a session timeout for a machine identity that's supposed to run all day, every day.

So the tools built for the old assumption miss the new failure mode almost entirely. Perimeter defenses and DLP systems watch data moving across the network or sitting in storage; they have no way to flag data that gets pieced together gradually across many retrieval events spread over months. SIEM tools and log-based anomaly detection need a baseline of "normal" behavior to compare against, and most organizations haven't built one, which tracks given how few agents have actually made it to production. Role-based access control assigns permissions to an identity, not to a memory state, so there's no clean way to say "this agent can act on finance data right now, but it should not be allowed to recall anything from HR while it's doing it." And audit logs record actions, not the memory lookups behind them. You can see that an agent approved a payment. You cannot see, in most systems today, which stored memory told it to.

The delayed poisoning pattern makes all of this worse rather than better. When the payoff of an attack lands weeks after the actual compromise, there's no two events close enough in time for a human analyst, or an automated system, to connect. The compromise and the consequence look like two unrelated blips on two different dashboards, and unless someone is specifically hunting for this pattern, they stay unrelated. That's not a tooling gap that gets patched with a software update. It's a gap in how the entire model of accountability was built, and closing it means rethinking what gets logged, what gets scoped, and who, or what, actually gets to decide what an agent remembers.