When You Consume AI, You Inherit Every Upstream Risk You Can’t See
Image: Shutterstock
Four elements of the artificial intelligence supply chain walk into a bar arguing who’s in charge.
See Also: Beat the Breach: Outsmart Attackers and Secure the Cloud
LLM: I run inference – I drive everything that matters.
AI IDE: Cute! I build the apps that make or break companies.
GPU: Please! Without me, none of you even compute.
Hormuz Strait: Hold my beer!
Most organizations deploying AI are not training models. They are consuming them via API calls to tech giants OpenAI, Anthropic or Google; via copilots embedded in productivity suites; via open-source models pulled from Hugging Face and wired into internal applications. Their engineering teams are moving fast, solving real problems and almost uniformly operating without a security framework adequate to what they are actually doing.
The uncomfortable truth: consuming AI is not safer than building it. When you build, you control the pipeline. When you consume, you inherit every upstream decision about training data, model updates, API security and data handling with little visibility into any of it.
The AI supply chain runs through every organization deploying AI today across four layers: third-party model APIs and pre-built services – the dominant model for most enterprises; open-source models and repositories – the substrate for most internal tooling; software orchestrators – the middleware connecting models to your data; and the cloud and physical infrastructure beneath it all. Each layer carries exploitable risk. The combination, deployed at today’s velocity, is the most consequential security challenge of this decade.
Let’s look at each of these layers.
The Third-Party API Layer
For most organizations, “deploying AI” means API calls to a foundation model provider – which implies:
You don’t control model updates: Providers update models continuously. Behavior and outputs change without versioned releases or change notifications. Applications that behaved predictably last month may not today.
Your data transits infrastructure you do not own: Data residency, retention policies and training opt-outs vary by provider, tier and geography. The contractual terms are rarely read before integration.
API keys are credentials: They are routinely hard-coded into repositories, embedded in pipelines and shared across teams. A leaked LLM API key is a data exfiltration vector, not just a billing problem.
Vendor concentration is a resilience risk: Deep integration with a single provider means service disruption, pricing changes or capability deprecation with no fallback – a business continuity issue when the AI system is load-bearing.
The controls: Apply the same vendor assessment discipline used for any critical SaaS dependency: contractual data-handling obligations, integration inventories, proper secret management and a continuity plan.
The Open-Source Repository Problem
Open-source model repositories have become the npm of the AI world – a vast, community-contributed ecosystem that accelerates development and imports supply chain risk at an equivalent scale.
Hugging Face hosts over 1 million model artifacts. Vetting is community-driven and inconsistent. Researchers have documented malicious models uploaded with names designed to mimic legitimate ones, which lead to the same dependency confusion attacks that have plagued software supply chains for years.
Some specific risks:
Pickle file serialization: Legacy PyTorch models use pickle files, which are executable code. A malicious pickle runs arbitrary code on load, which means no exploit is required. These remain widely distributed despite many warnings.
Typosquatting: Attackers upload models with names close to popular ones. A developer picking the wrong artifact has loaded untrusted code into their pipeline.
Malicious LoRA adapters: These small, portable weight-modification files alter a base model’s behavior when loaded. They aren’t inspectable by conventional security tools and increasingly circulate outside primary registries.
The controls: An internal approved model registry. Engineers pull from it after the architects and security leads vet what enters it. Pickle formats are blocked in favor of safetensors, and the registry carries the same access controls as your code artifact repository.
The Orchestration Layer
Most AI applications don’t call a model API with a simple prompt. They use orchestration frameworks such as LangChain, LlamaIndex, AutoGen to connect models to internal data, external tools and other agents. This is where sensitive data is assembled and transmitted, and where the vulnerability surface expands most sharply.
Orchestration frameworks carry the usual software supply chain risks: vulnerable dependencies and insecure defaults. But they also introduce AI-specific ones:
Prompt injection via data sources: An orchestrator that retrieves external content – emails, documents, web pages – and passes it to a model is vulnerable to prompt injection. Malicious instructions embedded in that content can redirect the model to exfiltrate data or take unintended actions.
RAG poisoning: Organizations augmenting model responses with internal knowledge bases are exposed if an attacker can influence that knowledge base through a compromised document or manipulated record. They then influence every response the model generates from it.
Excessive tool permissions: Agents are routinely granted more access than necessary to databases, email systems and code repositories, because restricting permissions during development is friction.
The control: Zero trust principles apply directly – least privilege access, explicit allowlists for data sources and APIs, and behavioral monitoring that flags anomalous patterns. This matters doubly as organizations move toward agentic architectures, as autonomous agents acting with real credentials and real API access amplify every orchestration gap from inconvenience to critical vulnerability.
The Infrastructure Layer
AI workloads run on specific hardware, in specific facilities, dependent on specific supply chains. Most security teams have not mapped this layer.
GPU and compute concentration create procurement pressure that bypasses normal security vetting. When internal capacity is constrained, engineering teams source compute from unvetted cloud providers to maintain delivery timelines. Shared tenancy across business units or clients, chosen for cost efficiency, increases lateral movement risk. Highly specialized AI accelerator hardware frequently runs proprietary firmware excluded from standard patch management cycles, meaning vulnerabilities persist longer than in conventional infrastructure.
Hyperscaler dependency introduces a different class of risk. Organizations running AI workloads exclusively on a single cloud provider have inadvertently created a concentration risk, not just for availability, but for security posture changes, regional data residency shifts and pricing that affects what workloads can realistically run where.
Energy and physical infrastructure are the layer nobody talks about until it fails. Data centers are increasingly dependent on specific energy sources with their own geopolitical and supply constraints. An organization with concentrated AI compute infrastructure has created a high-value physical target, and business continuity planning that ignores the physical layer of the AI supply chain is incomplete.
The controls: Geographic distribution of critical AI workloads, documented fallback compute options, hardware asset inventories that include AI accelerators and firmware patch management that explicitly covers specialized AI hardware.
The Regulatory Dimension
The EU AI Act introduces supply chain obligations for organizations consuming third-party AI. Deployers of high-risk AI applications bear responsibility for ensuring the systems they consume meet documentation and risk assessment requirements, and not just the providers building them.
The NIST AI RMF’s Govern and Map functions establish expectations for provenance documentation, third-party model assessment and incident response. For organizations in banking, insurance, healthcare and telecom, these frameworks are becoming audit criteria on a short timeline.
The contractual and documentation work that security teams should already be doing for AI vendor assessments is increasingly a compliance requirement.
The Blueprint for Defense
No dedicated AI security team required at the start. No six-figure tooling purchase. These are existing security disciplines applied to a new supply chain.
Inventory first. Map every AI integration: APIs being called, models running internally, orchestration frameworks deployed, and teams that own them. Shadow AI is as real as shadow IT – so treat it the same way.
Treat AI vendors like critical SaaS: Aspects such as data handling, retention policies, sub-processor lists and incident notification belong in the contract, not in assumptions.
Build an internal model registry: Register, version and integrity verify everything. Block pickle-format models. Require Safetensors.
Manage AI credentials properly: API keys belong in a secrets manager, scoped to minimum permissions, rotated regularly. Not in repositories. Not in shared Google Sheets.
Make prompt injection a first-class threat: Any application passing external content to a model needs input validation and output filtering. This is the SQL injection of the AI era.
Lock down agent permissions before deployment: Least privilege, explicit API allowlists and behavioral baselines should be non-negotiable requirements.
The Hormuz Strait doesn’t fire a packet or train a weight. It sits at a chokepoint and evrerything depending on what flows through it is exposed the moment it becomes a problem.
Your AI supply chain has unmapped chokepoints: the API provider whose terms nobody read, the open-source model pulled last Tuesday, the orchestration framework running with admin credentials because it was easier, the agent with access to your customer database.
Securing AI means securing everything that feeds it and that work starts with one uncomfortable question: Do you actually know what’s running in your environment right now?