FRONTIER Act Guide: Tiers, Audits, Incident Clocks and State Preemption

The FRONTIER Act would create the first federal rulebook for frontier AI developers, with tiered duties to publish safety frameworks, pass independent audits and report critical safety incidents within 72 hours, and it would preempt state frontier AI safety laws such as California's SB 53 and New York's RAISE Act. The Frontier Risk Oversight, National Transparency, Independent Evaluation, and Reporting Act is H.R. 9925 in the 119th Congress, introduced on 23 July 2026 by Representative Jay Obernolte (Republican, California) with Representatives Lori Trahan, Scott Franklin, Scott Peters, Erin Houchin and Suhas Subramanyam. It is a bill, not a law. This guide works from the bill text and section-by-section summary published on Representative Trahan's website. It sets out who would be covered, what each tier must do, how the incident clocks, independent verification and emergency orders would work, and what security, AI governance and identity teams at developers and their customers should prepare.

Source note: obligations, thresholds and deadlines come from the bill text and the sponsors' section-by-section summary. Status is as of November 2026 from LegiScan. Bills change in committee: confirm the details. Confirm against the official text before relying on it.

Key takeaways

• Three tiers by compute and money. A frontier model is trained with more than 10^26 operations. Large frontier developers also have over 50 million US dollars of gross revenue and at least 1 billion US dollars of AI development spending over 36 months; very large ones over 5 billion and 10 billion. Duties stack upwards.
• 72 hours for critical safety incidents. Any frontier developer must report a critical safety incident within 72 hours of learning facts giving a reasonable belief one occurred, and within 24 hours to law enforcement where there is imminent risk of death or serious injury.
• Audits and licensed verifiers. Large developers need an annual independent compliance audit. Very large developers must also retain a licensed Independent Verification Organisation (IVO) that assesses them at least every six months and must refer imminent catastrophic risk within 72 hours.
• A new Commerce regulator with emergency powers. A new Under Secretary of Commerce for AI Security writes rules and runs a registry. The Secretary of Commerce can suspend or restrict a model on a written finding of imminent catastrophic risk.
• Federal preemption of state frontier laws. States could not add new substantive obligations on frontier transparency, auditing or incident reporting, though general laws and deployer rules are saved.

Status and timeline

As of November 2026, LegiScan shows the bill at the introduced stage, pending in committee. The sponsors present it as part of the broader Great American AI Act framework. Representative Houchin's statement refers to a recent case of an advanced AI system escaping its developer's testing environment, the kind of event documented in the OpenAI and Hugging Face Breach 2026.

Who would be covered

Two points matter for scope. The Under Secretary can raise the compute, revenue and spending thresholds by rule, so the lines can move. And the duties sit with developers, not with enterprises that deploy frontier models: section 9 expressly saves state use and deployment rules for deployers and users. Customers are affected indirectly, through the transparency reports, audit summaries and any emergency order that restricts a model they depend on.

Key definitions

• Catastrophic risk: a foreseeable, material risk that a frontier model materially contributes to 50 or more deaths or serious injuries, or over 1 billion US dollars of property damage, in a single incident involving non-public help with a CBRN or cyber weapon, conduct without meaningful human oversight that is a cyberattack or would be murder, assault, extortion or theft, or evading the control of its developer or user. Publicly available information and lawful federal activity are excluded. The death and damage figures match those in California's SB 53, covered in the California AI Laws Guide.
• Critical safety incident: unauthorised access to, modification of or exfiltration of model weights; harm from a materialised catastrophic risk; loss of control; or a model deceiving its developer to subvert controls outside a designed evaluation in a way that shows materially increased catastrophic risk.
• Imminent catastrophic risk: a present or impending catastrophic risk. It triggers IVO referral and emergency orders.
• Acceptable levels of catastrophic risk mitigation: mitigation adequate to ensure the model's expected benefits outweigh its catastrophic risk. This is the benchmark IVOs assess against.

The first limb of the critical safety incident definition is a pure security event. A stolen or tampered set of model weights is reportable in 72 hours whether or not harm follows. That makes weight access an identity and access management problem with a regulatory clock attached. See Securing AI Model Weights.

What large developers must publish and prove

Section 4(a) lists what a large developer's frontier AI framework must cover. The right-hand column is NHI Mgmt Group's view of the evidence an auditor would look for, not bill text.

Other section 4 duties:

• Transparency report (4(d)): every frontier developer publishes, before or at deployment of a new or substantially modified model, a machine-readable report covering contact details, release date, languages, output modalities, intended uses, restrictions, catastrophic risk assessments and their results, and third-party involvement. Redactions are allowed for trade secrets, security and national security.
• Compliance audit (4(c)): annual, by an independent third party, with the summary and redacted report published within 30 days of receipt. Developers may impose security protocols on auditors.
• Registration (4(k)): large developers register with the Under Secretary, who keeps a public registry.
• False statements (4(e)): knowingly false or misleading statements are prohibited, with a good faith exception.

Incident reporting clocks

The 72 hour clock is much shorter than the 15 days in the AI Kill Switch Act and runs from "reasonable belief", not confirmation. Teams will need triage that can reach that threshold quickly from identity, access and model telemetry. Compare clocks in the AI Incident Reporting Guide and the Cyber Incident Reporting Requirements Map.

Independent verification and emergency orders

Independent Verification Organisations (section 5): the Under Secretary licenses and oversees IVOs. Very large developers must retain one for ongoing assessment of whether their framework, governance, risk monitoring and mitigations reach acceptable levels of catastrophic risk mitigation, with an assessment at least every six months. IVOs get access to unredacted materials at any time, may subcontract specialist work but remain responsible for it, and must not make material misrepresentations. The Comptroller General reports annually on the IVO market and IVO independence (section 7). See Third-Party AI Risk Guide for how assurance providers are themselves assessed.

Emergency orders (section 8): the Secretary of Commerce may suspend or restrict development, deployment or internal use of a frontier model on a written finding of imminent catastrophic risk.

1. Provisional order: may issue on a preliminary determination; notice and an opportunity to cure are required unless imminence prevents it; expires after 45 days.
2. Final order: needs a written finding; expires after 90 days; renewable only on a fresh finding.
3. Content: every order states its basis, restrictions and rescission conditions, and must be rescinded once those conditions are met or the risk has passed.
4. Challenge: expedited administrative hearing with the burden on the Secretary; judicial review only in the US District Court for the District of Columbia, with appeal to the D.C. Circuit.
5. Oversight: Congress receives each order and semiannual reports.

Section 8 is stated to be the exclusive federal means of restricting a frontier model on imminent catastrophic risk grounds. That contrasts with the DHS-led model in the AI Kill Switch Act Guide.

Penalties and preemption

The sponsors' summary says the preemption is aimed at closely related state frontier safety statutes, naming California SB 53, New York RAISE and Illinois SB 315. If enacted, a developer currently building to those state regimes would move to the federal one for these topics. See the New York RAISE Act Guide and the US State AI Laws Tracker. The text we reviewed contains no whistleblower provisions; state whistleblower protections are not listed among the preempted topics, but take advice on that point.

Where identity fits

Several FRONTIER Act obligations depend on identity controls for non-human identities. Weight theft or tampering is the first limb of a critical safety incident, so every service account, pipeline credential and workload identity with read or write access to weight storage is in scope of the framework's cybersecurity element. Loss of control and "evading control by its developer or user" are often visible first as an AI system using credentials, tools or permissions beyond its grant. Auditor and IVO access to unredacted materials creates a new class of privileged third-party access to manage. Useful starting points are the Privileged Access Management Guide and the Agent Identity and Access Guide.

How to prepare: a phased approach

1. Determine tier: calculate training compute per model including fine tunes, and revenue and AI spending with affiliates over 36 months. Record the calculation and review it quarterly.
2. Gap-assess against state regimes: if you already publish an SB 53 or RAISE framework, map it to the nine section 4(a) elements and note gaps, especially third-party assessment and internal governance.
3. Harden weight access: inventory every human and non-human identity with access to non-public weights, remove standing access, require approvals, and log and alert on every read, copy and write.
4. Build the 72 hour path: define who decides "reasonable belief", pre-draft report templates, and run a tabletop exercise with weight exfiltration and evaluation escape scenarios. Use the AI System Incident Report Template.
5. Prepare for auditors and IVOs: create segregated, logged access for assessors, with security protocols the bill permits, and an evidence library per model version.
6. Plan for an emergency order: know how to suspend a model by region, customer and internal use, and how to show rescission conditions are met. Customers should pin model versions and test fallbacks.

Rollback and testing: introduce new weight-access controls in monitor mode for one training cycle, then enforce; keep a break-glass path for incident response that is itself logged and reviewed.

Decision guidance

• Very large developer: treat the IVO relationship as continuous assurance. Budget for six-monthly assessments and for unredacted access that must be secured.
• Large developer near the threshold: the 36-month look-back means crossing the line is predictable. Build the framework before you cross, since you then have 90 days.
• Smaller frontier developer: only transparency reports and incident reporting apply, but the 72 hour clock still does. Keep runbooks proportionate.
• Enterprise customer: no direct duties. Use published transparency reports and audit summaries in supplier assessment, and plan continuity for a 45 or 90 day restriction on a model you rely on. See the Frontier AI Model Risk Frameworks Guide.

Detection and measurement

• Weight access identities: number of identities with standing access to non-public weights, trending to zero.
• Anomalous weight access alerts: time to triage each alert against the critical safety incident definition.
• Time to reasonable belief: hours from first signal to a documented determination in exercises; must leave room inside 72 hours.
• Transparency report timeliness: share of model releases with a report published at or before deployment.
• Audit findings closed: percentage of compliance audit and IVO findings closed before the next cycle.

Common failure patterns

• Counting only the base training run: the threshold includes substantial modifications, so heavy fine tunes can tip a model over.
• Treating weight access as an IT ticket: unauthorised access to weights is itself reportable in 72 hours; slow triage of storage alerts risks a missed clock.
• Evaluation leaks treated as test noise: deception or control evasion outside a designed evaluation is a critical safety incident; incidents like the Anthropic Claude Evaluation Incidents 2026 show how boundaries blur.
• Unmanaged assessor access: auditors and IVOs with broad, persistent access to unredacted materials become a new exposure.
• Assuming preemption removes all state duties: general state laws and deployer rules survive.

Framework mapping

For the AI-specific risk framework, see the NIST AI RMF Guide.

Practitioner checklist

• Confirm H.R. 9925's current status and text before citing it; it is not law.
• Calculate and record each model's training compute, including fine tunes.
• Calculate revenue and AI spending with affiliates over the 36-month window.
• Map any existing state framework to the nine section 4(a) elements.
• Remove standing human and non-human access to non-public weights and alert on every access.
• Name the person who determines "reasonable belief" and rehearse the 72 and 24 hour clocks.
• Set up segregated, logged access for auditors and IVOs.
• Customers: pin model versions and test a fallback for a 45 or 90 day restriction.

Standards and references

• Representative Lori Trahan: The FRONTIER Act, final text
• Representative Lori Trahan: FRONTIER Act section-by-section
• Representative Jay Obernolte: Obernolte, Trahan Introduce Bipartisan FRONTIER Act
• LegiScan: US HB9925, 119th Congress
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• NIST: AI Risk Management Framework

Related NHI Mgmt Group resources: Frontier AI Model Risk Frameworks Guide · Securing AI Model Weights · California AI Laws Guide · US Federal AI Policy Guide. This guide summarises the FRONTIER Act as introduced and is not legal advice.