Replacing generative judges with decision models for prompt injection defense

StackOne has updated its Defender prompt injection guard by replacing a generative large language model with a specialized decision model. This change, detailed in an engineering post published on October 15, 2026, shifts the final tier of their defense system from a text-generating judge to a probabilistic classifier that operates entirely within local infrastructure.

What happened

Defender protects tool-calling agents by inspecting every result returned by external tools. The system uses a three-tiered approach to balance speed and accuracy. Tier 1 performs rapid pattern matching in about one millisecond. Tier 2 uses a 22MB classifier that runs on CPU, scoring strings in tens of milliseconds. Previously, Tier 3 relied on a small generative LLM to review ambiguous cases escalated by Tier 2. While effective at catching attacks, this generative judge was costly and slow, requiring GPU resources and hundreds of milliseconds per call. It could only process a subset of results due to these constraints.

The engineering team sought a cheaper, faster alternative for Tier 3 that could potentially evaluate every tool result alongside Tier 2 rather than just the uncertain ones. They replaced the generative judge with a "System One" decision model. This type of model, popularized recently by TypeSafe and Jev, makes decisions without generating text. The new implementation uses a decision model built on a ModernBERT backbone, which fits on a single small GPU and can be hosted locally. This shift allows the system to maintain data privacy while reducing latency and cost.

How it works

System One models are named after Daniel Kahneman’s concept of fast, intuitive thinking. Unlike generative models that produce open-ended text, these models accept a state, such as text or JSON, and a set of typed questions. The output is strictly limited to predefined options: multiple-choice selections, numerical scores, or binary probabilities known as "nouls." Because the output space is closed, the model cannot be tricked into rambling, refusing, or producing malformed text through prompt injection. It can only assign probabilities to the options provided by the developers.

This architecture offers two main advantages for security guards. First, the closed output space prevents the model from being hijacked into unexpected behaviors. Second, the output is a raw probability rather than a generated word. Generative judges implicitly use a 0.5 threshold when choosing between words like "block" or "allow," but this threshold shifts unpredictably during retraining. A decision model provides explicit probabilities, allowing engineers to set custom thresholds based on desired false positive rates for each deployment. StackOne tested hosted APIs like Jev but rejected them due to data privacy concerns, as tool results often contain sensitive employee records. Instead, they fine-tuned an open-weights model on their own data.

Key details

• Tier 1 pattern matching completes in approximately one millisecond.
• Tier 2 uses a 22MB classifier that scores strings on CPU in tens of milliseconds.
• The new Tier 3 model is based on a ModernBERT backbone and fits on a single small GPU.
• Zero-shot performance of the untrained decision model was 54.5% accuracy on held-out test data.
• The model answers specific questions about instructions, data exfiltration requests, and identity claims.
• Hosted API testing with Jev cost $0.000025 per call but failed to generalize well to tool payloads.

Why it matters

For engineers building agentic systems, the cost and latency of security checks are significant bottlenecks. Generative judges, while flexible, introduce variable latency and high compute costs because they require GPUs and parse large blocks of text. By moving to a decision model, StackOne demonstrates that high-stakes classification tasks do not need open-ended generation. This approach allows for stricter control over model behavior and more predictable performance characteristics. It also enables the possibility of scanning every single tool result, rather than just a sampled or escalated subset, improving overall security posture without proportional cost increases.

Data privacy remains a critical constraint for enterprise AI applications. Many organizations cannot send internal data, such as CRM notes or emails, to third-party APIs for classification. The move to local, open-weights decision models addresses this by keeping all processing within the existing infrastructure. This pattern suggests a broader shift in AI security tooling: away from relying on frontier models for every task and toward specialized, smaller models that are fine-tuned for specific decision boundaries. This reduces dependency on external providers and lowers operational risk.

What you can do

• Audit your current prompt injection defenses to identify where generative models are used for simple classification tasks.
• Evaluate System One or decision models for any binary or multi-class security judgments in your pipeline.
• Define specific, typed questions for your security checks instead of asking open-ended questions like "is this safe?"
• Test open-weights decision models on local hardware to ensure they meet your latency and privacy requirements.
• Set explicit probability thresholds for blocking actions based on your acceptable false positive rate.
• Fine-tune models on your own historical data to improve accuracy beyond zero-shot capabilities.