LiteLLM Supply Chain Attack and the Owner Token | Elacity
The LiteLLM supply chain attack ran on an agent's GitHub token that carried an organisation owner's full power. Why identity-sized credentials fail, and what task-sized ones change.
The LiteLLM Supply Chain Attack Ran on a Token Sized to Its Owner, Not Its Job
The credential you hand an automation is usually a copy of you. The LiteLLM supply chain attack shows what that copy is worth to someone else, and why the fix is smaller authority, not better passwords.
On October 21, LiteLLM's release pipeline published a compromised version 1.107.0 to PyPI and its container registries, where it stayed live for about two hours. Microsoft's analysis found that the package ran through Python's startup hooks, so simply starting Python in an affected environment could launch a collector aimed at credentials across developer tools, cloud accounts and browsers.
How one agent's token became the whole organisation
LiteLLM's own root cause analysis is unusually candid, and the chain starts small. In May, a configuration file holding an administrative key to an internal agent platform was committed to a public repository. It was deleted about three hours later, but nobody followed through on revoking the key, so it was still valid more than four months later.
That platform ran cloud agents whose job was to file pull requests. On October 10 the attacker used the old key to read the platform's API, which returned the configuration of every managed agent. Inside it sat the GitHub CLI token of one of the organisation's two owners. In LiteLLM's words, it "was not a Personal Access Token scoped to the appropriate repositories and capabilities."
Everything after that used real credentials. The owner's token ran workflows that leaked two maintainers' tokens, overrode branch protection to change the release workflow, and pointed the build at a lookalike fork. A second maintainer's token approved the production gate. A third deleted the run records.
Every gate asked who, none asked what for
The safeguards were not missing. Branch protection required a pull request, two passing checks and a codeowner's approval. Publishing normally required an account locked to one laptop kept in LiteLLM's office, a rule relaxed that week so any two engineers could trigger and approve a release for bugfix backports.
Each of those gates checks identity. A stolen identity is still that identity, so every gate opened.
This is the default design of most software, not one team's lapse. GitHub's own documentation says a token has the same capabilities as the person who owns it, further limited by any scopes or permissions granted to it. Authority starts as the whole person and gets trimmed down when someone remembers to trim it.
Security engineers call this ambient authority: power that comes from who you are and follows that identity everywhere it goes. An agent acting with your token inherits all of it, including the parts its job never touches.
What a fair reading concedes
Scoped credentials already exist. The same GitHub page describes fine-grained tokens limited to chosen repositories and permissions, and it also lists the tasks they cannot do yet. Narrow tokens are a real option with real gaps, not a solved problem someone ignored.
LiteLLM draws its own lesson about rotating a potentially exposed key, and it published the full timeline, which is why anyone can learn from it. LiteLLM credits an outside researcher with catching the poisoned release within 20 minutes of publication, and that public report became its channel for status updates. Socket published its own analysis of the compromised package. No design removes human error, and a narrow key that leaks is still a leak.
The harder truth is about scale. Every agent, every token and every rotation is a chore a person must remember, and this incident turned on one chore left undone for more than four months.
The Elacity view: authority sized to the task
Elacity is building the ownership layer for the digital economy, where people turn their data and work into property they control and AI agents pay to use it. Through Elacity dDRM, a work becomes a Wealth Capsule designed to carry its owner's terms. That promise only holds if the software touching those goods starts with no standing power over them.
Beneath it sits the open-source ElastOS runtime, part of the Elastos project founded by Rong Chen, which Elacity helps build in public (https://github.com/Elacity/elastos-runtime). In the ElastOS alpha, an app can't make its own permission: it asks, and the Runtime mints and signs a capability token, then checks it before the app can act. The Runtime also keeps your hosted AI keys in an owner-only store, and ordinary capsules don't get them. Capabilities, not access control lists.
The difference from a scoped token is the direction. A scoped token is a copy of you, made smaller. A capability is designed the other way round: the Runtime mints it for one app, starting from nothing, so the app gets only the access granted to it. A capability can leak too; the design goal is that what leaks is the size of one task, not the size of an owner.
Now the honest edge. Per-app approval in Home is still being built, and so is taking a grant back from a single app. ElastOS is early, and we are not claiming any design makes a leaked credential harmless. The point is where authority starts.
Three questions for any agent you run
- If someone else held this agent's token, what could they do? If the answer is everything you can do, the agent is carrying a copy of you.
- Who owns revoking it, and when was that last done? A deleted file does not revoke the key inside it.
- Does any gate in your pipeline check what an action is for, or only who is asking?
For the idea underneath, read capability-based security explained. For the other way agents leak, through instructions hidden in the text they read, see why the secret was already in the room. More on this cluster lives under Trust & Safety Protocol.
Give the agent a task, not your name
Agents will keep multiplying, and each one will need some power to do its job. Hand it the task, sized to the task, and keep your name for yourself.
Follow Elacity on X for the next piece on how authority should work when software acts for you.