Because attackers already use the AI available now, and most are not waiting for any coordination agreement. Slowing responsible builders does little to affect criminal or state-backed actors that ignore restraint, but it can delay defensive tooling that depends on the same capability curve. The practical effect is often to widen the gap between attackers and defenders instead of closing it.
Why slowing frontier AI changes the defender timeline more than the attacker timeline
Offensive cyber capability is already broadly available through current models, public tooling, and established criminal tradecraft. Slowing frontier development does not remove that baseline from attackers who will not coordinate or comply, but it can delay the arrival of better detection, triage, code review, and response tooling that defenders would otherwise use to compress the gap.
Why the attacker side does not wait for policy coordination
The core problem is timing. Criminal groups and state-backed operators do not need frontier models to begin phishing, malware adaptation, vulnerability discovery, social engineering, or automation-assisted reconnaissance. They optimise around what exists now, so a slowdown at the frontier mainly changes what responsible teams can build next, not what hostile actors can already buy, steal, or repurpose.
That means the risk picture is asymmetrical. The attacker only needs enough capability to be effective at scale, while the defender needs capability that is reliable, integrated, and safe to deploy in production. When progress slows, the defender often loses the marginal gains that would have improved analysis speed, alert handling, and analyst leverage before the attacker loses meaningful capability.
Why defensive progress is the part that gets delayed
Many of the most valuable near-term AI uses in security are defensive and operational: faster summarisation of alerts, better detection engineering, safer code review, improved telemetry triage, and more efficient incident response workflows. Those improvements depend on the same general capability curve as offensive use, so a broad slowdown can defer both the protective gains and the misuse.
That is why “slowing down” can widen the relative gap even if it lowers absolute progress. If the defender’s tooling matures more slowly than the attacker’s already-available methods, the adversary keeps today’s advantage while the defender waits for tomorrow’s improvement. The result is often not reduced offensive risk, but delayed defensive catch-up.
Risk and Threat Considerations
Today’s offensive cyber risk is driven less by frontier access than by deployment realism: existing models, legacy exploit chains, stolen credentials, and human-operated workflows already support meaningful abuse. A slowdown matters most when it delays defensive adoption or creates a false sense that current threats will naturally pause.
Failure mechanism: Hostile actors continue using current capabilities while defensive teams postpone or underinvest in the AI-enabled controls that would otherwise reduce dwell time, triage load, and analyst bottlenecks. That preserves attacker throughput and can make the defender’s response window worse, not better.
Impact: Organisations see little immediate reduction in phishing, intrusion support, or automation-assisted abuse, while they may lose time on the tools that would have improved detection and response against those same patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1589 — Gather Victim Identity Information | The question concerns current offensive tradecraft and attacker capability now. |
| Recommendation — Map present attacker activity to ATT&CK techniques and tune detections for current tradecraft. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Slower defensive AI can delay alert triage and response improvements. |
| Recommendation — Improve log collection and review to shorten attacker dwell time. | ||
| NIST AI RMF | GV.1 — Govern AI Risk | The question weighs policy timing against real offensive and defensive AI risk. |
| Recommendation — Set AI risk priorities around current abuse and near-term defensive benefit. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | The answer centers on preserving detection speed as attacker capability persists. |
| Recommendation — Use SI-4 to strengthen monitoring against existing offensive techniques. | ||
Practitioner Guidance
What to prioritise: Treat offensive risk as a present-tense problem, not a frontier-timeline problem. If the threat already uses current models and commodity automation, focus on detection, identity hardening, exposure reduction, and response speed rather than waiting for policy to change attacker behaviour.
What to verify: Test whether your defensive use cases are blocked by governance, procurement, or model access constraints that do not meaningfully constrain adversaries. The practical question is whether your controls improve faster than attacker tradecraft evolves, not whether the industry has slowed frontier training.
Practitioner takeaway: Slowing frontier development is not a substitute for reducing today’s attack surface, because the immediate security gain comes from faster and safer defence than from hoping attackers will self-limit.
