Open-sourced prompt-injection detector (regex gate + quantised DeBERTa-v3 ONNX)

What Happened

A developer open-sourced a two-stage prompt-injection detector combining a regex gate with a quantised DeBERTa-v3 model exported to ONNX format. The model was trained on attack data collected from a live game environment, indicating the training corpus reflects real adversarial traffic rather than synthetic examples. The release targets AI application builders seeking a lightweight, deployable defence layer rather than a research prototype.

Why It Matters

Prompt injection remains one of the few attack classes with no reliable structural mitigation: the input channel and instruction channel are the same token stream. Most production defences today fall into two ineffective camps — brittle manual regex rules, or LLM-based judges that add hundreds of milliseconds and per-request cost. This detector offers a middle path: a small, specialised classifier that runs on CPU, costs fractions of a cent per request, and filters high-confidence malicious patterns before they reach the primary model. The regex-first architecture means the expensive model path is invoked only on ambiguous inputs, keeping median latency low. For teams deploying customer-facing agents, this reduces the attack surface without a GPU dependency or a second LLM in the critical path. Training on real game attack data further signals that adversarial examples are now domain-specific — generic public benchmarks will increasingly miss targeted injections.

Technical Details

The pipeline runs input through a regex gate that short-circuits on known high-confidence injection patterns, then routes remaining inputs to a quantised DeBERTa-v3 model served via ONNX Runtime. Quantisation allows CPU-only inference, removing GPU provisioning from the deployment story and making the detector viable inside existing web-service containers. The regex gate serves two functions: reducing false positives by handling unambiguous cases deterministically, and reducing average inference cost by bounding how often the model is invoked. As with any small classifier, precision and recall trade-offs are attack-distribution dependent — thresholds tuned on the game dataset will not transfer cleanly to finance, healthcare, or code-execution contexts without recalibration. The model is a classifier, not a sanitizer: it flags or blocks, but does not neutralise injected instructions mid-context.

Operational Impact

Builders can now insert a middleware layer between user input and LLM invocation that adds minimal latency and no GPU footprint, replacing either hand-maintained regex lists or expensive LLM-judge calls for the common case. This shifts prompt sanitisation from an ad-hoc engineering task into a deployable component with a clear interface, which lowers the barrier for small teams to ship agents exposed to untrusted input. Cost per protected request drops by an order of magnitude versus LLM-based judging, and operational complexity drops because there is no separate inference service to scale. The detector is not a substitute for output-side guardrails, tool-call allowlists, or least-privilege agent design — it addresses only the input boundary. Teams adopting it should treat it as one layer, not a control.