Safeguard
AI Security

Governments banning AI models: security implications for teams

Governments banned DeepSeek and other AI models in 2025 within days. Here's the security supply-chain risk teams face and how to find and fix it fast.

James
Principal Security Architect
6 min read

In January 2025, Italy's data protection authority ordered DeepSeek to stop processing Italian users' data, effectively pulling the app from the market within days. By February, the U.S. House of Representatives, the Pentagon, NASA, and the Navy had banned DeepSeek from government devices, and Australia, Taiwan, and South Korea followed with their own restrictions. These weren't abstract policy debates — they were concrete, dated bans on one specific model that had already been pulled into internal tools, chatbots, and coding assistants through its API and open-weights release. For security and engineering teams, a government ban doesn't make a model disappear from your stack. It converts a vendor-risk question into a compliance deadline, and most organizations don't have an inventory of where AI models are actually running inside their code, pipelines, and third-party products to even start remediation.

Which governments have banned or restricted specific AI models?

At least seven governments restricted a named AI model between 2023 and 2025, and the pace accelerated sharply after DeepSeek's January 2025 release. Italy's Garante forced an 11-day shutdown of ChatGPT in Italy from March 31 to April 20, 2023, over GDPR concerns before OpenAI added age gates and disclosures. Fast forward to DeepSeek: Italy's Garante ordered DeepSeek to stop processing Italian user data on January 30, 2025, pushing the app out of Italian app stores within a week. Texas Governor Greg Abbott banned DeepSeek and other Chinese-owned apps from state government devices on January 31, 2025. The U.S. House of Representatives' Chief Administrative Officer banned DeepSeek on House-issued devices in early February 2025, and the Navy, NASA, and the Pentagon issued their own internal bans the same month. Australia mandated the removal of DeepSeek from all federal government devices on February 4, 2025; Taiwan's government agencies were barred from using it February 1; and South Korea suspended new DeepSeek downloads on February 15, 2025, pending a review under its Personal Information Protection Act, lifting the suspension only after DeepSeek agreed to data-handling changes later that year. On the other side of the ledger, China has long blocked ChatGPT, Claude, and Gemini for its own citizens through the Great Firewall — model bans run in both directions.

Why do governments ban specific models instead of regulating AI use broadly?

Because the risk they're reacting to is usually about the vendor and the data flow, not the technology category. A named-model ban is a fast, narrow tool for a specific worry: that user prompts, code snippets, or documents sent to a foreign-owned model could be accessible to that country's government under laws like China's National Intelligence Law, which was the core concern cited in the Texas, Australian, and Taiwanese DeepSeek orders. Broader frameworks work differently. The EU AI Act, in force since August 1, 2024, prohibits categories of use — social scoring, untargeted biometric scraping, emotion recognition in workplaces and schools — starting February 2, 2025, with fines reaching €35 million or 7% of global annual turnover, whichever is higher. Those two mechanisms create different compliance timelines: a use-case rule gives you a regulatory runway to redesign a feature, while a named-model ban gives you days to rip a dependency out. Italy's December 2024 €15 million fine against OpenAI over ChatGPT's training-data practices shows regulators are willing to combine both approaches against the same vendor.

What security risk does a banned model actually create in your supply chain?

The risk isn't the model's training data or its outputs — it's that nobody tracked where the model got wired into your systems in the first place. DeepSeek-R1 shipped as open weights on January 20, 2025, and within weeks developers had published hundreds of derivative and fine-tuned versions on Hugging Face, any of which could be pulled into a container image with a single ollama pull deepseek-r1 or referenced in a requirements.txt via a community wrapper package. Traditional SBOMs built around CycloneDX or SPDX weren't designed to capture model provenance, so a model dependency can sit invisible next to your OSS libraries: an API key named DEEPSEEK_API_KEY in a CI secret store, a SaaS vendor whose "AI assistant" feature quietly routes to a banned model's API on the backend, or a browser extension developers installed for autocomplete. Each of those is a real path by which source code, credentials, or customer data could reach a jurisdiction your legal team never approved.

How do you find out if a banned model is already running in your environment?

You find it the same way you'd find any other supply-chain risk: by inventorying dependencies and then confirming which ones are actually invoked, not just present. Concretely, that means scanning package manifests (package.json, requirements.txt, pom.xml) and lockfiles for model SDKs and API wrapper packages, grepping Dockerfiles and Helm charts for baked-in model pulls, checking CI/CD logs and egress rules for calls to endpoints like api.deepseek.com, and sending targeted vendor questionnaires to any SaaS product with an "AI-powered" feature to ask which model runs underneath it. The gap most teams hit here is volume versus signal: a large codebase can surface dozens of AI-adjacent packages, and treating every hit as equally urgent burns the same triage time a banned dependency actually needs.

What should security teams do when a model they depend on gets banned?

Treat it exactly like a critical vulnerability disclosure: triage exposure, confirm reachability, and remediate before the compliance deadline rather than after. In practice that's a five-step sequence — inventory every place the model or its SDK appears in code and infrastructure; check whether each occurrence is actually reachable from a live code path or is dead code, a dev-only script, or an unused import; prioritize anything touching production systems or customer data; swap the dependency, gate network egress to the model's API, or pin an approved alternative; and document the fix for auditors. The window is usually short — Texas ordered "immediate" removal from state devices, and the U.S. House gave staff instructions within the same week the ban was announced — which means days, not fiscal quarters, to show a closed loop from detection to fix.

How Safeguard Helps

Safeguard's reachability analysis tells you which flagged AI SDKs, model API calls, or dependency paths are actually exercised at runtime versus sitting in dead code, so a banned-model alert turns into a scoped fix list instead of a codebase-wide fire drill. SBOM generation and ingestion give you a standing inventory of model dependencies and their provenance across repos, containers, and pipelines, so the next government ban doesn't start with a manual grep across every team's code. Griffin AI, Safeguard's agent, cross-references that inventory against ban and denylist updates in near real time and drafts the remediation plan automatically. When a fix is confirmed safe, Safeguard opens an auto-fix PR that swaps the banned dependency or pins an approved alternative, so your team ships the compliance fix in hours instead of tracking it across spreadsheets and Slack threads.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.