PromptFu
03 Offense: Agentic3.7Advanced18 min

Memory and persistence

Delayed tool invocation, and the classifier bypass OWASP names itself.

ASI06◆ Eleven days later

Module 3.1 removed the attacker from the session. This one removes the session. The payload arrives on a Tuesday, does nothing, and fires eleven days later in a conversation about something else.

The property that makes this work

OWASP lists three deployment-time properties that make injection worse. The second is the whole of this module.

Memory persistence: an injection that writes to long-term memory, a RAG corpus, a vector store, or a hosted memory service taints every subsequent session that reads from that store.
OWASP LLM01:2026

Note what it costs the attacker. One write, once. Everything after that is the application doing its job, on schedule, for as long as the entry survives.

Watch the session boundary

Two sessions, eleven days apart. Watch for the moment the payload becomes the user's own saved preference, and run all five controls.

Eleven days later

0 / 9

Signed in as Alice Okafor, tenant "acme". The target document belongs to tenant "globex".

Objective

Cause a cross-tenant read in a future session, from a payload planted once, with no attacker present and no trace of the original conversation.

Which memory control is in place?

Step through the trace. Every node is a real place content enters or leaves the application, and each one arrives with the analysis beside it: what a defender can still do at that instant.

Synthetic world, no live model. Controls and their stated limits per OWASP LLM01:2026 mitigation 9; the delayed-tool-invocation pattern follows the February 2025 Gemini proof of concept (Rehberger, 2025b).

Three of the five let every effect land. That is not a stacked deck. Two of the three are controls OWASP recommends, and the entry says why they fall short in the same paragraph that recommends them.

The mitigation that documents its own bypass

This is unusual enough to quote whole. Read the first sentence as the control and the last as the finding.

Treat agent memory writes as privileged operations. Log the causing prompt, classify writes for instruction or role-modification content, and require approval before instruction-bearing memories persist across sessions. A February 2025 Gemini PoC (Rehberger, 2025b) poisoned memory via delayed tool invocation (MITRE, n.d.). Factual entries shade into instructions, and incremental writes can evade per-write classification.
OWASP LLM01:2026, mitigation 9
The clauseWhat it asks forWhy it is not enough on its own
privileged operationsMemory writes get the scrutiny a state change gets, not the scrutiny a log line gets.The framing is right and it is a framing. Everything below is the implementation.
log the causing promptEvery entry records what produced it.Detection, not prevention. It is still the first thing to build, because without it an incident is unexplainable.
classify writesScore each write for instruction or role-modification content.OWASP's own next sentence: factual entries shade into instructions, and incremental writes can evade per-write classification.
require approvalA human clears anything instruction-bearing before it persists.Depends on the classifier above to know what to escalate, and decays under volume.
Clauses quoted from OWASP LLM01:2026 mitigation 9. The third column is this course's reading.

Delayed tool invocation

The Gemini proof of concept is worth naming because it separates the two halves in time. The write happens in one session. The tool call it causes happens in another.

This defeats a lot of monitoring by accident rather than by design. Any detection scoped to a single conversation sees a helpful assistant honouring a stored preference, because within that conversation that is all that happened.

Deep diveWhy testing this needs a different plan›

A test that opens a session, sends payloads and reads replies cannot find this. The write looks benign and the session ends before anything happens.

The test needs three phases: write in session one, close it, then open a fresh session and ask an unrelated question. Grade the second session on the recorded side effects, never on the reply.

Two practical notes. Leave real time between the sessions if the system expires or re-ranks memories, and check whether memory is scoped per user, per tenant or globally, because that determines whether one write affects one person or everyone.

Every store counts, not just the one labelled memory

OWASP's sentence lists long-term memory, a RAG corpus, a vector store and a hosted memory service together, and its Common Example #6 puts it plainly: one tainted entry in persistent memory or a RAG corpus reaches every future session that reads it.

So the inventory is wider than the feature. Saved preferences, chat summaries, extracted entities, user profiles, cached embeddings and anything an agent writes for its own later use all qualify. Module 3.6 covers the retrieval-layer half of the same problem.

Reduces attack rate· expected to degrade

Classifying writes and logging their cause are both worth deploying and neither is a boundary. OWASP recommends them and names their bypass in the same paragraph, which is the clearest example in the standard of a control offered as rate reduction rather than as a guarantee.

Bounds blast radius· survives adaptive attack

Not persisting anything that can behave like an instruction. Scope memory per tenant, expire it, and keep it to fields the application reads structurally rather than prose the model reads back as context. What is never stored cannot be replayed.

Sources