Examples
Examples from published documents
- Inability: a cyber safety case template argues a model "does not have capabilities posing unacceptable cyber risks" by breaking the claim into sub-claims supported by evaluation evidence (Goemans et al., Safety case template for frontier AI, 2024, Abstract)
- Control: a sketch argues "that a hypothetical LLM agent deployed internally at an AI company won't exfiltrate sensitive information" because monitoring stops red-team attack strategies (Korbak et al., A sketch of an AI control safety case, 2025, Abstract)
- Clymer et al. expect developers to rely "mostly" on "inability, then control, then trustworthiness" as systems advance (Clymer et al., Safety Cases: How to Justify the Safety of Advanced AI Systems, 2024, §2.2)
Counter-examples
Not to be confused with
- A failed capability evaluation is evidence, not an argument type: it supports an inability argument only if elicitation was strong enough to bring out the capability.
- A safeguard is not a control argument; the control argument is the further claim, tested by red-teaming, that the model and users cannot evade the safeguard.
Related terms
Related AI safety terms
Terms defined under this element that are not NIKOLAI elements themselves, each as the cited document uses it. Every term is also listed in the AI safety glossary.
- Inability argument
- An inability argument claims an AI system cannot cause an unacceptable outcome in any realistic setting, even without safeguards, typically shown by its failure on red-team-designed proxy tasks after strong capability elicitation.
- Source: Clymer, Gabrieli, Krueger and Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462, 2024)
- Control argument
- A control argument claims an AI system cannot cause an unacceptable outcome given the control measures around it, such as monitoring, assuming conservatively that the model and users pursue their best strategy to evade those measures.
- Source: Clymer, Gabrieli, Krueger and Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462, 2024)
- Trustworthiness argument
- A trustworthiness argument claims that even if an AI system could cause a catastrophe, it will not, because it robustly behaves as intended, for example following developer-specified rules across a wide range of reliably evaluated situations.
- Source: Clymer, Gabrieli, Krueger and Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462, 2024)
- Deference argument
- A deference argument relies on AI advisors, themselves shown to be trustworthy, judging that other AI systems are safe, much as regulators rely on human experts. It is expected to matter only once AI systems become much more powerful.
- Source: Clymer, Gabrieli, Krueger and Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462, 2024)
- Proxy task
- A proxy task is a task a red team designs so that if an AI system cannot accomplish it, the system also cannot carry out a strategy for causing an unacceptable outcome; inability arguments rest on such tasks.
- Source: Clymer, Gabrieli, Krueger and Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462, 2024)
Source of record
Where this definition comes from
Clymer, Gabrieli, Krueger and Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462, 2024), §2.2
“"we describe four categories: inability, control, trustworthiness, and deference." Inability arguments: "AI systems are incapable of causing unacceptable outcomes in any realistic setting." Control arguments: "AI systems are incapable of causing unacceptable outcomes given existing control measures." Trustworthiness arguments: "Even if AI systems are capable of causing catastrophic outcomes, they will not do so because they robustly behave in an intended way." (§2.2)”
https://arxiv.org/abs/2403.10462Goemans, Buhl, Schuett, Korbak, Wang, Hilton and Irving, Safety case template for frontier AI: A cyber inability argument (arXiv 2411.08088, 2024), §1
“"We focus on inability ('the system is not capable of X, even absent any safeguards') because it offers the simplest and best understood argument for why a system will not behave in a certain way." "Other arguments for why a model will not behave in a certain way include control ('the system is not capable of X, given existing safeguards') and trustworthiness ('even if the system is capable of X, it will consistently behave in a desirable way, thus avoiding X')" (§1)”
https://arxiv.org/abs/2411.08088
Crosswalk
How named organisations use this concept
| Organisation | Their term, as published | Match & verification | Source |
|---|---|---|---|
| Clymer, Gabrieli, Krueger and Larsen (academic paper)Shadow mapping Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462) | “Four categories: "inability, control, trustworthiness, and deference"; deference arguments: "AI advisors assert that other AI systems do not pose a catastrophic risk, and these AI advisors are at least as credible as human decision-makers." (§2.2)” Academic paper; the origin of the four-way classification used here. | exactEQ confidence: high | Clymer, Gabrieli, Krueger and Larsen, Safety Cases: How to Justify the Safety of Advanced AI Systems (arXiv 2403.10462, 2024) |
| UK AI Security Institute (AISI)Shadow mapping Safety case template for frontier AI: A cyber inability argument (Goemans et al., Centre for the Governance of AI and UK AISI, 2024) | “inability ("the system is not capable of X, even absent any safeguards"), control ("the system is not capable of X, given existing safeguards") and trustworthiness ("even if the system is capable of X, it will consistently behave in a desirable way, thus avoiding X") (§1).” Uses three of the four categories; deference is not discussed. | exactEQ confidence: high | Goemans, Buhl, Schuett, Korbak, Wang, Hilton and Irving, Safety case template for frontier AI: A cyber inability argument (arXiv 2411.08088, 2024) |
| UK AI Security Institute (AISI)Shadow mapping A sketch of an AI control safety case (Korbak et al., UK AISI and Redwood Research, 2025) | “A "control safety case", "which is a structured argument that models are incapable of subverting control measures in order to cause unacceptable outcomes" (Abstract).” Covers the control value only. | narrowNR confidence: high | Korbak, Clymer, Hilton, Shlegeris and Irving, A sketch of an AI control safety case (arXiv 2501.17315, 2025) |
| OpenAIShadow mapping OpenAI Preparedness Framework v2 | “Misaligned-model safeguard claims include "Lack of Autonomous Capability: The model is not capable of carrying out tasks autonomously, including the risk of severe harm.", "Reliable and Robust System Oversight: Effective AI and human oversight of model actions detects and prevents execution of harm or subversion of safeguards." and "Value Alignment: The model consistently applies human values in novel settings" (App. C).” CASRAI reading: these claims correspond roughly to inability, control and trustworthiness arguments; OpenAI does not use those labels. | closeCL confidence: medium | OpenAI Preparedness Framework v2 |
| Google DeepMindShadow mapping Gemini 3.7 Flash FSF Report | “"Currently, the severe misuse and misalignment threat models have been bottlenecked by models' inability to independently execute complex ML R&D tasks, and their inability to circumvent standard human oversight." (p.34)” CASRAI reading: an instance of an inability argument (with a reliance on oversight), not a classification scheme. | narrowNR confidence: medium | Gemini 3.7 Flash FSF Report |
| AnthropicShadow mapping Anthropic Risk Report, August 2026 | “"Because of our models' relatively weak covert capabilities, we believe they lack the behavioral propensities—as well as the capabilities—to present substantial risk of catastrophic harm." (§5.4)” CASRAI reading: combines a capability-based (inability) argument with a propensity-based (trustworthiness) one; the report does not use these labels. | narrowNR confidence: medium | Anthropic Risk Report, August 2026 |
What do these codes mean?
- exact
- The source term is equivalent to this element
- close
- The source term is close but not equivalent to this element
- broad
- The source term is broader than this element
- narrow
- The source term is narrower than this element
- none
- No mapping claim — used for false-friend and declared-but-undefined rows
- EQ
- Equivalent
- CL
- Close
- BR
- Source is broader than the element
- NR
- Source is narrower than the element
- FF
- False friend — same or similar label, different meaning
- DU
- Declared but undefined by the source
- UV
- Unverified
Related, not mapped
Pointers that are not crosswalk claims
These sources mention this concept but do not define or map it clearly enough to count as a crosswalk row — noted here so the research is visible without overstating it as a mapping.
- UK AI Security Institute (AISI)
Explains why argument types are expected to shift as capabilities grow; context, not a mapping.
UK AI Security Institute blog: Safety cases at AISI (Irving, 23 Aug 2024)
Gap
None of the lab frameworks or reports reviewed labels its safety arguments as inability, control, trustworthiness or deference; the OpenAI, Google DeepMind and Anthropic rows are CASRAI's own mapping of their wording onto these categories.
