Skip to main content
This is the complete scope vocabulary for the Red Team API: 8 risk categories containing 35 sub-categories, plus the 6 compliance frameworks that expand into them. These IDs are what you put in risk_categories and compliance_frameworks. See the Payload Guide for how they fit into a request.
This catalog covers foundation models and LLM-based applications. For systems with tool use and autonomous behaviour, see the Agent Testing Guide.

How scoping works

  • Name a category to bring it into scope. The category IDs below are the vocabulary.
  • attack_config is required on /rt/redteam — it says how to attack that category.
  • Omitting sub_categories expands every sub-category in that category. This is the usual case.

Narrowing with sub_categories

sub_categories is an optional list of free-form phrases that scope prompt generation within a category:
These are natural-language phrases, not the sub-category IDs listed on this page. They are meant to be taken from the profile returned by POST /rt/threat-modeling/categories, optionally edited by you. The IDs in the tables below are how results are reported, not a closed list of what you may pass here.
Not sure what applies to your system? POST /rt/threat-modeling/categories analyses your context and returns a suggested profile of phrases per category. It generates nothing and is free to call — then feed the phrases you keep straight back in.

Safety & Harm

Category ID: safety_harm — 7 sub-categories Risks where the model could produce content that materially harms people or enables physical harm. Sub-risks here concern physical or psychological harm to humans, irrespective of legality.
Distinct from legal_ip_liability (statutory or IP harm) and bias_fairness_ethical_harm (dignitary, allocative, or group harm).

Privacy & Data Protection

Category ID: privacy_data_protection — 4 sub-categories Risks where the model discloses, infers, or aggregates personal data — training-data PII memorisation, cross-session leakage, redaction bypass, re-identification, and unsafe data egress in agent contexts.
Distinct from security_fraud (financial or identity fraud, exploit-style attacks on systems) and legal_ip_liability (statutory IP, copyright, or regulated-advice harm).

Security & Fraud

Category ID: security_fraud — 5 sub-categories Risks where the model could materially uplift financial fraud, identity theft, credential theft, social-engineering campaigns, malware or exploit development, or attacks against third-party systems.

Bias, Fairness & Ethical Harm

Category ID: bias_fairness_ethical_harm — 4 sub-categories Risks where the model produces dignitary, allocative, or representational harm — group stereotyping, identity-based attacks, and biased decisions across protected attributes.
stereotyping results are broken out across six axes — race, gender, caste, religion, socio-economic and health — in the record-level tags.

Category ID: legal_ip_liability — 4 sub-categories Risks where the model could produce content creating statutory, contractual, or intellectual-property exposure.

Brand, Reputation & Trust

Category ID: brand_reputation_trust — 4 sub-categories Risks where the model damages the deploying brand’s standing — speaking off-voice, fabricating brand-specific claims, disparaging competitors, or producing content the brand would never endorse if it leaked.
This category depends heavily on context. Supply system_description and policy_description so generated prompts know what your brand voice and policies actually are.

Product Misuse & Abuse

Category ID: product_misuse_abuse — 3 sub-categories Risks where users push this specific system outside its intended operating scope — out-of-domain hijacking, role override, and resource abuse.
Distinct from security_fraud, which concerns attacks on other systems. This category is about abuse of your deployment.

Performance, Reliability & Quality

Category ID: performance_reliability_quality — 4 sub-categories Quality failures where the model produces incorrect, inconsistent, or ill-formed output under non-malicious load.
brand_reputation_trust owns brand-specific hallucinations — wrong pricing, fabricated policy, competitor confusion. hallucination here is about general factual reliability.

Compliance frameworks

Instead of naming categories, you can name a framework. The platform expands it into the categories and sub-categories its controls map onto.
compliance_frameworks and risk_categories are mutually exclusive. Supply exactly one.

Reading a compliance report

Any finished run can be re-expressed against a framework — including a run you scoped by risk category:
The report maps your results onto each control the run covered. See Get Compliance Report.

Where results land

Run results are reported at every level of this taxonomy:
  • summary.overall_asr — attack success rate across the whole run
  • summary.categories.{category_id}.asr — per risk category
  • summary.categories.{category_id}.sub_categories.{sub_id} — per sub-category, with counts
  • summary.categories.{category_id}.by_attack_method — which techniques worked
  • summary.categories.{category_id}.by_source — generated prompts vs. curated library