A single suspicious message is relatively easy to catch, both by a model's own trained resistance and by simple filtering that flags obviously adversarial phrasing. Multi-turn attacks work around this by never putting the full attack in one message. Instead, they build a supporting context gradually across several turns, establishing an innocuous-seeming premise early and introducing the actual manipulative request only once that premise is already accepted, at which point the model may treat the request as a natural continuation of an established, seemingly legitimate conversation rather than a fresh, suspicious one.
Why single-message defenses miss this pattern
Most prompt injection filtering and testing focuses on individual messages in isolation, checking whether a given input matches known adversarial patterns. A multi-turn attack, by design, avoids having any single message match those patterns clearly, because the manipulative intent only becomes apparent when several messages are considered together. A defense that evaluates each message independently, without considering the trajectory of the conversation, will tend to pass every individual message in a well-constructed multi-turn attack, even though the conversation as a whole is clearly adversarial.
Common patterns in multi-turn attacks
One common pattern establishes a fictional or hypothetical framing early, "let's imagine a story where a character explains how to do X," and builds on that framing across several turns before asking for content that would have been refused if requested directly in the first message. Another pattern gradually escalates a legitimate-seeming request, starting with an innocuous version of a task and incrementally asking for modifications that, taken individually, seem like reasonable refinements but collectively arrive at something the system should not produce. A third pattern uses earlier turns to plant supporting "facts" or context that the later, actual attack request then references as if it were already-established, legitimate information.
Why this matters more for agents than for simple chatbots
For a text-only chatbot, a successful multi-turn attack produces an undesired response, a real but bounded consequence. For an agent with tool access, a multi-turn attack that successfully manipulates the model's understanding of the current task can lead to an unauthorized tool call that looks, from the tool's perspective, like a normal continuation of an established conversation, making it harder to distinguish from a legitimate request based on the tool call alone.
Defenses that consider conversation trajectory
Effective defense against multi-turn attacks requires evaluating the conversation's overall trajectory, not just its most recent message. Techniques include periodically re-evaluating the full conversation against the system's original task scope, checking whether the current request is consistent with the conversation's established purpose, and flagging conversations that show a pattern of gradual escalation for closer review or additional confirmation before executing anything consequential.
Bound risk with the same downstream controls, regardless of how the attack arrived
Whatever technique led to a manipulated model decision, single-message injection, multi-turn escalation, or a jailbreak attempt, the same downstream controls that limit consequence apply equally: narrow tool scope, independent authorization checks, and output validation. This is a useful property of defense in depth, since it means these downstream layers do not need to specifically recognize a multi-turn pattern to still contain its worst-case impact, unlike prompt-level or single-message filtering, which does need to specifically account for this pattern to be effective at all.
Limiting conversation length and resetting context periodically
For agents with tool access, limiting how long a single conversation can run before requiring some form of re-confirmation or context reset reduces the window available for a gradual multi-turn attack to build the supporting context it depends on. This is a tradeoff against conversational continuity for legitimate long interactions, and the right balance depends on the specific application's risk tolerance and how essential very long, continuous conversations actually are to its intended use case.
Testing specifically for multi-turn patterns
A red team exercise that only tests single-message injection attempts will not surface multi-turn vulnerabilities. Testing needs to include deliberately constructed multi-turn scenarios: fictional framing built across several turns, gradual escalation sequences, and attempts to reference earlier, planted context as if it were established fact, run against the actual application rather than assumed to be covered by single-message results.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary evaluates a requested action independently of how many turns of conversation led up to it, which means a tool call resulting from a successful multi-turn manipulation still has to pass the same authorization check as one from a single-message request, providing a consistent backstop regardless of which technique produced the manipulated request.
Detecting the multi-turn pattern itself, and deciding when a conversation's trajectory warrants additional scrutiny, remains application-level detection work that has to evaluate the conversation as a whole.
A short checklist
- Evaluate conversation trajectory, not just the most recent message, for
signs of gradual manipulation.
- Watch for fictional framing, gradual escalation, and planted-context
patterns specifically.
- Apply the same downstream tool scope and authorization controls
regardless of which technique produced a manipulated request.
- Consider limiting conversation length or resetting context periodically
for high-risk agents.
- Test with deliberately constructed multi-turn scenarios, not only
single-message attempts.
Multi-turn attacks succeed by avoiding detection at the single-message level, which means defenses tuned only to individual messages will consistently miss them, and testing has to specifically account for this pattern to have any confidence about resistance to it.