Prompt injection in agent memory: check what survives

Persistent agent memory needs two separate checks: whether an unsafe action occurred, and whether the instruction that encouraged it remains available to a later session. A refusal can satisfy the first check while leaving the second unresolved.

That distinction is central to Bad Memory, a July 2026 preprint by Soham Gadgil, David Alexander, Sai Sunku and Franziska Roesner at the University of Washington. Their controlled study examines instructions already planted in user-visible workspace files. The findings support a closer review of memory ownership, updates and recovery. They are author-reported research, with no independent reproduction presented here.

Start with the study's entry condition

The researchers used Claude Code and Codex in a synthetic workspace with fictional context. They tested Claude Haiku 4.5, Claude Opus 4.7, GPT-5.2 and GPT-5.5 across three adversarial goals: disclosure, unauthorised tool use and biased product recommendations.

The attacker was assumed to control a persistent file before the experiment began. Establishing that access was outside the main evaluation. Preliminary attempts to make an agent rewrite trusted memory through external content were difficult in their setup. The paper therefore leaves the likelihood of that initial compromise unanswered.

This scope matters when interpreting the results. A downloaded configuration, a reviewed project instruction and an automatically generated note can all become durable context through different routes. Each route needs its own owner and review rule. The paper does not establish the same exposure for hosted chatbot memory or every coding-agent configuration.

The general context boundary remains useful when reviewing those routes:

Separate behaviour from surviving state

The study distinguishes files loaded automatically at session start from files the agent reads when relevant. Its experiments include a single probe and longer sequences with an intervening benign task. Those longer sequences preserve workspace changes between sessions.

For the repeated disclosure case, the authors report that Opus 4.7 performed the targeted action in zero of ten trials in each probe, while the planted rule survived all ten sequences. These small, controlled results show why action success and instruction persistence deserve separate columns. They cannot supply a production compromise rate.

Other results need similar care. A tool-use result counted as unsuccessful could reflect a command remaining unexecuted. An already installed dependency could also change a later probe's outcome. The authors warn against using the aggregate attack-success figures as a model-security league table.

The paper also describes a model moving a problematic instruction into a more authoritative file. Its qualitative examples describe observable behaviour; an agent's explanation of its own choices supplies limited evidence about the internal cause.

Give memory changes an explicit owner

A practical review starts by listing the files a session can automatically load, the notes it may retrieve, and the processes allowed to edit each. Include shared templates and synchronised copies. Record which source supplied each instruction and who authorised its adoption.

Separate factual notes from instructions that change tool access, destinations or safety checks. Review a proposed high-impact instruction as a change to the agent's operating rules. Keep a visible version history so the reviewer can identify what changed without rereading an entire workspace.

Our guide to source authority examines how models interpret instruction origins. The memory question adds a lifecycle requirement: preserve that origin when content is saved, moved or loaded again.

The following permission model can also guide the review of memory-writing tools:

Test the next session with harmless state

Use an isolated test workspace with deliberately fictional documents and a harmless marker that contradicts a test-only formatting preference. Keep real credentials, production data and external destinations out of the exercise. The purpose is to observe persistence and authority without creating a dangerous action.

Record the initial file versions, the files actually read, the observed answer and the final file changes. End the session, perform an unrelated benign task, and start a fresh session that would consult the same memory. Repeat for each permitted model configuration so every deployed configuration has its own result.

Give the useful task its own result. A system that stops reading necessary project context may avoid the marker while failing the legitimate work. A successful test should preserve the intended task and identify the instruction's disposition.

Recover deliberately

When an unexpected instruction is found, preserve bounded evidence and have the authorised owner decide whether to remove, correct or quarantine it. An agent's caution about deleting user files can be appropriate. The operational requirement is a clear handoff so the instruction does not remain silently eligible for future loading.

Verify the reviewed source, loaded copies and the next session after correction. Our retrieval-cleanup guide covers indexed copies; workspace memory adds file versions and session-start loading to the recovery record.

The resulting claim should name the tested files, agent configuration and session sequence. Bad Memory motivates this work; it supplies no universal memory defence, customer incident or verified vendor patch. To discuss a bounded evaluation of your agent workflow, book a Promptective demo.