TL;DR: A PyPI-distributed LiteLLM package exposed credential-stealing code capable of pulling environment variables, cloud credentials, SSH keys, and other secrets from affected environments, while Kong said its runtime stack was not affected, according to Kong and coverage cited in the article. The incident shows how AI proxy supply chains can become secret exfiltration paths when organisations trust transitive dependencies too broadly.
NHIMG editorial — based on content published by Kong covering the PyPI LiteLLM supply chain attack: Kong Security Update: Kong Is Not Affected by the PyPi-Distributed LiteLLM Supply Chain Attack
By the numbers:
- Any environment that ran pip install litellm==1.82.8 during the approximately 4-hour exposure window could have pulled the compromised dependency.
Questions worth separating out
Q: What breaks when a compromised package can read secrets during installation?
A: The main failure is that package installation becomes an identity event.
Q: Why do AI proxy libraries increase secret exposure risk?
A: AI proxy libraries often sit close to cloud credentials, API keys, and service tokens because they broker traffic between applications and models.
Q: How can teams reduce risk from transitive dependencies in CI/CD pipelines?
A: Teams should pin versions, review indirect dependencies, and require provenance checks before build-time execution.
Practitioner guidance
- Map which build and runtime environments expose secrets during package install Identify every place where pip install, dependency upgrades, or container builds can access cloud credentials, SSH keys, signing material, or API tokens.
- Pin and verify indirect dependencies in AI and API toolchains Lock versions for direct and transitive packages, review release provenance, and block unapproved upgrades in CI/CD.
- Separate AI proxy services from broad credential sets Run AI proxy and gateway components with narrowly scoped identities and minimal secret access.
What's in the full analysis
Kong's full post covers the operational detail this post intentionally leaves for the source:
- The exact LiteLLM versions implicated in the PyPI incident and the installation path that made them dangerous.
- Kong's specific assurance about its own runtime stack and why the company says it was not affected.
- The list of other projects and agent frameworks that reportedly rely on LiteLLM and may need review.
- The recommended reading path for organisations that used pip install litellm==1.82.8 during the exposure window.
👉 Read Kong's security update on the PyPI LiteLLM supply chain attack →
LiteLLM supply chain exposure: what IAM and AI teams need to review?
Explore further
Supply chain trust is now an identity problem, not only a software provenance problem. A malicious package is valuable because it can reach secrets, tokens, and certificates that identity teams assume are protected by perimeter or host controls. When installation-time code runs in a secrets-rich environment, package trust becomes credential trust. Practitioners should treat dependency integrity as part of identity governance, not a separate application hygiene issue.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should investigate if a package install may have been compromised?
A: Security, platform, and identity teams should investigate together. The first question is not only which code was installed, but which credentials were reachable at the time. If tokens, cloud keys, or SSH keys were present, they should be treated as exposed and rotated before the environment returns to service.
👉 Read our full editorial: LiteLLM supply chain exposure shows where AI security boundaries break