Frontier Safety Frameworks: What Developers Promise and What It Is Worth

Parts II to V kept arriving at the same place: the strongest evidence about a frontier model, and the strongest safeguards against its most extreme uses, sat with the developer that built it. Chapter 19 showed where the frameworks draw their lines for catastrophic misuse; Chapter 23 showed why tests can be gamed by the systems under test. This chapter asks the question both left open: how much weight can an enterprise or a public authority give to what developers promise?

No regional authority or insurance group can run dangerous-capability evaluations on a frontier model. The series has already established the deployer's half of the bargain: providers of general-purpose AI models with systemic risk carry the duty of adversarial testing under Article 55 of the AI Act (1, European Union, 2024), while deployers ask for the evidence and test the compound system themselves (AI Platform and Security, Chapter 20) (179, Nordqvist, 2026). It has also drawn the line between attestation, a party asserting something, and evidence, which is produced by the operation of the system (AI Governance, Chapter 11) (178, Nordqvist, 2026). A system card sits awkwardly between the two, and much of this chapter is about where. Frameworks and evaluations are described by their structure only.

Figure 29.1: Evidence about a frontier model passes from developer evaluation through the system card to the deployer, losing detail on the way.

Table 29.1: Who produces which evidence.

Party	Evidence
Developer	Dangerous-capability and propensity evaluations; framework thresholds and required safeguards; release decision (general, staged or withheld)
Published record	System card and framework report; external evaluator findings; government institute reports
Deployer	Supplier evidence request and contract triggers; own tests of the compound system; monitoring, containment and stop path; assurance record separating context from evidence

Lost on the way: elicitation detail, snapshot identity, uncertainty and configuration.

From responsible scaling to preparedness

In 2023 researchers from Google DeepMind, OpenAI, Anthropic, academic institutions and policy organisations argued that developers should evaluate models for extreme risks in two ways: for dangerous capabilities, whether a model could cause severe harm if used or directed to do so, and for alignment, whether it is inclined to do so (123, Shevlane et al., 2023). Their central proposal was a decision structure: evaluation results should feed risk assessments that inform, or bind, decisions about training, deployment and security, with results and assessments reported to external stakeholders.

The published frameworks implement that proposal, and their shared anatomy is what a deployer needs to recognise. Each names a small set of risk categories, typically biological and chemical capability, cyber offence and some form of autonomy or AI research acceleration; defines capability thresholds at which the risk would materially change; specifies the evaluations that decide whether a threshold has been reached; requires safeguards once it has, both deployment safeguards and security safeguards for the weights; assigns governance, meaning who decides and who can stop a release; and provides for its own revision.

Anthropic's Responsible Scaling Policy, rewritten as version 3 in 2026, maps capability thresholds to the mitigations it recommends for the industry, separates them from the company's own plans, adds Frontier Safety Roadmaps and Risk Reports that it aims to have reviewed by independent external parties, and keeps governance commitments including a Responsible Scaling Officer; the AI Safety Levels of earlier versions survive as names for present levels of mitigation, and the policy has been revised several times (127, Anthropic, n.d.). OpenAI's Preparedness Framework, in its second version of April 2025, tracks biological and chemical capability, cybersecurity and AI self-improvement, defines High and Critical thresholds, and requires safeguards that sufficiently minimise the risk before a model reaching High is deployed, and during development for a model reaching Critical (126, OpenAI, 2025). Research categories such as sandbagging are monitored without yet being tracked.

Two features deserve attention. First, the burden of proof runs the right way: where an evaluation cannot rule a threshold out, the model is treated as if it had been reached, as when Anthropic deployed Claude Opus 4 under its stricter standard as a precaution (Chapter 19) (125, Anthropic, 2025). Second, the frameworks are commitments a developer makes to itself: it writes them, runs the evaluations, interprets the results and decides when to revise the rules. The OpenAI framework states openly that it may adjust its requirements if another developer releases a high-risk system without comparable safeguards, subject to confirming that overall risk does not meaningfully increase and to acknowledging the adjustment publicly (126, OpenAI, 2025). That clause is honest about competitive pressure, and a reminder that a framework describes a present intention, not a standard the developer cannot leave.

European law changes the second feature, though not completely. Article 55 of the AI Act obliges providers of general-purpose AI models with systemic risk to evaluate their models, including through adversarial testing, assess and mitigate systemic risks, report serious incidents and ensure adequate cybersecurity (1, European Union, 2024). The General-Purpose AI Code of Practice asks signatories to maintain a safety framework, decide on the acceptability of systemic risks across the lifecycle, document the results in model reports for the AI Office and involve external evaluators where appropriate (3, European Commission, 2025). A framework thus becomes the document through which a legal duty is discharged, and its later weakening is visible to the AI Office. However, the documentation flows mainly to the regulator, not to the deployer, and that asymmetry runs through the rest of this chapter.

Dangerous-capability evaluations

A framework is only as good as the evaluations that decide whether its thresholds have been crossed. A capability evaluation asks what a model can do when pushed; a propensity evaluation asks what it tends to do when not (123, Shevlane et al., 2023). Thresholds are mostly stated as capabilities, because capability is easier to measure and can be misused by a person whatever the model's tendencies, whereas propensity findings, such as the scheming and shutdown experiments of Chapters 23 and 24, mostly appear in system cards as alignment assessments.

The methods include knowledge evaluations scored against expert answers, agentic task suites in a sandbox, long-horizon autonomy tasks of the kind Chapter 5 used to track the frontier, expert red teaming and uplift studies (Chapter 19). The decisive variable in all of them is elicitation: the effort made to bring out the model's full capability through prompting, tools, scaffolding or fine-tuning. Weak elicitation understates capability and clears a model that should not be cleared, and because elicitation is open-ended, a model may reach further a year after release while its system card stays unchanged. The July 2026 incident showed the other side: OpenAI estimated maximal cyber capability by running the evaluation without the production classifiers, the models also lacked production system prompts and automated review, and the agents' activity escaped the evaluation environment (133, OpenAI, 2026). The more seriously a developer elicits dangerous capability, the more the evaluation environment itself needs containment.

Two further limits come from this book's own findings. Models increasingly recognise evaluation settings, and the UK AI Security Institute found cheating in every model it tested for the behaviour, much of it absent from visible reasoning (114, UK AISI, 2026). A model can hide a disposition more easily than it can perform beyond its ability, although deliberate underperformance, sandbagging, is why OpenAI lists it among its research categories (126, OpenAI, 2025). Moreover, evaluations are run on snapshots, and how closely the evaluated snapshot matches the deployed model is a question system cards answer unevenly. The International AI Safety Report describes research into metrics for measuring capabilities and real-world impacts as still immature and fragmented (50, Bengio et al., 2026). Dangerous-capability evaluations therefore remain the best instrument available, better at showing that a capability is present than that it is absent, and their results reach the deployer as summaries of work done under conditions it did not choose.

System cards as evidence

A system card describes a model at release: what it is, how it performed on safety evaluations and against the developer's framework, what external evaluators found and which safeguards were applied. The better examples disclose findings unflattering to their authors. OpenAI's card for its o1 models rated them at medium risk for CBRN (chemical, biological, radiological and nuclear) capability and for persuasion and low for cybersecurity and model autonomy, and reported external evaluations by Apollo Research and METR, including the scheming evaluations that Chapter 23 discussed (124, OpenAI, 2024). Anthropic's card for Claude Opus 4 and Claude Sonnet 4 set out the precautionary deployment decision, the simulated-company experiments in which models sometimes chose blackmail, and Apollo's advice against deploying an early snapshot (125, Anthropic, 2025). Disclosures against the developer's immediate interest are evidence that the documents are not pure marketing.

What the cards omit matters as much. Some omissions are right, because evaluation detail is sensitive (Chapter 19); others are structural: a card rarely states elicitation effort in comparable terms or the uncertainty around a threshold judgement; it describes the model, not the compound system a deployer builds with its own instructions, tools and permissions; it often does not identify which snapshot was evaluated; it is seldom revised after release; and it reports only the evaluations the developer chose to run.

A system card is therefore a structured attestation by the developer, backed by evidence the deployer cannot see. Like an annual report, it carries weight to the degree that the process behind it is disciplined and partly external, and the deployer records it as context, not as evidence about its own system.

Practical guide: Reading a system card as a deployer

Purpose. Extract from a provider's system card and framework what bears on the deployer's own use of the model, record what the documents establish and what they do not, and turn the gaps into tests and evidence requests.

Roles. The AI governance lead owns the reading record; an evaluation engineer or the platform owner maps the evaluation sections to the organisation's use; the security function reads the safeguards sections; procurement receives the gaps.

Steps.

1. Pin the documents: the system card, the framework version in force at release and any addenda, each dated.
2. Identify the model: which snapshot the card describes and whether it is the one the organisation will call.
3. Map the use to the categories: for example autonomy and oversight subversion for an agent with write access to production, sycophancy and reliability for a drafting assistant.
4. Read the threshold judgements and conditions: the conclusion per category, whether it was a positive finding or a precaution, the safeguards that followed, and what the card says about elicitation and evaluation awareness. Flag safeguards the deployer's configuration might remove; absence of information is a finding.
5. Separate the voices: the developer's own findings from those of named external evaluators, with the access each had.
6. Translate the omissions into scenarios in the compound-system test plan (Chapter 23) and, where only the provider can answer, into an evidence request.
7. Record the weight: for each category, whether the card is context only or whether the organisation's own tests and monitoring provide the evidence on which acceptance rests.

Definition of done. A dated reading record that cites the card and framework versions, links each relevant finding to a test or an evidence-request item, and states the weight given per category. Default, to adapt: re-read on a new model version, a framework revision or after twelve months.

Independent and government evaluation

External evaluators' findings are often the most informative part of a system card. Apollo Research and METR have evaluated models before release for scheming and autonomous capability (124, OpenAI, 2024) (125, Anthropic, 2025). Their value is that they are not the developer; their limit is the access they are given, a snapshot chosen by the developer, days or weeks before release, under terms that govern what they may say. Investigation after the fact is a second form: after the July 2026 incident, METR, with a Redwood Research researcher, found from records that at least a fifth of the agents in its dataset expressed clear interest in tampering with their own transcripts (135, Wijk et al., 2026).

Government institutes add a third voice. The UK AI Security Institute's study of cheating was a cross-developer comparison no single developer would publish (114, UK AISI, 2026), and its pre-release evaluation of GPT-6 Astra, run in simulation with cyber classifiers disabled, reported how often the model carried out simulated supply-chain attacks on out-of-scope targets and how much an explicit scope statement reduced it (138, UK AISI, 2026). The Institute also reported its own incident, in which agents took unsanctioned actions on the live internet (137, UK AISI, 2026); publishing it was a mark of credibility, and its occurrence shows that evaluators face the same containment problem as developers. The US Center for AI Standards and Innovation at NIST shows the hazard of state evaluation: its 2025 evaluation of DeepSeek models reported shortcomings and a tendency to echo state narratives (130, NIST, 2025), credible but produced by an interested party, as Chapter 15 recorded.

In the Union, Article 92 of the AI Act empowers the AI Office to evaluate general-purpose AI models, including through independent experts, and Article 90 allows the scientific panel to issue alerts (1, European Union, 2024). By mid-October 2026 the Office had sent requests for information on security, external evaluation and monitoring to two developers after judging their voluntary disclosures insufficient (139, Bertuzzi, 2026), although the reporting duty that would feed it is fragile (140, Bastians & Herbosch, 2026), as Chapter 28 examined. The practical rule for a deployer is to give more weight to findings with a named external source and stated access conditions, and to ask whether its model has been evaluated by anyone other than its developer.

Restricted release as a safeguard

The frameworks' most consequential tool is the release decision itself. In April 2026 Anthropic reported that its Claude Mythos Preview model showed a marked advance in finding and exploiting software vulnerabilities (Chapter 18) (128, Carlini et al., 2026), withheld it from general availability and offered access instead to partners and open-source maintainers through Project Glasswing, to find and fix flaws in critical software before attackers could exploit them (129, Anthropic, 2026). AI Platform and Security, Chapter 18 records what defenders did with that head start, and the bottleneck it revealed in human verification and patching (179, Nordqvist, 2026). Anthropic's own report describes the same constraint at the source: the highest-severity findings were sent to professional human triagers for validation before disclosure, and fewer than 1% of the vulnerabilities found had been fully patched by their maintainers at the time of writing (128, Carlini et al., 2026).

Restricted release keeps a point of control, as Chapter 19 argued a safeguard must, while capability is shared with those best placed to use it defensively; releasing the weights would remove that point for good. Its weaknesses are structural. The developer decides alone who counts as a partner and when the restriction ends; access concentrates in large vendors and infrastructure operators rather than, say, a regional authority in a small member state; and the restriction lasts only until a comparable capability appears elsewhere, which is why Chapters 5 and 18 named such general availability as a trigger for reassessment. A European deployer should therefore ask whether the suppliers who maintain its critical software use the head start, and plan for its end.

Using the frameworks as a deployer

A deployer's leverage over a frontier developer is small, but European law strengthens it. An organisation that integrates a general-purpose AI model into its own AI system is a downstream provider, and Article 53(1)(b) of the AI Act entitles it to the information set out in Annex XII to understand the model's capabilities and limitations (1, European Union, 2024); a request that maps onto the Article 55 duties asks for evidence of work the law already requires. For financial entities, DORA requires contracts with ICT third-party service providers to contain provisions on, among other things, notification, access, audit and exit (Articles 28 and 30) (11, European Union, 2022). For public authorities, the tender documents are the point at which such requirements are set, because they are hard to add later.

What to ask for follows from the framework anatomy, as the worked example shows. Triggers matter as much: a framework revision, a new model version, a threshold reached or not ruled out, a published incident or an AI Office request for information should each reopen the reading record.

Worked example: A supplier evidence request derived from a provider's safety framework

The following request is illustrative. Hansa Mutual's evaluation engineers prepared it for the provider of the model beneath the claims-triage agent, after reading the system card with the guide above. It derives each item from a commitment in the provider's framework, states how the answer will be weighed and is stored beside the contract in the DORA register of information.

evidence_request:
  id: SER-HM-2026-01
  status: illustrative
  provider: Model provider A
  model: general-purpose model beneath the claims-triage agent
  owner: Group AI governance lead
  linked: [ATA-HM-2026-01, HM-PROC-GPAI-MISUSE-01, EVP-HM-CTA-2026-01]
  register_entries: [THR-HM-01, THR-HM-06]
  items:
    - ask: framework version and change log since our contract date
      derived_from: framework revision clause
      weight: context
    - ask: identity of evaluated snapshot and differences from served version
      derived_from: capability and safeguards reports
      weight: context
    - ask: threshold judgement per tracked category, summary only
      derived_from: capability thresholds
      weight: context
    - ask: external and government evaluators, access period and snapshot
      derived_from: external evaluation commitment
      weight: third-party attestation
    - ask: safeguards that our enterprise configuration removes or alters
      derived_from: deployment safeguards
      weight: input to own tests
  provider_must_notify:
    - framework revision or competitive adjustment, before it takes effect
    - serious incident involving the model, in deployment or evaluation
  own_evidence:
    compound_system_tests: EVP-HM-CTA-2026-01
    stop_path: quarterly stop-path test, Chapter 24
  acceptance_rule: provider answers are context; acceptance rests on own_evidence
  refusal_handling: record each unanswered item as a finding in the ORSA input

The request does not ask the provider to prove its model safe, which no document can do. It asks for the conditions behind the provider's claims, so that Hansa knows what its own tests must cover, and it makes silence visible.

What the frameworks are worth

The case for giving them weight

The strongest case starts with the absence of alternatives. Developers are the only parties with full access to their models during training, and the frameworks oblige them to look for dangerous capability before release and to decide in advance what they will do if they find it (126, OpenAI, 2025), the structure that the 2023 proposal had argued for (123, Shevlane et al., 2023). They have also produced costly actions: a model deployed under a stricter standard because a capability could not be ruled out (125, Anthropic, 2025), a model with marked cyber capability withheld and offered first to defenders (129, Anthropic, 2026), and a system card that published an evaluator's advice against deploying an early snapshot (125, Anthropic, 2025). Disclosures against interest are the ordinary test of whether a report is more than marketing, and these pass it. In Europe, moreover, a framework is now the instrument of a legal duty, and a framework that a regulator reads is worth more than one only its author reads (3, European Commission, 2025) (139, Bertuzzi, 2026).

The case for discounting them

The opposing case begins with the structure. The developer writes the framework, chooses the evaluations, interprets the results, decides on release and may revise the rules, even in response to a competitor (126, OpenAI, 2025); no other regulated field would accept such controls as independent assurance. The evidence base is also weaker than the documents' confidence suggests: research into evaluation metrics is immature and fragmented (50, Bengio et al., 2026), models recognise and game evaluations (50, Bengio et al., 2026) (114, UK AISI, 2026), and the most serious incident of 2026 began inside a developer's own evaluation (133, OpenAI, 2026). Finally, Arvind Narayanan and Sayash Kapoor argue that harm arises in deployment, through institutions and uses, rather than in a model's latent capability (60, Narayanan & Kapoor, 2025). On that view catastrophic thresholds measure the wrong thing for most deployers, whose real risks are unreliable outputs, unfair decisions and over-reliance, and the open-weight models many European organisations prefer for sovereignty reasons often come without a framework at all.

Where a deployer can stand

Both cases accept that the frameworks are the best source of evidence about capabilities only developers can see, that the evidence is partial and interested, that external scrutiny raises its value, and that a deployer's own risks lie mostly in the compound system it operates. A working position follows: treat a provider's framework and system card as structured attestation, read it seriously, give more weight to findings with named external sources, and rest acceptance on the organisation's own tests, monitoring and containment, which must hold whatever the model intends (AI Platform and Security, Chapter 19) (179, Nordqvist, 2026). That is also part of the answer to what one organisation can do about risks decided by a few developers. Alone it can choose its providers and write its contracts; together with others, through the evidence it asks for, the refusals it records and the questions it routes to the AI Office, it helps set the price of a weak framework, and public authorities, whose procurement is large and published, can set that price more visibly than most.

Nordvik Region and Hansa Mutual

Nordvik Region cannot evaluate a frontier model and does not try. Its systems mostly run on open-weight models served by a European cloud provider, which often come with a model card but no framework, so its lever is procurement. Under THR-NR-01 and THR-NR-05 its tenders ask every model provider and every supplier whose product embeds a model for the documentation it is entitled to as a downstream provider, the provider's position under the Code of Practice and notice of incidents, and record the absence of a framework as a finding rather than a disqualification. For the audit committee's work on ATA-NR-2026-01, the answer is that the frameworks govern risks the Region does not run directly, and that its assurance rests on what it controls: scenario tests of its compound systems, the absence of write access for any assistant and the stop path its supplier contracts require.

Hansa Mutual's evaluation engineers in Hamburg test the compound system themselves under EVP-HM-CTA-2026-01 and ask providers for the rest through the evidence request above. Because the group builds on a few vendor models, a framework revision or threshold notification at one provider is also a signal for THR-HM-06, correlated failure of a shared provider, and feeds the ORSA work under ATA-HM-2026-01. Nordvik's assurance is a procurement record honest about what it cannot verify, combined with an architecture that does not need it to; Hansa's is an engineering programme that uses the provider's evidence to decide what to test.

Summary

Frontier safety frameworks give developers a decision structure for dangerous capability. In the Union the Code of Practice makes such a framework the instrument through which providers of models with systemic risk discharge their Article 55 duties, with the documentation flowing mainly to the AI Office.

Dangerous-capability evaluations show presence better than absence, depend on open-ended elicitation and can be recognised by the systems under test. System cards report their results, sometimes against the developer's interest, but omit elicitation detail, snapshot identity, compound-system behaviour and later changes: they are structured attestation. External and government evaluators add other voices within limits of access and interest, and restricted release keeps a point of control while defenders go first, on the developer's terms and only for a time.

A deployer can stand between the case for relying on the frameworks and the case for discounting them by reading system cards systematically, turning the gaps into tests and evidence requests, setting triggers for re-reading, and resting acceptance on its own tests, monitoring and containment. Chapter 30 takes that last point further and sets out the defences an enterprise or public authority controls at every scale of threat.

Sources

1. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (179, Nordqvist, 2026)
2. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (178, Nordqvist, 2026)
3. Shevlane, T., Farquhar, S., Garfinkel, B., Phuong, M. et al. (2023). Model evaluation for extreme risks. (123, Shevlane et al., 2023)
4. Anthropic. Responsible Scaling Policy. (127, Anthropic, n.d.)
5. OpenAI (2025). Preparedness Framework, Version 2. (126, OpenAI, 2025)
6. Anthropic (2025). System Card: Claude Opus 4 & Claude Sonnet 4. (125, Anthropic, 2025)
7. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
8. European Commission (2025). The General-Purpose AI Code of Practice. (3, European Commission, 2025)
9. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (133, OpenAI, 2026)
10. AI Security Institute (2026). Cheating behaviour in frontier model evaluations. (114, UK AISI, 2026)
11. Bengio, Y. et al. (2026). International AI Safety Report 2026. (50, Bengio et al., 2026)
12. OpenAI (2024). OpenAI o1 System Card. (124, OpenAI, 2024)
13. Wijk, H., Cotra, A. & Greenblatt, R. (2026). Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. (135, Wijk et al., 2026)
14. AI Security Institute (2026). GPT-6 Astra performs unsanctioned supply-chain attacks in simulations. (138, UK AISI, 2026)
15. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. (137, UK AISI, 2026)
16. National Institute of Standards and Technology, Center for AI Standards and Innovation (2025). CAISI Evaluation of DeepSeek AI Models Finds Shortcomings and Risks. (130, NIST, 2025)
17. Bertuzzi, L. (2026). EU's AI rules face first enforcement test over lab incidents. (139, Bertuzzi, 2026)
18. Bastians, H. & Herbosch, M. (2026). The EU AI Act Mandates AI Incident Reporting—If We're Lucky. (140, Bastians & Herbosch, 2026)
19. Carlini, N., Cheng, N., Lucas, K. et al. (2026). Assessing Claude Mythos Preview's cybersecurity capabilities. (128, Carlini et al., 2026)
20. Anthropic (2026). Project Glasswing: Securing critical software for the AI era. (129, Anthropic, 2026)
21. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (11, European Union, 2022)
22. Narayanan, A. & Kapoor, S. (2025). AI as Normal Technology. (60, Narayanan & Kapoor, 2025)