Slow is a design principle, not a delay

Two things happened last week, one day apart, and almost nobody connected them. 

On 11 September, the EU Cyber Resilience Act’s vulnerability reporting obligations came into force. Companies covered by the regulation now have to report actively exploited vulnerabilities within 24 hours and provide a fuller notification within 72.  

On 12 September, Anthropic CEO Dario Amodei published an essay arguing that the AI industry should deliberately slow the rate at which frontier models become more capable.

Sam Altman backed the idea within hours, and Elon Musk, who runs a frontier lab of his own, responded simply: “Dario is right.” 

These look like unrelated stories, but they are driven by the same pressure. When a technology moves faster than our ability to understand, test and control it, slowing the rate of change is not a constraint on innovation. It is what makes innovation sustainable. 

What “pacing” actually means 

Amodei is not arguing for a halt. His point is that training and technical progress should continue, but that capability improvements should not outrun our ability to evaluate and control them. 

That principle should be familiar to anyone in cybersecurity. We do not assume an annual audit secures a constantly changing environment, which is why we use continuous monitoring, testing and response instead. AI is now running into the same problem, and it is arriving at the same answer. 

What makes this particularly relevant is where the risk is showing up. Amodei said his view changed as AI got better at building its own successors and at operating autonomously inside real systems. The second of those is a cyber problem before it is anything else. The concern is no longer primarily what a model says. It is what an agent can actually do inside a network, which happens to be our discipline rather than theirs. 

The uncomfortable part 

Slowing the frontier does not make the rest of us safer. Attackers are not waiting for the next generation of models, because they are already working with what exists: open-weight models, commercial APIs and freely available orchestration tools. 

In July, Sysdig documented an extortion operation in which a human selected the target while AI handled much of the attack. When an initial login failed, the system analysed the error, adapted its approach and succeeded shortly afterwards. If the major labs slowed their capability curve tomorrow, attacks built with today’s technology would still run next week. 

So why support pacing at all?

Because offence and defence have very different tolerances for failure. An attack agent that succeeds occasionally is still highly effective when it can make thousands of attempts at almost no cost. A defence agent that is wrong 10 per cent of the time is close to unusable, because it will isolate the wrong device, revoke legitimate credentials, or generate enough false positives that the customer stops trusting it. Attackers can afford to experiment. Defenders have to keep the business running. 

That asymmetry is why the things pacing is meant to buy are worth more to us than to the people we are defending against. Better evaluations, a clearer understanding of model behaviour, stronger controls and greater confidence that a system will behave predictably when someone is deliberately trying to break it are all defender requirements. An attacker needs none of them.

They need the system to work often enough. 

We have seen this before 

Almost everything in the pacing debate already exists in security engineering under a different name. Independent evaluators are separation of duties. Capability gates are change control. Proving something works before exposing it to production is staging. Requiring more than one person to approve a consequential action is the four-eyes principle. 

We did not invent those processes because security people dislike speed. We invented them because uncontrolled speed creates a different and more expensive kind of delay later, in the form of incidents, rollbacks, investigations and lost customers.

That is what I mean by slow as a design principle. Nobody thinks a code review means engineering has stopped, and nobody reads a staged rollout as a retreat. They are the mechanisms that let organisations move quickly without losing control. 

Europe has taken much of that logic and written it into regulation.

You can debate the detail of the Cyber Resilience Act, and plenty of people have, but the underlying principle is hard to argue with: software that creates security risk should be designed and maintained with security in mind, and serious vulnerabilities require rapid action. 

What this means for us 

None of this is an argument for moving slowly on cyber defence. Attack automation is real and it is getting cheaper. 

The same asymmetry applies in both directions. AI amplifies whoever already has the data and the discipline to use it well, and amplifies the mistakes of whoever does not, at the same speed.  

The answer is to apply the same discipline to AI-enabled defence that the frontier labs are only now applying to AI development, and to earn every new capability against real attack data, not assumptions. 

At Heimdal, that starts with being clear about the difference between assisted and autonomous functionality. Customers should know when AI is making a recommendation and when it is taking action, because blurring those two is how vendors lose trust they do not get back. 

It also means giving customers control over consequential actions. Isolating a host, revoking credentials or granting elevated privileges can have serious operational consequences, and the right answer genuinely varies. In some environments automation is correct. In others, a human decision is essential, and that judgement belongs to the customer rather than to us. 

Finally, it means being explicit about where inference happens which model providers are involved, which regions are used, and what customer data leaves the environment. Sovereignty is not a slogan. It is an architectural decision, and it can be answered specifically or not at all. 

Where this lands 

Cybersecurity does not get to slow down. Attackers will keep moving and they will automate more of the work, so there is no pause button on the estate you are responsible for. What we do get is the ability to be deliberate about where AI is allowed to act, what it is allowed to change, and what evidence we require before we trust it. 

When the companies building the most capable AI systems decide that a reduction in speed buys them something worth having, it is worth asking what they can see. In our field the answer is not smarter models. It is capable agents, available today, running inside real networks on behalf of people who intend harm. The labs can choose their pace. We do not get that choice, which is exactly why the discipline has to come from us instead. 

If you liked this article, follow us on LinkedIn, Reddit, X, Facebook, and Youtube for more cybersecurity news and topics.

Jesper Frederiksen

Jesper Frederiksen brings over 30 years of sales, technology, and leadership experience to Heimdal®, spearheading multiple IT technology organizations to exponential growth. Before becoming Heimdal®'s CEO, he successfully led the international operations at Lacework as General Manager, served as EMEA VP and General Manager at DocuSign and Okta, and held various senior leadership roles at Parallels, Symantec, and Google. In addition, Jesper is a non-executive board member at Keepit, Siteimprove, and LearnUpon.