For the last 30 years, policymakers have repeatedly tried to slow the spread of cybersecurity capabilities by restricting who can buy them, where they can be shipped, and under what conditions they can be used. The logic is straightforward: if you can limit access to powerful tools—whether encryption systems, intrusion software, or the technical know-how behind them—you can reduce the ability of hostile actors to operate at scale.
And yet, history has been stubbornly consistent. Cyber tools keep moving. Sometimes they move through legal channels that were never fully captured by the rules. Sometimes they move through gray markets, rebranding, and “dual-use” loopholes. Often they move because the underlying capability is not a single product you can lock down, but a set of techniques that can be learned, adapted, and rebuilt faster than regulations can keep up.
That long record is now colliding with a new wave of attention on Anthropic’s cybersecurity model, Mythos—and with renewed questions about whether cyber export controls could work differently this time. The debate isn’t just about one company or one system. It’s about whether the policy toolbox that has struggled for decades has any credible path to effectiveness in an era where cyber capability is increasingly software-defined, distributed, and rapidly iterated.
What makes the current moment feel different is not that the old problems have disappeared. It’s that the stakes are higher, the pace is faster, and the “unit of control” may be shifting—from hardware and packaged software toward models, workflows, and services that can be accessed remotely. That shift changes the enforcement landscape, but it doesn’t automatically solve the core issue: stopping the flow of capability is harder than stopping the flow of a product.
A 30-year pattern: restrictions don’t stop capability, they redirect it
To understand why cyber export controls have repeatedly failed, it helps to look at what those controls actually target. In many cases, they focus on specific categories of technology: certain cryptographic products, surveillance-related tools, exploit development frameworks, or other items deemed sensitive. The assumption is that if you restrict supply, demand will be constrained.
But cybersecurity demand is rarely satisfied by a single supplier. When access is blocked, capability doesn’t vanish—it migrates. Attackers and legitimate users alike find substitutes. Researchers publish methods. Vendors release updates. Tools are forked, repackaged, or integrated into broader platforms. Even when a particular product is unavailable, the techniques behind it can often be obtained through documentation, training, open-source code, or reverse engineering.
Encryption is the clearest example of how “cutting off” a capability can fail. Encryption is not merely a product; it’s a fundamental building block of secure communication. Attempts to restrict strong encryption have historically run into a reality that once cryptography becomes widely embedded in operating systems, browsers, messaging apps, and network protocols, controlling its spread becomes less like shutting a door and more like trying to empty the ocean with a bucket.
Spyware and intrusion tools show a similar pattern, though the dynamics differ. Export controls and related restrictions can slow the movement of certain commercial offerings, but they rarely eliminate the underlying ability to compromise systems. Attackers can use alternative tooling, develop their own, buy from other vendors, or rely on vulnerabilities that are already known and weaponized by the time controls are debated. Meanwhile, defenders and researchers continue to publish mitigations and analysis, which can indirectly accelerate attacker learning even as it improves defense.
The result is a recurring cycle: controls may delay some shipments or complicate procurement, but they do not prevent the emergence of capability. They often change the shape of the market rather than shrinking it.
Enforcement is the bottleneck, not the rulebook
Even when export controls are well-designed on paper, enforcement is where the plan tends to break. Cyber tools are easy to disguise as something else, easy to distribute in parts, and easy to integrate into legitimate software ecosystems. A capability can be split across components, delivered via updates, bundled into services, or provided through infrastructure that looks unrelated to its true purpose.
There’s also the practical challenge of classification. Cybersecurity technologies are frequently dual-use: the same technique can protect privacy and enable legitimate security testing, while also being used for surveillance or exploitation. That dual-use nature forces regulators to draw lines that are difficult to verify in real time. If the line is too narrow, it misses variants. If it’s too broad, it captures legitimate activity and becomes politically and operationally unsustainable.
Then there’s the question of jurisdiction. Cyber capability travels globally, and the enforcement reach of any single country is limited. Even robust compliance regimes can be undermined by transshipment, intermediaries, and the fact that software distribution can occur without the same physical logistics that traditional export controls were built around.
In practice, enforcement often becomes reactive: investigating after the fact, chasing evidence, and attempting to prove intent or end-use. But cyber operations are designed to be deniable, and the supply chain for software can be opaque. By the time enforcement catches up, the capability has already spread.
This is why critics argue that export controls can become a kind of “speed bump” rather than a barrier. They may slow some transfers, but they rarely stop the overall diffusion of capability.
Why “now” feels different—and why that doesn’t automatically help
The current conversation around Mythos reflects a broader shift in how cybersecurity capability is produced and consumed. Instead of thinking only in terms of discrete tools—like a specific exploit kit or a particular malware package—people are increasingly focused on models and systems that can generate, analyze, and assist with tasks that used to require specialized expertise.
If a cybersecurity model can help with threat analysis, vulnerability discovery, incident response, or even offensive planning, then the “product” is no longer just code. It’s a capability layer: a system that can compress expertise into a workflow.
That raises a natural policy question: if the capability is concentrated in a model, can export controls be more effective? If you can restrict access to the model itself, perhaps you can constrain the capability more directly than before.
But the same historical forces still apply, just in a new form.
First, models can be replicated or approximated. Even if a specific system is restricted, the underlying approach—prompting strategies, evaluation methods, fine-tuning techniques, and general model behavior—can be learned and reproduced. The barrier to entry may be lower than it was for building a bespoke exploit framework, especially if the ecosystem includes open research, public benchmarks, and accessible tooling.
Second, access can be routed around controls. If a model is offered as a service, restrictions might limit direct access from certain jurisdictions, but that doesn’t necessarily prevent indirect access through intermediaries, resellers, or infrastructure that obscures origin. If a model is downloadable, the problem becomes even more familiar: once distributed, it’s difficult to recall.
Third, the “end-use” problem remains. Export controls often depend on assumptions about who will use the technology and for what purpose. But cybersecurity models can be used for defensive work, compliance, and legitimate research as well as for harmful activity. Proving intent is hard, and the same system can be used in multiple ways depending on user goals.
So the uncertainty isn’t just whether Mythos would be treated differently by policy. It’s whether any model-centric approach changes the fundamental equation: can you meaningfully constrain capability in a world where knowledge and software can be adapted faster than enforcement can track?
A unique angle: export controls may be fighting the wrong unit of change
One reason the debate can feel repetitive is that it treats export controls as if they target a stable object. Historically, the object might have been a cryptographic library, a surveillance product, or a packaged tool. But cybersecurity capability is increasingly modular and composable. It can be assembled from components: datasets, model weights, inference pipelines, orchestration scripts, and evaluation harnesses.
In that environment, export controls may be targeting the wrong “unit.” Restricting one component might not stop the final capability if other components can fill the gap. Even if a particular model is restricted, the surrounding ecosystem—open-source libraries, publicly available exploits, vulnerability databases, and general-purpose AI tooling—can still enable harmful outcomes.
This suggests a more uncomfortable possibility: export controls may be structurally mismatched to the way cyber capability is created today. They can regulate distribution of certain items, but they struggle to regulate the emergent capability that results from combining many items.
That doesn’t mean controls are meaningless. It means their effect may be limited to marginal delays, increased costs, and reduced convenience—not elimination.
The “market pressure” argument: demand finds a way
Another recurring theme in the history of cyber restrictions is that global demand is persistent. Security professionals want tools to defend systems. Attackers want tools to compromise them. Governments want both intelligence and protection. When demand exists, supply adapts.
Export controls can raise friction, but friction is not the same as prevention. If the payoff is high, actors will invest in workarounds. If the tools are valuable, they will be sourced through alternative channels. If the tools are restricted, the incentive to develop substitutes increases.
This is why critics say that export controls often end up functioning like a tax on compliance rather than a barrier to capability. The most sophisticated actors can absorb the cost of finding alternatives. Less sophisticated actors may be slowed, but the overall capability ecosystem continues to evolve.
In the context of AI-driven cybersecurity models, the market pressure could be even stronger. If a model reduces the time and expertise required to perform complex tasks, it becomes attractive to a wide range of users. That includes legitimate defenders, but also includes malicious actors who see speed and automation as force multipliers.
So the question becomes: can export controls meaningfully reduce access enough to outweigh the incentives to circumvent? History suggests that the answer is often no.
What would it take for cyber export controls to work?
If the past is a guide, then the burden of proof is on proponents of future controls. It’s not enough to say “this time is