Google DeepMind's Frontier Safety Framework, explained: CCLs, TCLs and who checks them

The Frontier Safety Framework is Google DeepMind's published rulebook for deciding when one of its most capable AI models is dangerous enough to need extra safeguards. If you are asking what the Frontier Safety Framework is, it is a set of protocols that define capability thresholds, test for them, and commit Google to mitigations when a model reaches them. The current version, 3.1, is dated April 17, 2026, and it governs the Gemini 4 Argon release that went generally available on October 13, 2026.

Because every frontier lab now publishes something like it, knowing how to read one is a useful skill. This explainer walks through the structure, the terms and the criticisms.

What the framework says it does

DeepMind's page describes four components: identify the capability levels of frontier models, implement protocols to detect when they are reached across the model lifecycle, prepare mitigation plans for severe risks, and involve external parties where required or appropriate. It is used alongside Google's AI Principles and covers the company's most powerful foundation models.

The framework has been revised repeatedly. Version 1.0 appeared on May 17, 2024, 2.0 on February 4, 2025, 3.0 on September 22, 2025 and 3.1 on April 17, 2026, per DeepMind's page.

The vocabulary

Three terms do most of the work:

• Critical Capability Level, or CCL: a threshold where a model may pose heightened risk of severe harm unless mitigations are in place.
• Tracked Capability Level, or TCL: new in v3.1, a lower threshold aimed at "significant" harm, meant to trigger assessment and mitigation earlier.
• Alert threshold: an early warning that a model may be approaching a CCL.

The risk domains are chemical, biological, radiological and nuclear misuse, cyber, harmful manipulation, and a combined domain for machine learning research and development and misalignment. According to the Frontier Risk newsletter's analysis of v3.1, the last two had been separate, with misalignment previously exploratory. Two TCLs are described: one mirroring the CBRN level at the lower harm threshold, and one on stealth and situational awareness, asking whether control "cannot be ruled out as being significantly undermined."

Security levels and the process

For misuse risks, v3.1 recommends a Security Level 2+ standard. It keeps RAND's Security Level 2 as the baseline and adds protections against insider threats and well-resourced non-state actors, including dedicated insider risk teams, background checks for sensitive-access staff, red teaming that simulates capable adversaries, and 24/7 incident response, according to the same analysis.

The risk management process has five steps: risk identification, inherent risk assessment, mitigation, residual risk assessment and risk acceptance determination. v3.1 also adds "material capability change assessments" to judge whether a new model version is meaningfully different from the last.

How it shows up in a launch

When Google released Gemini 4 Argon on October 13, 2026, its launch post said the model was evaluated under the framework and described a layered defense. Google reported that external red teaming could unlock less than 1 percent of the biological sub-tasks tested, that violations on an adversarial harmful-request set fell nearly twofold against earlier Gemini models, and that an automated monitor reads agent reasoning and actions in real time. It said full details are in the model card. Those are Google's numbers, and the framework does not require independent confirmation of them. We covered the earlier restricted release in our report on the cyber-defenders-first launch.

The criticisms

External review is the main gap. An April 23, 2026 preprint by Barrett and colleagues applied the Assurance 2.0 method to an external review of DeepMind's public scheming inability safety case. The authors argue that developers who write their own safety cases face confirmation bias and conflicted incentives, and report the review "surfaced substantive new concerns that materially affect the scope of the safety case." The abstract does not detail the concerns.

The Frontier Risk analysis adds its own list. External parties may be engaged "as needed," with no detail on when or what they see. The line between "significant" and "severe" CBRN harm is not explained. The stealth and situational awareness level is vague about how it would be judged met. Governance lacks detail on decision-makers and on resolving internal disagreement. Thresholds are not well justified, and the framework does not commit to publishing risk reports, unlike Anthropic's approach, the author writes.

How it compares with government testing

The framework is a company policy. It is not law, and no regulator audits it. Government testers such as the UK AI Security Institute and the US Center for AI Standards and Innovation run their own evaluations, and access has been contested this autumn. See our tracker of pre-release model testing.

Why this matters beyond Google

A framework is also a promise that can be checked later. If a lab says a model stayed below a threshold, the framework tells you what evidence should exist: the evaluations run, the alert thresholds hit, and the mitigations applied. That gives reporters, regulators and rival labs a standard to hold the company to. It only works if the underlying evaluation results are published or shared with someone independent.

What we would do

Read any lab's framework for three things: whether thresholds are measurable, who outside the company can check a result, and what happens when a threshold is crossed. On those tests, the Frontier Safety Framework is clear on structure and thin on outside verification. Ask for the model card, ask which evaluators had pre-release access, and treat a "did not reach the threshold" result as a claim, not a finding, until someone outside Google confirms it.