CSIPE

Published

- 20 min read

The DeepSeek Removal Order Is an AI Dependency Inventory Test

AI Engineering Supply Chain Security Dependency Management Governance

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

A procurement team can remove an application from its catalogue in an afternoon. Removing a model that may sit behind other applications is harder. The logo on the screen tells you who sold the service. It may not tell you whose model handles the prompt, which provider runs it, or where the request goes after the user presses Submit.

That hidden layer is the important part of a US Department of Homeland Security order published on 20 October 2026. The notice excludes information technology products and services developed by DeepSeek and its affiliates from federal civilian agency procurement. It also orders the removal of DeepSeek products and “third-party products and services developed using DeepSeek implementations” from civilian agency information technology (Federal Register, 20 October 2026).

The order applies to covered US federal civilian systems and purchasing. It is not a general prohibition on private companies or members of the public. Independent reports from TechCrunch, The Guardian, and The Hacker News all described that federal scope and the extension to third-party technology built with DeepSeek (TechCrunch, 20 October 2026; The Guardian, 20 October 2026; The Hacker News, 21 October 2026).

For engineering teams outside government, the useful lesson is not “copy the ban.” It is much more practical: can you name the model behind each AI feature, the company operating it, the route taken by the data, and the work required to replace it? If the answer lives in somebody’s memory or a six-month-old architecture slide, you do not have an AI inventory. You have a guess.

What the order actually says

The public notice is short, but its nouns matter. It names products and services developed by Hangzhou DeepSeek Artificial Intelligence Co., Ltd., includes affiliated entities under the applicable regulations, and reaches third-party products and services developed using DeepSeek implementations. That last category turns a vendor-removal exercise into a dependency search.

The notice says the Secretary of Homeland Security acted under the Federal Acquisition Supply Chain Security Act of 2018 after reviewing a recommendation and supporting evidence from the Federal Acquisition Security Council. It contains the signed order as scanned pages and points readers to docket DHS-2026-0628. The machine-readable notice does not give a technical test for deciding when a third-party product counts as developed using a DeepSeek implementation (Federal Register, 20 October 2026).

That ambiguity should restrain confident claims. As of 21 October 2026, the public notice establishes the covered supplier, the federal civilian scope, the procurement exclusion, and the removal requirement. It does not establish that every locally run copy of an open model sends data to DeepSeek. It does not turn every application that once used a DeepSeek model during development into an obvious match. It also does not tell a private company what policy it must adopt.

The reporting adds context without changing the legal boundary. TechCrunch and The Guardian reported that the government cited national-security, data-transfer, and cybersecurity concerns. The Hacker News noted a particularly awkward implementation detail: the published notice itself does not state the reasons, while the signed order is attached as four scanned pages. That is a useful reminder to separate what the searchable notice says from what news coverage attributes to the government (TechCrunch, 20 October 2026; The Guardian, 20 October 2026; The Hacker News, 21 October 2026).

The practical boundary is still broad enough to cause work. A team can search a laptop for a named desktop application. It cannot find a model hidden behind an application programming interface by looking for an icon. The model may be selected in a server configuration, chosen dynamically by a routing service, called through a cloud marketplace, embedded in a library, or supplied by a vendor that reserves the right to change its subprocessors.

That is why this story has staying power beyond one federal order. AI is becoming a dependency that can move while the visible product stays put. A normal software inventory records packages and versions. An AI inventory must record decisions and routes as well.

The visible vendor may not be the model supplier

Suppose a case-management product adds a button labelled “Summarise.” The agency bought the case-management product, not a model. A user sees one product name, the contract names another company, and the actual request may pass through a cloud AI gateway before reaching a model supplied by a third party.

There are at least four identities in that ordinary transaction. The application vendor owns the interface. The model publisher created the model or weights. The inference provider runs the computing service that produces the answer. The data processor receives or stores prompts, outputs, logs, or abuse-monitoring records. Sometimes one company fills several roles. Sometimes none of the names match.

The distinction is not academic. A policy can prohibit one model publisher while permitting a service that routes among several models. A regional requirement can permit a model only when it runs inside a chosen cloud boundary. A contract can promise that prompts are not used for training while a logging add-on keeps complete request bodies. If the inventory has one field called “AI vendor,” it collapses different questions into one answer.

Model aliases make this worse. An application may request fast, reasoning, or best-available rather than a fixed model identifier. A gateway can translate that alias at runtime. A vendor can change the implementation behind a stable feature name. The user presses the same button on Monday and Friday, but the underlying dependency is different.

Open weights add another branch. A team might download weights associated with a publisher and run them on infrastructure it controls. In that case, prompts do not automatically travel to the model publisher. Yet the weights still have provenance, a licence, a version, an acquisition route, and a patch history. “Local” answers the hosting question. It does not answer the dependency question.

Fine-tuned models complicate the name further. A service can start with a base model, train an adapter, merge weights, change the serving stack, and sell the result under a new label. The runtime behaviour may depend on the base model, the added training, the system prompt, the retrieval source, and the tool permissions. A search for one brand name will miss this lineage unless somebody recorded it at build time.

The DeepSeek order exposes this ordinary design problem because it names third-party products and services built using a particular implementation. A team asked to comply cannot stop at the purchasing system. It has to connect contracts to deployed features, features to runtime routes, and routes to model lineage. That graph is the real inventory.

A model dependency is different from a package dependency

Software teams already know how to inventory packages. A lockfile records a library name and version. A container manifest records an image digest. A software bill of materials lists components that entered a build. Those records are valuable because the shipped object usually contains, or was compiled from, the named dependency.

An AI feature can depend on something that never enters the build. The application ships a network call. The model is selected when the call reaches a gateway, perhaps weeks after the application was deployed. No package scanner sees the choice because the choice is data, configuration, or provider policy.

Consider a support tool that sends a ticket to an internal AI gateway. The source repository contains only the gateway’s uniform client. Production configuration maps “ticket-summary” to a hosted model. A failover rule maps it to a second provider when the first exceeds a latency threshold. An experiment sends five percent of requests to a third model. The source code looks unchanged while three model dependencies are active.

The failure mode is silent. A security team asks which products use a named model and receives a list from procurement. The gateway team has a different list from configuration. The finance team has model-provider invoices. The data team has network logs. Each list is locally correct and globally incomplete.

A useful AI inventory therefore has two halves. The declared inventory records what a feature is allowed to use. The observed inventory records what it actually used. You need both because configuration drifts, experiments remain enabled, emergency fallbacks become permanent, and vendors change their own internals.

The declared half belongs near the feature’s code and deployment configuration. It should name the business owner, feature, model or model family, model publisher, inference provider, region, allowed data classification, tool permissions, retention terms, and fallback. The observed half belongs in runtime records: resolved model identifier, provider, route, time, application, environment, and policy decision. Prompt bodies usually do not belong in a central inventory log. Metadata does.

This separation also keeps the question answerable without collecting more sensitive content than necessary. You can prove that the payroll assistant called provider A in region B with model C without copying an employee’s salary question into a governance database. Good inventory is evidence about the route, not a second archive of everybody’s prompts.

The model itself is only one dependency. Retrieval systems add document indexes. Tool calls add email, code, ticketing, or payment authority. Guardrails add classifiers. Evaluation services receive sample data. Observability products may receive prompts and outputs. A complete record follows the data and the authority, not merely the model name.

That is the larger lesson behind the federal removal problem. If policy changes for any part of this chain, teams need to know where that part is used and what breaks when it disappears. A list of chatbot subscriptions cannot answer either question.

Why “we do not use DeepSeek” is a weak answer

A confident denial often means someone searched the obvious place. They checked the approved application catalogue, asked the central AI team, or searched a few repositories for the word deepseek. Those are reasonable first steps. None is a receipt.

The name may live in an environment variable rather than source control. A gateway can select it from a database. A low-code workflow can call it through a connector. A browser extension can bring its own provider. A vendor can use it inside a service without exposing the implementation in the user interface. A developer can run it locally under a generic server name.

Even a thorough text search answers only one moment. If a policy demands continuing exclusion, the team needs a control that catches the next deployment too. Otherwise the organisation performs an expensive search, removes the current instances, and quietly reintroduces the same dependency during the next experiment.

The stronger answer has three parts. First, a dated search describes where the team looked: contracts, architecture records, gateways, cloud accounts, source configuration, endpoints, extensions, local model stores, and vendor attestations. Second, runtime evidence covers the systems that can route model calls. Third, a release or policy gate prevents an unapproved model from returning unnoticed.

Ordinary security language can obscure the task. Teams sometimes call the answer “vendor risk management,” then route everything to a questionnaire. The questionnaire matters for hosted services, but it cannot inspect a configuration file or a developer workstation. Other teams call it “asset management,” then record servers without recording the models those servers provide. The work crosses both functions.

The useful unit is an AI capability: a named feature that receives particular data and can take particular actions. “Draft a reply in the support console” is a capability. “AI platform” is a budget line. For each capability, the inventory should tell you which model paths are permitted and which path was observed.

This framing also prevents overreaction. If a team runs an affected model family locally with no route to the publisher, that is materially different from sending regulated records to a hosted endpoint. A policy may still exclude both, but the technical reason and the removal work differ. Good records let policy owners make that distinction instead of guessing from brand names.

A denial backed by this evidence has a defined date and scope: “As of 21 October 2026, these production gateways, cloud accounts, managed applications, and approved local runtimes show no permitted or observed DeepSeek route.” That sentence has limits, which is exactly why it is useful.

What to inventory before a policy forces the question

Start with deployed features, not a grand spreadsheet of every model anyone has heard of. A feature has an owner, users, input, output, and consequence. Those facts make it possible to decide what evidence matters and who can repair the system.

A small record can carry enough detail if its fields are chosen carefully. Record the feature name and business owner. Name the application vendor, model publisher, inference provider, exact model identifier or controlled alias, hosting region, and route through any gateway. Add the data classes allowed into the feature, its retention setting, tool permissions, and the fallback used when the normal route is unavailable.

Do not put “OpenAI-compatible” in the model field. That describes an interface shape, not the provider or model. Do not put “private” in the retention field without a contract or configuration reference. Do not put “local” in the region field without naming the machine or cluster class that runs it. Vague labels feel tidy because they postpone the hard question.

Link each assertion to evidence. The provider and region can point to deployment configuration. The model lineage can point to a build manifest, model card, vendor attestation, or contract schedule. The data class can point to the feature’s threat model. The observed route can point to a gateway event that records metadata but omits prompt content.

Model lineage deserves special treatment. For a hosted proprietary model, the provider’s stable model identifier may be the best available reference. For downloaded weights, store a cryptographic digest, source location, acquisition date, licence, and base model declaration. For a fine-tuned model, record the base, adapter or training job, and the resulting artifact digest. The label painted on the endpoint is not enough.

The fallback has to be explicit because it is where policy often breaks. A primary provider can be approved while the emergency provider is not. A developer adds the fallback during an outage, sees the service recover, and forgets that a new data route now exists. If the fallback is absent from the inventory, the outage becomes an unaudited policy migration.

Tool permissions belong beside the model route because replacement can change behaviour. Two models given the same prompt may choose tools differently, format arguments differently, or handle refusals differently. Swapping a model under an agent that can send email or modify code is not equivalent to changing a spell-checker. The permission boundary should survive the swap even when the model does not.

Finally, record a removal owner and a tested exit. The owner is the person or team accountable for making the change. The exit is the path to disable, replace, or isolate the capability. A dependency with no exit plan is technical debt that can become an outage when policy, price, security, or availability changes.

A practical removal drill

A removal order is a poor time to discover that nobody can trace model traffic. Teams can rehearse the work with any non-critical AI feature before an actual deadline arrives. The point is not to predict which supplier a government or customer will reject next. The point is to prove that one supplier can be removed without losing control of data or production.

  1. Name one capability and freeze its scope. Choose a real feature such as ticket summarisation, code review, document search, or meeting notes. Write down the production environments, user groups, data classes, and actions in scope. This prevents the exercise from turning into a company-wide hunt with no owner.

  2. Trace the declared route. Follow the application configuration through gateways, cloud services, model aliases, and fallbacks. Record the model publisher, inference provider, region, model identifier, credentials, retention setting, and any tools the feature can call. If a vendor owns part of the route, ask for a dated answer about model and subprocessor use rather than accepting a generic security page.

  3. Compare the route with observations. Use gateway metadata, provider billing, network destinations, cloud audit records, and local runtime records to see what actually served requests. Keep prompt content out of the audit unless a separate, justified process requires it. A mismatch between declared and observed providers is a defect, even when both providers are individually approved.

  4. Disable the named dependency at the narrowest control point. Deny the model identifier or provider route in the gateway, remove the credential, or stop the local serving artifact. Do not rely on a message asking developers not to use it. A control should reject the request before data leaves the approved boundary.

  5. Exercise the fallback deliberately. Confirm whether the feature fails closed, degrades to a non-AI path, or moves to an approved replacement. Check the replacement with representative evaluations before treating a successful HTTP response as success. Quality, latency, cost, data handling, and tool behaviour can all change.

  6. Search for residue. Look for cached credentials, disabled but deployable configuration, copied model weights, old container layers, browser extensions, notebooks, and automation that can restore the route. Removal is incomplete if tomorrow’s deployment can reconstruct the dependency from an old secret and a stale configuration file.

  7. Produce a dated receipt. Save the inventory snapshot, policy change, affected systems, observed last use, credential action, replacement evaluation, exceptions, and approver. State what the drill did not cover. The receipt should let a reviewer reproduce the conclusion without interviewing the engineer who ran it.

This sequence does more than satisfy a ban. It tests whether the organisation can replace a model without turning the change into an uncontrolled production experiment. It also reveals where a vendor has become inseparable from application logic, evaluation baselines, prompt formats, or tool calls.

The drill should end with one enforceable rule. A practical default is: every production AI request must resolve through an approved route that records model and provider metadata, and unapproved routes fail closed. Local research can have a separate policy. Production should not depend on invisible choice.

Replacement is a safety change, not a string edit

A team finds model: old-provider, changes it to model: new-provider, deploys, and sees green health checks. The removal appears complete. Then the replacement produces longer answers that overflow a downstream field, calls a tool with different arguments, or refuses a class of valid requests that the old model handled.

Model substitution changes behaviour even when the interface is compatible. The new model may interpret the system prompt differently. Its context window, token accounting, structured-output reliability, safety policy, and tool-selection habits may differ. A gateway can hide the transport difference while leaving every behavioural difference intact.

That means a removal plan needs evaluation evidence. Use a fixed set of representative tasks, including ordinary cases, known edge cases, prohibited actions, malformed input, and requests that exercise tools. Compare outcomes against acceptance criteria decided before the replacement. A few hand-picked screenshots are not a release gate.

Keep the permission boundary stable while the model changes. The replacement does not need temporary access to every production tool merely because the team is under deadline. Run it in a test environment, use read-only data where possible, and preserve human approval for consequential actions until the evidence supports a wider release.

Watch costs and latency too. An approved replacement that is ten times slower can cause retries, queue growth, and emergency bypasses. One that is substantially more expensive can trigger hurried optimisation after launch. Those operational failures can reintroduce the removed route under pressure, especially when the old credential remains available.

A clean exit therefore has two independent proofs. The dependency proof shows that the disallowed model path is gone. The service proof shows that the replacement still meets the feature’s quality, safety, privacy, latency, and cost requirements. One does not imply the other.

This is also where the distinction between a model and an agent matters. A model returns text or tool choices. An agent wraps that model in memory, tools, retries, and authority. Replacing the model inside an agent changes one decision-maker inside a larger system. The rest of the harness still has to enforce what the agent may read, send, and change.

The book The Secure Harness: Shipping Production Code with AI Coding Agents treats permissions and external effects as system boundaries rather than promises made to a model. That approach travels well here. If a model replacement can silently gain a new route to data or tools, the system never had a stable boundary.

What leaders should ask for

An executive does not need a table containing every token price and model digest. They need evidence that the organisation can answer a policy change without stopping production or making claims it cannot prove. The question is operational readiness, not spreadsheet size.

Ask for the number of production AI capabilities with a named owner. Then ask what proportion has both a declared model route and an observed one. Ask how many permit dynamic routing, what their approved destinations are, and whether the fallback was evaluated. A total count without coverage is decoration.

Ask to see one removal receipt. It should show the last observed use of the old route, the control that blocks its return, the treatment of credentials and stored artifacts, and the evaluation of the replacement. If the receipt consists of a ticket marked Done, the evidence is too thin.

Exceptions need shape. Each exception should name the system, owner, reason, compensating control, data limit, expiry date, and approver. “Temporary” without a date means permanent with less honesty. A policy that cannot represent a narrow exception often drives work into personal accounts and unmonitored tools.

Vendor contracts need a change signal. If a third-party service can change its model supplier or processing route, require notice, an accurate subprocessor record, and enough detail to assess the change. A promise to use “industry-leading AI” tells an inventory nothing.

Engineers need a paved path, not just a prohibited list. Give them an approved gateway, clear model choices, testing support, and a way to request a new provider. If the safe route takes weeks and a direct API key takes minutes, the inventory will lose to delivery pressure.

The strongest governance rule is small enough to enforce: no production AI capability without an owner, an approved route, and a tested stop. Everything else can grow from those three facts. They tell you who acts, where data goes, and how to halt it.

The real test is whether the dependency can move

The DeepSeek order is a federal procurement and removal decision, not a universal verdict for every organisation. Private teams still have to make their own decisions from their legal duties, threat model, data, contracts, and operating context. Copying another institution’s conclusion is easier than doing that work, but it is not governance.

The order is still a valuable test case because it reaches below the visible application. A third-party product can inherit a model dependency. A stable feature can change providers behind the scenes. A local deployment can share lineage with a hosted service while having a different data path. Those distinctions are now operational facts, not architecture trivia.

Teams that can answer the order’s implied question will have a graph connecting capabilities, vendors, models, providers, data, tools, and owners. They will compare declared routes with observed routes. They will block an unapproved dependency at a control point and show what happened when the block fired.

Teams that cannot answer will begin with brand-name searches and meetings. Some will find the right systems. Others will miss gateways, fallbacks, local weights, and vendor internals. Comparable effort produces a weaker answer when the system was never built to produce a receipt.

Do one removal drill before somebody else chooses the deadline. Pick a non-critical feature, trace its real route, block one model, test the replacement, and save the evidence. The resulting receipt proves that your AI architecture has an exit, whatever future policy prompted the question.

For more calm, practical security explanations, join the newsletter. It is one email per month.

Sources