Frontier AI Safety and Security Framework: [Developer] [Model family]
Safety and security framework for a developer of advanced or
general-purpose AI models: scope and applicability, systemic risk
identification, capability thresholds and risk tiers, evaluations and
red teaming, safety and security mitigations, model weight security,
deployment decisions, model reports, serious incident reporting,
whistleblower channels, governance, external review and framework
updates. The structure follows the ten commitments of the Safety and
Security chapter of the EU General-Purpose AI Code of Practice
(final, 10 July 2025) for providers of general-purpose AI models with
systemic risk under Articles 51 and 55 of the EU Artificial
Intelligence Act (Regulation (EU) 2024/1689 as amended by Regulation
(EU) 2026/1744), and maps to the frontier AI framework required by
California SB 53, the Transparency in Frontier Artificial
Intelligence Act (in force 1 January 2026), and the New York RAISE
Act as amended in March 2026 (effective 1 January 2027). Replace every
[bracketed] value and every row marked Example. Thresholds shown
are examples, not regulatory values unless the text says so; check
the consolidated texts. This is a documentation format, not legal
advice.
Document control
| Field | Value |
|---|
| Document ID | [FSF-001] |
| Developer | [Legal name, affiliates included in revenue test] |
| Models covered | [Model family, versions, release dates] |
| Regimes | [EU AI Act GPAI with systemic risk / SB 53 / RAISE / voluntary] |
| Code of Practice signatory | [Yes: Safety and Security chapter, date / No] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Published / Superseded] |
| Owner | [@frontier-safety-lead] |
| Approvers/reviewers | [@ceo], [@board-risk-committee], [@cso], [@general-counsel], [@head-of-research] |
| Last updated | YYYY-MM-DD |
| Next scheduled assessment | YYYY-MM-DD (at least every 12 months) |
| Publication | [URL of published version / redacted annex reference] |
| Classification | [Public version / Restricted annex: confidential] |
Approvals
| Role | Name | Decision | Date |
|---|
| Executive management body | [@name] | [Approve / Reject] | YYYY-MM-DD |
| Supervisory body (board risk committee) | [@name] | [Oversight confirmation] | YYYY-MM-DD |
| Head of frontier safety | [@name] | [Approve] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Approve security sections] | YYYY-MM-DD |
| General counsel | [@name] | [Approve] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary | Material? | Published |
|---|
| 0.9 | YYYY-MM-DD | [@name] | Draft for board review | n/a | No |
| 1.0 | YYYY-MM-DD | [@name] | Example: First approved framework | Yes | YYYY-MM-DD |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added autonomous replication evaluation to loss-of-control tier 2 | Yes | YYYY-MM-DD |
Contents
1. Scope and applicability
1.1 Applicability tests
| Regime | Test (summary) | Our figure | Applies? | Evidence |
|---|
| EU AI Act Art. 51 | GPAI model with high-impact capabilities; presumed when cumulative training compute exceeds 10^25 floating-point operations, or designated by the Commission | Example: 3.1 x 10^25 FLOP (estimate method M-02) | Yes | Compute report EV-001 |
| EU AI Act Art. 52 | Notify the Commission within two weeks of meeting, or knowing you will meet, the threshold | Example: notified YYYY-MM-DD | Done | EV-002 |
| California SB 53 | Frontier model: foundation model trained with more than 10^26 operations, including fine-tuning, reinforcement learning and material modifications; large frontier developer: frontier developer with affiliates above 500 million USD annual gross revenue in the preceding year | Example: 1.4 x 10^26; revenue above threshold | Yes, large frontier developer | EV-003 |
| New York RAISE Act (amended) | Frontier model and large frontier developer tests broadly aligned with SB 53 after the March 2026 chapter amendment; check the enacted text | Example: same figures as SB 53 | Yes from 1 January 2027 | EV-004 |
| Korea AI Basic Act | Safety duties for AI above a cumulative compute level set by Enforcement Decree (reported as 10^26 FLOP) | [Figure] | [Yes / No] | [Evidence] |
1.2 Models and activities covered
| Model | Stage | Release type | Internal use? | Covered by |
|---|
| MDL-001 (Example) [Model] v3 | Deployed | API and chat product | Yes, research agents | All regimes above |
| MDL-002 (Example) [Model] v4 | In training | Planned closed release | Yes | All; pre-deployment review required |
| MDL-003 (Example) Distilled small model | Deployed | Open weights | No | AI Act GPAI obligations only (below systemic risk threshold) |
Internal use counts: SB 53 asks the framework to address catastrophic
risk from internal use, including a model circumventing oversight, and
large frontier developers send periodic summaries of internal-use risk
assessments to the California Office of Emergency Services.
2. Systemic risk identification
2.1 Risk register
| ID | Systemic risk | Source of the risk | Scenario (summary) | Code appendix type | SB 53 catastrophic risk? |
|---|
| SR-CBRN (Example) | Chemical, biological, radiological, nuclear | Expert-level uplift to novices | Model provides step-by-step guidance that meaningfully lowers barriers to producing a biological agent | Specified | Yes |
| SR-CYB (Example) | Cyber offence | Autonomous vulnerability discovery and exploitation | Agentic model chains discovery and exploitation against critical infrastructure without human direction | Specified | Yes (cyberattack without meaningful human oversight) |
| SR-LOC (Example) | Loss of control | Deception, oversight evasion, self-exfiltration | Model under agent scaffold disables monitoring and copies its weights | Specified | Yes (evading control) |
| SR-MAN (Example) | Harmful manipulation | Persuasion at scale | Model targets individuals with tailored political persuasion | Specified | Usually no; record reasoning |
| SR-OTH-01 (Example) | [Other identified risk] | [Source] | [Scenario] | Identified by us | [Yes / No] |
2.2 Catastrophic risk definition used
SB 53 defines catastrophic risk as a foreseeable and material risk that
the developer's model materially contributes to the death of, or
serious injury to, more than 50 people, or more than 1 billion USD in
property damage, from a single incident involving expert-level CBRN
assistance, a cyberattack or serious crime conducted without meaningful
human oversight, or the model evading the control of its developer or
user. Record here how your internal severity scale relates to that
definition: [Example: internal severity level S4 and S5 correspond to
the SB 53 definition.]
3. Systemic risk analysis and evaluations
3.1 Evaluation suite
| ID | Risk | Evaluation | Type | Elicitation | Run by | Checkpoints |
|---|
| EVL-001 (Example) | SR-CBRN | Biology protocol troubleshooting benchmark | Automated benchmark | Best prompting plus tool access | Internal | 25%, 50%, final, pre-deployment |
| EVL-002 (Example) | SR-CBRN | Expert red team, wet-lab uplift study design review | Human red team | Unrestricted model, expert testers | External lab [name] | Final |
| EVL-003 (Example) | SR-CYB | Capture-the-flag suite, professional difficulty | Agentic | Full agent scaffold, 50 attempts per task | Internal | Each checkpoint |
| EVL-004 (Example) | SR-CYB | Range exercise against emulated industrial network | Agentic | Scaffold plus human-in-the-loop baseline | External | Final |
| EVL-005 (Example) | SR-LOC | Oversight evasion and sandbagging probes | Behavioural | Agent with monitoring hooks | Internal alignment team | Final, pre-deployment |
| EVL-006 (Example) | SR-LOC | Autonomous replication and adaptation tasks | Agentic | Cloud sandbox | External | Final |
| EVL-007 (Example) | SR-MAN | Persuasion study with consenting participants | Human study | Production system prompt | Internal research, ethics approved | Major versions |
3.2 Risk modelling and estimation
For each risk, describe the pathway from model capability to harm,
the steps where the model provides uplift, and the estimate of
likelihood and severity with and without mitigations. Example: for
SR-CBRN the model is mapped against an attack chain of seven steps; the
evaluations measure uplift at the three steps where knowledge is the
main barrier.
3.3 Post-market monitoring inputs
| Source | Signal | Feeds |
|---|
| Example: Abuse detection classifiers | Rate of blocked CBRN queries | SR-CBRN estimate |
| Example: Bug bounty and researcher reports | Jailbreak reports | Safeguard effectiveness |
| Example: Downstream provider reports | Misuse cases | All risks |
| Example: Internal agent telemetry | Oversight anomalies | SR-LOC |
4. Risk tiers, thresholds and acceptance
4.1 Tier definitions
| Tier | Meaning | Required mitigations | Acceptance authority |
|---|
| T0 (Example) | No meaningful uplift over public resources | Baseline safety training and usage policy | Head of frontier safety |
| T1 (Example) | Early warning: capability approaching a level of concern | Enhanced monitoring, targeted refusals, security level S2 | Head of frontier safety |
| T2 (Example) | Capability that could provide significant uplift to a known threat actor | Classifier safeguards, trusted access programme, security level S3, external review | Executive management body |
| T3 (Example) | Capability that could cause catastrophic harm if misused or uncontrolled | Do not deploy externally; restrict internal use; security level S4; notify board | Supervisory body; default is not to proceed |
4.2 Capability thresholds per risk
| Risk | T1 trigger | T2 trigger | T3 trigger |
|---|
| SR-CBRN (Example) | Exceeds median expert baseline on EVL-001 | Red team confirms meaningful uplift on two or more attack chain steps | Uplift across full chain in EVL-002 |
| SR-CYB (Example) | Solves 30% of professional CTF tasks | Completes an end-to-end range intrusion with minor human help | Completes range intrusion autonomously |
| SR-LOC (Example) | Any successful oversight evasion in probes | Repeated evasion or sandbagging detected | Successful autonomous replication in sandbox |
4.3 Safety margins and acceptance
Explain the margin between measured capability and each threshold, how
uncertainty in elicitation is handled, and the rule when results are
ambiguous. Example: where results fall within 10 percentage points of
a trigger, the model is treated as having reached the next tier.
5. Safety mitigations
| ID | Mitigation | Layer | Required from tier | Effectiveness evidence | Owner |
|---|
| MIT-001 (Example) | Refusal and safe-completion training for CBRN | Model | T1 | Refusal rate on held-out set | [@alignment-lead] |
| MIT-002 (Example) | Input and output classifiers for CBRN and cyber | System | T2 | Red team bypass rate | [@safeguards-lead] |
| MIT-003 (Example) | Trusted access programme for dual-use cyber capability | Access | T2 | Vetting records | [@trust-safety] |
| MIT-004 (Example) | Account-level abuse detection and enforcement | Operations | T1 | Enforcement metrics | [@trust-safety] |
| MIT-005 (Example) | Staged release: internal, trusted testers, general availability | Release | T2 | Stage gate records | [@release-lead] |
| MIT-006 (Example) | Agent sandbox with egress controls and human approval for high-impact actions | Internal use | T1 for agents | Sandbox audit | [@platform-security] |
Open-weight release: state the rule. Example: models at T2 or above
in any risk are not released as open weights, since system-level
safeguards cannot be enforced after release.
6. Security mitigations and model weights
6.1 Security levels
| Level | Threat actors resisted | Example controls | Applies to |
|---|
| S1 (Example) | Opportunistic attackers | Standard enterprise controls, MFA, encrypted storage | T0 models |
| S2 (Example) | Organised criminal groups | Weight access limited to named staff, hardware-backed keys, egress monitoring | T1 |
| S3 (Example) | Well-resourced groups, insiders | Two-person rule for weight access, isolated training clusters, insider risk programme | T2 |
| S4 (Example) | Highly resourced state actors | Air-gapped storage, confidential computing, continuous red teaming | T3 |
6.2 Weight security controls
| ID | Control | Level | Evidence |
|---|
| SEC-001 (Example) | Inventory of every copy of weights, with owner and location | S1 | Inventory export |
| SEC-002 (Example) | Access requests approved by two people, logged and reviewed weekly | S3 | Access logs |
| SEC-003 (Example) | Rate limits and output monitoring on APIs to detect distillation or extraction | S2 | Monitoring dashboard |
| SEC-004 (Example) | Background checks for staff with weight access, as lawful | S3 | HR records |
| SEC-005 (Example) | Annual external penetration test of training and serving infrastructure | S2 | Test report |
7. Deployment decisions and model reports
7.1 Decision record
| ID | Model and version | Decision point | Tier reached per risk | Decision | Conditions | Decided by | Date |
|---|
| DEC-001 (Example) | MDL-002 v4 | External deployment | CBRN T1, CYB T2, LOC T0, MAN T0 | Proceed with conditions | MIT-002 and MIT-003 live; S3 confirmed | Executive management body | YYYY-MM-DD |
| DEC-002 (Example) | MDL-002 v4 | Open-weight release | CYB T2 | Do not proceed | n/a | Executive management body | YYYY-MM-DD |
7.2 Model report contents (EU)
| Element (summary) | Location |
|---|
| Model description, capabilities, intended uses, versions and model specification | [Report section] |
| Reasons for proceeding, safety margins and the conditions under which that reasoning would no longer hold | [Section] |
| Results and methods of systemic risk identification, analysis and mitigation, including evaluation results | [Section] |
| Reports from independent external evaluators | [Section] |
| Material changes to the systemic risk landscape | [Section] |
7.3 Transparency report contents (California and New York)
| Element (summary) | Location |
|---|
| Developer website, contact mechanism, release date, languages, output modalities, intended uses and restrictions | [Published page] |
| Summary of catastrophic risk assessments and results (large frontier developers) | [Section] |
| Extent of third-party evaluator involvement | [Section] |
| Other steps taken to fulfil the framework | [Section] |
| Redactions, with the reason (trade secret, cybersecurity, public safety, national security) and the unredacted version retained | [Annex reference] |
8. Serious incident tracking and reporting
8.1 Reporting clocks
| Regime | Event | Initial deadline | Recipient | Follow-up |
|---|
| GPAI Code of Practice (EU) | Serious and irreversible disruption of critical infrastructure | 2 days from awareness of model involvement | AI Office (and national authorities as appropriate) | Intermediate report at least every 4 weeks; final report within 60 days of resolution |
| GPAI Code of Practice (EU) | Serious cybersecurity breach, including weight exfiltration and cyberattacks | 5 days | AI Office | Same |
| GPAI Code of Practice (EU) | Death of a person | 10 days | AI Office | Same |
| GPAI Code of Practice (EU) | Serious harm to health, fundamental rights, property or the environment | 15 days | AI Office | Same |
| California SB 53 | Critical safety incident | 15 days from discovery | California Office of Emergency Services | As OES requires |
| California SB 53 | Critical safety incident with imminent risk of death or serious physical injury | 24 hours | Appropriate authority, including law enforcement or public safety agency | Then OES |
| New York RAISE Act (amended) | Critical safety incident | 72 hours from determination or reasonable belief (check the enacted text) | State oversight office (reported as an office within the Department of Financial Services) | As the office requires |
8.2 Incident log
| ID | Date found | Model | Category | Clocks triggered | Reports sent | Status |
|---|
| INC-001 (Example) | YYYY-MM-DD | MDL-001 v3 | Unauthorised access attempt to weight store, contained | EU 5 days (assessed as not serious, reasoning recorded) | None required; internal record | Closed |
Retain incident documentation for at least five years (Code of
Practice), and link each record to ai-data/ai-incident-report.
9. Whistleblower and internal reporting channels
| Item | Value |
|---|
| Anonymous internal channel | [Provider or tool, URL] |
| Who receives reports | [Independent function, with escalation to board risk committee] |
| Update to reporter | Example: at least monthly until closed |
| Periodic briefing to officers and directors | Example: quarterly summary of disclosures and responses |
| Notice of rights to covered employees | Example: posted on intranet and in offices; annual acknowledgement |
| External channels named | AI Office, California Attorney General, other competent authorities |
| Non-retaliation statement | [Policy reference] |
| Contract review | Example: confidentiality agreements checked so they do not prevent protected disclosures |
10. Governance and responsibility allocation
| Responsibility | Supervisory body | Executive management | Operational teams | Internal assurance | External assurance |
|---|
| Oversight (Example) | Board risk committee reviews framework yearly | CEO accountable | n/a | Internal audit reports to committee | n/a |
| Ownership (Example) | n/a | Head of frontier safety | Evaluation and safeguards teams | n/a | n/a |
| Support and monitoring (Example) | n/a | CFO allocates budget | Security, trust and safety | Risk function | n/a |
| Assurance (Example) | Receives reports | n/a | n/a | Annual audit of adherence | Independent evaluators per release |
Resources: [Example: the frontier safety budget is set as a share of
the training compute budget and approved by the board each year;
evaluation teams have priority access to pre-release checkpoints.]
Risk culture: [Describe how staff can raise concerns, how dissent on a
deployment decision is recorded, and how incentives avoid rewarding
speed over safety.]
11. External review and transparency
| ID | Reviewer | Scope | Access given | Report | Findings addressed |
|---|
| EXT-001 (Example) | [External evaluation organisation] | SR-CYB and SR-LOC on MDL-002 v4 | Pre-release checkpoint, no safeguards, 4 weeks | EXT-001 report | 5 of 6, one accepted with rationale |
| EXT-002 (Example) | [Government AI safety institute] | SR-CBRN | API access with safeguards off | Summary letter | Yes |
Public summary: [Describe what you publish: framework, model reports in
summarised form, transparency reports, and where.]
12. Framework assessment and updates
| Trigger | Action | Deadline |
|---|
| Annual cycle | Full framework assessment | Every 12 months from YYYY-MM-DD |
| New capability evidence (internal or external) | Targeted reassessment of affected risks | [30] days |
| Serious or critical safety incident | Reassessment of the related tier and mitigations | Before next deployment |
| Material modification of the framework | Publish new version with justification | Within 30 days (SB 53, RAISE) |
| Change in law, Code or guidance | Legal review and mapping update | [60] days |
Adherence review: [Example: internal audit checks each deployment
decision of the year against sections 3 to 7 and reports to the board
risk committee.]
13. Regulatory mapping
| Requirement (summary) | Code of Practice S&S | AI Act | SB 53 | RAISE | This document |
|---|
| Written framework, implemented and kept current | Commitment 1 | Art. 55(1)(b) | Framework duty | Framework duty | Whole document, 12 |
| Identify systemic or catastrophic risks | Commitment 2 | Art. 55(1)(b) | Framework content | Framework content | 2 |
| Evaluate and analyse, including adversarial testing | Commitment 3 | Art. 55(1)(a) | Assessments | Assessments | 3 |
| Thresholds and acceptance | Commitment 4 | Art. 55(1)(b) | Thresholds | Thresholds | 4 |
| Safety mitigations | Commitment 5 | Art. 55(1)(b) | Mitigations | Mitigations | 5 |
| Security and weights | Commitment 6 | Art. 55(1)(d) | Weight security | Weight security | 6 |
| Model and transparency reports | Commitment 7 | Art. 55 with Art. 53 | Transparency report | Transparency report | 7 |
| Responsibility allocation and governance | Commitment 8 | Art. 55 | Internal governance | Internal governance | 10 |
| Serious or critical safety incidents | Commitment 9 | Art. 55(1)(c) | 15 days, 24 hours | 72 hours | 8 |
| Documentation and retention | Commitment 10 | Art. 53, 55 | Unredacted records 5 years | [Check text] | 7, 8 |
| Whistleblowing | Measure 8.3 | Directive (EU) 2019/1937 | Labor Code protections | [Check text] | 9 |
EU timeline: GPAI obligations apply from 2 August 2025; the Commission's
enforcement powers for GPAI providers apply from 2 August 2026; models
placed on the market before 2 August 2025 must comply by 2 August 2027.
Check the consolidated text for changes made by Regulation (EU)
2026/1744.
14. Glossary and references
| Term | Meaning |
|---|
| Systemic risk | Under the AI Act, a risk specific to the high-impact capabilities of GPAI models with significant effects on the Union market or on public health, safety, security, fundamental rights or society |
| Catastrophic risk | Under SB 53, the mass-casualty or large-loss risk described in section 2.2 |
| Critical safety incident | Under SB 53 and RAISE, events such as unauthorised access to weights causing harm, harm from a catastrophic risk, loss of control, or deceptive subversion of controls |
| Elicitation | Effort to draw out a model's maximum capability during evaluation |
| Uplift | Increase in an actor's ability to cause harm compared with resources already available |
| Model weights | Learned parameters of a model |
- Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744,
Articles 3, 51, 52, 53, 55, 101 and 113 (consolidated text).
- General-Purpose AI Code of Practice, Safety and Security chapter
(final, 10 July 2025), digital-strategy.ec.europa.eu.
- California SB 53 (2025), Transparency in Frontier Artificial
Intelligence Act, Chapter 138, Statutes of 2025; Business and
Professions Code, Chapter 25.1 (from Section 22757.10).
- New York RAISE Act (signed 19 December 2025) and chapter amendment
(signed 27 March 2026), effective 1 January 2027.
- Directive (EU) 2019/1937 (Whistleblower Directive).
- Related templates:
ai-data/gpai-model-documentation,
ai-data/ai-red-team, ai-data/ai-incident-report,
ai-data/ai-post-market-monitoring, ai-data/model-card,
compliance/ai-regulatory-applicability-register.
Standard and licence note
Based on Regulation (EU) 2024/1689 (the Artificial Intelligence Act) as
amended by Regulation (EU) 2026/1744, Articles 51 to 55; structure
aligned with the ten commitments of the Safety and Security chapter of
the General-Purpose AI Code of Practice (10 July 2025); and mapped to
California SB 53 (2025) and the New York RAISE Act as amended in 2026.
Legislative texts are free to reuse; all requirements are paraphrased
in original wording and no text of the Regulation, the Code or the
state laws is reproduced. Check the consolidated text on EUR-Lex, the
Commission's Code of Practice pages, leginfo.legislature.ca.gov and
nysenate.gov for the binding wording and later changes. This is a
documentation format, not legal advice. Template licence: MIT.