In late March 2026, the LiteLLM breach sent shockwaves through the developer community. A supply chain attack on one of the most popular LLM gateway libraries — downloaded over 3.4 million times daily — compromised tens of thousands of developer environments, harvesting OpenAI, Anthropic, and Azure API keys along with cloud credentials. The attack started with a poisoned Trivy security scanner, which then exfiltrated LiteLLM’s PyPI publishing token, allowing attackers to push malicious packages that installed credential stealers and Kubernetes backdoors.
If your organisation is building with AI — and in 2026, most are — this incident is a wake-up call. Your AI stack is now a critical attack surface, and it demands the same rigour you apply to your core infrastructure.
TL;DR
- The LiteLLM supply chain breach in March 2026 exposed API keys and cloud credentials across tens of thousands of developer environments
- Your AI stack — LLM gateways, API keys, prompt pipelines — is now a first-class attack surface that needs dedicated security practices
- Prompt injection remains the number one vulnerability in production AI systems, appearing in over 73% of assessed deployments
- Practical defences include secrets management vaults, output filtering, least-privilege tool access, and AI-specific monitoring
- Shadow AI — unapproved LLM usage across your organisation — is a growing governance risk that most teams are ignoring
The LiteLLM Breach: A Case Study in AI Infrastructure Risk
The LiteLLM attack was not a simple credential leak. It was a sophisticated, multi-stage supply chain compromise that exploited trust relationships between security tools and build pipelines.
Here is what happened: on 19 March, attackers compromised the Trivy GitHub Action — a widely-used security scanning tool — by rewriting Git tags to point to a malicious release. Five days later, when LiteLLM’s CI/CD pipeline ran Trivy as part of its build process, the poisoned scanner exfiltrated the project’s PyPI publishing token. The attackers then published compromised versions of LiteLLM (v1.82.7 and v1.82.8) that contained a three-stage payload: credential harvesting, Kubernetes lateral movement, and a persistent systemd backdoor.
The compromised packages were live for approximately 40 minutes before PyPI quarantined them. In that window, over 40,000 downloads occurred.
The lesson is stark: your AI dependencies are not just libraries. They are privileged components with access to your most sensitive credentials — API keys that grant direct access to paid AI services, cloud metadata, and potentially your entire infrastructure.
API Key Management: Your First Line of Defence
Most AI integrations require API keys for services like OpenAI, Anthropic, Google, or Azure. These keys are effectively cash — each one represents direct access to billable compute. Yet too many teams treat them with less care than a database password.
What good looks like
Use a secrets manager. HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Never store API keys in environment variables on developer machines, in .env files committed to repositories, or hardcoded in configuration. The LiteLLM breach specifically targeted ENV variables — if your keys are there, they are vulnerable.
Rotate keys regularly. Set up automated rotation on a 30-90 day cycle. Most LLM providers support multiple active keys, making zero-downtime rotation straightforward.
Apply least privilege. If your application only needs chat completions, do not use a key with access to fine-tuning, file uploads, and admin endpoints. Scope your keys to exactly what each service requires.
Monitor usage anomalies. Set up billing alerts and usage monitoring. A sudden spike in API calls is often the first sign of a compromised key. Most providers offer usage dashboards — use them, and set threshold alerts.
Separate keys by environment. Development, staging, and production should each have their own keys with appropriate spending limits. A developer’s local key should have aggressive rate limits and spending caps.
Prompt Injection: The SQL Injection of the AI Era
OWASP now ranks prompt injection as the number one vulnerability for LLM applications, and for good reason. It appears in over 73% of production AI deployments assessed during security audits. If you are building AI-powered features, you will encounter this.
Prompt injection occurs when an attacker manipulates an LLM’s behaviour by injecting instructions through user input, retrieved documents, or tool outputs. Unlike traditional injection attacks, there is no simple escaping mechanism — the model processes natural language, and distinguishing between legitimate instructions and malicious ones is fundamentally difficult.
Practical defences
Never trust model output for security decisions. If your AI agent can execute code, call APIs, or access databases, validate every action independently. The model’s “decision” to perform an action should be treated as a suggestion, not an authorisation.
Implement output filtering. Scan model responses for sensitive patterns — API keys, internal URLs, database connection strings, or PII — before they reach the user. This catches both injection attacks and accidental data leakage.
Use structured outputs. Where possible, constrain the model to return structured data (JSON with a defined schema) rather than freeform text. This reduces the attack surface for injection by limiting what the model can express.
Sandbox tool access. If your AI agent uses tools (MCP servers, function calling, code execution), apply the principle of least privilege aggressively. Each tool should have the minimum permissions needed, and high-risk actions should require human approval.
Layer your defences. No single technique stops all prompt injection. Combine system prompt hardening, input validation, output filtering, and monitoring. Defence in depth is as important here as it is anywhere else in security.
Shadow AI: The Governance Gap
Here is a security risk that does not show up in your dependency tree: shadow AI. Developers, marketers, and operations staff across your organisation are using ChatGPT, Claude, Gemini, and other AI tools — often pasting in proprietary code, customer data, internal documents, and credentials.
This is not a hypothetical concern. Multiple security assessments in 2026 have identified shadow AI as one of the fastest-growing data leakage vectors. Employees copy-paste sensitive data into AI tools without understanding the privacy implications, the data retention policies, or whether their inputs are used for model training.
What to do about it
Establish an approved AI toolset. Rather than banning AI (which does not work), provide sanctioned tools with appropriate data handling agreements. Enterprise tiers of most AI providers offer data isolation and no-training guarantees.
Create clear usage policies. Define what data can and cannot be shared with AI tools. Make these policies specific and practical — “do not paste customer PII into ChatGPT” is more actionable than “use AI responsibly”.
Monitor egress. Network-level monitoring can detect when large volumes of text are being sent to AI API endpoints. This is not about surveillance — it is about catching accidental data exposure before it becomes a breach.
Securing Your AI Pipeline End-to-End
If you are running AI in production, your security model needs to account for the entire pipeline — from data ingestion through to model output.
Pin your dependencies. The LiteLLM breach succeeded partly because the project pulled Trivy without version pinning. Lock every dependency in your AI pipeline to specific versions and verify checksums. Use tools like pip-audit or npm audit specifically on your AI-related packages.
Isolate your AI infrastructure. Run LLM gateways and proxy services in isolated network segments. If an AI component is compromised, blast radius containment prevents lateral movement to your core systems.
Audit your RAG pipeline. If you are using Retrieval Augmented Generation, your document ingestion pipeline is an attack surface. Malicious documents can contain prompt injection payloads that activate when retrieved. Sanitise and validate ingested content.
Log everything. Every prompt, every response, every tool call. Not just for debugging — for security forensics. When (not if) something goes wrong, you need the audit trail to understand what happened and what data was exposed.
Test adversarially. Include AI-specific scenarios in your penetration testing. Can your chatbot be tricked into revealing system prompts? Can your AI agent be manipulated into executing unauthorised actions? Red-team your AI features the same way you red-team your APIs.
The Bottom Line
The AI stack is no longer a nice-to-have experiment — it is production infrastructure that handles sensitive data, controls billable resources, and increasingly makes decisions that affect your business. The LiteLLM breach demonstrated that attackers understand this, even if many development teams have not yet caught up.
The good news is that securing AI infrastructure does not require reinventing the wheel. Most of the principles are familiar: least privilege, defence in depth, secrets management, monitoring, and supply chain verification. The challenge is applying them consistently to a rapidly evolving technology stack.
At REPTILEHAUS, we help teams build AI-powered applications with security baked in from day one — from secure API integrations and secrets management to production-hardened AI agent architectures. If your team is deploying AI and wants to make sure it is done right, get in touch.
📷 Photo by Roman Budnikov on Unsplash
