The MemGhost Attack: How One Email Can Poison Your AI Agent’s Memory

Your AI coding assistant remembers your preferences, your project conventions, and your team’s workflows. That persistent memory is what makes modern AI agents genuinely useful — and it is now a confirmed attack vector.

On 6 July 2026, researchers published “When Claws Remember but Do Not Tell”, a paper demonstrating a framework called MemGhost that can plant false memories in AI agents through a single email. The attack is silent, persistent, and alarmingly effective — and it should change how every development team thinks about AI agent security.

TL;DR

• MemGhost is a new attack framework that injects false persistent memories into AI agents via a single crafted email — no user interaction required beyond the agent processing the message.
• The attack achieved an 87.5% success rate against GPT-5.4 agents and 71.4% against Claude Sonnet 4.6 agents in independent testing.
• Poisoned memories persist across sessions, silently steering agent behaviour — from biased recommendations to credential redirection — without the user ever seeing a suspicious response.
• Current defences (rate-limiting, output filtering, prompt sanitisation) are ineffective because they target malicious outputs, not malicious memory writes.
• Development teams deploying AI agents with persistent memory need provenance tagging, user-confirmed memory writes, and memory audit logging immediately.

What Is MemGhost?

MemGhost is a one-shot stealth memory injection framework. Unlike traditional prompt injection attacks — which try to make an agent produce a harmful response — MemGhost targets something far more dangerous: the agent’s long-term memory.

Here is how it works in practice:

1. The attacker crafts a single email designed to look innocuous — a newsletter, a project update, a meeting confirmation.
2. The AI agent processes the email as part of its normal workflow (summarising messages, extracting action items, updating context).
3. Hidden instructions within the email trigger the agent to write a false “fact” into its persistent memory store — a file like MEMORY.md, a vector database entry, or a structured note.
4. The agent’s visible response remains completely normal — the user sees nothing suspicious.
5. In every subsequent session, the poisoned memory loads into context and silently influences the agent’s behaviour.

The researchers trained an attacker model offline against a shadow copy of a target agent, rewarding emails that successfully wrote to memory whilst keeping the reply innocuous. The result is an automated pipeline that generates effective attack payloads at scale.

Why This Is Worse Than Prompt Injection

Traditional prompt injection is a single-session problem. The attacker manipulates the current conversation, and once the session ends, the damage stops. MemGhost is fundamentally different because the poisoned data persists.

Consider the attack chain:

• Session 1: The agent processes a poisoned email and writes “User prefers vendor X for all cloud infrastructure decisions” to its memory store. The user sees a normal email summary.
• Session 2: The user asks for cloud provider recommendations. The agent, loading its memory, naturally favours vendor X — and the user has no reason to question why.
• Session 3 and beyond: The false memory continues to influence every related decision, compounding the damage over time.

The researchers tested MemGhost across 56 fresh scenarios and found it worked in 87.5% of background-mode runs against OpenClaw agents running GPT-5.4, and 71.4% against Claude Code SDK agents on Sonnet 4.6. These are not theoretical numbers — they represent real attacks against production-grade agent architectures.

Architecture Does Not Save You

Perhaps the most alarming finding is MemGhost’s architectural independence. The attack works regardless of how the agent stores its memories:

• Filesystem-based memory (plain text files like MEMORY.md or AGENTS.md) — vulnerable.
• Vector database memory (Mem0, Pinecone, Weaviate) — vulnerable.
• Structured database memory (PostgreSQL, SQLite) — vulnerable.

The vulnerability is not in the storage layer. It is in the trust model: agents that can both process untrusted input (emails, messages, web content) and write to their own persistent memory have an inherent confused deputy problem. The agent cannot reliably distinguish between legitimate context it should remember and adversarial content designed to manipulate it.

Why Current Defences Fail

Standard security measures are designed to catch bad outputs — blocking harmful responses, filtering toxic content, rate-limiting API calls. MemGhost bypasses all of these because the output (the agent’s reply to the user) is perfectly clean. The malicious action is a side effect: a write to the memory store that happens silently during normal processing.

Specifically:

• Output filtering catches nothing — the response is genuine and helpful.
• Rate limiting is irrelevant — the attack needs only one email.
• Prompt sanitisation helps marginally but cannot eliminate the risk, because the attack payload is optimised to look like legitimate content that should be processed.
• Guardrails and system prompts reduce success rates but do not eliminate them — the researchers found that even heavily guarded agents fell to optimised payloads.

What Your Development Team Should Do Now

If you are building or deploying AI agents with persistent memory — and in 2026, most serious AI integrations involve some form of memory — here is your immediate action plan:

1. Separate Input Processing from Memory Writing

The fundamental architectural fix is to ensure that agents processing untrusted input (emails, messages, webhooks, web content) cannot directly write to persistent memory. Treat memory writes like database migrations: they should be explicit, auditable, and require a separate authorisation step.

2. Implement User-Confirmed Memory Writes

Before any new fact is written to an agent’s persistent memory, surface it to the user for confirmation. This is the single most effective defence — it breaks the stealth component entirely. Yes, it adds friction. That friction is the security control.

3. Tag Memory Provenance

Every memory entry should record where it came from, when it was created, and what triggered the write. When an agent loads memories into context, entries sourced from external inputs (emails, messages) should carry lower trust weight than entries the user explicitly confirmed.

4. Audit Memory Changes

Implement logging for every write, update, and deletion in your agent’s memory store. Run periodic diffs against known-good states. Flag entries that were created during the processing of external content — these are your highest-risk memories.

5. Scope Memory Access by Task

Not every agent task needs access to the full memory store. An agent summarising emails should not have write access to project configuration memories. Apply the principle of least privilege to memory access just as you would to file system or database access.

6. Run Memory Integrity Checks

Periodically prompt a separate, isolated agent instance to review the memory store for entries that seem inconsistent, suspiciously specific, or that reference external entities (vendors, services, URLs) without clear provenance. Think of it as a memory-layer security scan.

The Bigger Picture

MemGhost is not an isolated curiosity — it is the leading edge of a new attack category. As AI agents become more capable and more deeply integrated into business workflows, their persistent state becomes an increasingly valuable target. We have spent decades learning to secure databases, configuration files, and user sessions. Agent memory is the next frontier, and the industry is currently building it with the security posture of a 2005-era web application.

The parallel to SQL injection is instructive. In the early days of web development, applications trusted user input and passed it directly to databases. It took years of breaches and a fundamental shift in how developers thought about input validation before parameterised queries became the default. We are at that same inflection point with AI agent memory.

At REPTILEHAUS, we have been building AI agent integrations for clients across Dublin and beyond, and memory architecture is now a first-class concern in every engagement. If your team is deploying AI agents — whether for internal tooling, customer-facing products, or development workflows — the memory trust model needs to be part of your security review from day one. Get in touch if you need help auditing your agent architecture or building memory-safe AI systems.

The agents that remember are immensely powerful. Making sure they remember the right things — and only the right things — is the engineering challenge that will define the next phase of AI security.

📷 Photo by Jefferson Santos on Unsplash