By Luigi Caramico, Founder and CTO of DataKrypto

Every component in an AI system can read the plaintext data flowing through it. By design. The LiteLLM breach just made it visible.

On March 24, attackers compromised Trivy, a security scanner in LiteLLM’s CI/CD pipeline, and used it to steal PyPI publishing credentials. Two backdoored versions of the package followed. Over 119,000 downloads before PyPI quarantined it. The operation was discovered only because the malware had a bug that crashed a researcher’s machine.

The supply chain attack is well documented. The architectural problem it exposed is not.

Every layer in an AI system requires access to usable data to function. Which means every layer is also a potential extraction point. As long as AI systems operate on plaintext in memory, the architecture itself guarantees exposure.

Why AI Pipelines Concentrate Risk Differently

An AI pipeline is like a building where every contractor has a master key: the plumber, the electrician, even the security company that installed the alarm. The building was designed that way because every contractor needs full access to do their job. The LiteLLM incident is what happens when one of those contractors gets impersonated. You don’t break in. You show up with the key the building already gave you.

AI systems require plaintext access to credentials and data across layered components: retrieval, routing, inference, tool execution. An LLM gateway holds API keys for every provider it routes to. An MCP server holds tool credentials. An agent framework holds both, plus user context. The orchestration layer has access to everything.

Three Exposure Surfaces Most Teams Miss

• Transitive dependencies in build tooling. Trivy ran as a security scanner in LiteLLM’s CI/CD pipeline, not as a direct dependency. Teams audit their direct imports but rarely audit the tools that build, scan, and publish their code. Those tools often run with equal or higher privileges.
• Unpinned installs in CI/CD. PyPI data showed that 40–50% of all LiteLLM installs were fetching the latest version on every invocation. An unpinned pip install in a pipeline is a standing invitation for any future compromise to propagate automatically.
• Credential sprawl in orchestration layers. AI gateways, agent frameworks, and MCP servers aggregate credentials by design. A single compromised component in the orchestration layer gains access to every key it routes through.

How Enterprises Should Map Their AI Supply Chain

Most enterprises lack visibility here because the AI supply chain extends well beyond packages in a codebase. Three questions matter:

• Start with inventory. What AI components are running in your environment, and who introduced them? Much of the LiteLLM adoption that created exposure was decentralized. Individual developers were connecting AI agents to production resources without formal security review.
• Where are credentials aggregated? Any component routing to multiple providers is a credential aggregation point. Treat these as critical infrastructure, not developer tooling.
• What’s the blast radius if any single component is compromised? Consider the full reach of each: process memory, filesystem, environment variables, Kubernetes secrets. In regulated environments like financial services, this mapping is an audit requirement under SOX, GLBA, and model risk management frameworks. If your AI supply chain map can’t answer “what data could a compromised component in this layer access,” that’s a finding.

What “Pin and Rotate” Doesn’t Solve

The standard remediation advice after incidents like this is to pin your dependencies to specific, verified versions so you control exactly what gets installed, rotate all credentials that may have been exposed, and verify checksums to confirm packages haven’t been tampered with. This advice is correct and necessary. But it addresses the incident, not the underlying problem: the architecture itself requires plaintext access. Even with perfect dependency hygiene, every component in the execution path can read what it handles. Pinning versions is like running background checks on your contractors. Important, but the building still hands them a master key.

The Risk That Extends Beyond Credentials

The LiteLLM attack harvested credentials and operational data. The same class of attack can reach further. A trained model is a compressed, queryable representation of everything it learned, with no schema, no access controls, and no audit trail. An attacker who compromises a training pipeline doesn’t need to exfiltrate a database. They get a model that can be queried for what it knows, one innocuous response at a time. Stolen credentials can be rotated. Knowledge extracted from a model cannot.

Five Changes That Shrink the Supply Chain Blast Radius

These changes require alignment across security, engineering, and leadership to implement effectively. Each one is a conversation worth having before the next breach makes it urgent.

1. Minimize the plaintext surface. Limit what any single component can see in usable form. Encrypt data between pipeline stages and isolate credential access so no single layer holds keys to every provider.
2. Audit your build tooling with the same rigor as your production code. Any tool that executes in your pipeline has pipeline-level access to credentials and secrets. Security scanners, linters, CI/CD actions: if they run in the build process, they are inside the trust boundary and should be reviewed accordingly.
3. Design for containment, not just prevention. Assume that a component will eventually be compromised and architect your environment so the damage stays contained. Segment execution environments and limit lateral movement between them.
4. Control how fast new dependencies enter your environment. Automatically pulling the latest version of a package the moment it’s published is how 119,000 systems installed a backdoored LiteLLM in three hours. Pin versions, verify checksums, and build in a delay before adopting new releases. Pip v26.1, shipping this month, introduces exactly this kind of cooldown mechanism.
5. Protect data before it enters training. Encrypted, access-controlled training pipelines ensure that even if a model is exposed, the most sensitive material was never readable in the first place. You can’t extract what was never learned in the clear.

What We Told Our Customers

We were at the RSA Conference in San Francisco when the LiteLLM incident broke. Customers and prospects visiting our booth were already asking about it. Our first step was confirming whether any of our customers had exposure to the compromised versions. None did. But the conversations kept going, because the incident raised a more fundamental question: what would have happened if they had?

For our customers, the answer was straightforward. DataKrypto’s FHEnom for AI™ means model weights are encrypted, computation runs on ciphertext, keys are isolated, and no plaintext model or data exists in memory at any point. Someone may have gotten into your house, but your model is safe. It can’t be stolen. Most approaches try to restrict access to data. FHEnom removes the existence of usable data entirely.

We were honest about what remained at risk: compromised credentials could still allow API misuse, resource consumption, and behavioral probing. Credential rotation was still necessary.

But the core distinction matters. In a traditional AI stack, a breach of this kind means model theft, data theft, and access abuse. With DataKrypto, it means access abuse only. That’s a fundamentally different blast radius.

For prospects, the conversation was different. Most couldn’t give the same answer about their own environments.

The Bottom Line

Breaches are not edge cases. They are part of the system. The LiteLLM incident proved that every dependency in your AI pipeline shares the same trust boundary as the data flowing through it. The question isn’t whether that boundary will be broken. It’s what’s exposed when it is.

The only viable strategy is to make the data worthless to anyone who reaches it. If your AI ever exposes plaintext during execution, your architecture is already broken.