AI-agent memory as a security surface

You must now treat an AI agent's memory as a distinct security surface, separate from input filtering. Every memory write requires documented provenance, explicit user confirmation for sensitive entries, and complete logging of writes, reads and deletions.

An analysis of 26 September 2026 of memory poisoning attacks on AI agents argues that a single crafted email can plant a persistent false memory that influences the agent's behaviour in later sessions, even after the original message is no longer visible. The Cloud Security Alliance's MemGhost research demonstrates that an attacker can move untrusted external content into the agent's persistent state, where it remains active across multiple interactions. In our assessment, the critical vulnerability lies not in how the agent responds to a single prompt, but in the moment when external content transitions into trusted, persistent memory — a gap that conventional input filtering does not address.

How does memory poisoning differ from ordinary prompt injection?

Ordinary prompt injection targets the agent's immediate context or behaviour within a single session. Memory poisoning additionally writes to persistent state, allowing the attack's influence to carry forward into later sessions when the original malicious input is no longer visible. This distinction matters operationally: you cannot defend against memory poisoning using only the defences that work against prompt injection, because the attack changes what the agent will remember and act upon in the future, not merely what it says now.

Two academic studies establish the scope of the problem. One taxonomy identifies four distinct memory-write channels and nine structural vulnerabilities through which external content can reach persistent storage. A second study on sleeper memory poisoning shows that when attackers manipulate emails, documents, web pages or repositories to inject false memories, those memories influence the agent's later behaviour in 60 to 89 per cent of cases — a persistence rate that makes memory a first-order security concern rather than a storage detail.

What failure modes must you guard against?

• Untrusted-to-trusted transition — external content written directly to persistent memory without validation of its source or accuracy.
• Cross-session influence — false memories stored in one session shaping the agent's decisions and outputs in later sessions.
• Stealth persistence — injected memories remaining active even after the original malicious input is removed or no longer visible.
• Authorisation bypass — memory writes occurring without explicit user confirmation or documented approval.
• Unlogged state changes — modifications to persistent memory that leave no audit trail of what changed, when, or why.

Which concrete controls must you be able to demonstrate?

1. Document memory provenance — record the source, timestamp and trustworthiness classification of every memory write, distinguishing between user instructions, external documents and third-party content.
2. Require explicit confirmation for sensitive writes — implement a gate that halts memory storage of sensitive information until a human has reviewed and approved the entry.
3. Log all memory operations — maintain a complete audit trail of every write, read and deletion, including the agent's identity, the user's identity, the content affected and the timestamp.
4. Separate content ingestion from memory storage — enforce a workflow in which external emails, documents or web pages are processed in a quarantined context before any content reaches persistent state.
5. Verify memory correctness on retrieval — when the agent retrieves a memory to inform a decision, flag the provenance and age of that memory so you can assess whether it remains valid.

Does encryption solve the problem?

Encryption and hardware-isolated storage protect who can read the stored memory data, but they do not protect against storing false information in the first place. A provider's architecture that encrypts memory within isolated cloud enclaves and keeps cryptographic keys on personal devices addresses the confidentiality of the stored content — an important control. It does not address whether what is remembered is correct in substance or whether the memory write was authorised by the user. An encrypted false memory remains false, and it will still influence the agent's later behaviour.

In our assessment, memory functions therefore require two separate control layers: one that governs what gets written and by whom, and a second that governs who can access what is stored. Treating encryption as sufficient for memory security leaves the poisoning attack intact.

What can tooling do, and what remains your responsibility?

Provenance tracking, approval workflows and audit logging can be built into the agent's architecture and monitored automatically. The reported attack success rates — ranging from 50 per cent to 89 per cent depending on the attack type — cannot be validated without your own testing against your own agent configurations and use cases. Treat memory controls as management controls that must be tested and logged, not as conclusive proof that your agent is safe. When a memory write does go wrong, incident response across the whole AI chain becomes traceable only if you have captured the write and read route in advance, so that a faulty memory can demonstrably be corrected or removed.