DEV Community

Cover image for When Should Governments Pull the Plug on AI Models?
Joshua Fields
Joshua Fields

Posted on

When Should Governments Pull the Plug on AI Models?

The recent controversy around Anthropic’s Fable 5 and Mythos 5 models raises a question that I think every engineer working near AI infrastructure needs to take seriously:

Where should governments draw the line between protecting the public and controlling the future of AI?

According to Anthropic, the US government issued an export-control directive requiring the company to suspend access to Fable 5 and Mythos 5 for foreign nationals. Anthropic then disabled access for all customers to make sure it could comply.

That is a huge moment.

Not because one model was restricted. Models come and go. But because it shows the shape of a much bigger issue: frontier AI is starting to look less like ordinary software and more like strategic infrastructure.

I'm starting to notice a pattern once software becomes strategic infrastructure, governments tend to get involved.

AI is no longer just an app layer or a buzz term that people associate with sci fi films and vibe coding.

A lot of public discussion still treats AI like a product category.

Chatbots. Coding assistants. Image generators. Productivity tools.

But the more interesting shift is happening underneath that. Modern AI systems are becoming part of the infrastructure layer: they can write code, analyse vulnerabilities, operate tools, call APIs, generate workflows, reason across large systems, and increasingly act semi-autonomously.

That changes the risk profile.

A normal SaaS product can be regulated as a product. A powerful AI system that can discover vulnerabilities, automate cyber workflows, and scale expert-level reasoning starts to sit closer to infrastructure, security, and national capability.

That does not automatically mean governments should ban or restrict access. But it does mean the old mental model of “it’s just software” is not enough.

The argument for government intervention

There is a reasonable case for government involvement.

If a model can meaningfully accelerate cyber exploitation, biosecurity risks, fraud, mass surveillance, or other high-impact harms, then completely unrestricted global access may be irresponsible.

Engineers already accept this principle in other domains.

We do not expect anyone to be able to buy any chemical, access any exploit marketplace, export any military-grade hardware, or run critical infrastructure without oversight. Capability matters. Context matters. Access matters.

So if frontier AI systems become powerful enough to materially change the threat landscape, it is not irrational for governments to ask whether some access controls are needed.

The strongest version of the pro-regulation argument is not “AI is scary.”

It is:

«Some AI capabilities may scale dangerous expertise faster than our institutions, companies, and security teams can adapt.»

That deserves to be taken seriously.

The argument against government overreach

But there is an equally serious problem on the other side.

Government control over AI can easily become blunt, politicised, or captured by incumbents.

A sudden restriction on a model does not just affect bad actors. It affects researchers, engineers, startups, customers, international teams, and people building legitimate products. If access can disappear overnight, it creates uncertainty across the entire ecosystem.

There is also a competition problem.

If only a handful of large companies can afford to comply with the regulatory burden, then aggressive AI control may accidentally strengthen the biggest labs while making it harder for smaller teams to compete.

That is not safety. That is centralisation.

And centralisation has its own risks: fewer independent audits, fewer open alternatives, less resilience, and more power concentrated in private companies and state agencies.

The line should be capability-based, not hype-based

I think the line has to be drawn around specific capabilities, not branding, fear, or model names.

A model should not be restricted because it is impressive, popular, or politically inconvenient. It should be assessed based on what it can reliably do.

The questions should be practical:

  • Can it autonomously discover and exploit vulnerabilities?
  • Can it meaningfully accelerate harmful workflows for non-experts?
  • Can it operate tools across real systems with minimal supervision?
  • Can it bypass safeguards under realistic adversarial pressure?
  • Can access controls reduce the harm without destroying legitimate use?
  • Is there a transparent review process?
  • Is there a way for researchers and legitimate engineers to appeal or regain access?

This is where engineers need to be part of the conversation.

AI policy cannot be written purely as abstract law, and it cannot be left purely to companies either. The technical details matter. Model capability, tool access, deployment context, monitoring, rate limits, audit logs, and user verification all change the real-world risk.

A raw model is one thing. A model connected to tools, credentials, code execution, browsers, APIs, and production systems is another.

Access control is probably the real battleground

The more I think about AI safety, the more I think the future is not just about model weights or prompts.

It is about access control.

Who can use the system?
What tools can it call?
What data can it see?
What actions can it take?
What needs human approval?
What is logged?
What can be audited later?
What happens when something goes wrong?

That is familiar territory for software engineers. It is the same basic problem we face in backend systems, cloud platforms, internal tools, and financial infrastructure.

The difference is that AI makes the user interface more powerful. A natural language prompt can become a chain of actions across multiple systems.

That means permissioning needs to be designed as infrastructure, not sprinkled across the app as an afterthought.

If governments want safer AI, they should not only ask whether a model is allowed or banned. They should also ask whether the systems around the model have serious controls.

A powerful model in a weak product shell is dangerous.
A powerful model inside a well-designed permissioned system is at least governable.

My view

I do not think “ban it” is a sustainable AI policy.

But I also do not think “release everything and let the market figure it out” is serious.

The line should be drawn where three things meet:

  1. High capability
  2. High misuse potential
  3. Low accountability

When all three are present, government intervention may be justified.

But that intervention should be narrow, transparent, reviewable, and technically informed. It should target specific risky capabilities and deployment patterns, not entire categories of research or broad groups of users.

The goal should be to reduce catastrophic misuse without freezing the engineering ecosystem that will also build the defences.

The uncomfortable truth

AI is becoming infrastructure before society has agreed on the rules for governing it.

That is why moments like the Fable 5 and Mythos 5 controversy matter. They are early signals of a much larger fight over who gets to build, access, restrict, and control frontier AI systems.

As engineers, we cannot treat this as someone else’s problem.

The choices we make in system design — permissions, logging, deployment, human approval, model access, tool access, and failure handling — are going to shape what “AI governance” actually means in practice.

The future line between freedom and control in AI will not only be written in law.

It will be written in infrastructure.

Originally published at: joshuafields.uk

Top comments (0)