AI Safety Controls: What the White House Accord Expects

Key Takeaways

• The White House Accord on Super Intelligence, signed September 29, 2026, is a voluntary commitment by six AI and chip companies to adopt AI safety controls and audits.
• The Accord's four layers mirror Sarbanes-Oxley Act Section 404: an internal controls framework, testing of design and effectiveness, an independent external audit, and independent board committee oversight.
• Frontier AI developers already publish their own safety frameworks, but those frameworks use inconsistent terminology, risk categories, and capability thresholds.
• AI safety controls fit a four-stage lifecycle: build, gate, operate, and stop.
• Model developers own controls over training, release, and monitoring, while compute providers own controls over supply chain integrity, customer screening, and export compliance.
• Several proposed federal AI safety bills, including the CHAT Act (S.2714), could eventually clarify how consistently organizations must apply these controls.

As AI advances, the AI arms race is booming. How can you drive AI advances while maintaining safety controls? What are companies responsibilities regarding safety when developing ai when their business is only able to survive through advancement? 

There is some clarity required over whether regulation will be at the state or the federal level; however, there are several proposed AI regulations related to safety, including:

• CHAT Act (S.2714)
• Youth AI Privacy Act (S.4199)
• Schiff-Curtis bill
• Hawley-Blumenthal bill
• HR 8382
• AI LEAD Act (Durbin-Hawley)
• Broader kids' online safety bills

What Is the White House Accord on Super Intelligence?

Notwithstanding the absence of an overall federal AI law, on September 29, 2026, the White House signed an accord on Super Intelligence (the Accord) with six major chip and AI companies regarding safety controls and audits. 

How Do the Accord’s Controls Compare to SOX 404?

With the exception of being voluntary, and the focus is on safety control instead of financial reporting, the key takeaways related to internal controls in the Accord are not dissimilar from requirements related to Sarbanes-Oxley 404 requirements of public companies, as follows:     

1. An internal controls framework;
2. Testing of design and effectiveness of the internal controls, including monitoring and remediation;
3. Independent external audit of those internal controls; and,
4. An independent committee of the board of directors to oversee the above

Why Aren’t Existing AI Safety Frameworks Enough?

The Accord does not start from zero. Each of the frontier labs already publishes its own safety framework, including Anthropic's Responsible Scaling Policy, OpenAI's Preparedness Framework, and Google DeepMind's Frontier Safety Framework. Read side by side, however, these frameworks are qualitative and inconsistent with one another. Each company uses its own terminology, risk categories, and definition of when a model becomes dangerous enough to require stronger safeguards, and the frameworks are also revised frequently. An independent research group, METR, has published a comparison of common elements across these frameworks, illustrating both overlap and divergence.

While the Accord is a one-pager and not prescriptive in nature, the safety controls that AI developers and chip companies could monitor and test fall naturally into a four-stage lifecycle: how models and chips are built, what passes the gate to public release or customer access, how they are managed once in use, and how they can be stopped. Controls below are labeled by whether they apply to model developers or to compute providers.

A Four-Stage Lifecycle for AI Safety Controls

1. Build: Controlling How Models and Chips Are Developed

• Controls over AI-assisted model development (Developers): Human approval required for significant training runs, changes to training data, and changes to a model's objectives, with AI agents' research activity logged and reviewable.
• Risk-tiered review of AI-generated code (Developers): Code produced by AI agents is attributable through dedicated system identities. Safety-critical code, including evaluation, monitoring, and security tooling, sits in protected areas where AI systems cannot approve or merge changes, and every change requires approval by a designated qualified human.
• Monitoring of internal AI use (Developers): Models used internally, including AI agents doing research or engineering work, are monitored for anomalous behavior such as attempts to access restricted systems, disable monitoring, or underperform on safety evaluations.
• Model weight security (Developers): Protection of model weights against theft or unauthorized access, scaled to the model's capability level.
• Hardware and firmware supply chain integrity (Compute): Controls over chip design, manufacturing partners, and firmware, so only authorized updates can be installed.

2. Gate: Deciding What Reaches the Public and Who Gets Access

• Capability thresholds and release gates (Developers): Documented capability thresholds, defined and tested by the company, that trigger stronger safeguards, with pre-release evaluations and formal sign-off before any model ships, including any model developed with substantial AI assistance.
• Evaluation rigor and cadence (Developers): Evaluations designed to elicit a model's full capabilities rather than understate them, performed at defined points during training, before release, and at set intervals after deployment.
• Red teaming with tracked remediation (Developers): Internal and third-party adversarial testing before release, with findings logged, assigned, and resolved before sign-off.
• Model change management (Developers): Updates, fine-tunes, and new versions pass through the same gate as a new release, so the gate can't be bypassed after launch.
• Know-your-customer and end-use screening (Compute): Verification of customer identity, including beneficial owners, and intended use before large compute sales, with risk-rating of customers and escalation of red flags.
• Export control and restricted-party screening (Compute): Documented screening of every transaction against current export restrictions and restricted-party lists, with timely incorporation of list updates.

3. Operate: Managing Models and Computing Once They're in Use

• Youth safety controls (Developers): Age assurance, minor-specific content restrictions, crisis response protocols for self-harm disclosures, and parental controls.
• Post-deployment monitoring and incident escalation (Developers): Ongoing misuse detection, defined incident severity levels, and documented escalation timelines to the independent board committee.
• Transparency and reporting (Developers): Public disclosure of safety evaluations at release, timely reporting of critical safety incidents to regulators, and protected channels for employees to raise safety concerns.
• Framework change control (Developers): Changes to the company's safety framework are approved by the independent board committee, documented with a rationale, and disclosed publicly.
• Diversion monitoring (Compute): Ongoing monitoring for signs that chips have been resold or transferred to restricted destinations, supported by contractual rights to verify where chips are installed.

4. Stop: The Ability to Pause or Pull Back

• Predefined halt conditions and tested halt capability (Developers): Documented conditions under which deployment or further development will pause if capabilities of concern emerge before adequate safeguards are in place, supported by technical means to stop AI systems and agents, tested periodically with results reported to the board committee.
• Tested halt capability (Developers): Documented procedures and technical means to pause or stop AI systems and agents, including internal research agents, tested periodically with results reported to the board committee.
• Defined response to diversion or misuse (Compute): Documented procedures for halting shipments, suspending software and support services, terminating customer relationships, and reporting to authorities when diversion or misuse is identified.

Note on Stop: For developers, stopping a model is largely a technical capability. For computing, the question of how far stop mechanisms should extend is still actively debated, including whether chips should carry built-in location verification or remote disable features, with policymakers and chipmakers weighing security, privacy, and misuse concerns differently. The framework above reflects the controls available today while that debate continues.

What Comes Next for AI Safety Regulation?

Regulations that keep pace with technology will always face challenges. The Accord is a step toward setting expectations; however, participation and consistent application of those safety controls, including evaluation, monitoring, and remediation, may require further clarification at the state or federal level.

Organizations that build AI, supply compute, or rely on frontier models don't need to wait for regulation to act. The disciplines behind SOX compliance, including designing, testing, and remediating internal controls, apply directly to AI safety controls. Contact EisnerAmper's Risk and Compliance team to discuss how to assess your controls against the Accord's four layers.