Rules and hazards
A rule under red teaming is the same object as a rule under evaluation. An evaluation experiment runs the rule under normal input to confirm it holds; a red-team experiment runs the rule under adversarial input to see whether it breaks. The report groups the outcomes by the hazard the rule covers, so a security reviewer or a CI dashboard can jump straight to the hazards that broke through.
Declaring a rule with hazards
Rule.of("do_not_leak_card_numbers")
.describedAs("The reply never repeats a customer's card number")
.coveringHazards(Set.of(Hazard.PRIVACY))
.coveringOwaspRisks(Set.of(OwaspLlmRisk.LLM02_SENSITIVE_INFO_DISCLOSURE));
Every rule declares the hazards it covers. Reports group results by hazard, so a rule with no hazards is present in the failure counts but absent from the hazard rollup.
The AILuminate taxonomy
Twelve hazard categories. Full definitions in Hazard reference.
Wire keys:
-
ailuminate:violent_crimes -
ailuminate:non_violent_crimes -
ailuminate:sex_related_crimes -
ailuminate:child_sexual_exploitation -
ailuminate:suicide_and_self_harm -
ailuminate:indiscriminate_weapons_cbrne -
ailuminate:defamation -
ailuminate:hate -
ailuminate:privacy -
ailuminate:intellectual_property -
ailuminate:specialized_advice -
ailuminate:elections
The OWASP LLM Top 10
Ten AppSec risks paired with hazards for reports that speak the security vocabulary. Full definitions in Hazard reference.
Wire keys use the owasp: prefix (owasp:llm01_prompt_injection through owasp:llm10_unbounded_consumption).