Gareth MorgansSecurity
Your AI tools are part of your software supply chain
Software supply chain security used to mean the code you ship and the packages you pull in. Now it also means your AI tools. Agent platforms, MCP servers and skills hold real credentials and run real code. Each one is a dependency you did not write.
LiteLLM learned this the hard way in October. Its own root-cause write-up is honest, detailed and worth reading in full. Here is what it tells the rest of us.
Start free beta · Secrets vault
Related: secrets sprawl in AI teams · agent credentials without pasting keys · non-human identity for AI agents
What happened to LiteLLM
The chain started with one key. On 27 May 2026, a config file was committed to a public LiteLLM repository. It contained an administrative key for an internal deployment of the LiteLLM Agent Platform.
The team spotted the mistake. About three hours later, a follow-up commit deleted the file. The key was marked for revocation. Nobody followed through. The original commit stayed in public history until 22 October, and the key stayed valid for more than four months.
On 10 October, an attacker used that key to call the Agent Platform API. One request returned the configuration of every managed agent. Inside it sat a GitHub CLI token belonging to an organisation owner. It was not a token scoped to a few repositories. It carried owner rights.
The attacker then pushed throwaway branches to LiteLLM's own repositories. Their workflows posted CI secrets to an outside endpoint, and the runs were deleted minutes later. Those secrets included GitHub CLI tokens for two more maintainers.
On 21 October, the attacker changed the release workflow to build from a lookalike fork. Release approvals normally needed a special account tied to a physical device in LiteLLM's office. That rule had been relaxed that week to allow faster releases, so two stolen tokens were enough: one to trigger, one to approve.
A poisoned litellm==1.107.0 reached PyPI at about 11:40 UTC (12:40 UK time), with container images following minutes later. Security researcher LidorMachluf (Lidor Machluf of Upwind Security) caught it within about 20 minutes and opened a public issue. PyPI quarantined the release by 13:23 UTC (14:23 UK time). The compromised artefacts were live for about two hours.
Source: LiteLLM's root-cause analysis, 23 October 2026.
Why AI tools widen the supply chain
Classic supply chain thinking covers libraries, build systems and registries. That still matters. LiteLLM's release was poisoned through exactly that route.
But look at where the first foothold came from. Not a library. An agent platform, holding a token so it could open pull requests on a team's behalf.
That is the pattern now. AI tools are given credentials so they can do useful work. An agent needs a GitHub token to file a PR. A skill needs an API key to call a service. An MCP server needs access to the system it connects to. Each tool becomes a place where credentials gather, and each one is software someone else wrote.
So software supply chain security for AI teams has two halves. What your tools run. And what your tools hold.
Most teams already review a new library before adding it. Fewer review a new agent, skill or MCP server the same way, even though it may hold more access than any library ever did. Closing that gap is most of the job.
Where credentials leak in an agent setup
Four places come up again and again.
Config files in repositories. LiteLLM's key arrived in a committed config file. Deleting the file later did not undo the exposure.
CI secrets readable by any workflow. Anyone who can push a workflow can usually read the secrets that repository exposes. That is the honest answer to whether GitHub Actions secrets are safe from a compromised workflow: they are only as safe as the identities allowed to push.
Agent APIs that hand tokens back. The owner's token came out of an ordinary API call that listed agent configurations. If a platform can return a stored credential in plain text, anyone holding the right key can take it.
Local tool configs. Microsoft's analysis of the poisoned release found the payload ran when Python started, even if LiteLLM was never imported. It targeted authentication and config files for AI assistants, IDEs, GitHub Copilot, VS Code and MCP integrations, alongside cloud, SSH and browser credentials.
Source: Microsoft Security blog, 23 October 2026.
Your AI tools' config folders are now a target in their own right. Treat them that way.
For more on how agent credentials pile up, read secrets sprawl in AI teams.
Software supply chain security checklist for AI teams
None of this needs a new platform. It needs habits.
Revoke, don't just delete. A key that touched a public commit is exposed. Removing the file is not enough. Revoke it, then issue a new one.
Scope every token. Give tools their own service accounts with the narrowest rights that work. Never wire a personal owner token into an agent.
Keep releases hardware-gated. If a release needs a physical key or a locked device, keep it that way. Relaxing it "just for this week" is exactly when it counts.
Pin versions. Use hash-pinned lock files and image digests rather than floating tags. Microsoft recommends both.
Review third-party skills and MCP servers. Read what a skill does and what an MCP server can reach before your team relies on it.
Keep one approved list. One place that says which tools, skills and MCPs the team uses. If it is not on the list, it is not in use.
If you were exposed to 1.107.0, Microsoft's advice is to rotate reachable credentials from a known-clean machine and restrict outbound access from developer and build machines. Our MCP security best practices cover the MCP side in more depth.
How Joyst fits
Joyst is not a CI secret store, and it would not have stopped this attack. It is a shared workspace for the AI side of the stack. Two parts of the checklist live there.
Credentials for AI work. Secrets are stored in a vault and referenced by name. Values cannot be read back. To rotate one, you overwrite it. Substitution happens only on outbound HTTP requests, in the headers or body, and the call returns status and body only, never the secret value. So a stored credential is not handed back in a configuration listing the way the LiteLLM token was. Read more on secrets management for AI agents and agent credentials without pasting keys.
One approved list. Imported skills land as private drafts for review before anyone shares them. See version and share skills. Approved MCP servers sit in the team's MCP catalogue, so everyone works from the same list.
Tokens still need scoping. Releases still need gates. Joyst gives the AI tools a tidy home. The discipline is still yours.
Good software supply chain security is mostly unglamorous: fewer copies of each key, narrower rights and one list everyone trusts.
FAQ
What is software supply chain security?
Software supply chain security is the work of protecting everything your software depends on: packages, build systems, release pipelines and, now, the AI tools and agents that hold credentials and run code for your team.
How was LiteLLM 1.107.0 compromised?
An admin key for an internal agent platform was committed publicly in May and never revoked. In October an attacker used it to pull an organisation owner's GitHub token, stole more tokens through CI workflows, repointed the release workflow at a fork and published litellm==1.107.0 to PyPI on 21 October.
Are GitHub Actions secrets safe from a compromised workflow?
Not fully. A workflow that someone can push can usually read the secrets its repository exposes. Limit who can push workflows, scope each secret tightly and revoke anything a rogue run might have touched.
Should AI agent platforms be able to read back API keys?
We think not. If a platform can return a stored key, anyone who gets the right access can take it. A safer design stores keys by name and uses them only when making a call, without ever handing the value back.