SCOUT: adaptive detector allocation for prompt-injection defense

What is this?

In May 2026, Shuhao Zhang, Jiarui Li, Qi Cao, Ruiyi Zhang and Pengtao Xie (UC San Diego and University of Illinois Urbana-Champaign) posted Send a SCOUT First: Pre-hoc Reasoning for Adaptive Detector Allocation in Prompt-Injection Defense on arXiv (2605.30837). The paper starts from an observation most teams already feel in production: prompt-injection detectors are heterogeneous. Each one is strong against some attack shapes and weak against others, yet most deployed pipelines treat detection as a single fixed detector — or, increasingly, a single always-on LLM judge inspecting every request. That is expensive, slow, and still leaves gaps.

SCOUT (Scalable and Controllable Outcome-prediction for Uncertainty-aware Triage) reframes the problem as detector allocation: for each incoming request, decide which detectors to run and whether to escalate to a heavier LLM judge, rather than paying the full cost on every request.

How it works

The core idea is to predict, before running the expensive checks, how each candidate detector is likely to behave on the current input. SCOUT estimates each detector’s per-sample reliability and latency by looking at how that detector performed on structurally similar past inputs, then routes the request accordingly. Cheap, high-confidence cases are cleared by lightweight detectors; ambiguous or high-risk cases are escalated to a stronger judge. The operator is given a single safety-utility threshold to tune — one dial that trades off how aggressively the system escalates against how much latency and compute it spends.

To evaluate this under realistic conditions, the authors built SCOUT-450, a benchmark of structurally complex, agent-facing injections — the kind embedded in tool outputs, retrieved documents and multi-step agent state, not the toy “ignore previous instructions” template. Conceptually, the routing layer looks like this:

# Adaptive detector allocation (illustrative sketch, not exploit code)
for request in stream:
    # pre-hoc reasoning: predict each detector's reliability + cost
    predictions = {d: estimate_from_similar_past_inputs(d, request)
                   for d in detectors}
    plan = select_detectors(predictions, threshold=operator_safety_utility)
    verdict = run(plan, request)
    if verdict.uncertain and plan.allows_escalation:
        verdict = llm_judge(request)   # heavy check, only when needed
    route(request, verdict)

The point is that the LLM judge — the accurate but costly component — is invoked selectively, guided by a prediction of when it is actually needed, instead of on every single request.

Why it matters

Two things stand out. First, the framing is right for where defenses are heading. As agents consume more untrusted content, the naive answer has become “put a strong model in front of everything,” which does not scale in latency or cost. Treating detection as a routing decision — spend your expensive checks where uncertainty and risk are highest — is a more sustainable architecture, and it composes with existing detectors rather than replacing them.

Second, the reported numbers are practical rather than heroic. On SCOUT-450, a safety-oriented operating point reduces attack-success rate by about 46% and total wall-clock time by about 40% relative to an always-on GPT-4o judge, according to the paper. A defense that is simultaneously safer and faster than the brute-force baseline is unusual; most trade one for the other. These figures are from the authors’ own benchmark and have not yet been independently reproduced, so treat them as a promising result to verify, not a settled fact.

Defenses

Even before a SCOUT implementation lands in a library, the design translates into concrete guidance for teams shipping LLM agents:

1. Stop treating detection as one fixed check. Maintain a portfolio of detectors with known strengths, and route per request. A single always-on LLM judge is a cost and latency ceiling, not a security ceiling.
2. Budget your expensive checks by risk. Reserve heavyweight LLM-judge calls for ambiguous or state-changing requests; clear low-risk, high-confidence traffic with cheap detectors.
3. Expose one operator dial. A tunable safety-utility threshold lets security owners move the operating point during an incident without re-architecting the pipeline.
4. Benchmark on agent-facing injections. If your evaluation set is still template-style prompt injection, you are measuring an easier problem than the one your agents actually face. Structurally complex, tool-embedded payloads (as in SCOUT-450) are the realistic target.
5. Log detector behaviour over time. SCOUT’s predictions rely on history; even without the full framework, recording which detector caught what gives you the data to allocate smarter later.

Status

Item	Reference	Date	Notes
SCOUT paper	arXiv:2605.30837	2026-05	Zhang et al., UCSD / UIUC
SCOUT-450 benchmark	§benchmark of the paper	2026-05	Structurally complex, agent-facing injections
Reported result	Paper, authors’ benchmark	2026-05	−46% attack success, −40% wall-clock vs always-on GPT-4o judge
Public implementation	Not confirmed released	—	Verify before relying on any code

The broader signal: prompt-injection defense is maturing from “which single detector is best?” to “how do we allocate a portfolio of imperfect detectors under a cost budget?” That is a systems question as much as a modelling one — and it is the question production teams already have to answer.