Multi-turn attacks and persistent memory in LLM apps

Some injection attacks do not work in one message. They build up over several turns, plant instructions in memory, or wait for a later trigger. If your app keeps conversation history or long term memory, review what is stored, who can write to it, and what it may influence later.

What the guidance lists

OWASP's cheat sheet names multi-turn and persistent attacks as a category: session poisoning, memory persistence and delayed triggers. The point is that a check applied to each message in isolation can miss a pattern that only shows across the conversation.

It also lists context poisoning among agent specific attacks, where the material the agent reasons over is itself manipulated.

Why memory raises the stakes

Without memory, a successful injection ends with the session. With memory, it can survive. An instruction saved as a "preference" or "fact" may be loaded into every future conversation, possibly for other users if memory is shared.

That makes memory a write channel with long lived effects, and it should be treated like any other store that holds untrusted input.

Controls to apply

1. Decide what may be remembered. Do not let the model save arbitrary text. Store structured facts with a schema.
2. Mark provenance. Record whether an item came from the user, a document or a tool, and treat non-user sources as untrusted when loaded back.
3. Scope memory. Keep it per user by default. Shared memory needs the access controls of a shared database.
4. Let people inspect and delete. A visible memory list helps both users and reviewers spot odd entries.
5. Expire it. Old entries lose value and add risk.
6. Evaluate whole conversations. Run your adversarial tests across multiple turns, not only single prompts.

Monitoring ideas

OWASP recommends security logging that excludes sensitive data, alerting, and tracking of encoding attempts, markup injection and tool use. Add counters for memory writes per session and for tool calls that follow a memory load. A sudden change in either is worth a look.

The limits

You cannot eliminate multi-turn risk by filtering. A patient attacker can phrase each message innocently. The durable defence is limiting what any stored context can authorise: narrow permissions, approval for consequential actions and output validation downstream.

Safeguard's agent identity and policies help tie permissions to the agent rather than to whatever the conversation said earlier.

Questions for your design review. Ask where memory is written, by what, and from which sources. Ask who else's sessions can read it. Ask how an entry is removed, and whether the removal reaches backups and caches. Ask what the strongest action is that a remembered instruction could trigger. If the answers are unclear, memory is probably writable by more than you intend.

Quick check

Sources

• OWASP LLM Prompt Injection Prevention Cheat Sheet

Last reviewed: 19 October 2026.