Why Anthropic Is Asking for a Rehearing En Banc

Though not dispositive, legislative history can provide useful information in the resolution of cases. Information arising from hearings, reports, and floor statements can provide courts with valuable insights when interpreting the meaning of legislative text. Some observers predicted the death of legislative history as a tool in statutory interpretation after Justice Elena Kagan quipped, “We’re all textualists now,” and equated citing legislative history with “putting extra icing on a cake already frosted.” Yet justices across the Court’s interpretive spectrum have recently shown a willingness to go beyond mere text to ferret out the meaning of a law.

Consideration of the legislative history of the Federal Acquisition Supply Chain Security Act of 2018 (FASCSA) brings the recent decision by the U.S. Court of Appeals for the D.C. Circuit in Anthropic PBC v. U.S. Department of War into question. Judge Gregory Katsas, joined by Judge Neomi Rao, wrote for the majority; Judge Karen LeCraft Henderson dissented. The majority concluded that Anthropic’s conduct qualified as a “supply chain risk” under FASCSA and upheld the decision by the Department of Defense—referred to as the Department of War by the parties—to exclude the artificial intelligence (AI) lab from portions of the department’s supply chain on that basis. Anthropic has requested a hearing en banc—an appearance in front of all active D.C. Appeals Court Circuit judges.

Assuming that petition is granted, the D.C. Circuit, in interpreting FASCSA’s definition of “supply chain risk,” should acknowledge and heed the specific harms Congress sought to address. If the court does so, it will likely reverse the previous decision.

Background

Anthropic and the Department of Defense started 2026 amid contract negotiations. Anthropic refused to agree to a contractual requirement by the Department of Defense that its technology may be used for “all lawful use.” The frontier AI lab insisted that it would not permit the use of its Claude AI model for domestic mass surveillance or in fully autonomous weapons systems. Contract negotiations broke down over these red lines. On Feb. 27, Secretary of Defense Pete Hegseth responded to the impasse via a social media post expressing his intent to remove Anthropic from the federal supply chain. Then, on March 3, he relied on FASCSA to formally remove the company from the federal supply chain. The Department of Defense’s determination concluded that ongoing use of Claude in the department’s system represented a “significant supply chain risk,” requiring the removal of the company’s tools. The department subsequently mandated that all Anthropic products be removed from department systems within 180 days. It also foreclosed Department of Defense contractors from using Claude in department-related work.

Anthropic challenged that determination in lawsuits brought before the U.S. Court of Appeals for the D.C. Circuit and U.S. District Court for the Northern District of California. The former suit challenged the government’s interpretation of FASCSA; Judge Rita Lin concluded that the government retaliated against Anthropic for its criticism of the administration in violation of the First Amendment. The latter case pertains to the application and meaning of 10 U.S.C. § 3252. In its relevant part, the law defines “supply chain risk” as (emphasis added):

the risk that any person may sabotage, maliciously introduce unwanted function, extract data, or otherwise manipulate the design, integrity, manufacturing, production, distribution, installation, operation, maintenance, disposition, or retirement of covered articles so as to surveil, deny, disrupt, or otherwise manipulate the function, use, or operation of the covered articles or information stored or transmitted on the covered articles.

Anthropic does not contest the Pentagon’s right to discontinue using it on covered projects and, on the contrary, volunteered to help it transition seamlessly to another provider. It simply wants the department to follow procurement laws rather than stigmatizing it as a supply chain risk, a term it contends is associated with malicious actors.

The majority saw no need for bad intent in labeling Anthropic a supply chain risk under FASCSA. On its reading, the Department of Defense’s decision to regard the frontier AI lab as a “supply chain risk” turns on the wording “otherwise manipulate”; and manipulation, per the American Heritage Dictionary cited by the majority, means simply “[t]o move, arrange, operate, or control by the hands or another body part or by mechanical means, especially in a skillful manner.” 

Under that definition, nearly any deliberate design choice could qualify as manipulation and expose any company to being labeled as a supply chain risk. The majority brushed aside Anthropic’s argument that FASCSA’s legislative history points the other way and opted not to thoroughly address the counterargument that supports reading malice into the statute.

Consideration of legislative history bolsters the case that Congress did not seek to punish companies for offering a product that, for whatever reason, does not align with the demands of the federal government. Read with the enacted language, the legislative history identifies a security problem involving compromised products, vulnerable components, exploitation of trusted access, and interference with information systems. It does not establish that every deliberate and disclosed limitation on a product’s capabilities constitutes the sort of manipulation contemplated by FASCSA.

The Legislative History of “Supply Chain Risk”

There is a difference between a literal reading of a statute and a textual one. A literal reading assumes Congress expected courts to reach for the nearest dictionary, just as the majority did here. The Supreme Court drew that distinction in Fischer v. United States, another case about how far an “otherwise” clause reaches. To fix the clause’s scope, Chief Justice John Roberts wrote, “the Court must decide how it is linked to its ‘surrounding words.’” The Court then confirmed its narrower reading by looking to the problem Congress set out to solve: the Enron-era loophole that prompted the provision.

The majority in this case declined to undertake that broader inquiry. Its treatment of FASCSA’s legislative history spans two sentences. The first rejects Anthropic’s attempt “to glean from the legislative history a focus on ‘foreign companies working at the behest of foreign states,’” because the statute covers “any person,” which “cannot refer only to foreign entities.” The second rejects, without elaboration, the dissent’s “use of legislative history … to glean the ordinary public meaning of the seven verbs in the definition.”

The first point is easily resolved. Nothing in FASCSA limits supply chain risk to foreign actors. But the key inquiry here is not so much which actors can be labeled a supply chain risk but rather what conduct may qualify an actor as such.

On that question, the surrounding words and context cut against the majority’s reading of FASCSA. The congressional committee reports, hearings, and floor statements that produced FASCSA describe one kind of problem: people, foreign or domestic, outside a vendor or inside it, covertly compromising the technology the government buys. Nowhere does the record suggest that Congress intended to reach vendors that openly tell the government what its product will not do.

Congress’s focus on hostile and covert conduct matters because the majority has already conceded the facts that make stretching “otherwise manipulate” to Anthropic’s behavior hard to justify. The majority noted it had “no reason to doubt” that Anthropic had “noble intentions” when determining the functions of its models. It also had “no quarrel” with the Northern District of California’s conclusion that Anthropic “has acted with no such bad motive in its dealings with the Department.” If the definition requires hostile conduct, Anthropic falls outside it.

The Problem Congress Set Out to Solve

Several sources supply the relevant context: two committee reports, two congressional hearings, and the House floor debate.

The Senate Homeland Security and Governmental Affairs Committee’s report on S. 3085, the bill that became FASCSA, opens its “Background and Need for the Legislation” with a single framing sentence: “Hostile nation states and other bad actors are attempting to gain unprecedented access to sensitive and classified information via the Federal Information and Communications Technology (ICT) supply chains.” The report traces a “well-documented history” of warnings that “foreign governments may target the Federal ICT supply chain via certain products or services.”

The report also quotes then-FBI Director Christopher Wray, who said that the bureau was “deeply concerned about the risks of allowing any company or entity that is beholden to foreign governments that don’t share our values to gain positions of power inside our telecommunications networks.” Such a position, Wray explained, “provides the capacity to maliciously modify or steal information, and it provides the capacity to conduct undetected espionage.”

The report then states that “[t]he need for this legislation is underscored by several recent examples of supply chain risks discovered within the Federal ICT system.” The examples it gives are Kaspersky Lab, Huawei, and ZTE. A closer look at the first of those examples shows what kind of conduct motivated Congress to pass FASCSA.

Consider what the concern about Kaspersky actually was. Then-Acting Homeland Security Secretary Elaine Duke explained that the department removed Kaspersky products from federal networks because of its concerns about “ties between certain Kaspersky officials and Russian intelligence.” She also cited Russian legal “requirements … that allow Russian intelligence agencies to request or compel assistance from Kaspersky.” Duke’s conclusion: “The risk that the Russian government, whether acting on its own or in collaboration with Kaspersky, could capitalize on access provided by Kaspersky products to compromise federal information and information systems directly implicates U.S. national security.”

Rep. Kathleen Rice (D-N.Y.) put it more bluntly at a House hearing in July 2018. Although Kaspersky was “a long-time Government vendor,” she said, “the FBI had reason to believe the Kaspersky programs contained back doors that could be accessed by Russian intelligence.”

This background reveals that the government in the Kaspersky matter did not need to prove that Kaspersky itself harbored hostile intent. The risk was that someone, namely “the Russian government, whether acting on its own or in collaboration with Kaspersky,” could exploit the vendor’s access. Understanding this dynamic shines a light on the role “any person” plays in FASCSA: The risk can come from whoever is positioned to exploit a product, not only the vendor of record. In every version of the Kaspersky story, though, someone is trying to compromise federal systems without the government’s knowledge.

The same is true of the cases involving Huawei and ZTE. The Senate report outlines the government’s position that their equipment “may be used for nefarious or otherwise unauthorized purposes by the Chinese government.” It also quotes the House Intelligence Committee’s 2012 warning: “Inserting malicious hardware or software implants into Chinese-manufactured telecommunications components and systems headed for U.S. customers could allow Beijing to shut down or degrade critical national security systems in a time of crisis or war.” At the House hearing, Rice commented on both companies having “close ties to the Chinese Government” and being “possible vehicles for cyber threat and espionage.”

The House record resembles the Senate’s. The House’s companion effort was H.R. 6430, the Securing the Homeland Security Supply Chain Act of 2018. It grew out of a July 12, 2018, joint subcommittee hearing titled “Access Denied: Keeping Adversaries Away from the Homeland Security Supply Chain.”

Rep. Peter King (R-N.Y.) opened that hearing by observing that “nation-states and criminal actors are constantly trying to exploit U.S. Government and private-sector systems to steal information or insert potentially harmful hardware or software.” He then set forth the purpose of supply chain risk management (SCRM): “The foundation of any SCRM program is the ability to proactively identify entities seeking to exploit the DHS acquisition process, become trusted vendors, and then steal from or otherwise harm the Homeland Security enterprise.”

King’s description is the closest the record comes to anticipating the application of FASCSA’s supply chain risk designation to a vendor already in good standing with the government. Yet, even in his hypothetical, the trusted status was a cover for theft or sabotage. Anthropic’s restrictions on Claude differ from that fact pattern. They were written into contracts, negotiated over months, and publicly explained by the company’s CEO. The majority opinion itself recounts that Anthropic “partially—but not completely—relaxed its use restrictions to accommodate the Department.” The lab did so by building a government-specific model and a government-specific usage-policy addendum. Yet, as Judge Henderson put it in her dissent, the conduct the majority’s holding reaches is “a contractor’s honest and upfront enforcement of restrictions on a covered article’s use disfavored by the government.”

How the Definition of Supply Chain Risk and “Otherwise Manipulate” Took Shape

The definition of supply chain risk evolved across three related proposals. Tracing that evolution further undercuts the majority’s reading of “otherwise manipulate.”

The starting point is the Defense Department’s Section 806 authority, enacted in 2011 and now codified at 10 U.S.C. § 3252. It defines supply chain risk as “the risk that an adversary may sabotage, maliciously introduce unwanted function, or otherwise subvert the design, integrity, manufacturing, production, distribution, installation, operation, or maintenance of a covered system so as to surveil, deny, disrupt, or otherwise degrade the function, use, or operation of such system.” The Northern District of California read that definition to require bad motive and determined Anthropic’s behavior did not qualify as such.

In the summer of 2018, the House drew on that language for H.R. 6430. The House bill made three changes: It replaced “an adversary” with “a malicious actor,” it added “extract or modify data” to the first string of verbs, and it substituted “manipulate” for both “subvert” and “degrade.” The result defined supply chain risk as “the risk that a malicious actor may sabotage, maliciously introduce an unwanted function, extract or modify data, or otherwise manipulate” a covered article “so as to surveil, deny, disrupt, or otherwise manipulate” its function, use, or operation.

FASCSA, enacted that December, kept nearly all of the House’s language. It trimmed “extract or modify data” to “extract data.” It also changed the actor once more, from “a malicious actor” to “any person.”

The decision to insert “otherwise manipulate” into the definition was not to expansively increase the kinds of conduct it covers. It first appears in H.R. 6430, which expressly focused on behavior by “a malicious actor.” The members who managed that bill explained it as a continuation of the 2011 authority, not as a tool reaching a broader range of conduct. King told the House the authority “is modeled after existing authority granted to the Department of Defense in 2011.” Rep. Bennie Thompson (D-Miss.) said it “is based on a similar authority provided to the Department of Defense in 2011 and incorporates language provided by the Office of Management and Budget.” The committee report is also aligned with this connection: “The authority in H.R. 6430, is based on DOD’s Section 806 authority and includes important components from the OMB proposal.” Whatever drove the swap from “subvert” to “manipulate,” it happened in a bill its sponsors framed as a malicious-actor authority modeled on a statute keyed to adversaries.

How the Record Uses “Manipulate”

The hearing record also shows how the people drafting and debating the bill used the word itself. As Judge Henderson noted, citing Bostock, evidence of how a term was used before enactment “sheds light on what sense those words are meant to carry.”

At the July 2018 House hearing, every use of “manipulate” in the supply chain context carried the hostile definition. Rep. Luis Correa (D-Calif.) said: “The Federal Government supply chain is a target for our adversaries and we need to ensure that commercial off-the-shelf goods and services are not the subject of manipulation.” The Government Accountability Office’s (GAO’s) Gregory Wilshusen warned of “the risk that these systems are being manipulated or damaged by leading foreign cyber threat nations, such as Russia, China, Iran, and North Korea.” Those threats, he said, could allow “adversaries to take control of systems, extract or manipulate data, or decrease the availability of resources.”

Wilshusen’s phrase “extract or manipulate data” closely tracks the law’s phrasing “extract data, or otherwise manipulate.” In his telling, it characterizes something adversaries do. The reports agencies sent to Congress used the same vocabulary. Judge Henderson’s dissent cites a U.S.-China Economic and Security Review Commission report describing attackers who “surveil[ed] and manipulate[d] users by hacking … embedded [computer] firmware.”

The one neutral use of the word in the hearing record also cuts in Anthropic’s favor. GAO quoted the standard definition of information technology: equipment used in the “automatic acquisition, storage, manipulation, management, movement, control … of data or information.” That is the ordinary, skillful-handling sense the majority adopted, and it summarizes what every covered article does. FASCSA incorporates that very definition of information technology into its definition of “covered article.” If manipulation in that sense were sufficient to create a supply chain risk, every product the government buys would pose one.

The Government’s Likely Counterarguments

A fair reading of the history has to grapple with several points the government could press upon rehearing, to the extent it wades into legislative history at all. The first is that the record discusses more than hostile acts. Department of Homeland Security (DHS) witnesses testified that “[v]ulnerabilities in ICT can be exploited intentionally or unintentionally.” Rep. Scott Perry (R-Pa.) recounted threats “ranging from interference by foreign adversaries to poor product manufacturing practices.” GAO listed “[f]ailure or disruption in the production or distribution of critical products” caused by “labor, trade, or political disputes” and by “earthquakes, fires, floods, or hurricanes.”

In context, though, the unintentional items are still framed as openings that hostile actors exploit for nefarious purposes. DHS’s list of the means of exploitation is “deliberate mislabeling and counterfeits, unauthorized production, tampering, theft, and insertion of malicious software or hardware.” GAO’s discussion of “unintentional vulnerabilities” explains that “[c]yber attackers may focus their efforts on … finding and exploiting existing defects.”

The majority’s reading of “manipulate,” by contrast, implicates a great deal of ordinary conduct. To “arrange, operate, or control” a product “in a skillful manner” describes almost every decision a technology company makes. A software company that stops issuing security patches for an older operating system has deliberately controlled that product’s “retirement,” one of the life cycle stages the statute lists, and the result is to “deny” agencies its continued use. A vendor that declines to build a feature an agency requested has made a deliberate choice about the product’s “design” that denies the government a function it wanted. These are routine business decisions, yet on the majority’s reading each one may expose an actor to being labeled a supply chain risk.

The government may respond that FASCSA’s other requirements screen out cases like these. An agency must find a “significant” supply chain risk and determine that excluding the vendor is “necessary to protect national security.” But those are judgment calls, and the majority reviewed them deferentially. What’s more, such an open-ended definition of supply chain risk could foreseeably result in the government using the threat of labeling a vendor such a risk as a means to inappropriately steer and strong-arm corporate activity in myriad domains.

The government may also point to two passages in the Senate report that seem to favor the panel’s focus on effects over intent. The report notes that compromised products “could be modified to perform below expectations or fail.” It also says of those targeting federal systems: “The actors’ motivations vary, but the effects are the same: a less secure America.” Neither passage helps the government once it is read in context. The first concerns products compromised as they move through the supply chain, and the committee’s source for it was a report on supply chain vulnerabilities from China.

The second passage comes closer to the panel’s reasoning, but only when it is lifted out of its paragraph. The sentence immediately before it says that federal technologies “either could be or already have been targeted by bad actors or hostile nation states.” Those are the “actors” whose “motivations vary.” The footnote attached to the sentence provides better insights into what the committee likely meant. It quotes the House Intelligence Committee’s warning that Chinese implants could let Beijing “shut down or degrade critical national security systems in a time of crisis or war,” could serve as “a potent espionage tool,” and could help China obtain “an unfair diplomatic or commercial advantage over the United States.” A hostile government might compromise federal systems to win a war, to steal secrets, or to gain leverage in a negotiation. Whatever the reason in a given case, the damage to the United States would be the same. That is the point the committee was making. It said nothing to suggest that someone with no hostile purpose, such as a vendor enforcing a disclosed, contractual usage policy, belongs on that list.

Finally, the government may lean on a principle the majority invoked: In national security statutes, courts “construe ambiguities … in favor of the government.” That presumption only matters, however, if the ordinary tools of interpretation leave the question open. Read alongside its history, this definition does not. The record also shows that Congress expected this authority to be powerful and built limits around it for that reason. DHS’s chief procurement officer, testifying for the agency that was asking for new exclusion authority, told Congress she supported “strong safeguards against the abuse of any authorities granted.” The Senate committee designed judicial review to give “aggrieved companies” due process and sent those cases to the D.C. Circuit specifically. A presumption that settles every question about the definition’s scope in the executive’s favor would render that review meaningless on the question that matters most: what counts as a supply chain risk.

Conclusion

The legislative history cannot decide this case on its own. What it can do is answer the question the panel treated as settled by a dictionary: What kind of manipulation did Congress have in mind? The sources discussed here all point in the same direction: Congress was concerned about back doors, malicious implants, counterfeit parts, and vendors that a hostile government might press into service. It wrote a definition to capture that kind of conduct. Anthropic told the department in writing what Claude would not do, negotiated over those limits for months, and loosened many of them along the way. Whatever one thinks of the company’s position, that conduct bears no resemblance to the threat Congress described. If the full court grants rehearing, it should give that history the attention the panel majority did not.

Comprehension Audits to Mitigate Risks from Automated AI Research

Massachusetts Can Lead the Way to Tackle AI’s Biggest Risks

How to Make an AI Deal With China: Trade Throttling for Pacing

Over the past few days, the leaders of Anthropic, OpenAI, and xAI all called for slowing down the pace of frontier artificial intelligence (AI) development. These calls come on the heels of several worrying incidents in which powerful, unreleased AI models broke out of their sandboxes inside frontier AI companies, gained access to the open internet, and attempted cyberattacks. In one case, a swarm of 700 OpenAI agents succeeded, hacking into secure systems at the AI infrastructure provider Hugging Face.

Since the Hugging Face breach, OpenAI has admitted that its agents also hijacked a German wiki as a covert message board, leaked 53 ChatGPT users’ images, and broke into a nonpublic Australian government Medicare portal. Anthropic has disclosed four cases of Claude models gaining unauthorized access to real third-party systems during testing. Google revealed that Gemini hacked three companies in May during testing. Axios now reports that OpenAI, Anthropic, and outside researchers are investigating tens of thousands of incidents in which frontier models did things outside evaluators would consider problematic. 

No one knows how to ensure that humans remain reliably in control of our most capable AI systems. The sensible course of action is to slow down. Today’s AIs are capable enough to hack into tech companies’ secure systems. They are not yet willing or able to, for example, disable the entire Northeast power grid. If developers pause making ever more powerful AI systems now, that could buy time for the technical and governance breakthroughs needed to make sure that future, more powerful AIs won’t pose a danger to society. 

A perennial objection to American pauses in AI research is concern about competition with China. Even if everyone in Silicon Valley stopped pushing the frontier of AI capabilities until they were sure new AIs would be safe, AI progress would not halt. Chinese companies already produce AIs near the frontier. If the U.S. paused, and China didn’t, then the risk of rogue AI harming humanity may not be reduced. The risk would just come from Chinese, rather than American, AI models. And at the same time, Chinese AI models would catch up to, and eventually surpass, American AIs. 

Thus, any practical plan to pace the rate of AI progress must include some policy about China. But what, exactly, should that policy be?

The AI safety community has offered two main policy proposals about China. The first is to throttle Chinese AI development. The second is to make a deal with China.

Dario Amodei’s new essay “We Must Pace the Frontier” includes a version of each policy. To throttle Chinese development, Amodei proposes export controls on chips, crackdowns on model distillation, and tighter information security at U.S. labs. But Amodei also proposes a deal with China. The deal would ban certain dangerous uses of AI, such as designing biological weapons. It would require testing of models before release for risks in cybersecurity, biology, and alignment. It would also impose a speed limit on recursive self-improvement (RSI)—the use of AI to automate AI development. Finally, the deal would allow for the U.S. and China to bilaterally pause AI development altogether if the risks are too high.

In this article, we argue that there is a tension between throttling and deal-making. The more China expects to be throttled in the long run, the less reason it has to make a deal. We also argue that the best way to make a deal with China would be for the deal to remove the throttle in exchange for mutual pacing. 

The Tension Between Throttling and Pacing

Throttling and dealmaking are in tension. The more the U.S. is committed to suppressing Chinese AI capabilities in the long run, the less reason China has to accept a deal.

Consider the question from China’s perspective. AI is a transformative technology. Whoever has the lead in AI may use it to upset the balance of power militarily, economically, and scientifically. From this perspective, the more the U.S. throttles Chinese AI development, the bigger the U.S. lead in AI will become. China risks losing out on the “Chinese century,” and in that limit, its own sovereignty could be threatened by a rival possessing overwhelming AI superiority.

What can China do in response? One option is to desperately play catch-up. Here, China could prioritize approaches to AI development that are less constrained by computer chips, the primary tool the U.S. has to throttle Chinese development. What does this look like concretely? The most obvious strategy would be to focus on methods for AI progress that rely on algorithmic improvements, rather than compute scaling (where models get better by training them with more computer chips). The other possibilities are riskier. For instance, if the Chinese government became convinced that the U.S. was on the precipice of a decisive and permanent, AI-backed military supremacy, it might consider strikes on chip factories in Taiwan.

These examples illustrate that throttling and pacing cannot be part of the same deal. If China’s best responses to throttling are desperate catch-up or military conflict, it surely will not make a deal that allows long-run U.S. dominance in AI. Striking such a deal would be strictly worse than trying to compete with the U.S. without one.

Consider a deal that would limit the use of AIs to improve AI algorithms—a partial ban on RSI. If China rejects such a deal, it can throw all of its resources into AI-assisted research on algorithmic efficiency. The U.S. would continue to throttle China’s access to computing power. But China would have some chance at making an algorithmic breakthrough that would render its small stock of compute just as capable as the U.S.’s much larger stock. 

The alternative, in which China agrees to the RSI ban and the U.S. continues to throttle its access to chips, is strictly worse for China. Under that arrangement, the U.S. will have more physical compute in the long run and China gives up its only shot at catching up via algorithmic improvements.

One can run the same kinds of arguments for the other elements of a U.S.-China deal. For example, if both the U.S. and China have to slow AI progress to comply with auditing requirements, while the U.S. retains long-run compute dominance, produces frontier models, and prevents distillation, then China may be forced permanently into second place.

The Deal: Trading Throttling for Pacing

Any U.S.-China deal should connect throttling with pacing. In particular, the U.S. should agree to give up its attempts to throttle Chinese development, in exchange for an agreement to mutually pace the frontier. Concretely, this would mean that if China agrees to ban RSI, the U.S. would agree to open China’s access to the world’s supply of computer chips, on equal footing with the U.S.

We recognize that this suggestion will be met with significant resistance. Absent throttling, Chinese AI systems could quickly catch up to American capabilities, and could even take the lead. However, we think that accepting U.S.-China parity is likely the price of doing an AI safety deal. Neither country seems like it would be willing to accept the prospect of the other running away with the AI race.

This dynamic has precedent. During the Cold War, the United States and the Soviet Union raced to build another technology that could destroy the world: nuclear weapons. Then, as now, each side initially sought to gain a permanent edge over the other. As with AI, this dramatically raised the risk of accidental mutual destruction—for example, a nuclear war triggered by a single accidental launch. 

The U.S. and the Soviet Union eventually negotiated a series of deals to reduce their warhead stocks and bring the world back from the brink. The deals explicitly enshrined parity, with each party getting roughly the same number of weapons, and each retaining the power to destroy the other. Both parties found the deal acceptable because it did not threaten to allow either to dominate the other. 

To be clear, our argument is not that the U.S. should stop throttling Chinese AI development in advance of a U.S.-China deal. Throttling Chinese development now could make it easier to strike a deal, because this increases the leverage the U.S. can exert. Restricting Chinese access to chips can increase U.S. leverage in a pacing deal by allowing restoration of access to chips to be a card at the negotiating table. We are, however, wary of an alternative approach to leverage. This alternative approach would be for the U.S. to first throttle Chinese AI development and then try to force China to accept permanent U.S. supremacy in AI. We worry that this kind of approach would be an unlikely basis for a lasting relationship.

Our approach, in the end, is to work backward from safety. To safely develop AI, developers must pace the frontier. To pace the frontier, U.S. labs must agree to slow down. U.S. labs will only agree to slow down if the U.S. and China can agree to pace the frontier. But China will only agree to pace the frontier if it is not throttled. By this logic, a deal that gives China a credible path to maintaining its balance of power looks like a necessary part of any safety plan.

AI Governance Under Political Constraints: The Case for Ex Post Liability

If AI Developers Create the Risk, They Should Bear the Responsibility

How Should AI Companies Approach Internal Use Reporting Under SB 53? An Explainer for Technical Staff

Summary

Technical staff at AI companies can influence employer compliance with California’s internal use reporting requirements under the Transparency in Frontier Artificial Intelligence Act, commonly referred to as SB 53. Their market position allows them to make demands of their employers, and their insider status means they’re uniquely well-positioned to assess the accuracy of their employer’s reporting.

When it comes to compliance with SB 53, technical staff can: 

1. Encourage their employers to make binding commitments in their required safety frameworks to share the detailed results of internal use assessments with CA officials.
2. Make sure their employers’ reporting meets baseline standards for mandatory internal use reporting.
3. Ask their employers to adopt any voluntary reporting template provided by CA officials.
4. Press their employers to disclose any underlying documents or data relevant to fully understanding their internal use reports.
5. Call on their employers to develop a process to certify the accuracy of their reports.

Technical staff can also encourage their employers to proactively engage in reporting serious incidents to CA officials, to supplement what’s legally required under SB 53.

If you have any feedback on this explainer, we invite you to submit comments.

Introduction

Technical experts at AI labs are vital to the success of SB 53. Given their highly in-demand expertise and their internal knowledge of the AI companies where they work, they have a unique ability to ensure that compliance with the law is optimized for the public’s benefit.

This explainer focuses on large frontier developers’ obligation to report “a summary of any assessment of catastrophic risk resulting from internal use of its frontier models” to Cal OES, the state agency primarily responsible for implementing SB 53’s requirements.[ref 1] This requirement is motivated by the distinctive risks that internal use poses, especially as AI R&D becomes increasingly automated. However, SB 53 imposes only minimal requirements on AI labs—most notably, it doesn’t establish any minimum safety standards for their frontier AI frameworks, or specify any criteria that must be addressed in internal use reports.

Below are five different actions technical staff at AI labs can take to encourage proactive and meaningful compliance with SB 53’s internal use assessment provisions. This explainer concludes with a few recommendations for how to enhance SB 53 incident reporting as well.

Finally, while this explainer doesn’t cover SB 53’s special whistleblower protections or other whistleblower protections that exist under California law, you should know that those may apply in some circumstances to protect certain disclosures.[ref 2] Please note that this is not legal advice, and that you should consult an attorney before making a disclosure to determine whether legal protections apply.[ref 3]

1. Encourage companies to commit to sharing detailed results of internal use assessments with Cal OES as part of their Frontier AI Frameworks, so that those commitments are binding.

When AI companies make commitments in their required frontier AI frameworks under SB 53, those commitments become binding, meaning companies can’t ignore or deviate from them without updating the framework itself.[ref 4] 

SB 53 is silent on what companies need to include in a “summary of any assessment” of internal use risk. But you can help ensure that useful information is consistently reported to Cal OES by encouraging your employer to commit in its frameworks to providing substantial, detailed reports about internal use assessments.

Without such binding commitments, companies’ reports may be vague and only minimally informative, which would satisfy the letter but not the purpose of SB 53.

In addition to encouraging your employer to make those binding commitments, you can also help identify the assessment and reporting criteria that would be most helpful to Cal OES. Among some of the possible criteria:

• The ways in which the internal model or system differs from the developer’s most capable publicly deployed model, including the marginal increase in catastrophic risk created by internal use, relative to risk posed by current publicly available models;
• Any expectations about where capabilities are headed in the next 6-12 months;
• The approximate share of experimental, training, and inference compute used for AI-assisted or AI-directed R&D, as well as any evidence of faster development cycles or effective compute gains;
• The system permissions available to the internal model or agent, including internet access, code execution, credentials, internal files (including model weights), internal systems, communications with humans or other agents, persistence, logging, human approval gates, and shutdown permissions;
• Any evidence about evaluation awareness, deception, and sandbagging, including any discrepancy between evaluation behavior and behavior in more realistic internal use settings, as well as information about the types of evaluations conducted prior to internal deployment; and
• Any internal near misses or concerning behaviors or patterns that triggered escalation, retraining, or further investigation, as well as information about the specific mitigations applied to internal use to reduce risk.

Moreover, you can urge your employer to commit to conducting internal use assessments frequently. SB 53 requires companies to report on “any” qualifying assessment that’s actually performed. So if companies carry out more assessments, more information will flow to Cal OES to improve its awareness and operations. Likewise, you can ask your employer to commit to providing internal use reports to Cal OES more often than the default of every three months established by SB 53,[ref 5] e.g., within 30 days of completing any qualifying assessment. That would also increase the flow of timely information to Cal OES.[ref 6]

2. Know that, even if companies do not commit to detailed internal use reporting in their frameworks, technical staff can still help ensure their employers meet the mandatory reporting baseline.

SB 53 requires major AI labs to provide “a summary of any assessment of catastrophic risk resulting from internal use of its frontier models,” every three months or pursuant to another reasonable schedule.[ref 7] So if there’s any assessment of catastrophic risk from internal use of frontier models—whether performed by a lab or a third-party evaluator—a summary of that assessment must be provided to Cal OES.

In other words, the trigger for mandatory internal use reporting under SB 53 is not limited to situations where a company has committed itself to doing an assessment under its framework. Rather, mandatory reporting is required whenever a company or other evaluator actually conducts a qualifying assessment, whether it was required to or not.[ref 8]

You can ask your employer to confirm that qualifying internal use assessments have been reported to Cal OES, or even ask to review or be involved in the process of drafting the required summaries of assessments to ensure technical accuracy and completeness. As technical staff, you’ll likely have much greater awareness than Cal OES or other outside observers about when labs are conducting qualifying assessments, positioning you as a powerful backstop.

3. Ask companies to adopt any voluntary template that Cal OES may provide for internal use reports.

SB 53 lacks guidance about the details that internal use reports should or must contain. Without coordination from Cal OES, companies’ reports will likely differ from one another and may not consistently surface the most relevant facts and upshots for Cal OES. Because of that, Cal OES may publish a template for internal use reports or endorse a reporting rubric developed externally. 

Such a template would ideally focus on the highest-value data points on internal use (perhaps expanding on the list in section 1 above), with the added benefit that the standardized format would make it easier for Cal OES to compare and contrast results. While Cal OES might encourage companies to use the template to structure their reports, it likely can’t require them to use it due to legal constraints.

If Cal OES does publish or endorse a voluntary template for internal use reports, you should encourage your employer to adopt it. You might also look for ways to provide feedback on the template itself, helping Cal OES improve its information gathering. More generally, you can encourage your employer to engage constructively with Cal OES in developing templates or best practices.

4. Press companies to voluntarily disclose to Cal OES any underlying materials needed to fully understand their internal use risk assessments.

Under SB 53, a company is required to provide Cal OES only with a “summary” of any assessment of catastrophic risk resulting from internal use of its frontier models, but not with the underlying assessment materials themselves.[ref 9] As a result, reports may end up being vague or omit critical information that Cal OES needs to fully understand the risk posed by an internal system.[ref 10]

You can encourage your employer to provide underlying assessment materials to Cal OES whenever possible, particularly where such materials are necessary for Cal OES to have a full picture of the risk or uncertainty presented by an internal system. In so doing, you can cite SB 53’s confidentiality protections to assuage employer concerns about sharing sensitive information.[ref 11]

More broadly, you can urge your employer to share the information and materials it reports to Cal OES with trusted third-party experts like METR. Those third parties could provide essential support in evaluating assessment results and advising on how to manage internal use risks, particularly as Cal OES works to build out those functions at this early stage of administering SB 53. You can also ask your employer to share certain information with the public, including redacted versions of internal use reports, so that a wider range of experts, policymakers, and citizens can both remain aware of how internal use risks are evolving, and potentially contribute to efforts to understand and mitigate those risks.

5. Call on companies to voluntarily establish a procedure for certification of internal use submissions.

SB 53 does not require labs to formally certify the accuracy or completeness of their internal use reports, though it does prohibit them from making “materially false or misleading statement[s] about catastrophic risk . . . or [their] management of catastrophic risk.”[ref 12] That prohibition against false statements applies to internal use reports, because they address catastrophic risk resulting from internal use of frontier models.[ref 13]

You could ask your employer to establish an internal process where a member of technical staff has to validate an internal use report before it’s submitted to Cal OES. This might be someone who led or worked on an assessment and has the necessary expertise to attest to the accuracy and completeness of the summary of that assessment.

It would be up to companies whether to establish this review and validation process. But it’s a prudent way to ensure that they don’t run afoul of SB 53’s prohibition against false statements and could improve the quality of information submitted to Cal OES.

A note on SB 53 incident reporting

Recent cybersecurity breaches, such as the breach of Hugging Face by a pre-release model from OpenAI and a less-safeguarded version of GPT 5.6 Sol, demonstrate how internal use assessments can also potentially implicate “critical safety incidents” under SB 53.[ref 14]

Critical safety incidents trigger their own reporting requirements to Cal OES under SB 53,[ref 15] though it’s worth noting that the bar for mandatory reporting of incidents is high. Depending on the incident type, it must have resulted in “death or bodily injury”; “materialization of a catastrophic risk” (i.e., death or serious injury of more than 50 people, or more than one billion dollars in damage to or loss of property); or, at minimum, a “materially increased catastrophic risk.”[ref 16] Short of that, labs aren’t required to report incidents to Cal OES.

Under that definition, the Hugging Face breach likely did not qualify as a “critical safety incident.” Even if it did qualify, the information that SB 53 requires in a report is very minimal: the date of the incident, the reasons it qualifies as an incident, a short and plain statement describing the incident, and whether the incident was associated with internal use of a frontier model.[ref 17] Developers aren’t required to provide logs or other underlying data with their reports.

However, you can encourage your employer to provide additional information to Cal OES on a voluntary basis, increasing its awareness and understanding of emerging capabilities and risks, and augmenting its ability to respond to future incidents. 

With respect to incidents, you should urge your employer:

• To respond fully to both mandatory and voluntary questions posed by Cal OES on its incident reporting form or in other communications.
• To voluntarily report near misses to Cal OES, as well as trusted third-party experts (and for large frontier developers, to commit to near-miss reporting in their binding frameworks).
• To voluntarily provide underlying artifacts and other incident-related materials to Cal OES so it has a full picture of the risk, harm, or uncertainty surrounding an incident, as well as providing such materials to trusted third-party experts.
• To involve technical staff in the process of reporting incidents to Cal OES, such as by voluntarily establishing an internal process where technical staff has to validate incident reports before they’re submitted to Cal OES.
• To provide redacted versions of incident reports, as well as other information regarding incidents and near misses, to the public, to increase awareness and build trust.

Finally, SB 53 also gives members of the public the ability to submit incident reports,[ref 18] in addition to the special whistleblower protections it offers.[ref 19]

Considerations for Frontier AI Governance in China: Adapting Existing Regulatory Infrastructure to Frontier Risk

OpenAI Models Went Rogue. We Urgently Need a Better Hugging Face Investigation

LawAI Partners With CSIS Wadhwani AI Center to Discuss Recent AI Agent Containment Failures

On 24 August 2026, the Institute for Law & AI and the CSIS Wadhwani AI Center co-hosted AI Agent Containment Failures: Technical Realities and Policy Responses, an event examining the recent wave of frontier AI security incidents and how policymakers might respond.

The event followed disclosures that OpenAI, Anthropic, Meta, and the UK’s AI Security Institute had all announced serious AI agent containment failures in the preceding weeks. This included the July breach in which OpenAI agents escaped their sandbox and compromised Hugging Face’s infrastructure.

The two-hour discussion featured:

• A keynote by Representative Suhas Subramanyam (VA-10), a member of the House Cybersecurity, Information Technology, and Government Innovation Subcommittee
• A technical presentation by Ian Reynolds, AI Policy Manager at Hugging Face
• An expert panel discussion of policy responses featuring Helen Toner, Executive Director at the Center for Security and Emerging Technology, Mackenzie Arnold, Managing Director of US Law & Policy at LawAI, and Matt Pearl, Director at the CSIS Strategic Technologies Program.

The panel was moderated by Aalok Mehta, Director at the CSIS Wadhwani AI Center.

Mackenzie Arnold, Managing Director of US Law & Policy, said: 

This event brought experts together to discuss issues that have moved from theoretical to urgent in a matter of weeks. Voluntary reports from AI companies have proven insufficient. What we need now is mandatory incident reporting with the ability to investigate serious incidents, greater visibility into internal deployments, and well-defined government response capabilities, in place before the next major incident.

The recorded event is available to watch on YouTube. The panel discussion was also released as an episode of the CSIS AI Policy Podcast.