The Case for Synthetic Adversarial Personas in Your Eval Suite

Most eval suites grow the same way: someone writes a handful of representative examples, and over time real production failures get added as regression cases. Both sources are valuable, and both share a blind spot — they only cover inputs that happened to occur. Neither one tells you how the system behaves against a user who is actively trying to confuse it, extract something it shouldn't share, or push it into an edge case nobody happened to hit yet.

Synthetic adversarial personas close that gap by generating eval cases from an explicit model of intent rather than from observed traffic. Instead of asking "what have users asked," you ask "what would someone trying to break this ask" — and you write that persona down as a reusable spec rather than a one-off prompt.

Personas as a spec, not a vibe

A useful adversarial persona is specific enough to generate many distinct test cases from one description: "a user who rephrases a rejected request as a hypothetical," "a user who buries a policy-violating ask inside a long, reasonable-sounding request," "a user who asks the same question ten different ways looking for one answer that leaks." Each persona becomes a small generator — feed it into a model with instructions to produce 20 concrete attempts in that style, then run those attempts against your actual system.

The output is uneven, and that's fine. Most generated attempts won't find anything. The ones that do are worth far more than another well-behaved example, because they show a failure mode you didn't think to test for directly. Treat a successful adversarial hit the same way you'd treat a real production failure: add it to the permanent regression set, and generalize it into a new persona property if it reveals a whole category rather than a one-off.

Where this fits relative to red-teaming

This isn't a replacement for dedicated red-teaming or security review — it's a cheap, continuous complement that runs in CI alongside your other evals, at a much smaller scale and lower cost than a full red-team engagement. The goal isn't finding every possible attack; it's catching the obvious, high-frequency failure modes automatically, before a real user or a real red-teamer finds them for you, and keeping the eval suite honest about the fact that "passes on our examples" and "holds up under someone trying to break it" are different claims.

If your eval suite has never generated a single case designed to fail on purpose, that's the fastest place to invest the next hour of eval work — it will surface failures your happy-path set structurally cannot.