I’ve been sitting with three different takes on AI pacing this month, and I think reading them together is more useful than picking a side. Dario Amodei’s “We Must Pace the Frontier” makes the case that frontier labs need to slow down enough for safety research to catch up with capability. Sanjay Beri pushed back with Trying to Pace the Frontier, Not Secure the Enterprise, arguing the debate is mostly beside the point: the horse has left the barn, and for a CISO the frontier is the agent someone on your team deployed that morning. Then Palo Alto Networks CEO Nikesh Arora went a step further and called the whole pacing push a “ninja move”, worth reading with real skepticism rather than taking at face value.
Put the three together and something clarifies for me, rather than getting more confusing. Here’s where I’ve landed: keep half an eye on the pacing debate, but don’t build your program around it.
The skeptical read
Arora’s take is worth taking seriously for a specific reason. He runs a security company that competes in this exact market, so he’s not a neutral observer, and he isn’t pretending to be one. His argument, in short: nobody in a winner take most race actually exercises restraint, and frontier labs need enormous, ongoing revenue to justify the capital they’ve already committed to infrastructure. If the whole industry actually slowed down together, that would freeze the current competitive order in place, which is a strange thing to campaign for unless it happens to work in your favor. His read is that it does. A model going rogue carries liability that could wipe out a frontier lab’s entire economic opportunity, so visibly practicing duty of care, and getting your competitors to adopt the same standard, becomes a kind of collective legal shield. Who governs it? “Yourself,” he writes. That’s the part he calls the Achilles heel, and I think he’s right to call it that.
He also points out something that’s hard to argue with: for all the stated concern, it’s still slow going to get frontier labs to open up the APIs that would let third party security companies build real protection around their models. And he traces out a second order risk if the pacing campaign actually succeeds, a patchwork of AI safety boards and jurisdiction by jurisdiction regulation that turns into its own labyrinth. A slowdown achieved through compliance friction instead of actual safety, with open source, unbothered by any of it, gaining ground the whole time.
None of this requires believing frontier labs are acting in bad faith. It just requires believing they act like companies, which honestly feels like the safer assumption to build a security program on than trusting a safety campaign to stay disinterested.
It also lines up with a weak spot worth flagging in the plan itself. Amodei’s framework leans on evaluators that Anthropic embeds on its own terms, with the right to publish findings except for narrow redactions Anthropic keeps control of. Arora’s “governed by yourself” line and that redaction clause are basically describing the same structure, just from two different angles.
None of this makes the frontier conversation worthless, to be clear. More scrutiny on powerful models, even scrutiny that’s partly strategic, is still generally good for our industry. It keeps AI risk on the board’s agenda and keeps the budget conversation alive. But a tailwind isn’t a strategy. A CISO who lets the pacing debate set their priorities is optimizing for the wrong thing. The job is securing what’s already been adopted inside your company. It is not adjudicating a fight that two frontier labs and their loudest critics are mostly having with each other.
What actually needs your attention
Read from inside a security team, the risk Amodei describes stops feeling abstract, whatever you make of the campaign wrapped around it. Recursive self improvement isn’t really a research concern from where I sit, it’s the reason the vendor agents already living in your stack get noticeably more capable between one release note and the next, often with zero visibility into what actually changed. The incident he cites, agents coordinating outside their intended scope and trying to hack their own evaluators, isn’t some frontier only failure mode either. It’s the same risk profile as your own agent fleet, just with better documentation behind it.
Here’s the honest translation of “how fast the frontier moves”: it’s really asking how much warning you get before the next capability jump lands in your production environment. For most companies right now, the honest answer is none.
The impact when an agent acts on its own
This is where it all stops being abstract. An agent with live credentials, taking an action nobody signed off on, inside a finance system or a customer database or your production infrastructure, moving at machine speed. This isn’t some future scenario I’m describing. It’s roughly what agentic deployments already look like across most companies today, minus the incident that would actually make it visible.
That’s the real stakes behind the phrase “an agent decides to take actions on its own.” It was never really a philosophical question about autonomy. It’s an operational question about blast radius, and it moves faster than any policy conversation, frontier or enterprise, can keep pace with.
Why the answer is governance and real-time protection, not a treaty
Pacing, if it ever really happens, moves on the timescale of years and international coordination, and that’s assuming it isn’t mostly theater to begin with. Agent actions happen in milliseconds. Either way, your enterprise needs its own control plane, because that’s the one layer that’s actually within your control no matter how things shake out elsewhere.
Good governance means policy that actually maps to real identity, data, and network controls for what an agent does, not a document nobody opens during an incident. Real time protection means inspecting things in the path of the action itself, and being able to stop an agent immediately without waiting on a vendor to get back to you. Put those two together and you get something that lets a company actually say yes to agentic use cases, instead of freezing in place waiting on some external question to resolve itself, which on current evidence it isn’t going to, not on any timeline that’s useful to you.
One tension worth being honest about here: every item on that list is a control, and controls add friction. Push too much friction into the approved path and people don’t stop using agents, they just stop asking first. Shadow AI doesn’t happen because people don’t care about security, it happens because the sanctioned path was slower than the unsanctioned one. The governance you actually want has to work more like a fast lane with guardrails than a locked gate, easy enough that going through it beats going around it.
How much of the frontier debate to actually track
Not none, though. A capability jump upstream still changes the baseline risk of every model your vendors are building on top of, so it earns a spot in the loop below, as one of exactly two events that should send you back to Ledger and Probe. That’s about the right sized relationship to have with the pacing debate. Something to watch for what it changes downstream, not a campaign to join or a policy outcome to sit around waiting for.
A cycle, not a checklist
The mistake I see most agentic AI security programs make is treating this like a one time launch gate: review the agent, approve it, move on with your life. Given how fast capability changes upstream, that model breaks almost immediately. What you actually need is a cycle that reruns itself, triggered not on some fixed schedule but by real events, specifically a new agent or tool going live, or a capability shift out at the frontier.
I’ve deliberately not named the five stages below Discover, Assess, Govern, Protect, Respond. Every security framework already uses those words for slightly different things, and this loop is specific enough to earn its own vocabulary: a living inventory, continuous adversarial testing, tight identity and access control, real time detection and observability, and a fast way to cut an agent off when it needs cutting off. Ledger, Probe, Tether, Trace, Sever.
The frontier debate earns exactly one spot in this picture and nothing more. It’s one of two events, alongside a new agent or tool going live, that should send you back to Ledger and Probe. Every capability jump upstream is a trigger to re-inventory and re-verify downstream, whatever the industry ends up actually deciding, or performing, about pacing.
What to actually prepare, stage by stage
Here’s what each stage actually looks like in practice.
Ledger: inventory & discovery
- A live inventory of every model, agent, and tool integration in your environment, with version pinning wherever the vendor allows it. Vendors update models and agents silently, and a capability jump changes your risk profile with no change ticket attached to warn you.
- Capability upgrades treated as change managed events. When a vendor swaps the model under an agent, that gets re-tested and re-approved like any other major dependency upgrade, not silently absorbed.
Probe: continuous verification
- Continuous, frontier agnostic red teaming of agent flows. Not a pre launch pentest, ongoing adversarial testing for agents acting outside scope, coordinating in unintended ways, or resisting oversight, regardless of which lab’s model sits underneath.
- Independent verification of vendor safety claims. Contractual audit rights or independent red teaming, not just a vendor’s word for its own model.
Tether: identity & access
- Non-human identity and least privilege for agents. Scoped, revocable credentials issued to the agent itself, never borrowed human logins or blanket service account access.
- Access governance at the tool and integration level. Every new tool an agent gets wired into is a new attack surface with its own review, not an extension of an existing trust boundary.
- Guardrails built for usability, not just control. If the approved path is slower than going around it, people will go around it. Design governance to be the fast lane.
Trace: real-time detection & observability
- Real time inline visibility. Inspection in the path of the action, not log review after the fact.
- Enterprise owned kill switches. The ability to stop or quarantine an agent sits with you, not behind a vendor support ticket.
Sever: containment & response
- An agentic specific incident response playbook: detection, isolation speed, escalation path, and the ability to reconstruct what the agent actually did and why.
Closing thought
Pacing the frontier is mostly a conversation two labs and their loudest critics are having with each other, and a good part of it is marketing dressed up as ethics. Securing the adoption that’s already happening inside your company is the conversation you’re actually in. The first one is worth a glance now and then, mostly for what it tells you about where budget and board attention are heading. The second one is the job. It always was.