Agent Memory and Context Persistence Security Risks

A stateless LLM interaction dies when the session closes. An agent with memory doesn't get that mercy: whatever gets written into its storage sits there, waiting to be pulled back out in a session it never shared with the one that wrote it. That difference, between an attack that ends and one that waits, is the whole reason agent memory security needs its own vocabulary and its own defenses.

Researchers now use the term "always-on agents" for systems whose future behavior depends on state built up over time, not just retrievable memories, but task ledgers, permissions, credentials, commitments, provenance records, trigger conditions, and side effects already committed out in the world. A June 2026 arXiv survey (2606.30306) on persistent memory, state, and governance in LLM agents centers on this exact property: the agent is carrying forward a history that shapes what it does next, whether anyone asked it to or not.

Stellar Cyber's late-2026 threat analysis lays the contrast out almost like a spec sheet. Stateless generative AI: session-based memory, a read-only sandbox, worst case is bad output, and detection is more tractable. Agentic AI: persistent storage, read-write access to APIs and databases, and a worst case that includes actual system compromise and financial loss. Detecting problems here can't rely on pattern-matching alone. It needs behavioral observability, watching what the agent does over time, not just what it says in one exchange.

That shift turns the memory store into shared state. Anything that reaches it doesn't just affect one conversation, it shapes every conversation the agent has afterward. Stellar Cyber calls the resulting failure mode a "confused deputy" problem: an attacker doesn't need to breach the network at all. They just need to convince a trusted agent to act on their behalf, once, in a way that gets remembered.

Two risk families come out of this, and the rest of this piece covers both. One is adversarial: someone deliberately plants something in memory, knowing it'll get retrieved later. The other is non-adversarial: safety instructions and constraints just fall out of context on their own, through ordinary operations like compaction. Neither exists in a stateless system. Both are a direct consequence of giving an agent a memory that is actually worth having.

How OWASP, NIST, and regulators have codified the persistent-memory attack surface

Standards bodies caught up to this fast, and for good reason. OWASP published its Top 10 for Agentic Applications in December 2025, built with input from industry experts, researchers, and practitioners, and announced it at Black Hat Europe 2025 and the OWASP Agentic Security Summit. Item ASI06 is Memory and Context Poisoning, and it exists as its own category for a specific reason.

The existing LLM Top 10 assumes an attack happens inside a session and gets evaluated there. ASI06 attacks don't work that way. They persist across sessions and can execute days or weeks after the original write, which means the standard prompt injection defenses under LLM01:2025 simply don't see them coming. OWASP's LLM08:2025, covering vector and embedding weaknesses, ties into the same conversation: it addresses both inversion attacks and poisoning attacks inside the retrieval pipeline, linking RAG infrastructure directly to memory security.

Regulators aren't far behind. NIST's AI Risk Management Framework and its Generative AI Profile are relevant reference points for organizations, and NIST's AI Agent Standards Initiative, launched February 2026, named agent identity, authorization, and security as explicit priorities, not afterthoughts. Microsoft's updated framework covering security practices for AI development, also from February 2026, calls out agent identity and role-based access control enforcement in multiagent environments by name, and flags memory and cache protection as concerns engineers need to address.

The EU AI Act adds its own layer for high-risk systems: data governance obligations under Article 10, automatic logging under Article 12, and transparency requirements under Article 13 that require users get meaningful information about how outputs get generated. Atlan's April 2026 governance analysis draws a direct line from memory-layer risk to regulatory exposure: memory poisoning triggers FTC Act Section 5 and EU AI Act Article 12 concerns; access control failures implicate HIPAA, GDPR Article 25, and FINRA SR 11-7; and a missing audit trail hits EU AI Act Article 12, a set of financial reporting controls, and FINRA all at once.

None of this is a compliance checkbox exercise. It's institutions across security, engineering, and regulation independently arriving at the same conclusion: persistent memory changes what an agent is, structurally, and the old threat models don't cover it.

Adversarial memory poisoning: how attackers plant instructions that outlast the session

The mechanism is simple to state and hard to catch. An adversary implants false or malicious content into an agent's long-term storage, whether that's a RAG store, a vector database, or saved conversation history. The agent treats that content as learned fact, recalls it in a future session, and acts on it, often weeks after the original write, with no attacker present at the moment of harm.

A few named techniques show how this plays out in practice.

MINJA (Memory Injection Attack), published at NeurIPS 2025 by Dong et al., doesn't require touching the memory store directly. The attacker just sends crafted queries that get the agent to generate and store its own poisoned reasoning traces, which later surface as few-shot examples for other users. The study reported roughly a 95% injection success rate and a 70% attack success rate.

AgentPoison targets RAG knowledge bases with an optimized backdoor trigger, one that maps a triggered query to a tight, specific region of embedding space so the poisoned entry gets retrieved reliably instead of by chance. Reported attack success rates ran high across the agents tested in the study.

PoisonedRAG, presented at USENIX Security 2025, makes the asymmetry of this problem impossible to ignore: researchers injected just 5 malicious documents into a corpus of millions and got the RAG system to return the attacker's desired false answer 90% of the time on targeted queries. Five documents. Millions in the corpus. Ninety percent success. That ratio is the entire argument for why memory poisoning deserves separate attention from ordinary data quality problems.

MemoryGraft, described in recent research, skips the injection drama entirely. It hides malicious content in something completely mundane, a README in a code repo, a document sitting in a shared folder. The agent reads it during normal operation, stores a summary, and moves on. Weeks later, it retrieves that "successful experience" and imitates the pattern, believing it's following its own proven playbook rather than someone else's plant.

Enterprise-scale incidents have described attackers corrupting persistent memory to manipulate financial guidance and operational decisions. An attacker files a support ticket instructing an agent to "remember" that vendor invoices from a certain account should route to an external payment address, according to a scenario in Stellar Cyber's research that makes the mechanics concrete. Three weeks pass. A legitimate invoice comes in. The agent, following its own memory, routes payment straight to the attacker. Nothing about that transaction looks anomalous to traditional detection, because by the time the payment fires, the compromise is old news to the system, even though no one outside it knows yet.

Cisco's MemoryTrap research found something similarly unglamorous: a routine developer workflow, clone a repo, let an agent assist, approve a dependency install, can quietly become a persistent prompt injection vector. No part of that sequence looks like an attack while it's happening. And 2026 research into what's being called "sleeper memory poisoning" describes assistants storing a fabricated user memory pulled from manipulated context, one that sits dormant before resurfacing to steer a later, unrelated session. The compromise can predate its own discovery by a wide margin.

Across academic studies, attack success rates against LLM-based agent implementations have been reported at 80% to over 99%. And Memory Poisoning and Supply Chain attacks carry disproportionate severity and persistence risk, while in Stellar Cyber's 2026 incident tracking Tool Misuse and Privilege Escalation remain the most frequently logged categories (520 incidents tracked).

Memory poisoning breaks the assumption that containment happens fast and that once you find the breach, you can bound how long it's been active, which is the closing point that matters here. Traditional incident response assumes containment happens fast, that once you find the breach, you can bound how long it's been active. Memory poisoning breaks that assumption outright. Investigating one of these incidents can mean discovering the compromise started well before anyone noticed the deployment behaving strangely at all.

Non-adversarial context loss: when safety instructions fall out of their own accord

Persistence doesn't only help attackers get in. It also makes an agent's own safety mechanisms fragile in ways stateless systems never had to worry about. A compaction event, an entirely routine, non-malicious operation, can silently strip out a safety constraint the same way an injection plants a malicious one. No adversary required.

Here's how it happens mechanically. When an agent's context window fills up, the system runs compaction or summarization to make room. That process can quietly drop safety-critical instructions, things like "confirm before acting", and the agent reverts to unconstrained behavior without any signal that something changed.

A study on what researchers call "Governance Decay" (arXiv 2606.22528) put numbers on this. Across 1,323 episodes, policy violations sat at 0% when the policy stayed in full context. After compaction, violations rose to 30% on average, and as high as 59% for some models. The split matters: when the constraint survived the summarization step, violations stayed at 0%. When it got dropped, violations hit 38%. The constraint's survival, not its wording, is what determined the outcome.

A related project, the "Lost in Compaction" work using the CompInt test suite (arXiv 2608.11242), found that current compactors retain only 17% of injected safety constraints on average. Retention swung sharply depending on which compactor ran, how the prompt was phrased, how long the context was, and where in the conversation the constraint sat. The loss wasn't tied to one bad setting. It appeared everywhere the researchers looked.

A CIKM 2026 study on what it terms the "Compaction Cliff" tested hierarchical truncation across 50 real agent configurations and found it preserved only 50% of safety constraints. An agent reviews a patient's history, the context fills up, compaction drops the allergy line, and the agent later recommends a contraindicated drug, which makes the paper's medical scenario's stakes plain. Nobody attacked anything. The system just ran out of room and made a choice about what mattered.

Delivery channel affects how much constraint loss occurs and where it happens. The Governance Decay research found constraint loss stays near zero when a policy lives in the preserved system message, the part of the context a harness is built to protect. Loss jumps sharply the moment that same policy sits in a standing user instruction, a memory entry, or a tool output instead, the parts most compaction routines are designed to trim first.

There's also an adversarial variant of this exact mechanism, described in the same Governance Decay paper as a "Compaction-Eviction Attack." Instead of injecting a malicious instruction, an attacker crafts an optimized input that biases the summarizer into omitting a legitimate policy during compaction. Optimized versions of this attack defeated every model the researchers evaluated. That result blurs the line between "adversarial" and "non-adversarial" pretty badly, since the vulnerability being exploited is architectural either way, not a content filter gap.

A related technique exploits agents that load large numbers of tool schemas into the context window, where an attacker can inject enough token volume through legitimate channels to push security constraints toward the far edge of the model's effective attention range. No malicious payload gets sent. No content filter has any reason to trigger. The attack is just volume, applied in exactly the right place.

Separate research from Hadeliya et al. found that safety mechanisms grow unstable simply as context length increases, with refusal rates shifting by 30 to 70 percentage points once conversations pass 100,000 tokens. And in production, agent runtimes typically trigger compaction before the context window is fully exhausted, condensing earlier content into a summary and discarding the originals. The agent has no built-in way to detect that this loss happened. It processes the post-compaction state as complete, because as far as its own reasoning is concerned, it is.

None of this is a bug report on one product. It's a structural property of how compaction has to work when context windows are finite and conversations keep going, which means every memory-enabled agent runtime, regardless of vendor, faces some version of this same risk class.

Embedding inversion, privacy leakage, and the false assumption that vectors anonymize data

A common assumption needs correcting up front: converting text to an embedding is not anonymization. A vector is a mathematical approximation of the text that produced it, and approximations, given the right technique, can be reversed back toward the original.

Embedding inversion attacks work best on exactly the kind of content memory systems tend to store most: short, high-value strings like names, email addresses, and physical addresses, which happen to be precisely the categories GDPR and HIPAA are built to protect. Research on MemoryPrivacyRisks (Wang et al., 2025) found that when an agent's memory holds sensitive user data, the agent itself can be induced to disclose it, sometimes on purpose through a crafted prompt, sometimes by accident through normal operation.

LeakAgent (Nie et al., 2025) pushed this further by showing privacy leakage isn't just something that occasionally slips out. It can be systematically elicited and optimized by a learning-based red-teaming agent built for exactly that purpose. That moves the risk from a theoretical edge case to something demonstrably engineerable, which is a meaningfully worse category to be in. A paper in Frontiers in Computer Science found that memory-related leakage carries the highest persistence and amplification risk among the leakage types studied, and that tool-mediated leakage widens the exposure surface considerably beyond what direct queries alone would produce.

Regulation runs straight into a wall here. GDPR's right to erasure under Article 17 applies to personal data stored in agent memory, in principle. But Atlan's governance analysis points out that vector databases don't currently have a proven erasure mechanism for embeddings. No commercially available vector database offers a provable way to delete embedded personal data on request, which means "right to erasure" and "data stored as a vector" are, right now, uncomfortably hard to reconcile. Atlan's broader analysis maps memory-layer compliance failures to GDPR Article 17, HIPAA retention rules, a set of financial reporting IT general controls, and EU AI Act Articles 12 and 13, and notes that current memory-layer tooling has no data classification by regulatory category built in at all.

A newer research thread, MRMMIA (Chen et al., 2026), looks at membership inference attacks against agent memory specifically, testing whether an attacker can determine if a particular piece of data was ever stored in memory at all, without necessarily extracting the data itself. Specific success rates aren't available from current sourcing, but the attack class exists and is drawing active research attention.

The pattern connects back to everything already covered. Persistence amplifies privacy risk the same way it amplifies security risk generally. A data exposure that would've been a one-time embarrassment in a stateless system becomes, once it's sitting in memory, a permanent retrieval target that outlives the incident that created it.

Cross-user contamination and multi-agent state conflicts in shared memory environments

Shared memory creates a shared attack surface, and multi-user deployments make that literal. If access controls operate at the query level instead of the content level, a poisoned entry written during one user's session can get retrieved during a completely different user's session, with no relationship between the two beyond sharing a memory store.

Atlan's governance analysis flags the downstream consequences: multi-agent conflicts create exposure under a set of financial reporting controls for reporting accuracy and under HIPAA for care continuity, and current memory-layer tools are built single-agent by design. There's no cross-agent consistency checking and no conflict detection built into the tooling most teams are using today.

The June 2026 always-on agents survey (arXiv 2606.30306) identifies shared and social memory as its own distinct category of state, separate from an individual agent's private memory, and governance is thinnest exactly at the points where different state types intersect. That's not a coincidence. Nobody designed for that boundary because nobody was thinking about it as a boundary in the first place.

Picture two agents pulling from the same semantic memory store and retrieving contradictory facts about the same customer, the same policy, or the same vendor. Neither agent has any way to detect the conflict, because each one just sees its own retrieval as ground truth. Downstream decisions built on those two different "truths" diverge quietly, and nothing flags the divergence until the consequences appear somewhere else entirely.

Atlan notes that current vector databases enforce access at the query level, coarsely, rather than at the content level tied to user identity. A retrieved chunk becomes visible to any user whose query lands close enough in semantic space, regardless of whether that user actually has any right to see the underlying data. Proximity in embedding space, not permission, decides what gets shown.

Scale it out, and the exposure gets harder to dismiss as edge-case territory. The Zenity 2026 AI Agent Security Threat report found that only 14.4% of enterprise AI agents went live with full security and IT approval. The rest launched with some gap in that review process, which means the access control and cross-contamination risks described here aren't confined to a handful of poorly run pilots. They're sitting inside the large majority of agent deployments currently running in production.