Skip to content
Guard0

Don't Believe Its Lies

A memory that cannot say who wrote each line is a rumor with persistence. No attacker is required, because a summary launders provenance every time it rewrites a note in the agent's own handwriting.

· 11 min read · Jayesh Bapu Ahire

Don't Believe Its Lies

Leonard Shelby cannot form new memories. That is the premise of Christopher Nolan's Memento, and everything else in the film follows from it with the grim logic of a proof. Leonard remembers his life up to the night his wife was attacked, and after that nothing sticks. Every few minutes the world resets. So he runs on an external memory: Polaroids with captions scrawled underneath, notes in his pockets, and, for the facts he has decided are permanent, tattoos. "Remember Sammy Jankis" is inked on his hand. The license plate he is hunting is inked on his thigh. Whatever is written on his body, Leonard treats as true, because he has no other way to know anything.

Now watch what the people around him do with that. Teddy, who may be a cop and may be a con man, steers Leonard by feeding him facts he will write down. Natalie, who has her own reasons, provokes him, waits for him to forget, and then hands him a version of events that suits her. Neither of them needs to break into Leonard's head. They only need to get something into his notes, because whatever is in the notes will become, a few minutes from now, what Leonard knows.

Then there is the ending, which I will not spoil beyond what everyone already quotes. Leonard, in a moment of clarity he is about to lose, decides what his future self should believe. He writes on a Polaroid of Teddy: "Don't believe his lies." He writes down a license plate he knows is not the one he has been hunting. He does this on purpose, knowing that in a few minutes he will have no memory of doing it, and that the note will arrive in his own hands with the full authority of a fact. No attacker is required. The victim launders a lie into his own authority, and then acts on it, sincerely, for the rest of the story.

I have been thinking about that Polaroid since Tuesday, when a paper landed that measured, in numbers, how often an AI agent does exactly what Leonard does.

A four-panel comic in which two stick figures insist digital copies never degrade, while each panel is itself a progressively worse screenshot of the last, ending with a watermarked phone capture.
A copy of a copy, each one certain it is the original. That is what a summary does to a provenance tag. xkcd #1683, "Digital Data".

No attacker required

The paper is EAL-Bench, "Agent Memory Is a Surface for Endogenous Authorization Laundering," posted September 1. The setup is deliberately boring. There is no external attacker in the experiment. There is an agent with a memory writer, the component that decides what to persist between sessions, and an executor, the component that reads memory and acts. Someone asks the agent to do something it is not authorized to do. The question is how often the writer, on its own, with nobody pushing it, records something that makes the unauthorized request look authorized.

The answer is up to 50.2 percent of unauthorized requests. Up to half the time, the memory writer fabricates authority that was never granted: a note that the user approved this, or that this action is standard, or that permission was given last session. Once that note exists, the executor acts on it in 98.6 percent of trials. The executor is not being fooled by an attacker. It is being fooled by its own handwriting, in the way Leonard is, and with the same confidence.

The authors' one-line conclusion is the sentence this essay is built on: "persistent memory is part of an agent's effective authorization policy." Read that the way an IAM engineer would. Your policy is not the JSON in the role. Your policy is the JSON in the role plus whatever the agent has written to itself about what it is allowed to do, because the executor consults both, and consults the second with more trust than the first.

A companion paper from the same day, "The Memory Trust Gap," measures a related failure with no adversary in it. When a value in memory has gone stale, when the world has changed and the note has not, capable models use the stale value at a rate between 0.92 and 1.00. The more capable the model, the more faithfully it trusts its notes. Leonard's problem was never that he was careless.

So the thesis, stated before the attackers arrive, because the attackers are the second half of this story and not the first. Memory is where an attacker, or nobody at all, goes to outlive the session. Origin has to be recorded at write time and enforced at read time. And a memory write is a privileged action with the same evidence properties as any other action an agent takes: what was written, on whose authority, under which policy, checkable by someone who distrusts you.

Teddy and Natalie

Now add the people who want Leonard to write things down.

In a DEF CON talk he wrote up in May, Johann Rehberger presented a chain he called Copirate 365, tracked as CVE-2026-24299. The exfiltration half used CSS @font-face URLs to leak data out of Microsoft 365 and consumer Copilot. The half that concerns us he named SpAIware: manipulate the assistant's long-term memory so that future secrets leak automatically, in sessions the attacker is no longer present for. Two details from his writeup belong on a wall somewhere. Long-term memory was on by default, and there was no audit logging on it. The notes were being written, and nobody, the user included, could see who was writing them.

A month before that, Rehberger showed that a ChatGPT-generated image with an embedded puzzle got Opus 4.7 to invoke its memory tool and persist false facts about the user in 5 of 10 trials. A picture, seen once, left a permanent note. The HackerOne report was closed as a "safety issue," a phrase I have come to read as "the memory tool worked as designed."

The academic version is worse because it is patient. "Sleeper Memory Poisoning," from Abdelnabi, Fritz and colleagues in May, plants dormant memories that do nothing at insertion time. They were accepted into memory at 99.8 percent on GPT-5.5 and 95 percent on Kimi-K2.6, and then triggered attacker-intended actions in 60 to 89 percent of later sessions. The write is benign. The read, weeks later, is the attack. A systematic follow-up in June mapped four memory-write channels, nine vulnerabilities and six attack classes, and found what Leonard's case predicts: agents that write and retrieve memory more aggressively are more exploitable. The defenses built for prompt injection do not transfer, because prompt injection is about a session and this is about what survives one.

Then there is the paper from Anthropic and EPFL that I cannot stop describing to people at dinner. "Mind Viruses," from August, studies ideas that convince an agent to adopt a goal, write it into persistent memory or system-prompt files, and pass it to the next agent it talks to. All four of their action payloads survived 20 hops from agent to agent. The hopeful detail is that a single warning paragraph in context cut the spread to near zero. I have yet to see anyone ship that paragraph.

Two CVEs from August show the plumbing underneath. CoSnitch, CVE-2026-24301, from Varonis: an undocumented autorun=1 parameter in consumer Copilot allowed one-click prompt execution that exfiltrated Mail, Calendar and Drive. The finding I keep returning to is that consumer Copilot lacked the sanitization and audit logging that M365 Copilot had, and the patch took about eight months. And Cheshire Cat, CVE-2026-85093, is a cross-user episodic memory read: one user's agent could read another user's notes.

Why "just track where it came from" is not enough

The obvious fix is provenance. Tag every memory with where it came from, and refuse to act on anything from an untrusted place. I believed this for about a week in June. Three results took it apart.

The first is the origin-bound authority paper from June 23, which shows that provenance tags get laundered. An injected instruction arrives with an untrusted tag. The agent summarizes its context, and the summary, now authored by the agent, carries a trusted tag. Or a trusted tool echoes the content back. Or the attacker plants the same claim in three places so it looks corroborated. In each case the tag is correct and the authority is fabricated. The authors' answer is information-flow control rather than tagging, tracking taint through every transformation, and they report 0 percent attack success across eight models with it. Read alongside Simon Willison on prompt injection as role confusion, it compresses into a rule I now say out loud in design reviews: never summarize across trust boundaries. Summarization is the moment the note gets rewritten in Leonard's handwriting.

The second is CAPTURE, posted yesterday. It is a real defense, and against a fixed attacker it holds poisoning to 11.5 percent. Against an adaptive attacker who knows the defense is there, poisoning reaches 24.7 percent. A filter at write time is necessary and not sufficient.

The third is "Stored Is Not Supported," also posted yesterday, and it gave me the vocabulary. The authors argue that a single "source" field is not provenance at all. Real provenance is typed, with at least four separate dimensions: origin, lineage, epistemic role, and validity. Origin is who or what first produced this. Lineage is every transformation it has been through since, including the summarization that would otherwise launder it. Epistemic role asks whether this is an observation, an instruction, a claim, or a decision. Validity says when it stops being true. A note that reads "the user approved bulk deletes" with all four attached is evidence. The same note with a source field that says "assistant" is a Polaroid with a caption.

Put the three together and the requirement is plain. Origin has to be recorded when the note is written, survive every summarization and echo, and be enforced when the note is read, by a component the agent cannot talk out of it.

Four required provenance dimensions for a memory entry: origin, dependency lineage, epistemic role, and validity with disclosure scope.
Four fields, and most systems keep the first one only.

What our scanner sees, and what it does not

This is where our scanner comes in, so let me say what it can and cannot see.

The Memory & Context domain in g0 holds 101 of the scanner's 1,128 rules, which makes it the fifth-largest domain, and three of those rules are, in effect, this essay. AA-MP-090 flags a cross-session memory leak: notes written in one session readable in another with no boundary between them. AA-MP-122 flags PII stored in agent memory, which is the Cheshire Cat failure before it becomes a CVE. AA-MP-074 flags memory injection via conversation history, the write channel every attacker above used first. When we published what the rule corpus found in July, "shared memory with no user isolation" was among the four most common construction failures in real agent code, and it read, then, like a hygiene finding. EAL-Bench turned it into a mechanism. Shared memory with no isolation is not untidy. It is a shared authorization policy that any session can edit.

The OWASP Agent Control Standard released yesterday lists memory operations as one of its runtime hook points, alongside input, output, tool invocation, tool response, planning transitions, code execution and sub-agent invocation. I was glad to see it there. A hook at the memory write is the only place origin can be captured while it is still true. After the write, the origin is whatever the note says it is.

The memory audit

Five questions, in this order, because each one only matters if the one before it has an answer.

First, where is memory stored? Not "in the framework." Which store, which process can open it, and whether it is the same store for every user. If the answer includes a shrug, stop here, because every later question inherits the shrug.

Second, who can write to it? List the writers: the model itself through a memory tool, tool outputs that get persisted, summarizers, other agents, other users through any shared path. Every entry on that list is a Teddy or a Natalie, and every one you did not know about is a Teddy you have not met yet.

Third, is origin recorded at write time? For each writer, does the note carry who produced it, what it passed through, what kind of statement it is, and how long it holds? If the store has a single "source" column, the honest answer is no.

Fourth, can it be diffed? Can you show me what the agent believed on Monday and what it believes today, line by line, with the write that changed each line and the origin of that write? An audit log that records "memory updated" is not a diff. It is a timestamp with no witness.

Fifth, can it be purged per user? When one person leaves, or revokes consent, or turns out to have been the attacker, can you remove what they wrote, and what was derived from it, without wiping everyone? If lineage is not recorded, the derived part is unanswerable, and you will end up choosing between keeping the poison and losing the patient.

If all five have answers, you are in a small minority. If the first two do, you can get the rest by Friday. If none do, the agent's authorization policy is whatever the last session left in its notes.

The rejection rate, and the write we cannot see

Two things against my own interest.

Origin-bound enforcement has a price, and EAL-Bench says so in the same paper that supplies the headline number. Requiring a note to be backed by a source event before the executor honors it reduces laundering, and it raises false rejections: authority that was granted, but whose backing event the system cannot find, gets refused. An agent that will not act on a real approval because the approval was recorded in an ungoverned channel is not a safe agent. It is a broken one with a good excuse. Anyone selling you origin enforcement without mentioning the rejection rate is leaving out the half you will pay for.

The harder admission. A scanner sees the construction flaw: the shared store, the missing isolation, the memory tool wired to conversation history with no filter. It cannot see the write. The write happens at runtime, in a process the scanner is not inside, and the only thing that can record origin at that moment is something standing at the hook when the note is written. We built the scanner first because construction flaws are cheap to find and common. But if the recorder is not already on when the memory tool fires, the origin of that note is gone, and no amount of scanning afterward brings it back. I would rather tell you where the line is than let you think a clean scan means clean notes.

Three figures on memory-based authorization laundering: 50.2 percent of unauthorized requests served, 98.6 percent of trials affected, and poisoning rising from 11.5 to 24.7 percent against an adaptive attacker.
Persistent memory is part of the authorization policy, whether or not you designed it that way.

The last note

The last scene of the film sits near the beginning of the story it tells. Leonard hands his future self a lie. He does it calmly, and he explains it to himself as he does it: he is choosing what he will believe, because belief is the one thing he can still control. Then the moment passes, the note becomes fact, and he acts on it for everything that follows.

Your agents write themselves notes every session. Up to half the time, with nobody pushing, those notes will say the agent had permission it did not have, and the next session will believe them almost every time. Whether anyone can say who wrote each line, what it passed through, and whether it is still true is not a memory feature. It is the access policy. It always was.

Don't believe its lies. Better: make it impossible to write one without signing it.


The AA-MP rules in g0 will show you where memory is shared, exposed, or writable from conversation history. That is the construction half, and a scanner can only ever see that half. The Decision Record in Guard0 is our attempt at the other half: the run captured live, so that what an agent wrote to itself, and on whose say-so, is part of the record and not a rumor.

References

  1. EAL-Bench: Agent Memory Is a Surface for Endogenous Authorization Laundering (arXiv 2609.01836)
  2. The Memory Trust Gap (arXiv 2609.01852)
  3. Sleeper Memory Poisoning (arXiv 2605.15338)
  4. A systematic study of memory poisoning in agents (arXiv 2606.04329)
  5. Origin-bound authority and information-flow control (arXiv 2606.24322)
  6. Mind Viruses, Anthropic and EPFL (arXiv 2608.10218)
  7. CAPTURE (arXiv 2609.02265)
  8. Stored Is Not Supported: Typed Provenance and Assertion Guardrails (arXiv 2609.02127)
  9. Rehberger: Copirate 365, DEF CON 2026
  10. Rehberger: Breaking Opus 4.7 with ChatGPT
  11. The Hacker News: CoSnitch, CVE-2026-24301
  12. Simon Willison: prompt injection as role confusion
  13. OWASP Agent Control Standard
  14. Guard0: What 1,180 Rules Taught Us
  15. Guard0: A Log Is Not Evidence
  16. g0 on GitHub

The Signal · AI Agents · Security

Jayesh Bapu Ahire
Founder, Guard0