Question presented to candidate: "Before launch, your team is asked to red-team the new LLM assistant. What does red-teaming an LLM application actually mean, how is it different from running evals, and how would you organise it so it keeps paying off after launch?"
What a strong answer should cover:
- Red-teaming is adversarial testing of the whole application (prompts, retrieval, tools, guardrails, UI), searching for worst-case behaviour; evals measure typical behaviour on representative inputs
- Start from a threat model specific to the app: what data it holds, what it can do, who would attack it and how; attack categories such as system prompt extraction, jailbreaks, direct and indirect injection, cross-tenant or PII leaks, tool abuse, harmful or off-brand output, and cost abuse
- Manual creative attacks to find new classes, plus automated campaigns that multiply seed attacks with mutators (role-play, encodings, multi-turn escalation) and score outputs with detectors such as canary tokens, regexes and judge models
- Metrics: attack success rate per category and per technique, with repeated sampling because model output is not deterministic; severity triage
- Fixes go into layers (permissions, guards, data scoping), not only prompt patches, and every successful attack becomes a permanent regression case run on each prompt, guard or model change
- Awareness of tooling and frameworks (open-source scanners and orchestrators, OWASP Top 10 for LLM Applications, NIST AI 600-1) without treating any of them as the whole job
Clarifying questions expected:
- What tools and data can the assistant reach, and is there a non-production environment with the same permissions?
- Which harms are unacceptable for this product, and who signs off on residual risk?
Code / implementation expected: Optional โ a small harness that runs seed attacks through mutators against the app and scores the outputs.