By NHI Mgmt Group Editorial TeamBased on Corgea: “The Crypto Wars are back, this time over AI models” (July 6, 2026)

TL;DR: The Commerce Department’s brief export controls on Anthropic’s Fable 5 and Mythos 5 replay the same logic that failed in the 1990s crypto wars, where restrictions hit law-abiding defenders more than determined adversaries, according to Corgea. The practical lesson is that AI governance has to assume diffusion, not depend on enforceable scarcity.


At a glance

What this is: Corgea argues that export controls on frontier AI models risk repeating the crypto wars pattern, where restrictions land on compliant users while determined actors route around them.

Why it matters: For IAM and AI governance teams, the issue is how to manage model access, distribution, and cross-border use without assuming that policy controls can hold back capability once it is widely understood.


Context

Export controls are a governance tool for limiting cross-border access to sensitive technology, but they rarely eliminate the underlying capability. In identity and AI security terms, that creates a familiar control problem: policy can slow legitimate users while leaving the real threat path intact if the capability is already reproducible or easily transferred.

This article uses the crypto wars as the analogy for model export controls, arguing that the hard part is not writing restriction language but governing diffusion. For AI programmes, that intersects with access governance, residency decisions, and who can operate advanced models across organisational and national boundaries.


Key questions

Q: What breaks when AI model export controls are used as the main security control?

A: They break when the underlying capability can still diffuse through other routes. The result is often a policy that slows compliant organisations while doing little to stop determined actors from using equivalent models elsewhere. Effective governance has to measure whether the control changes attacker access, not just whether it limits one distribution channel.

Q: Why do export controls on AI models often create more friction for defenders than attackers?

A: Because defenders are the actors most likely to comply, document use, and seek approval, while adversaries can route around the control through open releases, offshore services, or derivatives. That asymmetry means the burden falls first on researchers, security teams, and enterprises that are already trying to operate within policy.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: What should organisations do when frontier AI access becomes a legal or residency issue?

A: Treat it as an identity and entitlement problem, not only a policy problem. Organisations need to know who is entitled to use the model, from where, under which jurisdiction, and with what business justification. Without that inventory, restrictions become hard to enforce and easy to route around.


Technical breakdown

Why export controls struggle against diffuse capabilities

Export controls work best when the item being restricted is scarce, traceable, and difficult to replicate. Strong cryptography eventually failed that test because the underlying mathematics was public, and frontier model capability can also diffuse through weights, fine-tuning, open releases, or derivative systems. Once capability spreads, a licensing regime may still inconvenience legitimate users, but it stops being a reliable barrier to determined adversaries. The core issue is governance over a widely reproducible capability, not simply control over a shipment or account. Practical implication: design AI governance around diffusion risk, not around the assumption that restriction alone can preserve scarcity.

Practical implication: Treat access control as a delay mechanism, not a guarantee, when capability can be copied or redistributed.

What a served model changes compared with public software

The article correctly notes one important difference from the crypto wars: a served model is a chokepoint, not open mathematics. That means operators can gate access, apply regional restrictions, and monitor usage in ways they never could for downloadable cryptography. But a chokepoint is only as strong as the operating model behind it. If downstream labs, customers, or employees can still obtain equivalent capability elsewhere, the control becomes partial rather than decisive. Practical implication: build policy around the whole lifecycle of model access, including hosting, federation, resale, and offboarding, rather than assuming the service layer is the whole boundary.

Practical implication: Govern the full model distribution chain, not just the front door to the API.

Why defenders usually absorb the compliance burden first

The article’s central warning is that broad restrictions tend to bite defenders before adversaries. Security teams, researchers, and startups are the actors most likely to follow licensing rules, document usage, and seek approval. Malicious actors are more likely to obtain capability through unauthorised channels, offshore services, or open-source alternatives. That creates an asymmetry where the regulated population loses speed and visibility while the threat population keeps moving. Practical implication: if a control mainly constrains compliant operators, it should be tested against whether it measurably reduces adversary access or just raises operational friction.

Practical implication: Challenge any AI control that slows defenders more than it changes attacker reach.


Threat narrative

Attacker objective: The objective is to preserve or obtain frontier AI capability despite policy restrictions, while competitors and defenders absorb the operational cost of compliance.

  1. Entry occurs when capable AI models are restricted through export controls or other access-limiting policy, creating a regulated distribution channel rather than removing capability from circulation.
  2. Escalation happens when alternative paths such as open-source models, foreign services, or derivative deployments provide equivalent or sufficient capability to the actors the policy was meant to constrain.
  3. Impact is a governance imbalance where compliant organisations lose access or speed while adversaries continue to obtain advanced model capability through other routes.

NHI Mgmt Group analysis

Export controls are a weak substitute for capability governance when the technology can diffuse. The article is strongest where it argues that model restrictions resemble the failed crypto wars pattern more than a durable security boundary. Once capability is reproducible, policy can slow legitimate use but cannot reliably contain determined actors. Practitioners should therefore judge controls by whether they reduce adversary reach, not by whether they look restrictive on paper.

AI governance now has to account for distribution paths, not just model possession. The interesting security question is not whether a vendor can block one customer class, but whether equivalent capability can still be accessed through open models, offshore services, fine-tuned derivatives, or internal replicas. That is an AI governance debt problem as much as a policy problem. Practitioners should map where model access can reappear after a restriction is imposed.

Identity and access controls matter because frontier models are becoming governed assets, not just software endpoints. The article’s own example of foreign-national access shows how model policy intersects with workforce identity, regional entitlement, and organisational access decisions. If AI systems are treated as governed services, then who may use them, from where, and under which legal regime becomes part of the control plane. Practitioners should align AI access policy with identity governance instead of treating it as a standalone legal filter.

Compliance-first controls often impose the highest cost on the least risky participants. That is the repeat lesson from the crypto wars, and it still matters here. Security teams, researchers, and regulated enterprises tend to follow policy, while malicious actors route around it. Practitioners should challenge any AI restriction that cannot show a clear adversary-impact mechanism beyond broad operational inconvenience.

AI model export controls create a verification problem, not just a legal one. The named concept here is model diffusion risk: once capability exists in multiple jurisdictions and forms, the real challenge is measuring where it can still be used. That points to governance, inventory, and entitlement visibility as core controls. Practitioners should measure exposure across the full model estate rather than assuming one policy change fixes the problem.

From our research library:

What this signals

Model diffusion risk: the governance problem is no longer whether one provider can block access, but whether equivalent capability can still be obtained after the restriction lands. For practitioners, that means AI policy has to be designed around distribution, replicas, and entitlement paths, not around a single vendor gate.

The identity angle matters because model access is now part of the enterprise access model. When residency, employment status, or role determines who may use a frontier system, AI governance starts to behave like privileged access governance, which means visibility, review, and revocation become operational requirements.


For practitioners

  • Map model diffusion paths Identify where frontier model capability can reappear through open-source releases, derivative models, hosted services, and internal replicas before you rely on a single restriction regime.
  • Tie AI access to identity governance Review who can use advanced models by role, residency, employment status, and business justification so access decisions are tracked like other privileged entitlements.
  • Test controls against adversary bypass For each proposed restriction, document how it would reduce attacker reach rather than merely adding approval steps for compliant teams.
  • Track policy impact on defenders Measure whether restrictions are reducing real risk or simply slowing researchers, security teams, and regulated operators who already follow process.

Key takeaways

  • Export controls can delay access to frontier AI models, but they do not remove the underlying governance problem when capability can spread through other channels.
  • The crypto wars analogy matters because restrictions often bind compliant organisations first, while determined actors route around them.
  • For practitioners, the control question is whether a policy changes adversary reach and access paths, not whether it simply adds friction.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF sets the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is fundamentally about AI policy design and governance trade-offs.
MAP — AI Context and Risk MappingThe article depends on understanding where capability can diffuse and who is affected.
MEASURE — AI Risk MeasurementPractitioners need evidence that restrictions reduce real risk rather than only adding friction.
Recommendation — Define AI access policy, accountability, and enforcement around GOVERN before restricting model distribution. Map model diffusion paths, user classes, and jurisdictional exposure before enforcing export-related controls. Measure whether restrictions change attacker access and not just internal approval latency.
ISO/IEC 42001:2023AI Management SystemThe topic is about how an organisation structures AI governance and accountability.
Recommendation — Embed model access decisions and restriction logic into the AI management system.

Key terms

  • Model Diffusion Risk: The chance that a controlled AI capability will spread beyond the intended distribution channel and remain usable elsewhere. In practice, diffusion can happen through open-source releases, derivatives, hosted services, or internal copies, which makes restriction policy an incomplete control on its own.
  • API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
  • Protocol Chokepoint: A protocol chokepoint is the mandatory passage point where traffic can be inspected, authorised, or blocked before it proceeds. In agent governance, it gives security teams a single place to apply identity, policy, and audit controls to every tool call or delegation step.
  • Entitlement-Tied Visibility: Entitlement-tied visibility means a secret can only be viewed by identities that currently hold the relevant access grant. It keeps disclosure aligned with lifecycle state, which is especially important for shared passwords, database credentials, and other ongoing access that should not follow stale distribution lists.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity controls to broader security decisions. It gives security and IAM teams a practical foundation for governing access where identity, privilege, and automation intersect.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org