October's four API key leaks, from a compromised LiteLLM release to a Railway breach

Four ways keys leaked in one month

An API key is a credential that also authorises spending: whoever holds a copy can use an account, and incur its charges, until the owner revokes it. According to a dev.to analysis published on October 28, developers' keys leaked through four separate channels in a single month.

The most elaborate involved LiteLLM 1.107.0, a release of a widely used open-source AI gateway. Per the post, the attacker began with a master key sitting in an agent config file that had been committed to a public repository and never revoked. That key was used against LiteLLM's agent API, which returned a GitHub token; the token pulled repository secrets and sent them to a webhook through CI, and a release workflow was pointed at a lookalike fork. The published wheels, the post says, ran remote code at every Python start, and a stealer component read disks, browsers and cloud metadata before exfiltrating an encrypted archive.

Separately, version 0.5.144 of a Tensorlake npm package carried code that copied developers' keys, used them to spread into their other packages, and planted agent configuration files in repositories. The author notes the payload is mostly encoded, so what is known about it comes from its plain strings.

Third, Railway, a cloud hosting provider, suffered a privilege escalation in its build infrastructure; encrypted variables were pulled and some decrypted, with searches for AI provider key names — a report the post calls preliminary. Fourth, a legacy system behind OpenCode's hosted Console was reached, exposing provider keys users had saved there, although the author found no first-hand statement from OpenCode, only users' issue reports.

Would a local defence have helped?

The post's other half asks whether Cloakroom, a local agent hook that masks secrets, would have changed any of this. The verdict is blunt: no. The author mapped each step of every incident against the tool and found that every actual theft step read disk, a server or CI directly, beyond anything a local hook can observe.

What the tool can affect are upstream copies: a key committed through an agent, or a token passing through tool output into model context and gateway logs. Even the LiteLLM commit step depends on how that commit was made, which the post says LiteLLM never clarified. Neither stealer read agent session transcripts, so keeping secrets out of transcripts would not have altered these thefts either — both took agent credentials straight from disk.

A controlled benchmark

To quantify what it does stop, the author built a repository with eleven dummy secrets in the places stealers typically look: .env files, a gateway config, an MCP config, npm, AWS and SSH files, and a script that prints a GitHub CLI token. Claude Code then ran the same task twice, once plain and once with Cloakroom 0.8.0, after which the model's input, the session transcript and the git history were scanned for the exact values.

Without Cloakroom, all eleven secrets reached the model's input and the transcript, and one — the gateway key — entered git history. With the tool, the count was zero across all three. Cloakroom withheld the script's full output so the token never reached the model, and it refused an attempt to write the gateway key into a setup file, after which the agent substituted a placeholder. The author is candid about limits: placeholders are restored to real values in files an agent writes, transcripts record what was written, and the result comes from one machine, one model and one prompt, though the run script is published for others to repeat.

What shipped alongside

Two features landed in Cloakroom 0.8.0 on PyPI on October 27, the post says. One reports which secrets an agent has seen; the other scans a repository's agent and editor configurations — including .claude/settings.json hooks, .mcp.json and .vscode/tasks.json — for commands that were added or changed, wired to a git hook that runs after checkout and merge. Both report; neither blocks.

Why it matters

October's incidents show attackers aiming at the AI development toolchain itself: the gateway you install, the npm package you depend on, the agent config in your repo, and the provider keys entrusted to hosted consoles. Credentials now live in far more places than a single .env file, and every copy is a target.

The Cloakroom exercise also marks the honest boundary of client-side masking: it shrinks the copies that exist in model context, transcripts and logs, but it cannot see disks, servers or CI. That argues for layered defences — rotation and revocation, short-lived credentials, secret scanning in repositories and CI — rather than trust in any single control. And a public write-up concluding that its own tool would not have stopped the incidents it examines is a rare, useful data point in itself.