OmegaEngine · Evidence · Judge Card
Red-Team Verdict Engine — Judge Card
A red-team report is only worth what its verdicts are worth. This card is the honest system-card for the engine that decides whether an attack bypassed or was blocked — what it is, the numbers we measured, their limits, and how to re-run it yourself.
What this is (and is not)
- This card covers the VERDICT engine — the component that labels an (attack prompt, model response) pair as bypassed or blocked. It is what makes a finding trustworthy.
- It is NOT the input-safety catch-rate. That is a separate, deterministic measurement over the full 5,023-vector corpus — see the Benchmark Methodology page and the published artifact.
- Every number below is on a 48-example, self-authored seed set — a demonstration of shape, not a production population estimate. We state that everywhere rather than implying broader coverage.
The engine under test
Two tiers, escalated by confidence:
- Heuristic (lib/redteam/classifier.ts) — a fast, deterministic rule/keyword classifier: refusal-phrase matching, compliance indicators, category patterns, leakage-in-refusal detection. Free, but blind to the attacker's goal.
- Tiered (heuristic + LLM judge) — verdicts below a 0.7 confidence threshold escalate to an LLM judge (lib/redteam/judge.ts) asked the only question that matters: did the attacker actually achieve their goal? Verdicts merge back via mergeVerdicts.
Positive class = bypassed. Judge model on the reference run: gpt-4o-mini.
Measured results — recall is a function of judge budget
Ground-truth set: 48 human-labeled examples spanning jailbreak, prompt-injection, data-exfiltration, encoding-bypass, multilingual, social-engineering, compliance, and harmful-content — including deliberately hard cases (leakage-in-refusal, encoded payloads, fictional framing with real actionable content) and benign controls that must not be flagged. In production the judge is cost-capped, so the realistic recall is whatever the budget buys — we publish the curve, not one headline number.
| Judge budget / run | Precision | Recall | F1 | FP-rate | Accuracy |
|---|
| 0 (heuristic-only) | 100% | 17.4% | 29.6% | 0% | 60.4% |
| 10 | 100% | 43.5% | 60.6% | 0% | 72.9% |
| 20 | 100% | 73.9% | 85.0% | 0% | 87.5% |
| full (≈ judge everything) | 100% | 95.7% | 97.8% | 0% | 97.9% |
- Precision stays 100% at every budget — the judge never introduces a false positive on this set; more budget only ever raises recall.
- The heuristic alone misses ~5 of 6 real bypasses while reporting a clean 100% precision that makes it look trustworthy. Shipping the judge off is shipping the 17%-recall engine.
- The ~96% figure requires judging essentially the whole run. Do not quote 96% for a budget-capped run — quote the curve. A limited budget is spent false-negative-risk-first.
Escalation policy (asymmetric, by design)
A missed bypass (false negative) is the expensive error in security, so "blocked" verdicts escalate to the judge far more readily than "bypassed" ones: shouldConsultJudge escalates anything below 0.7 confidence either way, plus any "blocked" verdict below 0.9. A limited budget is allocated blocked-first, lowest-confidence-first (escalationPriority). The judge prompt also carries a per-category success criterion (CATEGORY_SUCCESS_CRITERIA) so it scores goal-achievement, not just "is there harmful content".
Failure modes & known limitations
- Small-judge ceiling: gt-0006 (a prompt-injection where the model complied with a terse PWNED) is still missed even at full budget with the explicit success criterion — a gpt-4o-mini limitation, not a prompt-wording bug. We deliberately did not overfit the prompt to force one example on a 48-example self-authored set.
- The judge is itself an LLM and can err — which is exactly why we measure it against human labels rather than trusting it blind.
- The numbers are on a 48-example seed set, not production traffic. They demonstrate the shape of the result (the judge massively lifts recall at no precision cost), not a population estimate.
- Findings shipped to customers carry a verification status (judge-verified / heuristic-confident / needs-review, lib/redteam/verdictStatus.ts) so an unverified heuristic flag is never presented as a confirmed vulnerability.
Calibration — are the labels themselves trustworthy?
The biggest credibility risk is that one person authored both the examples and their labels. To check the labels (not the judge), an independent, stronger model (gpt-4o vs the gpt-4o-mini judge) re-labels every example blind to our label (npm run audit:labels):
| Metric | Value |
|---|
| Agreement | 95.8% (46/48) |
| Cohen's κ | 0.917 (almost perfect) |
| Disagreements | 2 — flagged for human adjudication, not edited away |
This is a silver check (a model reviewer, not human gold), but κ ≈ 0.92 is strong evidence the labels reflect a defensible standard rather than one author's bias. The two disagreements are kept as-is (editing them would game the metric) and are exactly where human labeling effort pays off most.
How the ground-truth set grows
To turn the seed set into a publishable population number we mine real traffic (npm run mine:labels), a human reviewer fills the label field, and confirmed lines move into data/seed/. Target: 500–1000 real labels, at which point these metrics become a defensible, third-party-auditable benchmark.
Reproduce it
- npm run eval:judge — heuristic-only, hermetic, no API calls.
- npm run eval:judge -- --judge — tiered: also runs the LLM judge on low-confidence verdicts (uses your own OMEGA_JUDGE_API_URL/KEY or OPENAI_API_KEY — BYOK).
- OMEGA_EVAL_MIN_PRECISION=0.95 npm run eval:judge -- --judge — gate a release on minimum precision.
- npm run audit:labels — independent stronger-model label audit (the κ number above).
Related evidence
The deterministic input-safety catch-rate over the full 5,023-vector corpus is published as a machine-readable artifact at /evidence/fuzzer-corpus-score.json.