The DeepSeek ban reaches what you built. Do you know which model is inside?

What did DHS actually order?

If you sell software to a federal civilian agency, or you build part of something that ends up there, you may get a question this week that you can't answer from memory: is DeepSeek anywhere in your product?

Here's what happened. At 8:45 a.m. Eastern on Monday, October 19, Homeland Security filed a notice for public inspection, scheduled to run in the Federal Register on Tuesday, October 20. It announces an order from the Secretary of Homeland Security under the Federal Acquisition Supply Chain Security Act of 2018, the law people shorten to FASCSA. The order does two things. It excludes products and services developed by Hangzhou DeepSeek Artificial Intelligence Co., Ltd and its affiliated entities from civilian agency procurements. And it requires civilian agencies to remove DeepSeek and DeepSeek-affiliate products, "and third-party products and services developed using DeepSeek implementations," from their information technology.

The signed order is attached to the notice PDF as Exclusion and Removal Order #2026-01, with an original release date of July 24, 2026. It applies to federal civilian executive branch agencies, but not to their national security systems or sensitive compartmented information systems, which fall to Defense and the intelligence community. Exclusion takes effect immediately after issuance. Agencies are told to remove covered products immediately or ask for an exception, in writing, within 60 days. The order doesn't say whether "issuance" means the July date or the October notice, so that's one of the first questions to ask.

DHS's stated reasons are in the order itself. It points to DeepSeek's servers sitting in China, the account data DeepSeek-hosted services collect, and the risk that sensitive data moves to China "if used by U.S. government employees or vendors." It also says the models themselves may contain malware or other security vulnerabilities. That's DHS's case, and we won't add to it.

Does it reach software I built or sell?

Possibly, and that third-party line is why this lands on builders and not only on agency IT teams. A footnote adds that the procurement exclusion is "to include third party implementations of DeepSeek used to provide products and services to civilian agencies." The order doesn't define the phrase any further. It doesn't say whether an open-weight DeepSeek model you host on your own servers counts, or a model fine-tuned from one, or a feature that only calls DeepSeek as a fallback.

So let's be plain about our lane. Whether a specific product is covered is a question for your counsel and your contracting officer, and nothing here is legal advice. What we can help with is the part that comes before that conversation: knowing what's actually inside the thing you ship.

The contract side already has a mechanism. Federal contracts carry FAR clause 52.204-30, which says contractors may not provide or use, in performing the contract, anything an applicable FASCSA order prohibits. For contracts outside the Defense Department, DHS orders are the ones that apply. A new order reaches an existing contract through an amendment or modification. The clause's notice paragraph asks more of you in the meantime, though. During the contract, you're expected to check SAM.gov for FASCSA orders at least every three months. When one could touch your supply chain, you make a reasonable inquiry. If you find a covered product was delivered or used, you report it to the contracting officer within three business days, with a follow-up within ten. The clause also flows down into subcontracts.

The clause defines a reasonable inquiry as one into information already in your possession, with no audit required. That's both a relief and a catch. If nobody on your team ever wrote down which model runs where, there's nothing in your possession to inquire into.

Where could DeepSeek be hiding in a product?

Rarely in the place people check first. DeepSeek's models are popular partly because they're cheap and open-weight; Bloomberg noted on October 19 that those affordable open-weight models are an increasing challenge to Silicon Valley developers. That means they show up in places that never appear in a product spec.

Behind a router. Plenty of teams send model calls through an aggregator or a routing layer that picks a model by price or availability. The feature code says "the router"; the router config says which model, and sometimes it changes by the hour.

On your own hardware. An open-weight model downloaded and served on your GPUs doesn't send a single request to DeepSeek. It's still DeepSeek's model.

Underneath a fine-tune. A model your team or a vendor trained on top of a DeepSeek base can carry its own name. The base model is the fact you need on file.

Inside a vendor's tool. The transcription service, the document summarizer, the search plugin in your agent. Their model choice is your supply chain.

In a tool call, not the chat. DeepSeek has just launched Search and Fetch APIs for agents. An agent can talk to one model and fetch the web through another provider entirely, so the tool layer belongs in the inventory too.

None of this is hypothetical tradecraft. It's how ordinary AI features get built in 2026.

How do I find out which model my product uses?

Write one row per feature, and follow each call all the way to where it actually runs. The gap is rarely the main assistant, which everyone knows about. It's the quiet ones: the background job that tags documents, the fallback set months ago when a provider had an outage, a summarizer a vendor added in a release note nobody read.

For each AI feature, capture:

• The feature in plain words, and who uses it, including whether an agency user ever touches it.
• The code path. Which service makes the call, found by searching the code and config for model SDKs, API base URLs and model ids, not by asking around.
• The provider and endpoint. The direct vendor API, a cloud platform's model catalog, a router, or your own server.
• The model id and version, plus the base model if it's a fine-tune or a distilled model.
• Fallbacks and routing rules. Every model the call can land on, not just the default.
• Where the weights run and where the prompts and outputs go.
• The owner who can change it, and the date someone last checked.

Then check the row against things that can't drift: billing invoices show you which providers you actually paid, egress logs show where calls really went, and router dashboards show what got served. For vendor tools, ask in writing which models their feature uses and how they'll tell you when it changes. Our note on asking how AI touched your code has questions that carry over almost word for word.

Keep the finished inventory where your contracts and security people can find it. It's the document you hand over when the contracting officer asks.

And if a feature does run on DeepSeek?

Then you want swapping the model to be a configuration change, not a rewrite. That's easier if every model call already goes through one interface in your code, a single place that knows the provider, the model id and the settings, rather than SDK calls scattered across services.

If you're not there yet, that's the first piece of work, and it pays off well beyond this order. Models get deprecated, prices change, a provider has a bad week, and a vendor can retire the feature you depend on. One seam means one place to change.

Swapping the model is the easy part. Proving the replacement does the job takes longer. Prompts tuned for one model drift on another, tool calling and output formats differ, and a cheap model may have been cheap for a reason you were counting on. Before the switch goes to an agency, run the replacement against the real tasks that feature handles and compare, which is the case we made in score the job before you buy the model. Write down what you changed and when, because that record is part of what the contract clause asks you to describe.

And if counsel tells you a feature is clearly outside the order, keep the row in the inventory anyway. The next question will be about a different model.

Put this into practice

This week, before anyone asks:

• Search SAM.gov for "FASCSA order" and read the DHS notice and the signed order yourself.
• List every AI feature you ship to, or build for, a civilian agency, and follow each one to its model, its provider and where it runs.
• Flag any row where the answer is DeepSeek, or "we're not sure," and take those to counsel and your contracting officer.
• Put every model call behind one interface so a swap is a config change, then test the replacement on real tasks.

We build AI applications and agents and web applications, and our government and public sector page covers how we approach software for agencies. Inventories like this, and the refactor that makes a model swappable, are the engineering part of that work. If you want a second pair of hands mapping what your product actually calls, tell us what you're running.

Related work: Howcast.