Frontier AI Model Risk Frameworks Guide: Comparing AI Lab Safety Policies

Every major frontier AI developer now publishes a safety framework, but the frameworks use different vocabularies, change several times a year and are written for the lab's own decisions rather than for the organisations that buy and deploy the models. Security and risk teams are asked whether a model is "safe to use" and are pointed at documents such as Anthropic's Responsible Scaling Policy, OpenAI's Preparedness Framework and Google DeepMind's Frontier Safety Framework, alongside the EU General-Purpose AI Code of Practice and California's SB 53. This guide explains what these frameworks actually commit to, how they compare, which version is current, and how to turn them into evidence for your own AI supplier assessment and deployment controls. It is written for AI governance leads, security architects and third-party risk teams. Versions and dates were checked against each publisher's own pages on 24 October 2026.

Key takeaways

• Frameworks are about severe, catastrophic risk. They govern capability thresholds such as biological, cyber and autonomous AI research uplift, not the everyday risks of prompt injection, data leakage or excessive agency in your deployment.
• Versions move quickly. Anthropic's RSP went from version 3.0 in February 2026 to 3.4 in July 2026; Google DeepMind updated its framework to 3.1 in April 2026. Record the version you relied on.
• The common shape is threshold, evaluation, safeguard, decision. Each framework defines capability levels, tests models against them, requires safeguards when they are reached and names who decides whether to deploy.
• Regulation is converging on the same shape. The EU GPAI Code's Safety and Security chapter and California's SB 53 both require developers to publish or notify a framework and report serious incidents.
• Your controls still decide your risk. The 2026 evaluation incidents at Anthropic and Meta showed that harness configuration, network reach and credentials, not model policy, determined what the models could actually do.

What a frontier AI risk framework is

A frontier AI safety framework is a developer's published policy for deciding whether a new, highly capable model can be trained further, deployed internally or released, given the risk that it materially helps cause severe harm. The industry commitment behind them came at the AI Seoul Summit on 21 May 2024, where 16 companies (later 20) agreed to publish a safety framework, set thresholds for severe risks that would be "intolerable" without adequate mitigation, and in the extreme not develop or deploy a model if mitigations cannot keep risk below those thresholds.

• Frontier model: a general-purpose model at or near the leading edge of capability. Regulators define it by training compute: the EU AI Act presumes high-impact capabilities above 10^25 floating-point operations of cumulative training compute (Article 51(2)).
• Capability threshold: a defined level of dangerous capability (for example meaningful uplift to a weapons programme or the ability to automate AI research) that triggers stronger safeguards. Each lab names these differently.
• Safeguards: deployment controls (classifiers, access restrictions, monitoring, jailbreak response) and security controls (protection of model weights from theft or unauthorised release).
• Governance decision: the named body and evidence that decide whether a model proceeds, such as a safety case, capabilities report or risk report.

What the frameworks do not cover matters equally. They do not replace the OWASP Top 10 for LLM Applications 2025 risks in your application (LLM01 Prompt Injection, LLM06 Excessive Agency) or your obligations as a deployer. See the OWASP Top 10 for LLM Applications Guide and the LLM Security Guide.

The main lab frameworks compared

Every Seoul signatory committed to publish a framework, so expect one from any provider on that list and compare it against the same columns before relying on it. Where a model reaches you through a cloud provider or a SaaS product, the developer's framework still applies to the model, but the host's contract governs your data.

Reading the differences

• Commitment strength: Anthropic's version 3.0 announcement separates what the company will do unilaterally from an industry-wide map of capabilities to mitigations, and describes its roadmap goals as public but nonbinding. OpenAI's framework reserves the final deployment decision for leadership after Safety Advisory Group review. Read which statements are commitments and which are intentions.
• Internal deployment: Google DeepMind explicitly extends safety case review to large-scale internal deployment for advanced ML R&D CCLs. Internal use of agentic models with access to code and infrastructure is where enterprise-style identity and access controls become part of frontier safety.
• Cyber capability: all three track cyber capability in some form. For a security buyer this is the most relevant domain, because a model that crosses a cyber threshold will be deployed with extra safeguards that may also block legitimate red team and security operations use.
• Security of weights: Anthropic's ASL-3 security material describes model weight access controls and endpoint binary authorisation. These are familiar controls, and asking whether they are independently assessed is a reasonable supplier question.

Regulatory frameworks that now expect the same thing

• Security mitigations in the Code: the Safety and Security chapter requires protection of models and infrastructure against unauthorised release, access and theft, with an exemption for models weaker than one that is already publicly downloadable.
• Systemic risks named in the Code: the specified systemic risks are chemical, biological, radiological and nuclear risks, loss of control, cyber offence and harmful manipulation.
• Industry coordination: the Frontier Model Forum, a non-profit established in 2023, runs workstreams on frontier frameworks, AI-bio, AI-cyber, AI-nuclear and AI security.

See the EU General-Purpose AI (GPAI) Code of Practice Guide for the chapter-by-chapter detail and the EU AI Act Compliance Guide for deployer obligations.

Using frontier frameworks in supplier assessment

A framework is evidence about how a supplier governs its most dangerous risks. It is not a security attestation. Use it in four steps inside your existing third-party AI risk process (CSF 2.0 GV.SC-07; NIST SP 800-53 SR-6 Supplier Assessments and Reviews, SA-9 External System Services).

1. Confirm the framework exists and is current: record the URL, version and effective date, and whether the developer signed the EU Code's Safety and Security chapter. A developer with no published framework and a model near the frontier is a high-risk supplier in its own right. See the DeepSeek and High-Risk AI Vendor Assessment Guide.
2. Read the model-specific evidence: system cards, capabilities or risk reports and safety case summaries for the exact model version you will use. Check which thresholds were evaluated and which safeguards apply to your access route (consumer app, enterprise product, API or cloud marketplace).
3. Map safeguards to your use case: if you plan agentic use with tools, code execution or credentials, ask how the developer evaluates agent hijacking and prompt injection, and what monitoring applies to API traffic. Frameworks focused on CBRN thresholds may say little about this.
4. Set change triggers: a new framework version, a model crossing a new threshold, a disclosed safety incident or a change in signatory status should reopen the assessment.

Questions to ask a frontier model provider

• Which version of your safety framework applies to the model we are licensing, and where is the model-specific report?
• Which capability thresholds has this model been evaluated against, and did any trigger additional safeguards?
• Which of those safeguards apply to API and enterprise traffic, and which only to the consumer product?
• How are model weights protected, and has that protection been independently assessed?
• How will you notify customers of serious incidents involving this model, and on what timeline?
• Do third parties run your dangerous-capability evaluations, and how are their environments isolated?

Decision guidance

Applying frontier lessons to your own deployments

The same threshold, evaluation, safeguard and decision cycle works inside an enterprise, scaled down. A practical phased rollout:

1. Inventory: list every model in use, its developer, version, framework version and access route. Include models embedded in SaaS products.
2. Define your own thresholds: for example "can execute code", "holds write credentials to production", "can send external email". These are the deployment equivalents of capability thresholds (CSF 2.0 GV.RM-01, ID.RA-04).
3. Evaluate before deployment: run red team tests mapped to MITRE ATLAS AML.T0051 LLM Prompt Injection, AML.T0054 LLM Jailbreak and AML.T0053 AI Agent Tool Invocation, in an environment with no route to real third parties (NIST SP 800-53 SA-11, CA-8). See the AI Red Teaming Guide.
4. Pilot with safeguards on: start with read-only credentials and a small user ring, with full logging of prompts, tool calls and outcomes.
5. Decide and record: a named owner approves each step up in permissions, with the evidence attached, mirroring the safety case approach.
6. Roll back by design: keep the ability to revoke the agent's credentials, switch to a previous model version and disable tools without redeploying the application.

Where identity fits

Frontier frameworks reason about what a model could do. In production, what it can do is bounded by the identities and network paths it is given. In the 2026 evaluation incidents, the models used leaked passwords, exposed endpoints and credentials stored in files, and every significant step relied on a machine credential. Give each model deployment and agent its own non-human identity, scope its tokens to the minimum (AC-6 Least Privilege), enforce egress at the network layer (SC-7 Boundary Protection) rather than through prompt instructions, and make revocation a tested procedure. See the Red Teaming AI Agents for Identity Abuse guide.

Detection and measurement

• Track framework change: watch each supplier's framework page and version history; Anthropic publishes an explicit version table, which makes this a simple monitored check.
• Log model activity: prompts, tool invocations, credentials used, outbound connections and model version per request, so an incident can be tied to a specific model and framework version.
• Feed incidents back: treat a developer's disclosed safety incident as a trigger under IR-6 Incident Reporting and your supplier review.

Framework mapping

Common failure patterns

• Treating a framework as a certificate: a published policy says how the developer will decide, not that your deployment is secure. Frameworks rarely address prompt injection or excessive agency in your application.
• Citing an outdated version: an assessment that quotes RSP 2.2 or an earlier Preparedness Framework is describing a policy that no longer applies.
• Trusting evaluation isolation by assertion: in the Anthropic Claude Evaluation Incidents 2026, models told they had no internet access reached real organisations through a misconfigured third-party evaluation environment.
• Unscoped targets: in the Meta Muse Spark Evaluation Breach 2026, a scenario named a real website as the target and the environment had internet access, with safeguards removed for the test. The target given to an agent works as its authorisation.
• Ignoring the access route: safeguards described for a consumer product may not apply to raw API or marketplace access.
• No change trigger: Anthropic published five RSP versions between February and July 2026; an annual review misses most changes.

Lessons from incidents

The 2026 evaluation incidents are the clearest public evidence that frontier risk is partly an operational security problem. In both cases the dangerous-capability testing that frameworks require was itself the source of harm, because the environment's network reach and the credentials available to the model were wrong. Anthropic described its failure as closer to a harness and operational failure than a model alignment failure. For organisations running their own agent evaluations or red team exercises, the lesson is to verify egress blocking and target scope independently before every test cycle and to give test agents credentials that cannot reach anything real.

Practitioner checklist

• Record the developer, framework name, version and effective date for every model in use.
• Check whether each provider signed the EU GPAI Code and which chapters.
• Read the model-specific report for the exact model version and access route you use.
• Ask providers the six supplier questions above and file the answers with the assessment.
• Define deployment thresholds for code execution, write credentials and external communication.
• Red team agents in an environment with verified no-egress and fictional targets.
• Give each agent a dedicated identity with scoped, revocable credentials.
• Monitor framework pages and model versions and review within 30 days of a change.
• Treat disclosed developer safety incidents as triggers for supplier review.

Standards and references

• Anthropic: Responsible Scaling Policy
• OpenAI: Our updated Preparedness Framework
• Google DeepMind: Strengthening our Frontier Safety Framework
• European Commission: The General-Purpose AI Code of Practice
• European Commission: Guidelines for providers of general-purpose AI models
• Office of the Governor of California: Governor Newsom signs SB 53
• UK Government: Frontier AI Safety Commitments, AI Seoul Summit 2024
• Frontier Model Forum: About us

Related NHI Mgmt Group resources: EU General-Purpose AI (GPAI) Code of Practice Guide · Third-Party AI Risk Guide · AI Red Teaming Guide · AI Governance Guide · DeepSeek and High-Risk AI Vendor Assessment Guide. This guide summarises public frameworks and regulations and is not legal advice.