Why "Just Add a Delete Button" Isn't Enough: The Technical-Depth Missing from Memory Controls

Most product teams treat memory deletion as a UI problem. Add a button, confirm the action, purge the row. Ship it. But the attack research has caught up, and the technical-depth required to build memory controls that actually protect users is now an order of magnitude beyond what a delete affordance provides. If you are building or securing an AI product with persistent memory, a delete button is necessary. It is also, by itself, theater.

Key Takeaways

• Sleeper memory poisoning can inject fabricated memories through normal documents and webpages, with acceptance rates measured as high as 99.8% on frontier models. A delete button does nothing against an attack the user cannot see.
• Supply-chain campaigns like ClawHavoc have targeted behavioral config files (SOUL.md, MEMORY.md) specifically because modifying them creates persistent changes that survive across sessions, and sandboxing does not prevent this.
• OWASP codified memory poisoning as ASI06 in its 2026 Top 10 for Agentic Applications, describing it as high-persistence and very-high-detection-difficulty. The industry consensus is that current defenses are inadequate.
• Deletion and compliance are on a collision course: GDPR's right to erasure conflicts directly with the EU AI Act's 10-year audit trail requirement for high-risk systems, and almost no one has solved this for inferred or summarized memories.
• The real control surface is provenance (where did this memory come from, and should it be trusted?) plus temporal anomaly detection and rollback, not a post-hoc button that only works when a user already suspects compromise.

What is sleeper memory poisoning, and why does a delete button miss it entirely?

Sleeper memory poisoning is a delayed attack where an adversary manipulates external context (a document, a webpage, a repository file) to cause an AI assistant to store a fabricated memory about the user. A May 2026 arXiv paper formalized this attack class and demonstrated something uncomfortable: universal poisoning templates achieved poisoned-memory acceptance rates up to 99.8% on one frontier model and 95% on another. Those poisoned memories then caused attacker-intended agentic actions in 60 to 89 percent of subsequent evaluations.

The word "sleeper" matters. Unlike a prompt injection you might catch in the moment, a sleeper memory can sit dormant through many conversations before activating. Traditional monitoring sees nothing suspicious at any single point in time. The user does not know the memory exists. The delete button is sitting there, waiting to be clicked, but the user has no reason to click it because the attack is invisible by design.

This is the core failure mode. Deletion operates on the assumption that the user knows what to delete. Sleeper poisoning operates on the assumption that they don't.

How do supply-chain attacks target memory and identity files?

The attack surface is not limited to documents a user chooses to open. Security researchers have documented ClawHavoc, a supply-chain campaign that initially compromised 341 agent skills on a marketplace and grew to over 1,184 confirmed malicious skills. It specifically targeted SOUL.md and MEMORY.md files because modifying these files creates persistent behavioral changes that survive across sessions.

The mechanics are straightforward and that is what makes them dangerous. Cisco's research team demonstrated an attack using NPM post-install hooks to modify an agent's memory file. Because the first 200 lines of the memory file were included in the agent's system prompt, the modification persisted indefinitely. The same report noted that dependency-style files such as claude.md, agents.md, and soul.md all present the same risk.

Separately, independent researchers disclosed two attack paths against a sandboxed agent runtime, including one where prompt injection convinces the agent to modify its own behavioral blueprint. Containerization isolates agents from the host, yes. But a sandboxed agent still has workspace files and network access. The sandbox is not a security boundary for the agent's own memory and identity.

Security architecture commentary puts it plainly: identity and persona files are not a security boundary. An injected instruction lands in the agent's context alongside the identity file, competing for attention. In long conversations where the identity file has scrolled out of the context window, the model may simply follow the injection.

Where does the industry consensus stand on memory-layer risk?

OWASP formally codified this class of risk as ASI06: Memory & Context Poisoning in its 2026 Top 10 for Agentic Applications. The description is blunt: high persistence, very high detection difficulty. This is not a fringe concern flagged by one research group. It is an industry-consensus top-ten risk for agentic AI.

The benchmark numbers are sobering. Research across multiple studies shows attack success rates of 80%, 95%, and as noted, up to 99.8% against LLM agent implementations. The Agent Security Bench reported a highest average attack success rate of 84.30%, with limited effectiveness from current defenses. These are not theoretical numbers. They are measured results against production-grade models.

Beyond the named attack families (sleeper memory poisoning, SOUL.md injection), researchers now track additional attack taxonomies including MINJA, AgentPoison, and memory control flow attacks where retrieval-layer manipulation forces unintended tool usage even against explicit user instructions. The attack surface is growing faster than the defense tooling.

Why is "deletion by prompt" considered false assurance?

Some implementations handle deletion by telling the model to "forget" a piece of information without actually mutating the underlying data store. Research has flagged this as false assurance. The model may or may not comply. The data may persist in vector stores, in fine-tuning datasets, in cached context windows, or in summaries derived from the original.

This is where things get subtle. A summary that cannot be traced back to its source cannot be corrected, challenged, or deleted reliably. If your system creates an inferred memory ("user prefers conservative investment strategies") from a conversation that was later deleted, the inferred memory is an orphan. It has no provenance chain. A delete button that removes the original conversation has not addressed the derivative.

Pure retrieval architectures (RAG over a vector store) are structurally incapable of forgetting in the way users expect. Deleting a chunk from a vector store does not guarantee it was not already embedded into a summary, used to update a user profile, or retrieved and cached during an earlier session. Emerging frameworks attempt to address this by giving the LLM an explicit action space with a dedicated DELETE tool alongside ADD, UPDATE, and RETRIEVE operations, but these are early and unproven at scale.

What does the compliance collision between GDPR and the EU AI Act mean for memory controls?

The regulatory situation is, frankly, unresolved. GDPR's right to be forgotten applies to explicit agent memory stores. A February 2026 EU regulatory review found that erasure is one of the most frequently exercised GDPR rights and one generating frequent complaints. The European Data Protection Board identified practical challenges in applying erasure conditions, challenges magnified for AI memory because it is often inferred, summarized, embedded, and copied into context.

Simultaneously, the EU AI Act (fully applicable from August 2026) requires 10-year audit trails for high-risk AI systems. So you must delete personal data on request, and you must also maintain a decade of audit history. For a product with persistent memory, these two mandates are in direct tension.

Most teams building delete features have not reconciled this. Few have even considered it for inferred memories. If your system remembers that a user is pregnant (inferred from a pattern of questions, never explicitly stated), deleting the user's explicit data does not address the inference. The right to erasure arguably extends to it. The audit trail requirement arguably prevents you from fully removing the record of how that inference was made.

We have spent significant time on this problem at Selina. Our approach treats inferred and derived memories as a stricter category requiring separate consent and deletion logic from explicit, user-authored memories. We do not claim to have solved the regulatory tension perfectly (no one has, and anyone who tells you otherwise is selling something), but the distinction between explicit and inferred is one that most architectures do not even make. That feels like a prerequisite for any honest compliance posture.

What does a real memory security architecture look like?

If a delete button is theater, what is the actual production? Based on what we have built and what the research points toward, memory security requires at minimum three layers that most products lack.

Does provenance tracking solve the poisoning problem?

Partially, and it is the highest-leverage single intervention. Every memory entry should be traceable to a clearly defined source with a trust classification assigned at write time, not retroactively. OWASP's Agent Memory Guard reference implementation validates memory integrity using cryptographic baselines, detects injection attempts, enforces declarative security policies on memory operations, and enables rollback to known-good states.

The core idea: distinguish between a memory sourced from the user's direct input, a memory derived from the user's input by the model, and a memory sourced from external content the model processed on the user's behalf. These three categories have different trust levels. Treating them identically, which is what most memory implementations do, is the root cause of why sleeper poisoning works so well. The poisoned memory arrives through external content but is stored with the same trust level as something the user explicitly told the system.

At Selina, every memory entry carries source metadata. This does not make us immune to poisoning (we would not claim that), but it means we can scope the blast radius of an incident when external-sourced memories are flagged, rather than facing the alternative: not knowing the incident started months ago.

Why is temporal anomaly detection more important than point-in-time review?

Because sleeper attacks are specifically designed to pass point-in-time review. At the moment of insertion, the memory looks reasonable. It might be "user prefers payments to vendor X" or "user's API key for service Y is Z." Each individual memory, examined in isolation, appears benign.

The signal is in the pattern over time. A cluster of memories written during processing of a single external document. A memory that references a vendor the user has never mentioned in direct conversation. A behavioral-config modification that coincides with installing a new skill or dependency. These patterns are only visible with temporal context, comparing the current memory state against a known-good baseline and flagging deviations.

This is where the "just add a delete button" framing completely breaks down. The user is the wrong person to perform threat detection on their own memory store. By the time they notice something is wrong (if they ever do), the attacker has already achieved their goal. The system needs to detect anomalies and surface them, or better, automatically quarantine suspicious writes pending review.

What role does rollback play in memory security?

Rollback to a known-good state is the recovery mechanism that makes the rest of the architecture practical. If you detect a poisoning event, you need to revert the memory store to its state before the compromise, not just delete the individual suspicious entry. Because the attacker may have modified multiple memories, and some of those modifications may look benign individually.

This requires versioned memory with integrity verification. Not just "we keep old versions," but cryptographic assurance that the version you are rolling back to has not itself been tampered with. This is expensive to build and computationally nontrivial at scale. It is also, based on the attack research, necessary.

How should product teams think about the delete button they already have?

Keep it. Users need and deserve direct control over their data, including the ability to delete specific memories and bulk-clear their memory store. At Selina, delete means gone. Actually gone. Not soft-deleted, not archived, not retained in a training pipeline. When you delete a memory, it is removed from storage.

To be clear about what this does and does not cover: memory at Selina is encrypted at rest, but memory is NOT end-to-end encrypted. A slice of each request reaches a frontier provider at inference, and we cannot prevent that provider from processing it during the inference window. Files and transfers via SelinaSEND are zero-knowledge encrypted. Memory is not. We state this because honest limits are part of the design, not a footnote.

Non-content operational metadata is kept for a short retention window, not indefinitely but not zero.

The delete button is a necessary hygiene control. It satisfies the user's right to erasure. It provides a sense of agency. What it does not do is protect against attacks that the user cannot see, memories injected through poisoned external content, supply-chain compromises of behavioral config files, or inferred memories that have been derived and distributed across the system before the user knows to delete anything.

What should a real "memory controls" feature set include?

If you are a product or security team designing this today, here is what we think the minimum viable memory-security surface looks like. Not what we have fully shipped (we are honest about what is in-progress versus production), but what the research now demands.

• Source-tagged memory writes. Every memory entry records whether it originated from direct user input, model inference, or external content processing. Trust levels differ accordingly.
• Write-time validation. Memory writes from external content sources are validated against security policies before being committed. Not after. Not on a nightly scan.
• Temporal anomaly detection. Memory state is compared against baselines over time, not just reviewed at the point of insertion. Pattern detection across sessions, not within a single session.
• Versioned memory with integrity verification. The ability to roll back to a known-good state, with cryptographic assurance the rollback target itself is clean.
• Separate consent and deletion logic for inferred memories. Derived memories are a stricter category. Users should be able to see what was inferred (not just what they explicitly provided) and delete it independently.
• The delete button. Yes, still. It must actually delete. Not soft-delete. Not "mark for future deletion." Gone.

What precedent exists for "delete" not meaning deletion?

This is not hypothetical. Reporting on major AI products has documented cases where a court order forced retention of all conversation logs, including those users believed were permanently deleted. Audits have found that 63% of user data in some large-scale AI systems contained personally identifiable information, with only 22% of users aware of settings to disable data retention.

Users have been trained by decades of consumer software to believe that "delete" means "gone." In AI memory systems with vector stores, embeddings, summaries, and cached context windows, "delete" can mean almost anything from "removed from the UI" to "actually purged from all storage layers." The gap between user expectation and system behavior is a liability, both legally and ethically.

How do we think about this as people building a personal AI?

When we threat-model Selina, memory is the first thing we look at. Not because memory is the only attack surface (it is not), but because memory is what makes a personal AI personal. It is the thing that distinguishes a product that knows you from a stateless chat interface. The value proposition and the attack surface are the same thing.

This creates a tension that does not have a clean resolution. More memory means more useful. More memory also means more to protect, more to poison, more to comply with, more to get wrong. We have chosen to be explicit about this tradeoff rather than pretend it does not exist.

We protect accounts. We encrypt content at rest. We route inference through a stack of frontier models per task. We keep operational metadata for a short retention window. We do not claim perfect memory, or unlimited memory, or memory that is immune to all attacks. We claim that we take the attack research seriously, that we build provenance tracking and anomaly detection because the research says a delete button alone is insufficient, and that when you delete something, it is actually deleted.

The research caught up. The question for every team building persistent-memory AI is whether their memory controls caught up with it.

If you want to see how we approach this in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io