Treat an AI agent's memory as a separate security surface: label the provenance of every memory, separate user instructions from external documents and emails, require explicit confirmation for sensitive memory writes, and log writes, reads and deletions. According to the Cloud Security Alliance, a single email can already plant a persistent false memory.
On 23 July 2026 the AI Safety Initiative of the Cloud Security Alliance published a research note on MemGhost, an attack that can plant a persistent false memory in an AI agent through a single specially crafted email. The tainted memory then persists and can influence the agent's behaviour in a later session, even when the original email is no longer visible. The Cloud Security Alliance reports high end-to-end success and stealth rates in the cited evaluations, but itself stresses that the samples per condition are modest and the figures should be read as indicative.
In our assessment that is the crux: the critical moment lies not in the answer the assistant gives to that one message, but in the transition from untrusted external content to trusted, persistent state. Anyone who assesses memory only on storage privacy misses that transition entirely.
Why is memory poisoning a different problem from ordinary prompt injection?
Ordinary prompt injection primarily targets the agent’s current context or behaviour, whereas memory poisoning additionally writes to persistent state, allowing the influence to carry into later sessions. With memory poisoning the attack changes the agent's persistent state. Two academic studies underpin that distinction.
The study From Untrusted Input to Trusted Memory introduces a taxonomy of four memory-write channels and nine structural vulnerabilities. The authors report an average attack success rate of 50.46 per cent and a retrieval success rate of 41.05 per cent across the agents studied. According to their analysis, existing prompt-injection defences do not fully cover memory poisoning. The study Hidden in Memory examines sleeper memory poisoning, where an attacker manipulates external documents, web pages, emails or repositories so that a fabricated memory is stored. According to that study, successful injected memories influenced the behaviour the attacker wanted in 60 to 89 per cent of cases in later agentic evaluations; the authors themselves report limitations, including partly reconstructed provider configurations and the use of an LLM judge for some measurements.
The practical difference in one line:
- Prompt injection tries to influence the agent's current context or current behaviour; memory poisoning additionally writes to persistent state, so the influence can carry through into later sessions.
- Memory poisoning writes to persistent state and carries through into later sessions.
- According to the authors, the studies show that existing prompt-injection defences do not fully cover memory poisoning; Hidden in Memory further warns that prompt-based defences remain model-dependent and vulnerable to adaptive attacks.
That makes memory an attack surface of its own, not a detail of input filtering. It belongs to the broader question of AI security and security surfaces, and connects to the idea of treating least privilege as a runtime control for AI agents.
Does server-side memory with encryption and enclaves solve this?
Providers are actually trying to make persistent memory privacy-friendly. On 23 September 2026, Google DeepMind described an architecture for persistent memory across multiple devices, in which personal data is processed in encrypted storage within hardware-isolated cloud enclaves. According to that announcement, cryptographic keys remain solely on personal devices, data is re-encrypted after processing, and tamper-proof software attestation, a technical whitepaper and an independent audit are named as verification mechanisms.
That addresses the question of who can decrypt the stored memory data. In our assessment it does not address whether what is remembered is correct in substance and whether the storing was authorised in the first place. Encryption and enclaves protect the storage; they do not judge the trustworthiness of the content. An encrypted false memory remains a false memory.
From this follows our central editorial proposition: memory functions require two separate controls.
- Infrastructure privacy of stored memory: encryption, key management, isolation and demonstrable deletion.
- Integrity control over what may be remembered: provenance, authorisation and separation of external content.
Which controls belong with an AI agent's memory?
The recommendations of the Cloud Security Alliance and the two studies point in the same direction: memory provenance, explicit user confirmation, logging of every change, and separation between reading external content and writing to memory. Translated into a workable checklist for professionals with sensitive information:
- Label the provenance of every memory record, so that externally derived memories remain recognisable.
- Strictly separate user instructions from external documents and emails; do not automatically treat incoming content as trusted context.
- Require explicit confirmation before sensitive or action-oriented memories are stored.
- Log writing, reading, changing and deleting of memory as separate events.
- Quarantine externally derived memories until they have been checked.
- Test whether retrieving a memory does not trigger unauthorised actions.
The sources cited provide the figures, but also report their limitations: modest samples, partly reconstructed configurations and model-dependent defences. In our assessment that is no reason to postpone the measures, but it is a reason to treat them as management controls that must be tested and logged, not as conclusive proof. Provenance control and approval on writing can be checked; the reported attack success rates cannot be, without your own validation.
In practice this means that memory writes deserve the same treatment as other sensitive agent actions. Anyone who already gives AI agents their own identity with logged authorisation extends that log to memory. And when a tainted memory does later steer behaviour, it helps to capture incident response across the whole AI chain in advance, so that the write and read route remains traceable and a faulty memory can demonstrably be corrected or removed.
Sources and references
Sources: The article draws on the Cloud Security Alliance's MemGhost note, the arXiv studies From Untrusted Input to Trusted Memory and Hidden in Memory, and Google DeepMind's architecture announcement.