Red-teaming frontier models: a practitioner's guide

What a rigorous adversarial evaluation program actually looks like — beyond a list of jailbreak prompts copied from a forum.

Red-teaming has a credibility problem: a lot of what passes for it is a spreadsheet of publicly known jailbreak prompts, run once, checked off. That catches nothing a model hasn't already been patched against. A program that actually finds new failure modes looks different in three ways.

It's adversarial by role, not by script

Our red-teamers are trained to adopt a goal ("extract this restricted information," "get the model to endorse this harmful claim") rather than execute a fixed prompt list. That produces multi-turn attacks that build context over several exchanges — the failure mode most single-prompt testing misses entirely.

Domain specialists find domain-specific harms

A generalist red-teamer can find a model willing to write a phishing email. A cybersecurity specialist can find a model willing to help debug working exploit code across three back-and-forth turns of "just for research." The harms that matter to your specific deployment usually require someone who understands the domain well enough to know what a real attacker would actually try.

Every finding closes the loop back into training data

A red-teaming report that lives in a PDF nobody reads twice is not a red-teaming program. Every confirmed finding in our pipeline gets converted into a labeled training example — the harmful pattern, a graded refusal or redirection, and a rationale — so the next fine-tuning pass has a direct, traceable countermeasure.