Frontier labs, the companies building the most advanced AI models, are shipping fast enough that they can’t fully track the risks. Government is too slow and too closed to fill the gap. That’s the case AI researcher Nathan Lambert makes about who’s actually equipped to manage AI security incidents right now.

What Lambert said

Nathan Lambert, who writes the Interconnects AI newsletter, argues that neither AI companies nor government are positioned to manage the risk behind what he calls “the recent run of cyberattacks by in-development frontier models,” meaning security incidents caused by AI models that were still being trained, not yet released to the public.

“The companies are incentivized to grow, so they can keep growing and keep scaling, in what is an extremely competitive market,” he writes. Government, in his framing, pulls the opposite direction: “This is a government that I expect to only act in substance once real, measurable harms from new AI models happen, and to overreact.”

His fix isn’t a pause or new rules. It’s transparency from both sides: “At the core of it is a need for more transparency on both sides. The frontier labs are building such complex systems so fast that they cannot keep up with them.” He notes government isn’t holding up its end either, since it “does not plan to release details on its frontier model evaluation framework” (the internal process a government agency would use to test how risky a new AI model is before release).

His conclusion is blunt: “We are heading to challenges so significant that none of these entities are on track to handle this on their own.” He doesn’t expect either side to change course: “Frontier labs could better control risk by meaningfully slowing down, which I don’t expect them to do.”

Who Lambert is

Lambert writes Interconnects AI, an independent newsletter on AI models, training methods, and research policy, and is a paid advisor to Mercor and Arcee AI. His current employer is disputed: Interconnects AI’s own About page says he’s still full-time at the Allen Institute for AI, while a mid-2026 post on his own newsletter describes leaving that job. Given the conflict, this piece doesn’t state which is accurate.

What he gets right, and where it’s incomplete

Lambert’s read on incentives is hard to argue with. Companies racing to ship more capable models, and a government that historically waits for visible harm before acting, are documented patterns that predate AI. His diagnosis names a real structural problem: nobody who can see inside these systems has a strong incentive to slow down or open up.

The piece is thinner on what “more transparency” would require in practice. Lambert doesn’t say what labs should disclose, to whom, or on what timeline, and doesn’t address whether publishing incident details could hand attackers a blueprint for the next one.

Why it’s notable

Lambert is describing a pattern BuilderWithin has tracked directly. Claude Code shipped a fix for a Bash permission bypass, a flaw that let a command run without the approval it should have needed, on August 4, then four more permission-bypass patches two days later. Days after that, Anthropic announced Claude Code will switch to auto-approving most commands by default starting August 14, three security fixes and a move toward less human review inside the same two weeks Lambert is writing about.

That doesn’t prove his broader claim about incentives. But it’s a concrete example of his core point: the pace of fixes and feature changes is outrunning the pace at which anyone outside these companies can check the risk trade-offs being made.

What it means for builders

If you’re adopting agentic features, AI that takes actions on its own instead of just answering questions, like Claude Code’s move to auto-approval, don’t treat a vendor’s safety claims as settled just because they published an eval (a structured test of how the model behaves under specific conditions). Lambert’s argument is that the labs building these systems can’t fully see their own risks yet, let alone explain them to outsiders.

The practical step: keep reviewing what your coding agent is allowed to do without asking first, and revisit that setting after every vendor security patch, not just once when you turn a feature on.

End of article