DEV Community: Shanjeev Rajendran

What Cloakroom would and wouldn't have done in October's incidents

Shanjeev Rajendran — Wed, 28 Oct 2026 01:48:17 +0000

An API key is a password that also pays the bill: hold a copy and you can run up charges on someone else’s account until they revoke it. In October, developers’ keys leaked four different ways in one month.

LiteLLM 1.107.0, a popular AI gateway, shipped an update that copied its users’ keys every time Python started; the attacker got in through a master key that had been committed to a public repo. Tensorlake’s npm package 0.5.144 carried code that copied developers’ keys, used them to spread into their other packages, and planted agent config in repos. Railway, a cloud hosting company, was breached and some stored settings were decrypted. OpenCode’s hosted Console exposed the provider keys users had saved in it. I checked which steps Cloakroom touches.

Step by step

stops means Cloakroom, as shipped, prevents the step. reduces means it removes one copy or one path but not the step. none means it is outside what a local agent hook can see.

Incident, step	Cloakroom
LiteLLM: master key in an agent config file, committed to a public repo, never revoked	reduces (only if the commit went through an agent or Cloakroom's git hook; unknown)
LiteLLM: key used on their agent API, which returned a GitHub token	none
LiteLLM: stolen token sends repo secrets to a webhook through CI	none
LiteLLM: release workflow pointed at a lookalike fork	none
LiteLLM: wheels run remote code at every Python start	none
LiteLLM: stealer reads disk, browsers, cloud metadata	none
LiteLLM: encrypted archive sent out	none
LiteLLM: Claude Code puts a GitHub token in a response body	reduces if it passed through a tool result; none if Claude Code added it to its own API request
Tensorlake: admin account commits the payload	none
Tensorlake: `npm install` runs the payload	reduces (narrow: only if the agent runs the install; it masks output, doesn't block)
Tensorlake: reads credential files and `.env*` files	none
Tensorlake: plants `.claude/settings.json` in repos	none
Tensorlake: republishes the victim's packages	none
Railway: privilege escalation in build infrastructure	none
Railway: encrypted variables pulled, some decrypted	none
Railway: search for AI provider key names	none
OpenCode: legacy system behind Console reached	none
OpenCode: stored provider keys exposed	none

The test

I built a git repo with 11 random dummy secrets in the places the stealers look: a .env, a gateway config file, an MCP config, npm, AWS and SSH files, and a script that prints a gho_ token the way gh auth status --show-token does. Claude Code ran the same task twice, plain and with Cloakroom 0.8.0: read the configs, run the script, write a setup file, commit. Then I scanned the model's input, the local session file and git history for the exact dummy values.

Where	Without Cloakroom	With Cloakroom
What the model was given	11 of 11	0 of 11
Session transcript	11 of 11	0 of 11
Git history	1 of 11 (the gateway key)	0 of 11

The agent's final answer held none in either run. Cloakroom withheld the script's whole output, so the token never reached the model.

Cloakroom refused the agent's write of the gateway key into the setup file. The agent used a placeholder and committed that file alone; the commit check rightly passed it, so it never had a key to stop. Read it as "the key didn't get committed", not as a test of the commit check.

To rerun it (two short runs on your own login): bench/black-october/run.sh

Honest limits

Cloakroom would not have stopped any of the four incidents. Every theft step reads disk, a server or CI directly.
The only steps it touches are upstream copies: a key committed through the agent, and a token passing through tool output into model context and gateway logs. Even the commit step depends on how it was made, which LiteLLM didn't say.
Neither stealer read agent session transcripts, so keeping secrets out of transcripts would not have changed these thefts either. Both took agent credentials straight from disk, which Cloakroom's placeholders never touch.
Placeholders are restored to real values in files the agent writes, by design, and Claude Code's session log records what was written (a known limit in the repo's limits file). In this run the agent wrote no values into the setup file, so that path wasn't exercised. A task that copies a key into a new file would put it back on disk and in the transcript.
The Tensorlake payload is mostly encoded, so what I know about what it reads comes from the plain strings only.
I found no first-hand statement from OpenCode, only users' issues. Railway's report is preliminary.
One machine, one model, one prompt: counts can move a little between runs.

In 0.8.0

Two features shipped today (2026-10-27) in Cloakroom 0.8.0 on PyPI. cloakroom exposure reports which secrets your agents saw. cloakroom scan checks a repo's agent and editor config (.claude/settings.json hooks, .mcp.json, .vscode/tasks.json) for commands that were added or changed, and a git hook runs it after checkout and merge and warns. Both report; neither blocks.

The commands are in the README's command reference.

How I keep secrets and personal data out of Claude Code

Shanjeev Rajendran — Thu, 15 Oct 2026 00:39:00 +0000

The problem

Claude Code reads whatever a task touches. Ask it to fix a failing job and it opens the .env, tails the log, greps the support export. Everything it reads goes to the model as context.

But my working folders hold API keys, database passwords, and support tickets with customers' names, emails and home addresses. I didn't want any of that leaving my machine just because Claude needed to look at a file that happened to contain it.

Secret scanners help with keys that have a known shape. They don't help with a customer's name in a ticket, or an address in a log line. To a regex, those look like ordinary text.

So I built Cloakroom: a Claude Code plugin that masks secrets and personal data before the model sees them, and puts the real values back when Claude writes.

What Claude sees

Claude Code lets a plugin run hooks before and after every tool call. Cloakroom sits on those hooks. When Claude reads a file or runs a command, the output goes through Cloakroom first. It looks for:

secrets with a known shape (cloud keys, tokens, private keys, passwords in URLs and config lines)
numbers with a checksum (cards, IBANs, SSNs)
personal data in free text (names, emails, addresses, birth dates), found by a small model that runs locally

Each value it finds is swapped for a placeholder. Here's a support note and a config line, on disk and as Claude gets them:

# on disk
Nadia Petrov called about a double charge. Reach her at nadia.petrov@gmail.com, 18 Larkspur Lane, Charlotte NC.
DATABASE_URL=postgres://admin:Hunter2x9@10.0.4.12/prod

# what Claude sees
PII_PERSON_1 called about a double charge. Reach her at PII_EMAIL_1, PII_ADDRESS_1.
DATABASE_URL=postgres://admin:PII_SECRET_1@10.0.4.12/prod

Claude can still do the job. It knows there's a person, an email and a password, and where each one sits. It just doesn't know the values. A value keeps the same placeholder for the whole session, so PII_PERSON_1 in one file is the same person in the next.

Scans and photos

A lot of personal data lives in pictures: a scanned form, a photo of an ID. Cloakroom can't check pixels, so it reads them instead. A scanned PDF page or a photo that Claude opens goes through OCR on your own machine, and Claude gets the masked text instead of the image. The OCR models ship inside the package, so nothing is uploaded. A photo of a form that says Patient: Nadia Petrov DOB 03/14/1986 reaches Claude as Patient: PII_PERSON_1 DOB PII_DATE_1.

OCR misreads digits, so in that text every long run of them is masked as an account number. Handwriting still reads poorly.

How restore works

Masking alone breaks things. If Claude writes Hi PII_PERSON_1, into a reply draft, that's useless to you.

So the original values go into an encrypted vault for the session, with the key in your OS's secure store (Keychain on macOS, Credential Manager on Windows, Secret Service on Linux). When Claude writes a file or runs a command that contains a placeholder, the hook swaps the real value back in, locally, just before the tool runs. The draft on your disk says Hi Nadia Petrov,. The model never saw the name.

Prompts are different. Claude Code lets a hook block a prompt but not rewrite it, so if you paste a key or an email straight into the chat, Cloakroom stops that prompt and tells you what it found. Put the detail in a file and ask Claude to read it instead, or start the prompt with cr! to send it as is.

Fixing false alarms

A detector that masks too much gets switched off. Mine flagged Order 4471 as an account number, which is harmless and gets in the way.

cloakroom dashboard opens a local page listing every masked call. Label an alert as correct, a false alarm, or something it missed. A false alarm suggests a "never mask this" rule; a miss suggests an "always mask this" one. Approve the rule and that order number reaches Claude as plain text from then on. Rules that would unmask a key, password or card number always wait for your yes, and undo puts everything back.

The detection model itself never changes. Your labels become rules in front of it, encrypted like the vault.

What I learned

Regex isn't enough. Keys are easy. Names, addresses and free-text personal data need a model. I use a small one that runs on your machine. The cost is a one-time download and some false alarms, which is why the labels and rules exist.

Restore is the hard part. Detection gets the attention, but the real work was making write-back reliable: the same placeholder everywhere in a session, the right shape for each tool's input, and edge cases like Claude's Edit tool checking text against the file before any hook runs.

Fail closed. If Cloakroom can't check something (the model still loading, the service down, OCR timing out), tool calls are held back rather than waved through. Prompts fall back to the fast rules, so you're never locked out.

Encoded output counts. A command like base64 .env or xxd turns a secret into something no pattern matches. Cloakroom decodes those dumps and checks them too.

Know what it isn't. Cloakroom stops accidental exposure: the key in a file Claude happened to open, the customer list in a log. It isn't a sandbox, and a model determined to leak data piece by piece is out of scope.

Try it

It's open source, runs locally, needs no account, and works on macOS, Windows and Linux. Inside Claude Code:

/plugin marketplace add shanjeevrajendran/cloakroom
/plugin install cloakroom@cloakroom

It protects keys and card numbers within seconds, then downloads the local model in the background for names and addresses.

I'd like to hear what it misses and what it over-masks: https://github.com/shanjeevrajendran/cloakroom