Lights Out, part 2: old school stays king | Dibran's Blog

3 622 words

Share ↗

Lights Out, part 2: old school stays king<br>On 26 August 2025, someone pushed eight malicious versions of Nx to npm. Nx is a build tool with millions of weekly downloads. The packages were live for five hours and twenty minutes.

The malware did something new. Buried in a postinstall script was this:

const cliChecks = {<br>claude: { cmd: 'claude', args: ['--dangerously-skip-permissions', '-p', PROMPT] },<br>gemini: { cmd: 'gemini', args: ['--yolo', '-p', PROMPT] },<br>q: { cmd: 'q', args: ['chat', '--trust-all-tools', '--no-interactive', PROMPT] }<br>};

The attacker checked whether you had a coding agent installed, and if you did, asked it politely to walk your filesystem and inventory your SSH keys, your .env files and your crypto wallets. The agent complied. Results went to /tmp/inventory.txt, then to a public GitHub repository created under your own account using your own token.

Final tally: 2,349 distinct secrets harvested from 1,079 developer machines. GitHub tokens, npm tokens, AWS keys, Postgres credentials, Anthropic and OpenAI keys. Snyk called it likely the first documented case of malware weaponising AI assistant CLIs for reconnaissance and exfiltration. As a closing insult, it appended sudo shutdown -h 0 to .bashrc and .zshrc, so every new shell died on arrival.

There is a detail in that code that should keep engineering leaders awake, and it is not the malware. It is the confidence.

The attacker did not write code to disable your agent’s guardrails. They did not need to. They passed the bypass flag and assumed it would just work . They were building a mass-market payload, so that assumption had to hold across a thousand random developer machines to be worth writing.

It held.

Nobody has a real number, and that is the point<br>I went looking for hard data on how many developers habitually run --dangerously-skip-permissions, --yolo or --trust-all-tools. There is none worth citing. A few blogs quote survey figures with no traceable methodology, so ignore them and ignore me if I repeat them.

But look at the indirect evidence, which is stronger than a survey anyway.

Attackers built a mass payload on the assumption. Anthropic shipped an intermediate “auto” mode in 2026, which is not something you build unless the all-or-nothing choice was being resolved the wrong way at scale. And every serious practitioner guide on the subject converged on the same one-line answer: only in a container.

I want to be precise here, because this is where most governance conversations go stupid. The flag is not the problem. I use it. It is genuinely useful. Approving 200 tool calls individually is not diligence, it is theatre, and after the fortieth prompt you are not reading them anyway. Permission fatigue is real and clicking “allow” while thinking about lunch is worse than not being asked.

The problem is what the flag is pointed at.

Running an unsupervised agent inside a disposable container with scoped, short-lived credentials is a reasonable engineering decision. Running the identical command on a laptop that holds your SSH keys, a live az login session, a ~/.aws/credentials file and a .env with the production connection string is not a decision at all. It is an outcome you have not thought about yet.

Same flag. Two completely different companies.

Your developers’ laptops are your production perimeter<br>Here is the mental shift I keep asking leadership teams to make, and it is uncomfortable because it costs money.

Assume breach. Not as a slogan on a strategy slide. As an operating assumption about the machines your engineers work on. An agent running on a developer laptop acts with that developer’s identity, that developer’s tokens and that developer’s network position. When it acts, it is acting on behalf of your organisation. It will read hostile content, because reading things is its job: dependency READMEs, issue comments, pull request descriptions, web pages, error messages from third party APIs. Any of those can carry instructions.

Simon Willison’s framing is the most useful thing a leader can carry into this conversation. He calls it the lethal trifecta : access to private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three can be turned into an exfiltration tool by a single injected prompt. The poisoned content steers it, it reads your secrets, it sends them out.

The lethal trifecta. Diagram by Simon Willison, used with credit.

Meta turned that into an actual decision rule, the Agents Rule of Two : an agent operating without human approval gets two of those three properties. If it needs all three, a human is in the loop. That is a rule you can put in a policy document and hold people to, which is more than can be said for most AI governance I read.

And now the part that should end the “our developers are sensible” objection.

Replit, and the sentence that reframes...