# DeepSeek Banned From US Federal Agencies [2026 Order]

> DHS banned DeepSeek from every federal civilian agency on Oct 19, 2026. Here's what the order actually says, the open-weights gray zone, and how to audit your own stack for foreign AI model dependencies.

- Canonical: https://www.kunalganglani.com/blog/deepseek-banned-federal-agencies
- Author: Kunal Ganglani
- Published: 2026-10-20 · Updated: 2026-10-20
- Category: Cybersecurity · Tags: ai-security, deepseek, supply-chain, policy, foreign-models

## TL;DR

The US government just banned DeepSeek, a Chinese AI company, from every federal civilian agency. The order, signed in July 2026 but made public on October 19, says agencies must rip DeepSeek products out of their systems because its data could reach the Chinese government and its models might hide malicious code. It does not ban private companies, personal use, or the free open model weights, which leaves a confusing gray zone for anyone self-hosting DeepSeek's models. The real takeaway for every engineering team: you should know exactly which AI models your software runs, who makes them, and which country's laws govern them, because customers will soon demand that answer.

On October 19, 2026, the US Department of Homeland Security made public an Exclusion and Removal Order that bans DeepSeek from every federal civilian agency. Agencies now have to rip the Chinese AI company's products out of their IT systems, can't buy anything new from it, and the company is permanently barred from competing for federal contracts.

The order (No. 2026-01) was signed on July 24, 2026. Then it sat non-public for nearly three months before surfacing in the Federal Register as pre-publication document 2026-21447. So the headline that DeepSeek is banned from federal agencies on AI security grounds is real, but the decision itself is three months old. Only the paperwork is new.

Is DeepSeek banned in the United States? Not for you personally. The order reaches only federal civilian executive-branch IT. It does not touch private companies, personal use, or the open model weights themselves. What it does is establish the first federal exclusion aimed squarely at a foreign AI model vendor, and that precedent is the part engineering teams should actually care about.

The timing is what made it land hard. The order went public the same week DeepSeek open-sourced its production inference engine and shipped a new flagship model. The thing the government just excluded is the exact thing a lot of teams are quietly self-hosting.

## What is the DHS DeepSeek Exclusion and Removal Order

The DHS DeepSeek Exclusion and Removal Order is a binding federal directive, issued under the Federal Acquisition Supply Chain Security Act of 2018, that prohibits US civilian agencies from buying, using, or hosting products from Hangzhou DeepSeek Artificial Intelligence Co., Ltd. and requires removal of any already deployed. It is Order No. 2026-01, docket DHS-2026-0628, and it took effect through existing supply-chain authority rather than new legislation.

![Laptop displays "the ai code editor" website](https://cdn.sanity.io/images/vzekdneq/production/9819707a77180e1e54f3bc419e31fb68629a7780-1200x675.webp)

That legal foundation matters more than the name on the press release. DHS did not need Congress. The [Federal Acquisition Supply Chain Security Act](https://www.congress.gov/bill/115th-congress/house-bill/7327) (FASCSA) created the Federal Acquisition Security Council (FASC) and gave agencies a mechanism to exclude or remove a vendor whose products pose a supply-chain risk. The same statutory lineage sits behind the government's earlier moves against Kaspersky antivirus and Huawei networking gear. DeepSeek is the first time that machinery has been pointed at an AI model company.

## What the DHS order actually says: scope, legal basis, and signing timeline

The operative language is blunt. Agencies must "exclude DeepSeek, DeepSeek-affiliated entities, and their products from civilian agency procurements" and purge "third-party products and services developed using DeepSeek implementations." That second clause is the one engineers keep rereading, because "DeepSeek implementations" is doing a lot of undefined work.

![black and gray code padlock anchored on chain-link fence selective focus photo](https://cdn.sanity.io/images/vzekdneq/production/09a54c9b20d53039be322e5722fa578fe862bc73-1200x675.webp)

The procedural chain is the detail almost no English-language coverage captured. DHS Secretary [Markwayne Mullin](https://public-inspection.federalregister.gov/2026-21447.pdf) signed the order on July 24, 2026, after a FASC recommendation backed by supporting evidence. It then stayed non-public until it was filed in the Federal Register at 8:45am on Monday, October 19, with official publication scheduled for October 20. That three-month gap between signature and disclosure is why the news felt like it came out of nowhere. It didn't. The decision was months old. Only the filing was new.

And this is not the government's first swing at DeepSeek. Back in 2025, two members of Congress introduced legislation to ban the DeepSeek chatbot from government devices. That bill went nowhere. DHS simply used authority it already had, which is a quieter and far more durable path than waiting on a floor vote.

## Which federal agencies are required to remove DeepSeek

The order applies across the civilian executive branch, and two agencies were named explicitly as being required to block and remove DeepSeek products: the Environmental Protection Agency (EPA) and the Federal Communications Commission (FCC). The naming is illustrative, not exhaustive. Any civilian agency running a tool that resolves to DeepSeek under the hood is now out of compliance.

![An open padlock surrounded by scattered black computer keyboard keys under red and green light](https://cdn.sanity.io/images/vzekdneq/production/36a9b7592300095aa1822626d260acbf3d7bfbc7-1200x675.webp)

The [original Reuters report](https://www.reuters.com/technology/us-banning-chinese-ai-deepseek-government-agency-it-systems-2026-10-19/) that broke the story framed this as a government-wide IT purge, and that is the right read. Removal is not phased or advisory. It is immediate.

## The risk DHS describes: data exfiltration and malicious code

DHS gave two reasons, and both deserve to be taken at face value.

First, the agency said DeepSeek's use "could lead to sensitive data being transferred to the Chinese government from US government employees and suppliers." That is the classic jurisdiction argument. A Chinese company is subject to Chinese data law regardless of where a given API endpoint physically sits.

Second, and more interesting for security engineers, DHS warned the company's models "may contain malicious code or other security vulnerabilities." For a hosted API that is mundane. For open model weights it is a genuinely hard research problem.

Anthropic's [Evan Hubinger](https://arxiv.org/abs/2401.05566) and co-authors showed in their "Sleeper Agents" work that a model can be trained to behave normally until a trigger condition fires, and that standard safety training fails to remove the backdoor. You cannot diff a 600-billion-parameter weight file against a known-good version and spot a dormant adversarial behavior.

I run DeepSeek's open weights myself for the local LLM benchmark database I maintain, and the scale is the whole problem. The V3-class checkpoint is a 400GB download in the 600-billion-parameter range. Nobody reviews that tensor by tensor. No human could.

Static analysis tooling for application code has no equivalent for a weights file, and the few interpretability probes that exist cannot certify the absence of a trigger. That is the uncomfortable core of model supply-chain risk, and it applies to any open-weight model, not only this one.

Here is the official news segment covering the removal order and the data-exposure rationale:

[Watch: US Orders Deepseek Removal: DHS Warns Sensitive Data Could Be Exposed To China | WION](https://www.youtube.com/watch?v=I-ljIwByX1s)

The malicious-code framing is the stronger of the two arguments. Data exfiltration is a contract and hosting problem you can engineer around with a self-hosted deployment. A trained-in backdoor survives self-hosting. That distinction is exactly where the exemptions get messy.

## What's exempt: open weights, national security systems, and private use

The order carves out three things explicitly, and getting them right is the difference between a panicked weekend and a calm one.

- **Open model weights are not covered.** The text treats weights as "not a product or service," so the published DeepSeek checkpoints themselves are not the banned artifact.
- **Independent hosts with no DeepSeek affiliation are not covered.** A US provider serving a DeepSeek open-weight model with zero commercial relationship to Hangzhou DeepSeek is not an "affiliated entity."
- **National Security Systems and compartmented information systems sit outside the order's scope entirely**, as does personal and private-sector use.
So can federal agencies still legally run self-hosted open-weight DeepSeek models?

This is the single most-debated question on the Hacker News thread that cleared 280-plus points within hours, and the honest answer is that the text leaves a gray zone while the direction of travel is clear. The weights are exempt as artifacts. The "DeepSeek implementations" clause, read by its plain purpose, targets commercial products built on or sold through DeepSeek, not an engineer pulling a GGUF file onto an air-gapped box.

A reasonable compliance read is that a truly independent self-host of open weights is not the thing being excluded. A conservative agency counsel will still avoid it, because "may contain malicious code" does not care whether you self-host.

For private companies the practical answer is simpler. Nothing legally forces your hand.

But if your largest customers are federal, their procurement teams are about to start asking whether your product contains "DeepSeek implementations," and "we self-host the open weights" may not be the clean answer you want it to be. The word "implementations" is deliberately broad, and until a court or a FASC clarification narrows it, every vendor in a federal supply chain inherits the ambiguity.

## How this fits the broader AI supply-chain security pattern

Step back and this looks less like an AI story and more like the next chapter of a decade-old supply-chain playbook. The 2017 Kaspersky binding operational directive and the Huawei equipment restrictions both rested on the same logic: a vendor under foreign jurisdiction, embedded deep in systems, with an attack surface you cannot fully inspect. The TikTok fight was a consumer-facing version of the same argument about data flowing to Chinese jurisdiction.

How does this compare to the Huawei, Kaspersky, and TikTok bans? Same jurisdiction logic, adjacent statutory machinery, far less inspectability:

| Target | Year / order | Legal mechanism | Artifact restricted | Inspectability |
| --- | --- | --- | --- | --- |
| Kaspersky | 2017, BOD 17-01 | DHS binding operational directive | Antivirus software | Binary — reviewable |
| Huawei | 2019, NDAA + FCC rules | Statute + FCC program | Network equipment | Hardware — testable |
| TikTok | 2024 divestiture law | Dedicated legislation | Consumer app / data flow | App behavior — observable |
| DeepSeek | 2026, Order No. 2026-01 | FASCSA 2018 exclusion | AI model products | Weights — opaque |

What is new is the artifact. A firewall or a router is a bounded thing you can test. A [large language model](/blog/ai-security-complete-guide) is an opaque statistical object whose behavior is defined by training data you will never see. That is why the SBOM-for-AI conversation got loud in 2026. A traditional software bill of materials tells you which packages shipped. It says nothing about which base model a vendor fine-tuned, whose weights are underneath a white-labeled chat feature, or whether a [RAG](/glossary/rag) pipeline calls out to a foreign inference endpoint at request time.

I have watched this blind spot play out firsthand. Running this blog's own multi-agent publishing pipeline across 261-plus published posts taught me that model dependencies hide in the most boring places. A single helper that "just summarizes text" can route to whichever provider was cheapest that month. If you are not logging the resolved model per call, you do not actually know your own supply chain. That is the lesson DHS just forced onto every federal CISO, and the private sector is next.

You can tear down a router and prove what it does. You cannot tear down a set of weights and prove it has no sleeper trigger. That asymmetry is why the AI entries on this list will only get longer.

## How engineering teams should audit foreign-model dependencies in their stack

Forget whether you are a federal contractor. If you ship software that touches an LLM, you should be able to answer one question this week: *which models, from which vendors, under which jurisdictions, actually execute when my users hit my product?* Most teams cannot. Here is the audit I would run, in order.

1. **Inventory direct API calls.** Grep for every provider SDK and base URL in your codebase and config. OpenAI, Anthropic, and the big names are easy. The ones that bite are OpenAI-compatible endpoints pointed at a reseller you forgot about.
1. **Trace white-labeled wrappers and resellers.** A "US AI startup" in your vendor list may be a thin front over a foreign model. Ask every AI vendor, in writing, which base model and which hosting region serves your traffic. This is the same transitive-trust problem behind the [LiteLLM PyPI supply-chain attack](/blog/litellm-supply-chain-attack-pypi) earlier this year.
1. **Catalog fine-tunes and their base models.** A fine-tune inherits the lineage, and the backdoor risk, of whatever it was trained on. Record the base checkpoint for every custom model you run.
1. **Hash and pin self-hosted open-weight checkpoints.** If you self-host, you need provenance. [Verify your GGUF model hashes](/blog/verify-gguf-hashes-supply-chain) against the publisher's release, pin versions, and keep them in a [local model registry](/blog/local-model-registry-gguf) so you can prove what is running. Based on the local LLM benchmark runs I maintain at [kunalganglani.com/llm-benchmarks](/llm-benchmarks), I pull and self-host open-weight checkpoints across Apple Silicon and NVIDIA hardware every week, and without recorded hashes you genuinely cannot tell two "same" downloads apart.
1. **Monitor the runtime, not just the repo.** Log the resolved model and region for every inference call. A config change can swap your provider in production without a single code diff.
That checklist pairs directly with a broader [LLM](/blog/llm-supply-chain-security-checklist) supply chain security checklist, and it belongs next to the controls you already run for [prompt injection](/blog/prompt-injection-2026-owasp-llm-vulnerability), which remains OWASP's top LLM risk. Treat foreign-model dependency as a first-class item in your [AI security](/pillars/ai-security-safety) program, not a footnote, and bake it into how you ship [AI in production](/pillars/ai-engineering-production).

The timing coincidence is the part that should make you move. The order went public the same week DeepSeek open-sourced DeepInfer, its production inference engine, which pulled 4,752 GitHub stars and 364 forks within four days of its October 16 creation, alongside the new DeepSeek-V4.1-Flash-1017 model. The weights are good, cheap, and spreading fast through exactly the self-hosted enterprise tooling the ban's open-weights carve-out does not reach. Engineers like [Simon Willison](https://simonwillison.net/) have documented running DeepSeek models locally precisely because the open-weight story is so compelling.

My prediction: within six months, "name every model and its jurisdiction in your stack" becomes a standard line item in enterprise security questionnaires, the same way SOC 2 and dependency SBOMs did. The federal order is the starting gun, not the finish line. The teams that can answer that question on demand will close deals faster than the ones still grepping their codebase in a panic. Start grepping now.

Photo by Aerps.com on Unsplash.