LLM Red Teaming: Test Workflow and Scoring Guide

You must document each red-team finding as a regression test, a specific control change, and a retest cycle, so that a later model update cannot drop a known failure unnoticed. A single refusal count is not evidence; a defensible program treats red teaming as structured evidence of professional reliability, with findings that can be reviewed, repeated and defended.

The prompt is an analysis of 12 November 2026 of a structured LLM red-teaming workflow, which argues that red teaming should move beyond counting refusals to produce repeatable, categorised evidence of model behaviour under adversarial conditions. The example used is a legal-intake assistant that may refuse a direct request for prohibited advice but still draft an unauthorised filing when given a retrieved document and tool access. In our assessment, this distinction matters because it shows that a model score and deployed behaviour are separate questions; you cannot rely on a benchmark pass to establish safety in the actual workflow where users will interact with the system.

What does a defensible red-team scope include?

Start with the use case, the sector, the users, the intended outcomes and the unacceptable impacts. Name who will use the system, what a correct result looks like, and which harms are unacceptable in that setting. Testers then receive scenario instructions that name the violative information they should try to elicit, with explicit pass or fail criteria so a later reader can see what was tested and what counted as a failure.

Before the first run, write a scope record that names the owner of each assessment area, the languages in scope, and the user groups covered. A customer instance, account or document is in scope for testing only where you own it or have explicit written authorisation to test it. Limit the first cycle to one use case and one pinned model version. Map each confirmed finding to adversary techniques, so you see the attack pattern, not only the prompt that failed. A model can pass isolated safety tests while the deployed application still fails through its retrieval layer, tool permissions, infrastructure or runtime controls.

Which failure modes must you test for?

• Direct prompt injection — a user attempt to override system instructions through the chat interface.
• Indirect prompt injection — hidden instructions in a document, web page, email or tool result that the model processes as untrusted input.
• Fabricated authority or citation — plausible procedural harm, selective citation, omission of contraindications, or confident misreading of a confidential document.
• Refusal that still leaks detail — a nominal refusal that still gives a partial or transformed detail, or weak comprehension recorded as a safe refusal.
• Language-specific safety gaps — unsafe or misleading output in languages other than English, or safety norms that encode predominantly Western assumptions.
• Conversational injection — harm that appears only late in a long session, not in single-turn evaluation.

What concrete controls must you be able to demonstrate?

1. Separate the holdout test before the first run — keep one test set unseen by the people who write prompts, so a later rerun on the pinned configuration can show whether a fix worked.
2. Map findings to specific control changes — a confirmed injection through a retrieval layer becomes a rule that retrieved content is treated as untrusted; a fabricated citation becomes a check that every cited claim links to a source a reviewer can open.
3. Report six measures separately — attack-success rate, refusal quality, comprehension, toxicity, helpfulness and severity, all broken out by harm category, attack family, model version and conversation length.
4. Use independent reviewers for generation, factual audit, adversarial challenge and source verification — no single model has the final word, and disagreement stays visible instead of being smoothed into one answer.
5. Record the trail as test, model, fix and retest — a reviewer should be able to see which configuration failed, which change was made, and whether the holdout still fails on the same pinned version.
6. Retire attack families only when new seeds stop producing new confirmed failures — spend the next cycle on the family that still does, and do not widen the first cycle to every product surface.

Why does a benchmark pass in English not establish safety for other languages?

English-only benchmarks do not establish comparable safety in other languages or cultural settings. Multilingual training alone does not produce safe behaviour; some multilingual models produce more toxic outputs in low-resource languages, and safety norms may encode predominantly Western assumptions. Weak language comprehension can be recorded as a safe refusal, which is a scoring error, not a control. For a global professional system, you need language-specific reviewers and a harm taxonomy grounded in the communities served. Legal, healthcare, journalism and public-sector workflows are where an English pass is most likely to mislead.

What should you bring to the sign-off meeting?

Bring three figures: the severity-weighted rate for the highest harm category, refusal quality, and the categories that have no tests. Ask who accepts residual risk in writing. That person should be able to see the untested languages and the open failures, not only the categories that passed. Three decisions are available. Approve fits when the in-scope categories have been tested, open failures are closed on retest, and the remaining uncertainty is named. Approve with named conditions fits when a control is in place but a deadline, a language limit or a human review step is still attached. Hold fits when a high-severity failure is open, a required language was not tested, or the retest was run on a different configuration from the one that failed. Write the remaining uncertainty beside the decision.

Tooling can route an answer through separate factual, adversarial and source checks, and it can keep disagreements visible. Verification across several models reduces the risk of a confident but wrong answer but does not eliminate it. Judgement and the final decision remain with you.