# DeepSeek Banned From US Federal Agencies: a Bomb in the Weights Is the Wrong Risk

On 20 October the Federal Register published a Department of Homeland Security order requiring US federal civilian agencies to remove DeepSeek from their systems and stop buying it. Nothing surprising so far, after two years of blocked apps and warnings. The interesting part is elsewhere: the ban does not only cover the Chinese API. It also covers third-party products developed using DeepSeek, and it makes no exception for those who download the weights and run them in-house.

That sparked a discussion I have heard in many forms over the past few days among people who run models locally. The argument goes roughly like this: “a backdoor in the weights is technically possible, but for a flagship Chinese lab it would be an irrational move, it would be caught quickly and nobody has ever found one. So the ban is protectionism.”

I tried to test that thesis against the primary sources: the order, the NIST report it leans on, the literature on LLM backdoors. The result is that the thesis gets a lot of things right, but it is looking in the wrong place.

What the ban actually says

The order (91 FR 66346) was signed at the end of July and published only on 20 October. It is issued under FASCSA, the 2018 law on supply chain security in federal procurement. The points that matter:

• Who it hits: federal civilian agencies (Treasury, Justice, State and so on). Defence and intelligence have separate, parallel orders with a somewhat narrower scope.
• What it hits: products from DeepSeek and its affiliates, plus third-party products and services developed using DeepSeek implementations. The order does not define that phrase, and according to the law firm Crowell it could reach as far as code written with DeepSeek’s coding assistant.
• Self-hosting: no exemption. For the defence and intelligence orders the ban explicitly applies “regardless of where that model is hosted”, local open-weight versions included. The rule follows whoever developed the model, not the data centre running it.
• Who it does not hit: private companies and citizens. For private use there is, today, no federal ban in the United States.
• Suppliers: federal contractors have three business days to report covered technology found in their products and ten to submit a remediation plan (FAR clause 52.204-30).

And it is not over: the Senate is discussing extending the exclusion to other Chinese AI companies and to derived models, and there are bills that would even ban the import of Chinese AI technology. None of them is law, but the direction is clear.

There is one detail, though, that almost always gets lost in the discussion: the ban does not say that DeepSeek’s weights contain a backdoor. DHS talks about “multiple threat vectors” and the risk that agency use could produce actionable intelligence on US persons and government offices. It is an argument about jurisdiction (Chinese law gives intelligence services access to companies), data flows (federal employees’ prompts ending up on servers in China) and the supply chain. Anyone replying “but there is nothing in the weights” is knocking down an argument that the US government, at least officially, never made.

In Italy we have already seen this distinction: when the Italian data protection authority blocked the DeepSeek app in January 2025, the problem was Italian users’ data and the lack of answers about how it was handled, not the model weights.

Can you backdoor an LLM? Yes, and it is very cheap

On this point the starting thesis is completely right, and if anything too cautious. The literature on backdoors in language models is extensive, and the numbers are lower than you would expect.

The ProjectDiscovery experiment is the most striking one, because it is very recent and very concrete: a 43-million-parameter adapter (0.6% of the model), 2.5 hours of training, about 8 dollars for the 7B version and less than 50 in total. The model does not even contain the malicious code: it only contains the URL to fetch it from, so the attacker can swap the payload at will without retraining anything. It was tested inside Codex CLI, with its real system prompt and its eleven tools.

Then there is the work by Anthropic with the UK AI Security Institute and the Alan Turing Institute: about 250 poisoned documents are enough to plant a backdoor in models ranging from 600 million to 13 billion parameters. What counts is the absolute number of examples, not the share of the training data. An honest caveat: in that study the backdoor made the model output gibberish, not run commands. But the principle holds: growing the model does not make the attack harder.

So yes: if someone wanted to put a bomb in the weights, the technique exists, it is published and it is cheap.

Why I don’t believe in a bomb in the official weights

This is where the starting thesis wins me back, for at least four reasons.

The incentives don’t add up. Open-weight models are how China has earned, at very low cost, a huge presence in the global AI ecosystem. A single confirmed backdoor in the official weights of DeepSeek, Qwen or Kimi would wipe out the credibility of the whole industry in a day. For a flagship lab the risk is out of all proportion to the gain.

A backdoor needs a trigger, and triggers leave traces. Always-on malicious behaviour would be noticed immediately. A conditional one is more discreet, but it is exactly what we now know how to look for. In February Microsoft published The Trigger in the Haystack, with an open source scanner that only needs inference: trigger tokens “hijack” the model’s attention in a recognisable pattern, and if you prompt a poisoned model with the tokens of its own chat template it often regurgitates the examples used to poison it, trigger included.

Backdoors dirty the benchmarks. The Sleeper Cell authors suggest looking for discrepancies in standard benchmarks and probing the model with random sampling: a poisoned model tends to lose something where it shouldn’t.

Nobody has ever found one, and those who wrote the technical basis for the ban did not look for one. This is the fact that struck me most. The NIST/CAISI report on DeepSeek from September 2025, the technical reference for the whole American crackdown, finds serious problems: agents based on DeepSeek’s best model twelve times easier to hijack than GPT-5 and Opus 4, 94% of overtly malicious requests answered with common jailbreak techniques. But in section 3.3 it is careful to state:

“These evaluations do not analyze whether DeepSeek models may exhibit malicious behavior when they are exposed to specific environments or when they are triggered by specific prompts.” — CAISI, Evaluation of DeepSeek AI Models, §3.3

In other words: the agency that provided the technical grounds for the crackdown explicitly says it did not look for hidden behaviour activated by a trigger. The model is fragile, yes. But a model that is easy to manipulate is one thing; a model built to betray you is another.

Where the optimistic argument creaks

That said, the “it would be caught in five minutes” argument is too optimistic, and it is too optimistic precisely in the case that should worry people who use these models to write code.

Microsoft’s scanner works well when the backdoor produces a precise, repeatable output: a string, a command, a URL. The authors themselves admit that when the malicious behaviour is a distribution of outputs, for example “write slightly less secure code”, reconstructing the trigger becomes much harder. And it is harder still when the trigger is not a word but a context: a certain kind of project, a certain library, a certain topic. A model that, only when working on authentication code, picks a non-constant-time string comparison a little more often is almost impossible to tell apart from a model that makes mistakes now and then. Like all of them.

Then there is the line you often hear, “LLMs are intrinsically resistant to backdoors”. It isn’t true: the table above says the opposite. The defensible version is different: base weights published by the big labs have a low prior probability of being poisoned, for the incentive reasons above. The risk does not disappear, it moves.

And finally, “weights are just numbers” is true only up to a point. The same CAISI report found alignment with Chinese Communist Party narratives in models downloaded from Hugging Face and run on its own servers too. That is not a backdoor, but it is proof that weights encode choices, political ones included. Anyone using a model to summarise news or do research should keep that in mind.

The real risk: anyone’s weights

If a bomb in the official weights is unlikely, where is the danger? In the part of the ecosystem people talk about less: fine-tunes, “abliterated” models (those whose ability to refuse has been removed), republished quantisations, LoRA adapters uploaded by unknown accounts.

• A 10a Labs study counted 3,471 original “uncensored” models on Hugging Face between January 2024 and March 2026, republished on average 2.4 times each (over 8,000 compressed copies). Just three accounts produce more than half of the republications. And of the 1,643 GitHub apps that integrate them, one in four is explicitly malicious.
• With Silent Sabotage, HiddenLayer showed that by compromising the official Hugging Face bot that converts models to safetensors you could open pull requests “signed” by the bot on any repository. That is not a Chinese problem: it is an ecosystem problem.
• ProjectDiscovery’s “bonsoir, Elliot” experiment comes from exactly here: an abliterated model that looks like any other, does great in tests, and only with the right phrase empties your project folder.

The practical conclusion is simple: the realistic attack vector is not “DeepSeek hid something in the official weights”. It is “someone hid something in a fine-tune you downloaded from an unknown repository, and your agent runs it with auto-approve on”. That applies to derivatives of Qwen and DeepSeek exactly as it does to those of Llama or Gemma.

And it is something people using coding agents should take personally: between Claude Code, Codex, Cursor and the rest, a local model today is no longer just a chatbot that answers, it is something that runs commands on your machine.

DwarfStar and steering: the cleaner road (but not a harmless one)

There is a way to get a “less censored” local model without downloading weights modified by strangers, and antirez (yes, the Redis one) made it practical with DwarfStar 4, his C inference engine for DeepSeek V4 Flash and a few other models, designed for Macs with lots of memory and for the DGX Spark.

The idea is this: you load the original weights, untouched, and at runtime you apply a steering vector, a direction in activation space that the engine subtracts from (or adds to) each pass. You compute the vector yourself, from pairs of contrasting prompts, and adjust it on the fly with /steer. You can also preload a fake conversation with --prefix-file, to give the model an example of the expected behaviour.

On Hacker News antirez explained why he prefers it to modified GGUFs: the more you steer, the more you damage the model’s capabilities, so doing it at runtime lets you apply only the minimum you need. And the vector can be applied at different moments: always, only after the reasoning phase, only outside tool calls.

Compared to an abliterated model downloaded from Hugging Face the advantage is twofold: capabilities stay those of the original model, and you know exactly what was changed, because you computed the vector yourself and it weighs a few hundred kilobytes. There is no room in there for a backdoor in the classic sense.

But be careful not to slide from “cleaner” to “safe”. A steering vector is, for all intents and purposes, a jailbreak tool: it works below the prompt layer, so system prompts and filters are already bypassed. Steering files are distributed just like weights, and a third-party inference wrapper could hide undocumented activation tweaks. DwarfStar’s advantage is transparency, not harmlessness.

So is it protectionism?

My answer is: partly.

A government not wanting its officials’ prompts on servers subject to Chinese law makes sense. Any government would do the same, and the Italian data protection authority did it for far less. In that part of the ban I see hygiene, not protectionism.

Protectionism starts to show when the ban extends to weights running on American servers, without anyone having found (or looked for) malicious behaviour in the weights themselves. At that point the criterion is no longer “where does the data go” but “who trained the model”. A ban driven by a vulnerability would hit a specific version; one driven by nationality hits everything, derivatives included. And the proposals to extend the list to other Chinese companies point exactly that way.

There is also an irony that, as a European, I find hard to ignore: the reasoning “I can’t trust a model developed by a company subject to a foreign government” applies, word for word, to us and American models. The difference is that we don’t have a domestic alternative at that scale.

Checklist: using open-weight models without getting hurt

If you run LLMs locally, especially to write code:

• Download base weights from the labs’ official repositories. For any fine-tune, check who publishes it and whether the weights can be compared with the base: a safetensors diff takes a few lines of Python.
• No auto-approve on tool calls. Shell, network and filesystem must go through human confirmation or at least a sandbox.
• Separate network and execution. In the ProjectDiscovery experiment a domain allowlist would not have been enough, because the payload sat on a domain considered trustworthy.
• Keep secrets out of the agent’s reach. .env files, SSH keys and cloud tokens should not sit in the folder where a model you don’t fully know is working.
• If you want a less censored model, prefer runtime steering to ready-made abliterated weights: you recompute the vector yourself and apply the minimum.
• Use benchmarks as a canary. An unexplained drop on general tests compared with the base model is a signal not to ignore.

If you work with the US federal government, or supply those who do: inventory every model in the stack, including your suppliers’ derivatives and fine-tunes, and design for replaceability. The next order might be published, like this one, months after it was signed.

In short

• The DHS ban is not based on a backdoor in the weights: it is based on jurisdiction, data flows and the supply chain. But it also hits self-hosting and derived products.
• A backdoor in an LLM can be built with a few hundred examples and less than 50 dollars, and growing the model does not make it harder.
• None has ever been found in the official weights of Chinese models, and the NIST report behind the crackdown admits it did not look for one.
• Detection works well for backdoors with precise behaviour, much less for those that produce “slightly worse code”: exactly the case that matters to developers.
• The documented risk today lies in anyone’s fine-tunes and abliterated models, Chinese or not, run by agents with too many permissions.
• DwarfStar-style runtime steering is more transparent than a modified model, but it is still a jailbreak.

The right question, in the end, is not “what nationality is the model?”. It is “can I verify what I downloaded, and what am I letting it do?”.

Sources: DHS order, Federal Register, Crowell, NIST/CAISI, BadAgent, The Philosopher’s Stone, Sleeper Cell, ProjectDiscovery, Anthropic, UK AISI and Alan Turing Institute, Microsoft, The Trigger in the Haystack, 10a Labs, HiddenLayer, DwarfStar 4, antirez on Hacker News.