AI Gateway

Your AI Gateway Was a Backdoor: What Stolen LLM Credentials Cost After the LiteLLM Breach

September 23, 2026

~ 5 min

On this page
    Cap what a stolen key can cost you
    Book a Demo

    In March 2026, thousands of engineering teams learned the hard way that the most dangerous component in their AI stack was the one they trusted most: their gateway.

    What happened

    A threat actor calling itself TeamPCP compromised the GitHub Actions pipeline of Trivy – a popular open-source vulnerability scanner. Because LiteLLM's own CI/CD pipeline used Trivy, the poisoned scanner ran with legitimate access inside LiteLLM's build environment and silently exfiltrated the project's PyPI publishing tokens. TeamPCP then published two backdoored versions of LiteLLM (1.82.7 and 1.82.8) with malicious code injected directly into the distributed wheels – Trend Micro's analysis walks through the full chain.

    The packages were live for roughly 40 minutes. That was long enough: any CI job or routine upgrade – the responsible thing to do – that resolved LiteLLM in that window pulled the backdoor into production. Once triggered, it harvested credentials, attempted lateral movement across Kubernetes clusters, and installed a persistent systemd backdoor that polled for additional payloads.

    The blast radius: more than 2,500 organizations and roughly 434,000 CI/CD pipelines, according to CloudSEK – reconstructed exposure rather than confirmed compromise in every case, but the response boundary is the same either way. And TeamPCP has since open-sourced the Shai-Hulud worm framework it used, meaning the next actor to run this playbook won't need to build any of it.

    Why a gateway is the worst possible place to be compromised

    An LLM gateway is not just another library. By design, it's a credential concentrator. To do its job, it holds:

    Every provider API key you own. OpenAI, Anthropic, Azure, Bedrock, Vertex – all of them, in one place, because that's the whole point of a gateway.

    Every virtual key you issued. The internal keys your teams, apps, and agents use to reach models all terminate at the gateway. Whoever controls the gateway controls them all.

    A privileged network position. The gateway sees every prompt and every response – customer data, internal documents, source code – in plaintext, before any provider-side protection applies.

    A compromised text editor leaks a file. A compromised gateway leaks your credentials, your data in transit, and your entire AI spend authority – simultaneously.

    The bill you didn't run up

    Here's the part finance discovers before security does: stolen AI credentials are a monetizable asset with a liquid resale market.

    The pattern even has a name – LLMjacking, coined by Sysdig's threat research team when they first caught it in the wild. Attackers who obtain working model-access credentials don't just poke around; they resell access or run their own inference workloads at industrial scale, on your account, against your rate limits, on your invoice. Sysdig put the damage at over $46,000 a day per victim in its first analysis – and closer to $100,000 a day once frontier models are involved. Your first symptom is not an alert – it's a bill.

    And if your gateway's budget enforcement itself is what got compromised, the one control that was supposed to cap the damage is the thing working for the attacker.

    When it stops being a billing problem and becomes a legal one

    Consumption is only half the risk. The other half is what the stolen capacity is used for.

    From every provider's and regulator's point of view, traffic generated with your keys is your traffic. If an attacker uses your compromised account to generate malware, phishing content, disinformation, or outright illegal material, the audit trail points to your organization first. In practice, that means frozen provider accounts mid-quarter, abuse investigations you have to clear yourself, potential exposure under sanctions and export-control regimes if your capacity was resold to prohibited parties, and – under regimes like the EU AI Act, whose high-risk record-keeping obligations took effect in August 2026 – the burden of proving which activity was yours and which wasn't. Without an independent, tamper-evident audit trail, you can't.

    The honest lesson – it's not "open source is bad"

    LiteLLM is a capable project, and open source is not the villain here. The maintainers disclosed quickly, and the official Proxy Docker image was never affected. The lesson is narrower and harder: when you self-host your gateway, you inherit its entire supply chain – and LiteLLM was breached through Trivy, a security tool doing exactly what it was installed to do.

    We've already written up the recurring cost of owning the gateway layer – patching, provider drift, reliability, access control, attribution – as the Gateway Maintenance Tax. This incident adds the line items that only appear after a compromise: forensics across every runner that installed the package, credential rotation far beyond the OpenAI key, the abuse conversation with each provider, and the burden of proving which traffic was yours. None of that appears in the "it's free" calculation. All of it landed on the desks of 2,500 potentially exposed organizations this year.

    For a platform team of one or two engineers running the gateway "on the side," this is not a manageable risk profile. It's a standing bet that nobody targets you before you notice.

    What a proprietary, managed alternative changes

    This is exactly the gap OptScale AI is built to close – a unified platform for efficient and secure AI adoption, with accountability where the open-source model leaves you alone:

    A managed gateway with an accountable supply chain. OptScale AI owns the build pipeline, the dependency auditing, and the patch cadence of the gateway layer – with a vendor contractually on the hook for it, instead of a volunteer maintainer and your own on-call rotation.

    Budget enforcement that actually enforces. Hard caps per key, per team, per agent – enforced at the gateway, not advisory. A stolen key hits its ceiling and stops; a $47,000 weekend becomes a blocked request and an alert.

    Anomaly detection tuned for exactly this failure mode. Token bursts, abnormal consumption patterns, runaway loops, and traffic from registered agents that suddenly stops looking like that agent – flagged live, not discovered on the invoice.

    AI Agent Control. Register the agents you've already built – LangChain, CrewAI, custom code – and OptScale governs them: cost, time, and recursion limits, blocking of unauthorized MCP servers and vector stores, and alerts on insecure operations. OptScale AI doesn't run your agents. It controls them.

    A full, independent audit trail. Every request, every key, every agent action – logged in a system the attacker who owns your cluster doesn't also own. When you need to prove which traffic was yours, you can.

    The 2026 LiteLLM breach won't be the last supply-chain attack on AI infrastructure – the tooling for the next one is already public. The question for every platform team is simple: when it happens again, do you want to be the security team, or do you want to have one?

    Frequently asked questions

    What is LLMjacking?

    LLMjacking is the use of stolen credentials – cloud keys, provider API keys, or gateway virtual keys – to run large language model workloads on someone else's account. Sysdig's threat research team coined the term in 2024. Attackers typically resell the access through a reverse proxy or run their own inference at scale, so the victim pays the bill, absorbs the rate limits, and carries the abuse record. It differs from prompt injection or model poisoning in that the target is not the model's behavior but its meter.

    How did the LiteLLM supply chain attack actually work?

    TeamPCP never targeted LiteLLM directly. It compromised Trivy, an open-source vulnerability scanner, via its GitHub Actions. LiteLLM's CI/CD pipeline ran Trivy automatically, so the poisoned scanner executed inside LiteLLM's build environment and lifted the project's PyPI publishing tokens. Those tokens then published LiteLLM 1.82.7 and 1.82.8 with a credential-stealing payload that ran on interpreter startup, with no import required. One unrevoked token, three tools deep, is what turned a single credential leak into ecosystem-wide exposure.

    How do I know whether we were affected, and what should we do?

    Check whether any host, runner, or image resolved LiteLLM 1.82.7 or 1.82.8 from PyPI on 24 March 2026. The official Proxy Docker image and LiteLLM Cloud were outside the compromised path. If a system did install either version, removing the package is not enough: treat every credential that process could reach – provider keys, cloud IAM, repository tokens, Kubernetes service accounts, SSH, registry logins – as exposed and rotate all of them, check for a systemd persistence unit, and review provider usage for consumption you don't recognize. Cycode published a practical response guide that covers the checklist.

    Can budget caps stop LLMjacking?

    Only if they are enforced on a path the attacker doesn't control. A hard per-key cap at the gateway turns a stolen key into a bounded loss: the key spends to its ceiling and is blocked. But a cap configured inside a gateway whose host has been compromised is a cap the attacker can read, edit, or bypass. The control has to live in a layer that is separately secured, verified to enforce under concurrency, and backed by anomaly detection that flags a token burst before the cap is even reached.

    Are we liable for what attackers generate with our stolen API keys?

    From the provider's side, yes by default: the request carried your credentials, so it is your account's usage and your account's policy violation until you show otherwise. Providers can suspend the account while they investigate, and if the capacity was resold into a sanctioned jurisdiction, export-control exposure follows the key, not the attacker. Under the EU AI Act's record-keeping requirements for high-risk systems, deployers must also be able to produce automatic logs of system use – which is exactly what a compromised host cannot be trusted to provide. An independent audit trail is what lets you separate your traffic from theirs.

    Does a managed gateway eliminate supply-chain risk?

    No – it relocates it to a party that is contractually responsible for it. A managed vendor still has dependencies, a build pipeline, and a patch cadence; the difference is that a named organization owns them, tests them, signs the artifacts, and owes you disclosure and a fix window when something goes wrong. Ask any vendor, OptScale AI included, how artifacts are signed, whether a software bill of materials is available, how dependencies are pinned and audited, and what the disclosure and remediation SLA looks like in writing.

    Put a ceiling on every key

    Route your traffic through a gateway where a stolen key hits its cap and stops – and every request lands in an audit trail you own. Try it on your own keys, or see it in the live demo.