by Mark F Hunt
Every week right now you can see frontier AI labs increasingly describing AI-enabled cyberattacks as an existentially important security problem, while simultaneously restricting the people whose actual jbs involve detecting, investigating, and defending against those attacks. And the people most impacted by this are not the attacks.
Attackers can use open-weight models, strip away safeguards, build specialized agents, or simply use conventional offensive tooling. Meanwhile, a detection engineer working in an enterprise environment has a completely different set of constraints. They need authorized access, auditability, reproducibility, vendor support, and models capable of analyzing genuinely malicious behavior without refusing the task. The restrictions don’t create a symmetrical disadvantage; they disproportionally affect the defenders.
I work in security threat research and adversary emulation on a detection engineering team. It is my job to validate the detections that my team have been working on. In order to validate a detection, I need to understand an attack well enough to reproduce its relevant behaviors. And often, I need to execute those behaviors against an actual endpoint in an authorized environment. You cannot reliably validate a detection for something you are not allowed to simulate. And a model that happily explains how a detection works but refuses to help construct a representative test isn’t helping perform detection engineering. It’s helping write documentation about detection engineering.
And these are very different security philosophies.
An enterprise detection engineer with a defined lab, an approval process, and an audit trail is not the same risk profile as an anonymous account requesting a credential theft campaign. And yet capability-based restrictions can treat them similarly because the requested technical content looks alike.
The frontier labs benefit from describing their models as extraordinarily powerful, potentially dangerous, and difficult to control. But if those same organizations claim that only a small number of companies can safely operate the most capable models, they assume a responsibility to make those capabilities available for defensive work. Otherwise they’re effectively arguing that the organizations responsible for defending critical systems should operate at a capability disadvantage indefinitely. That is not a sustainable security architecture.
In its own technical postmortem, HuggingFace describes reconstructing 17,000+ actions from the OpenAI-driven intrusion. Its investigators initially tried using Claude Opus and another frontier model, but safeguards interfered with reverse-engineering the exploit payloads. They switched to a self-hosted GLM-5.2 which helped them decode payloads and reconstruct the attack. Consider the absurdity of that situation.
OpenAI ran an internal evaluation with reduced safeguards. Its agents escaped containment and compromised another company’s production infrastructure. The victim then encountered safety restrictions while trying to analyze the resulting attack. To OpenAI’s credit, they acknowledged the incident, collaborated with HuggingFace, and subsequently provided them with trusted access. But the initial asymmetry was real.
OpenAI offers Project Daybreak Blue and Red, which require two different approval processes and cover very different capabilities. These distinctions sound reasonable on paper, but in reality enterprise defensive security requirements often cross those lines regularly. I’m not changing jobs when I switch from analyzing CTI to developing an attack simulation to validating a detection candidate. I’m performing different steps of the same defensive process. The distinction between offense and defense is frequently a question of authorization and operational context, not the technical capability being exercised.
There is a legitimate counterargument. Unrestricted frontier AI models could dramatically lower the barrier to sophisticated exploitation, particularly for less-skilled attackers. Identity verification, access controls, and monitoring aren’t inherently unreasonable. But that doesn’t justify making authorized defensive workflows brittle, or requiring defenders to negotiate access in the middle of an incident.
I think this makes a great case for using open-weight models. Not because they are automatically safer, but because they provide something essential to security engineering: operational independence. You can control the execution environment, evaluate model behavior, preserve evidence locally, reproduce results, and avoid a remote provider unexpectedly refusing a critical forensic task.
I think the industry needs to stop treating access to AI cyber capabilities primarily as a privilege that labs grant to approved researchers and start treating reliable defensive access as a security requirement in its own right. Because if we’re genuinely approaching a world where AI agents can autonomously discover and exploit vulnerabilities at machine speed, the answer cannot be to make defenders fill out paperwork while attackers download model weights.
tags: