Anatomy of a Judge-Scored Red-Team Run
How Oxyne separates 'the model said something bad' from 'the model was actually compromised' — and why that distinction is the difference between a useful finding and noise.
Adversarial testing of AI systems has a noise problem. Run a large template library of jailbreak and injection prompts against any production model and you'll get a wall of transcripts — most of them false positives, hedged refusals, or responses that look alarming out of context but represent no real compromise.
The judge layer
Every attack template in an Oxyne run is paired with an explicit success condition: what would the target system have to actually do, or actually say, for this to count as a real finding. A dedicated judge model — not the model being tested — evaluates each transcript against that condition and produces a structured verdict: confirmed, likely, or not exploited, with the specific evidence that drove the call.
This matters more than it sounds. A model that responds "I cannot help with that, but here's some general information about X" to a jailbreak attempt is not compromised, even though the raw transcript contains the sensitive-sounding topic. A judge with the actual success criteria in front of it catches that distinction reliably; keyword-matching the transcript does not.
What this looks like in practice
For each system under test, Oxyne runs a fixed library of attack templates spanning prompt injection, jailbreaking, data exfiltration, and tool-call abuse (for agents with tool access), scored independently by the judge layer. Only confirmed and likely findings surface as reportable results — with the full transcript attached, so your team can verify the judge's call directly rather than taking it on faith.
We validate judge quality against hand-reviewed transcripts before it ever scores a real customer engagement, and we keep doing that as the template library grows. Read more about the methodology on the AI Red Teaming product page.