The U.S. should find a better policy than “Chinese model = prohibited.” That's not a current policy, but it's been rumored some are leveraging for exactly that.
That distinction matters because an Axios report, based on unnamed sources and not confirmed by the White House or Commerce Department, says Trump administration officials may again be considering ways to restrict U.S. use of cutting-edge Chinese AI models. The reported ideas include Entity List actions, security advisories, hosting liability requirements, procurement restrictions, and supply-chain rules.
None of that proves a policy is imminent. It does raise a real concern about where the debate is headed.
If Washington’s answer to Chinese AI progress is a broad, geography-based crackdown, especially one that chills the use of open-weight models, it would be a gift to the U.S. companies already dominating the closed-model market.
It would also be a bad way to do security.
A country of origin is not a threat model
There are legitimate reasons for governments and companies to scrutinize AI systems. A model can be served through an API that collects sensitive prompts. Its download package or dependencies can introduce supply-chain risk. Its update path can be compromised. An agent with access to internal files, tools, and credentials deserves a much higher level of caution than a chatbot asked to summarize public documents.
Those are concrete risks. They can be tested.
A policy that begins and ends with a model’s country of origin is something else: a proxy. Sometimes proxies are tempting because they are easy to explain and politically convenient. They are also a poor substitute for evidence.
The question some seem to be asking it “Was this model built in China?”
I think the right question is likely: What does this model, its distribution channel, and its deployment actually do? And what can independent, qualified security and AI professionals demonstrate about the risk?
That means examining model artifacts and dependencies, how updates are delivered, whether a deployment phones home, what data leaves the customer’s environment, how the system behaves under adversarial testing, and what permissions it receives. It means giving vendors clear standards and a meaningful way to meet them. And it means restricting models in high-risk deployments when the evidence supports it, such as classified systems, defense workflows, or critical infrastructure.
That approach is harder than a ban, and it's how security is supposed to work in a world of non-absolutes.
Do not turn “open” into the problem
This debate has another trap: treating open-weight models as uniquely dangerous.
The terms get blurred constantly. Many of the models at issue are better described as open-weight: their downloadable model weights are available, but that does not necessarily mean every part of the training pipeline, data, or software stack is open source. Precision matters because policy built on a fuzzy label tends to produce fuzzy collateral damage.
More importantly, open weights can make some security practices easier, not harder. A company can run the model in its own environment, inspect associated code, choose its own inference stack, freeze a tested version, and limit network access. None of that guarantees safety. But it creates options that a black-box, vendor-hosted service may not offer.
Closed systems deserve scrutiny too. A proprietary API may be polished and capable, but users cannot independently inspect the weights or all of the surrounding infrastructure. If the real concern is data exfiltration, remote control, malicious behavior, or insecure dependencies, the standard should apply to any model and any provider. Security should not become a label that conveniently means “protect the companies we already know.”
This is especially important now. As The Neuron recently covered, Moonshot’s Kimi releases are pushing Chinese open models closer to the frontier (if not already.) That creates real competitive pressure on U.S. labs, and potential cost and customization advantages for American companies. It also creates a legitimate need for serious evaluation. Those two facts do not cancel each other out.
The competition problem is not theoretical
The Axios report quotes David Sacks warning that leading closed labs may want the government to eliminate their open-source competition. That is a pointed charge, and it should not be accepted on faith. But the incentive is obvious enough to warrant skepticism.
A broad restriction on Chinese models would not hit every U.S. company equally. The biggest labs and cloud platforms can absorb higher model costs, negotiate capacity, or steer customers toward their own products. Startups, researchers, and enterprise teams that use lower-cost open-weight models would have fewer choices and less leverage.
That is how a security policy can quietly become industrial policy for incumbents.
It also risks making the U.S. ecosystem less resilient. Builders learn from testing competing models. They use open systems to customize workflows, run private deployments, build alternatives to a single vendor, and pressure market leaders on price and performance. Kimi K2.6’s release was a reminder that model competition is no longer a distant geopolitical abstraction. It lands in developer budgets, product roadmaps, and procurement conversations.
A better policy: assess the system, protect the deployment
There is a defensible middle path here.
Government agencies should be able to bar unvetted models from the most sensitive systems. They should publish threat advisories when they can point to credible evidence. They should fund independent testing, set supply-chain and data-handling requirements, and require strict isolation for high-risk AI deployments.
But the rules should be specific, transparent, and behavior-based. They should identify what risk is being addressed, what evidence establishes it, and what controls can mitigate it. They should apply to every relevant vendor, not just companies from the country Washington is most worried about this week.
That would still leave room for strong action when strong action is warranted. If an evaluation finds a backdoor, malicious dependency, insecure update mechanism, or demonstrable avenue for exfiltration, restrict that system. Notify the creator and have a remedy process in place for them to submit changes. If a sensitive deployment cannot be secured, do not use it. That is targeted regulation tied to tangible evidence, not a digital travel ban.
The claims in Axios’s report remain unverified, and they may never become policy. But the premise is worth resisting before it hardens into one. America should compete aggressively in AI, protect genuinely sensitive systems, and demand real security from every supplier.
It should not confuse the country on a model’s passport with proof that the model is unsafe...or safe.
