Dependency Confusion Attacks: The AI Supply Chain Blind Spot

Most enterprise AI security discussions focus on the model itself — prompt injection, jailbreaks, output sanitization. Those are real problems. But in 25 years of enterprise security work, I’ve learned that the most dangerous attacks rarely hit what you’re watching. They hit the infrastructure you assumed was fine.

Right now, the blind spot for most AI teams is dependency confusion — a class of supply chain attack that has quietly followed AI tooling straight into enterprise pipelines, and that most AI-focused security reviews completely miss.

TL;DR

Dependency confusion attacks exploit how package managers resolve package names across private and public registries. An attacker publishes a malicious package to a public registry using the same name as an internal private package. The package manager fetches the public version — and runs attacker-controlled code inside your AI pipeline. Enterprise AI environments are uniquely exposed because they pull from multiple package registries at build time, often with minimal review.

What a Dependency Confusion Attack Actually Looks Like

The attack was formally documented in 2021 when security researcher Alex Birsan compromised internal systems at Apple, Microsoft, PayPal, and 33 other companies using a single technique: publishing packages to PyPI and npm with names that matched internal package names found in leaked manifests or public GitHub repos.

The package manager resolves the higher version number. Public repo wins. Malicious code executes.

Here’s why AI teams should be alarmed specifically:

A typical enterprise AI pipeline touches pip install or npm install across several components — the model serving layer, the vector database client, the orchestration framework (LangChain, LlamaIndex, CrewAI), the observability tooling, and any custom internal libraries wrapping API calls. Each of those install steps is a potential resolution point. Most of them run in automated CI/CD pipelines where nobody is reviewing what actually got pulled.

I’ve reviewed several enterprise AI deployment architectures in the past year. Almost none of them had explicit registry pinning for every dependency. Most had requirements.txt files with version ranges, not locked hashes. Some were pulling from three different registries without a consistent resolution policy.

That’s not a hypothetical attack surface. That’s an open door.

Why AI Pipelines Are Higher Risk Than Traditional Software Stacks

Traditional enterprise software typically has a reasonably mature software composition analysis (SCA) process — Snyk, Black Duck, Dependabot. Not perfect, but present.

AI pipelines are newer and often built by teams that came up through data science or ML, not security engineering. The culture is different. Speed and experimentation take priority. Requirements files are copied from tutorials. Containers are rebuilt from scratch every sprint. Pinning dependencies to verified hashes feels like friction.

There are three specific factors that elevate AI pipeline risk:

Rapid tooling churn. The AI framework ecosystem is moving fast. LangChain alone has had multiple major version breaks in under two years. Teams are constantly upgrading, pinning to latest, or pulling experimental branches. Every upgrade is another resolution event.

Private internal packages with predictable names. As enterprises build internal AI abstractions — wrapper libraries around their approved models, internal RAG utilities, shared prompt management libraries — they create private packages with names that follow predictable conventions. Any one of those names leaking into a public repo (even a developer’s personal project) becomes a target.

Containerized build environments with broad registry access. AI model serving infrastructure often runs in containers built with broad outbound access and minimal egress controls. A confused dependency doesn’t just run once — it runs every time the container builds, potentially across dozens of microservices.

How to Detect Dependency Confusion Exposure in an AI Pipeline

Before you can fix anything, you need to understand your exposure. Here’s the checklist I’d run on any enterprise AI environment:

Registry audit

• Enumerate every package registry configured in pip.conf, .npmrc, pyproject.toml, or equivalent
• Identify any configuration that allows fallthrough from private to public registry
• Document which services have outbound access to PyPI, npm, or Conda

Package name inventory

• List every internal/private package name in use
• Search GitHub (public and private org repos) for any of those names in requirements files
• Check PyPI and npm directly: are any of those names already claimed? By whom?

Build pipeline review

• Audit CI/CD pipelines for unversioned or loosely versioned AI framework dependencies
• Verify that requirements are pinned with hashes (pip install --require-hashes)
• Check whether Dependabot or equivalent is scanning AI-specific requirements.txt files

Container security

• Review egress rules for build containers — does your AI inference container need to reach PyPI at runtime?
• Verify base images for AI workloads come from your internal registry, not directly from Docker Hub

Dependency Confusion Controls That Actually Work

Awareness is cheap. Here’s what actually reduces exposure.

Private registry with explicit deny of public fallthrough. Tools like Artifactory, AWS CodeArtifact, and Azure Artifacts let you configure a private registry that proxies approved public packages. The key configuration is disabling automatic fallthrough to the upstream public registry when a package isn’t found internally. If a package isn’t in your private registry, the build fails — it does not silently resolve from PyPI.

# pip.conf — enforce private registry, no public fallback
[global]
index-url = https://your-private-registry/pypi/simple/
no-index = false  # set to true to completely block public resolution

If you’re on AWS CodeArtifact:

aws codeartifact put-domain-permissions-policy \
  --domain your-domain \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Principal":"*","Action":"codeartifact:GetPackageVersionAsset","Condition":{"StringNotLike":{"aws:PrincipalArn":"arn:aws:iam::ACCOUNT:*"}}}]}'

Hash pinning in requirements files. Every AI project should be running pip-compile (from pip-tools) to generate a locked requirements file with cryptographic hashes. This means even if an attacker somehow inserts a malicious version at the correct version number, the hash won’t match and the install will fail.

pip-compile --generate-hashes requirements.in > requirements.txt
pip install --require-hashes -r requirements.txt

Claim your internal package names. If you have internal packages with names that could plausibly be confused with public packages, register those names on PyPI with dummy packages that point to your security contact. This is an inexpensive defensive measure that closes the attack vector for the specific name.

Software composition analysis on AI requirements files. Make sure your SCA tooling is actually scanning your AI-specific files. Many enterprises have Dependabot configured on their application repos but haven’t extended that coverage to the ai/, ml/, or notebooks/ directories where the AI dependencies live.

What the EU AI Act and NIST AI RMF Say About This

Neither the EU AI Act nor NIST AI RMF calls out dependency confusion by name — they’re framework documents, not technical specifications. But both create organizational accountability that makes these controls relevant from a compliance standpoint.

The EU AI Act’s Article 9 requirements for high-risk AI systems include maintaining a quality management system covering the “relevant supply chains.” NIST AI RMF’s GOVERN function explicitly addresses AI supply chain risk as an organizational risk category. If you’re a security or compliance team being asked to attest to AI supply chain controls, “we don’t audit our package registries” is not an answer that holds up.

The practical translation: any enterprise that needs to demonstrate AI supply chain due diligence needs documented registry controls, not just application-layer security.

Key Takeaways

• Dependency confusion attacks are a supply chain attack class that predates AI but maps directly onto how AI pipelines are built
• Enterprise AI environments are higher risk than traditional software stacks due to rapid tooling churn, predictable internal package naming, and loose build pipeline controls
• The primary controls are: private registry with no public fallthrough, hash-pinned requirements, claiming internal package names on public registries, and extending SCA coverage to AI-specific dependency files
• Neither model security nor prompt-level controls address this exposure — it sits below the application layer
• EU AI Act and NIST AI RMF both create supply chain accountability that makes these controls compliance-relevant, not just security best practice

The AI security conversation needs to expand past the model. What runs the model matters just as much. Dependency confusion is a known, exploitable attack with documented tooling and real enterprise victims. The controls exist. The question is whether AI teams will apply them before they become a case study.