← all runs

Detector benchmark: deterministic rules vs model classifiers

Run 20261004-075810 · version dev · 2026-10-04 07:58 UTC · 536 upstream calls (0 replayed) · $0.0143

Question. How well does each detection layer generalise to attacks it was not built from, what does each cost in latency and money, and which combination is worth deploying?

Findings

• Generalisation gap: the deterministic engine stops 100.0% of attacks on the corpus it was developed against but 18.8% of the held-out set, at sub-millisecond latency (p95 0.71ms) and zero marginal cost. Rules are a regression floor, not a generalising detector.
• prompt-guard-86m alone reaches 72.5% held-out injection recall but 0.0% on harmful-content requests: it is an injection classifier, not a content-safety model.
• Cascade calls the classifier on 2% of requests and reaches 20.8% recall; running it on every request reaches 64.6%. The difference is the attacks that carry no lexical signal at all: the cascade cannot escalate what the rules never saw.
• OpenAI moderation catches 100.0% of held-out harmful requests and 0.0% of injections: moderation APIs do not cover prompt injection, so they cannot replace an injection layer.
• Best F1 on held-out data: Deterministic + prompt-guard-86m + safeguard-20b (0.970).

Recall: in-distribution vs held-out

False-positive rate on benign traffic (held-out hard negatives)

Median added latency per request

Strategy trade-off on the held-out set

Detector benchmark

Defence-in-depth strategies (held-out set)

Held-out attacks caught, by technique

Held-out errors of the deterministic engine

Method notes

• Positive class = attack (injection, jailbreak, extraction, indirect, exfiltration) or harmful request; benign cases include deliberately hard negatives (security discussion, near-keyword phrasing, multilingual).
• The held-out set was written after the deterministic guards were finalised and was never used to tune them; it is small (88 cases) and hand-built, so treat differences of a few points as noise.
• Classifier latency is the upstream latency of the successful call as recorded at first run (it includes provider queue time). SDK retries are disabled during experiments, so rate-limit back-off is not counted as latency. The deterministic engine's latency is in-process time; on Windows the OS timer quantises sub-millisecond readings, so see the Go benchmarks in the README for precise figures.
• Prompt Guard has a 512-token window; long inputs are scored in overlapping windows and the maximum taken.
• Strategies are evaluated offline from the same verdicts (sequential latency shown; the gateway's parallel mode hides classifier latency behind the upstream call).

{
  "classifiers": [
    "prompt-guard-22m",
    "prompt-guard-86m",
    "safeguard-20b",
    "gpt-5-nano",
    "moderation"
  ],
  "escalate_above": 0.25,
  "policy": "balanced",
  "policy_version": "1.0.0",
  "workers": 4
}