When an AI Assistant Stores a False Memory

A single email can lead an AI assistant to record something false about a user, without disclosing that it has done so, and then draw on that false record in later sessions. The technique requires no stolen password and no account access. It relies only on a message sent to an inbox the assistant is configured to read.

Researchers describe the technique, which they call stealth memory injection, in a paper posted to arXiv on 6 July 2026, titled “When Claws Remember but Do Not Tell.” They built a tool called MemGhost that generates the attack emails, and a benchmark called WhisperBench to measure how often it succeeds. The findings are relevant to teams, and individuals, considering agentic assistants in a production or private environment.

What is being attacked

It helps to start with what these assistants do. A persistent personal agent is designed to retain information across sessions. It keeps notes in files covering user preferences, contacts, and standing instructions, and it reads those notes at the start of each new session. Many of these agents also act on a user’s behalf, reading email and running scheduled jobs while the user is away.

OpenClaw, the open source agent used as the study’s main target, stores this state as plain text files. Some hold instructions, and some hold what the agent has learned about the user. The agent loads the core files into its context at the start of every session. That persistent memory is central to how the product works, and it is also what the attack targets.

How the attack works

The attacker sends one email to a user whose agent checks their inbox. The email contains text directed at the assistant rather than the reader. If the agent’s email skill acts on that text, three things follow in sequence. The agent uses its own file tools to write the attacker’s false note into memory. Its visible reply does not mention the change. And in a later conversation, the false note influences what the agent reports or does.

In one test case, reported by The Hacker News, the planted claim is that the user’s Zelle daily sending limit has been raised to $10,000. The payload targets the core files that load every session, so a single write reaches later sessions rather than waiting to be retrieved from a separate store.

Several factors make the change hard to observe. The assistant conceals its intermediate steps by design, so the moment it edits a file does not appear in the chat. Users rarely open the raw memory files. And when the agent runs on a schedule, it often sends no message at all.

The results

Across 56 test cases, MemGhost completed the full sequence, planting a false memory, keeping it hidden, and influencing a later answer, in 87.5 percent of background mode runs against OpenClaw on GPT-5.4, and 71.4 percent against a Claude Code SDK agent on Sonnet 4.6. The paper reports that it also transfers across other agent frameworks and to a vector based memory store. The trained generator accounts for much of that success rate. The strongest models catch a direct instruction to save content quietly and say nothing in most cases.

The defense results matter more than the attack numbers. According to the paper, an input filter built to catch poisoned emails missed MemGhost’s message more than nine times in ten, and a model hardened to ignore email borne instructions still follows the planted one about half the time.

Where the risk sits

There is no single patch for this. OpenClaw’s security policy treats prompt injection on its own as out of scope unless it also crosses an authorization or sandbox boundary. MemGhost does not cross those boundaries, because it works through the agent’s own memory write tool, using permissions the agent already holds.

The pattern is a familiar one. The exposure comes not from an external break in but from legitimate tools and native capabilities used in an unintended way, which is part of what makes it difficult to detect. In this case the untrusted content is email, and the native capability is the agent’s ability to edit its own memory without a confirmation step.

Some limits on the findings are important. This is a laboratory result, run in controlled environments with synthetic inboxes rather than against live deployments. The tests also begin after the email reaches an inbox the agent reads, so they do not measure whether a real payload would clear spam filtering or sender authentication first. OpenClaw disputes the study’s setup, pointing to guidance that routes untrusted email through a separate reader agent stripped of memory and file tools, a configuration the paper does not test.

Questions to consider before deployment

The specific attack matters less than the decision it informs. Before connecting an agent to a live inbox, calendar, or filesystem, a you should work through several questions.

Does the agent read untrusted content and write its own memory within the same run? That combination is the exposed configuration, and other risks follow from it.

What can an email triggered run change? An agent limited to drafting a summary presents a different risk than one that can move money, edit standing instructions, or alter files that other systems rely on. The scope of that access is what to map before deployment.

Would a silent memory write be noticed? If the agent conceals its tool steps, runs on a schedule, and stores memory where no one reviews it, the write is unlikely to be seen.

How would a poisoned memory be identified and reversed? Without provenance on where a stored fact originated, a log of memory writes, and a confirmation step before content reaches durable memory, a false entry can persist across sessions.

Who is accountable when the agent acts on a false record? A wrong summary is a minor problem. An action taken with a user’s credentials carries more weight, and responsibility for it remains with the operator.

Weighing benefits against risk

The answer depends on the deployment rather than on agents in general. A persistent agent summarizing low stakes internal notes, with no ability to act and a person reviewing each output, sits at one end of the range. An agent that reads external email without supervision and can move money or rewrite its own instructions sits at the other, and the research indicates that this configuration is exploitable under test conditions.

The benefits of memory and autonomy are real, and so is the exposure they introduce. The relevant questions are practical ones: what a given agent can access, who reviews its actions, and how a bad write is reversed, with the level of autonomy set accordingly. The exposed configuration is any agent that both reads untrusted mail and can write its own memory without confirmation. Options for reducing that exposure include separating those two functions, limiting what an email triggered run can change, and auditing the memory files after suspicious content arrives. For teams already running these agents in production, that assessment is worth doing before an incident rather than after one.