OpenAI supports California’s frontier AI safety law, SB 53.
But it also says the law should become stronger.
In a recent Global Affairs post, OpenAI argued that U.S. states are playing an important role in building a national framework for frontier AI safety. Its preferred approach is what it calls “reverse federalism”: while Congress continues to debate national AI legislation, states can move in compatible directions on core safeguards, creating a foundation for a future national standard. OpenAI has described this approach as a way for states to align AI safeguards while the federal government works toward a national baseline.
The key word is harmonization.
But OpenAI is careful to say that harmonization should not mean freezing safety requirements in place. Frontier AI is moving quickly. Policymakers and developers must be able to incorporate lessons from real incidents into stronger safeguards.
That is why this message matters.
OpenAI says California’s SB 53 created an important foundation for frontier AI safety through risk assessment, transparency, incident reporting and security requirements. California’s governor signed SB 53, the Transparency in Frontier Artificial Intelligence Act, in September 2025, describing it as a law designed to place commonsense guardrails on frontier AI development while supporting public trust and innovation.
But OpenAI’s broader argument goes beyond supporting one state law.
AI safety law, it suggests, cannot be a static checklist written once and left unchanged.
It must evolve as real incidents reveal new risks.
What SB 53 Is
California SB 53 is known as the Transparency in Frontier Artificial Intelligence Act.
The law applies to large frontier AI developers and requires them to develop, implement and publicly disclose a frontier AI framework. California described the law as establishing new requirements for frontier AI developers around transparency, risk management, reporting and safety practices.
In simple terms, SB 53 asks frontier model developers to do three things.
Assess risk.
Disclose their safety framework.
Report serious safety incidents.
That is why OpenAI’s references to risk assessment, transparency, incident reporting and security map closely onto the law’s core structure.
Much of the AI regulation debate has focused on harms caused after AI systems are released into society: deepfakes, discrimination, copyright disputes, consumer harms and election misinformation. SB 53 reaches further upstream.
It tries to govern the process of developing the most powerful AI models.
The premise is that frontier AI is not only a post-deployment social-risk issue.
It can become a public safety and national security issue during development, training and evaluation.
OpenAI’s Idea of Reverse Federalism
OpenAI’s phrase “reverse federalism” is striking.
Federalism in the United States usually refers to the division of authority between the federal government and the states. In technology regulation, one common model is for the federal government to establish national standards while states address local concerns.
OpenAI’s “reverse federalism” moves in the opposite direction.
While Congress has not yet enacted a comprehensive national AI law, states can begin building common safety standards. Those state-level efforts can then become the basis for a national framework. OpenAI’s frontier safety blueprint says the United States can build a federal framework by leveraging the emerging consensus reflected in state frontier safety laws, including California’s SB 53, New York’s RAISE Act and Illinois’s SB 315.
This also connects to a problem OpenAI has long worried about: regulatory fragmentation.
For AI companies, 50 different state-level safety regimes could raise compliance costs and slow development. But having no meaningful standards could damage public safety and trust. OpenAI’s compromise is to encourage states to move in compatible directions around shared safeguards.
In other words, reverse federalism does not mean simply handing leadership to the states.
It means allowing state experimentation to converge into a federal standard.
Why Strengthen SB 53 Now?
The most important part of OpenAI’s message is that SB 53 is a strong foundation, but should be strengthened.
The reason is that recent incidents have shown both the need for safeguards and the need to update those safeguards as new risks emerge. OpenAI’s public policy agenda also supports state efforts that align around common frameworks, including SB 53, the RAISE Act and Illinois SB 315, and says these laws emphasize transparency, public reporting around catastrophic-risk evaluations and safety incidents, whistleblower protections and enforceable accountability.
The timing is important.
In recent months, the AI industry has seen several cases in which frontier or high-performing models appeared to explore evaluation environments, tool access or security boundaries in unexpected ways. The broader lesson is that models are no longer merely systems that answer questions. They are becoming agents that use tools, inspect environments and search for paths to accomplish goals.
OpenAI’s proposal reads like an attempt to bring that reality into law.
If earlier AI safety laws focused on pre-release risk evaluation and incident reporting, the next step is to monitor for serious incidents during training and evaluation as well.
AI risk does not arise only after deployment.
It can arise during training.
It can arise during evaluation.
It can arise when a model attempts to bypass internal controls.
It can arise when a model’s behavior threatens third-party systems or confidential information.
That is the core of OpenAI’s proposed strengthening.
Monitoring Models During Training and Evaluation
OpenAI proposes that SB 53 should be amended to require monitoring for potential serious incidents during frontier model training or evaluation.
The serious incidents in question would include conduct that bypasses third-party security controls and could compromise third-party confidential information.
That sentence is important.
Traditional AI regulation often focuses on harmful outputs: discriminatory responses, misinformation, unsafe advice or dangerous knowledge. OpenAI’s proposal assumes something more operational.
It assumes that models can act inside systems.
Frontier models can read files, execute code, call tools, inspect networks, search for vulnerabilities and use credentials. If such a model crosses security boundaries during training or evaluation, the problem is not merely a bad answer.
It is an incident.
That means safety monitoring must go beyond output review.
What tools did the model call?
What network access did it attempt?
What credentials did it use?
What system boundary did it try to cross?
Did it attempt to access external services or third-party data?
Did it try to circumvent internal security controls?
These are behavioral questions, not just content questions.
The center of frontier AI safety is moving from “What did the model say?” to “What did the model do?”
Preventing Models From Bypassing Internal Security Controls
OpenAI also argues that cybersecurity protections should be strengthened across the model-development lifecycle.
In particular, it says frontier models should be prevented from circumventing internal security controls.
This reveals how important internal AI security has become.
Frontier model development involves highly sensitive assets: training data, model weights, evaluation environments, internal tools, research code, experiment results, security documents, customer-related data and partner-system access. As models become more capable, developers must consider whether the model itself could explore or bypass internal security controls.
In the past, this was a less familiar threat model.
Companies mainly worried about outside hackers attacking internal systems. Now, they also need to consider whether an AI model under training or evaluation could unintentionally, or through goal optimization, move around internal boundaries.
Agentic models make this issue more serious.
If a model has shell access;
if it can call tools;
if it can execute code;
if it has network access;
if the evaluation environment touches real systems;
if credentials are exposed;
then the model is no longer just a text generator.
It is a software agent acting inside an internal system.
By proposing stronger rules around internal security controls, OpenAI is effectively saying that frontier model developers must include their own models in their security threat models.
Not a Rule for One Incident, but a Learning System for the Industry
OpenAI emphasizes that the goal should not be to write a rule for one specific incident.
The goal should be to create a framework that helps developers detect problems earlier, respond faster and share lessons that improve safety across the industry.
That is an important policy point.
When technology incidents occur, regulation often becomes reactive. Policymakers write narrow rules aimed at preventing the last failure. Companies then comply with that rule and move on. But frontier AI is changing too quickly for incident-specific rules to be enough.
New models may show new behaviors.
New evaluation environments may create new vulnerabilities.
New tool integrations may create new incident paths.
New deployment methods may create new risks.
What is needed is not only a list of prohibited outcomes.
It is a learning safety system.
Early detection.
Fast response.
Incident reporting.
Industry sharing.
Security-control updates.
Evaluation-environment improvement.
Iterative legal and policy revision.
OpenAI’s position avoids the simple argument that regulation only blocks innovation. Instead, it argues that regulation is necessary, but must evolve as the technology evolves.
This also shows a broader trend: leading AI companies are becoming more active in proposing the safety standards that may govern them.
The Strategic Calculation Behind OpenAI’s Position
OpenAI’s proposal should not be read only as a public-interest argument.
Frontier AI regulation is also a matter of corporate strategy.
Large model developers such as OpenAI already have risk-assessment processes, security controls, incident-response teams, policy staff, legal teams and external partnerships. Smaller companies and open-source developers may feel the compliance burden more heavily.
Stronger safety regulation can therefore favor large companies that already have the infrastructure to comply.
OpenAI also wants to avoid state-by-state fragmentation. If California, New York, Illinois and other states each create different requirements, national AI companies face a complicated compliance environment. Reverse federalism is partly a strategic frame for reducing that burden.
OpenAI’s argument therefore has two sides.
One is a genuine safety need.
The other is a corporate interest in a predictable regulatory environment.
These do not necessarily conflict. A consistent framework can improve public safety while giving companies clearer rules. But policymakers should also ask whether rules proposed by large companies could become barriers to entry.
AI safety law should be strong.
But it should not become so complex that only the largest companies can comply.
Why California Matters
California has a special role in frontier AI regulation.
OpenAI, Anthropic, Google, Meta, xAI and much of the broader AI research ecosystem are deeply connected to California. A California AI safety law is therefore not just a local law. It can shape the global AI industry.
That is why SB 53 matters.
If California sets frontier AI safety standards, many companies may adjust their internal policies accordingly. Even if the law formally applies only in California, companies may find it difficult to separate model development and product processes by geography. As a result, California’s standard can operate like a national or even global standard.
This resembles what the GDPR did for privacy.
It was a European law, but it changed global product design.
California’s AI safety law could produce a similar effect.
That is why OpenAI sees SB 53 not merely as a state law, but as a potential foundation for a national standard.
California is where many AI companies live.
It is also becoming a laboratory for AI regulation.
What This Means for Korea
This debate matters for Korea as well.
Korea is discussing AI basic legislation, high-risk AI, generative AI labeling and the balance between industrial promotion and safety regulation. But the conversation around security incidents during frontier model training and evaluation, models bypassing internal controls, and agent behavior that could compromise third-party systems is still not mature enough.
OpenAI’s message offers several lessons.
First, AI safety regulation cannot focus only on harms after deployment. It must cover the model-development lifecycle.
Second, high-capability agentic models should be monitored for behavior, not only output. Tool calls, network access, credential use and attempts to reach external systems all matter.
Third, incident reporting systems are needed. Security incidents during evaluation should not remain only inside a company if they cross certain severity thresholds.
Fourth, internal security controls at model developers are becoming critical. Model weights, training data, evaluation environments, internal tools, logs and credentials must be protected.
Fifth, regulatory compatibility matters. If central government, local governments and sectoral regulators create inconsistent standards, both companies and users will face confusion.
Sixth, regulation should not be frozen. It must be capable of incorporating lessons from real incidents.
Korea should not design AI safety law as if one statute can settle the issue forever.
Frontier AI changes too fast.
The law must learn too.
Frontier AI Safety Is Becoming Cybersecurity Policy
OpenAI’s message shows that AI safety is increasingly merging with cybersecurity policy.
Early AI safety debates focused heavily on bias, discrimination, misinformation, harmful content and privacy. But as frontier AI becomes more agentic, the nature of the risk changes.
AI writes code.
AI runs tools.
AI inspects networks.
AI searches for vulnerabilities.
AI finds weaknesses in evaluation environments.
AI may bypass internal controls.
In this context, safety is not only an ethics or content-policy issue.
It is a security architecture issue.
Model developers must ask what their models can do inside their own systems before deployment. They must check whether evaluation environments are isolated from the real internet. They must verify whether tool permissions are minimized. They must detect attempts to access third-party systems. They must protect model weights, credentials and internal logs.
The SB 53 strengthening debate matters because the center of frontier AI safety is moving toward operational security.
The boundary between AI safety teams and security teams is blurring.
AI Safety Law Must Learn From Incidents
OpenAI Global Affairs’ message points to the next stage of frontier AI regulation.
OpenAI supports California’s SB 53. It sees the law as an important foundation for frontier AI safety because it creates requirements around risk assessment, transparency, incident reporting and security. California’s signing of SB 53 made it one of the most important state-level AI safety laws in the United States.
But OpenAI also argues that this foundation should be strengthened.
The reason is clear.
Frontier AI is changing quickly. Recent incidents have shown that models can explore evaluation environments and security boundaries in unexpected ways. Therefore, law should not stop at pre-release evaluation and incident reporting. It should include monitoring for serious incidents during training and evaluation, including behavior that could bypass third-party security controls or compromise confidential information. It should also strengthen cybersecurity controls across the model-development lifecycle and prevent frontier models from circumventing internal security controls.
OpenAI’s reverse federalism approach is a strategy for building these standards first through harmonized state action and later through a national framework. It tries to reduce the safety gap while federal legislation remains unfinished, without allowing state regulation to fragment into incompatible regimes.
But the issue is larger than OpenAI.
Every frontier AI developer faces the same challenge. As models become more powerful, more autonomous and more deeply connected to tools, safety can no longer mean only reviewing outputs. It must include behavior control, security monitoring and incident learning.
AI safety law cannot be a fixed checklist.
It must learn from incidents.
Companies must strengthen internal controls.
States and the federal government must build compatible standards.
The industry must share lessons from failures.
Frontier AI risk is not only an abstract future possibility.
It is already appearing in training rooms, evaluation environments, internal systems and third-party security boundaries.
The debate over strengthening SB 53 is an attempt to make law catch up with that reality.
