Why do prompt injection controls need to be measured on different agent turns?

Why the measurement point has to change with the agent turn

Prompt injection is not a single event, it is a control problem that shifts as the agent moves from intake to retrieval, reasoning, and tool use. Measuring only user input can give a false sense of safety because malicious instructions can arrive later, while measuring every turn changes the economics of detection, latency, and false positives. The right turn to measure depends on where attacker-controlled content can enter the loop.

That is why turn-level evaluation has to match the agent’s actual data flow. In an agentic system, the highest-risk turn may be the one that consumes retrieved context, the one that ingests tool output, or the one that prepares an action. A detector that works on one turn can still miss the turn where the attacker’s payload becomes actionable.

Different turns also produce different message volumes and different signal quality. User prompts are usually sparse and more intentional, while retrieved snippets, tool logs, and chained outputs can be noisy, repetitive, or partially trusted. If you apply the same threshold everywhere, you either miss indirect attacks or overwhelm operations with alerts that nobody can sustain.

Where prompt injection enters the loop

The practical question is not whether prompt injection exists, but which turn can carry attacker influence into the model or agent control path. The most obvious entry point is the user message, but indirect prompt injection often travels through content the agent treats as auxiliary, such as retrieved documents, webpages, tickets, emails, or tool responses. A control that only inspects the first turn will systematically under-sample those paths.

This is why agent security guidance usually treats the conversation as a sequence of trust boundaries rather than a single inspection point. A retrieval turn, for example, may need stricter content scrutiny than a normal chat turn because the agent is about to mix external text into its working context. Tool-response turns can be even more sensitive because they may contain instructions, identifiers, or data that influence the next action.

For readers comparing patterns across the agent stack, the Agentic AI Security Guide and the OWASP Agentic AI Top 10 both reflect the same operational reality, prompt injection risk is distributed across inputs, memory, tools, and orchestration, not concentrated in one front door.

Why one detector cannot be equally effective on every turn

A single detector design rarely performs well across all turns because each turn has different context length, trust level, and acceptable delay. On user input, the detector can be aggressive and relatively cheap. On retrieval and tool-output turns, the model may need more contextual interpretation, but the same strictness can create false positives when benign external text resembles instructions, code, or configuration.

That trade-off is the core reason to measure control effectiveness by turn. If you only score “prompt injection blocked” at the front door, you may miss the control failure that occurs when the attack is actually introduced later. If you instead force the same detector to run everywhere at maximum sensitivity, you may protect the model while making the system too slow, too expensive, or too noisy to use.

Operationally, the better question is whether each turn has a detection threshold that is appropriate to its role. A turn that can trigger an irreversible action deserves a higher bar than a turn that only updates working context. A turn that merges untrusted retrieval should be measured differently from a turn that carries plain user conversation, because the failure mode and the blast radius are not the same.

Risk and Threat Considerations

Prompt injection controls fail most often when teams assume that “the prompt” means only the user message. Attackers exploit that blind spot by hiding instructions in retrieved content, tool output, or chained agent context, then waiting for the agent to act on the wrong turn.

Failure mechanism: A detector tuned only for the first turn misses indirect payloads, while a detector deployed uniformly across every turn may be too costly or noisy to keep enabled, creating coverage gaps where malicious content becomes actionable.

Impact: The result can be data exfiltration, unauthorized tool use, or incorrect autonomous actions, especially when the affected turn precedes retrieval, delegation, or execution.

Practitioner Guidance

What to prioritise: Measure detection by turn type, not just by overall session outcome. The most important turns are the ones that combine untrusted content with an upcoming action, such as retrieval, tool invocation, or policy-relevant decision points.

What to verify: Confirm that your evaluation set includes attacks introduced after the initial user prompt, plus benign examples that resemble injections in retrieval or tool-output turns. If all your tests target the opening prompt, your metric is incomplete by design.

Decision rule: If a turn can influence an external action or expand the model’s working context, it deserves separate measurement and often a stricter threshold than a plain conversational turn. If the turn is low-risk and high-volume, optimise for low noise and low latency instead of maximum suspicion.

Practitioner takeaway: The control should follow the attacker’s path through the agent, not the developer’s instinct to inspect only the first message; otherwise you will either miss indirect injections or tune the system into operational paralysis.

Related resources from NHI Mgmt Group

• How should security teams design agent controls to reduce prompt injection risk across tool calls and browser actions?
• When should organisations retest prompt injection controls on an AI agent?
• Why do kernel-level controls reduce the risk from prompt injection in agent runtimes?
• What is the difference between human identity governance and AI agent governance?