On October 8, a compromised release of the tensorlake npm package did something that should change how teams think about agent configuration. According to the GitHub security advisory, a preinstall script went looking specifically for AI tool configs and MCP settings, the files where developers now keep their most powerful tokens. It shipped with valid npm provenance. And it set a dead-man's switch: a monitor that wiped the developer's home directory if the stolen GitHub token was revoked before the monitor itself was removed. It also wrote agent config files into repositories, so it would run again the next time someone opened the project.
Read the target selection again. The malware did not grep for .env and cloud credential files, or not only those. It went for ~/.claude, ~/.cursor and MCP configuration, because that is where the valuable tokens moved. The attackers updated their map of where secrets live. Most security programs have not.
This is the quiet consequence of adopting coding agents: a new class of high-value files landed on every developer's machine, and the supply chain already knows it.
What the tensorlake compromise did
The sequence, from the advisory, is worth laying out because each step generalizes.
A preinstall hook ran on install, before any human looked at what the package did. It harvested AI tool and MCP configuration files. It installed a monitor keyed to the stolen GitHub token: if the token was revoked while the monitor still ran, it destroyed the developer's home directory, turning the obvious incident-response step into a trap. It wrote agent configuration into repositories so the payload would re-execute later. And it did all of this while carrying valid provenance, live for under two hours before it was caught.
Under two hours is enough. An install that fires in a single CI run or a single developer's npm install does not need a long window.
Why .claude, .cursor and MCP configs are the new .env
For years the credential hygiene advice centered on .env files and cloud credential paths. Agent adoption added a new set of files that are just as valuable and far less guarded.
Agent configuration holds tokens with broad scope, because that is what makes an agent useful: access to repositories, cloud APIs, internal services, MCP servers that themselves hold credentials. And unlike a static .env, these files are read-write in normal use. Agents edit their own settings, define tasks, register hooks and install MCP servers. A file the agent writes to during ordinary work is a file a malicious instruction or package can write to as well. The config is both a credential store and an execution surface, which is a worse combination than .env ever was.
Provenance proves where a package was built, not what it does
The uncomfortable detail is that tensorlake carried valid npm provenance. Teams have been told, correctly, to prefer signed and attested packages. That advice is not wrong. It is just answering a different question.
Provenance proves that a package was built where it claims to have been built, from the source it claims. It says nothing about what the code does when it runs. A legitimately built package from a compromised account, or a maintainer who turned, produces a perfectly attested artifact that still runs a malicious preinstall hook. Supply-chain signing raises the floor. It does not remove the need for runtime controls on what an install is allowed to read and reach.
Revocation order matters now
The dead-man's switch introduces a wrinkle into incident response that most runbooks do not account for. The instinct, on learning a token is stolen, is to revoke it immediately. Against this malware, revoking first is what triggers the destruction.
So the order inverts: remove the persistence first, then revoke. Find and kill the monitor, confirm the payload can no longer re-execute from a repository-written config, and only then rotate the credential. This is a short sidebar in a larger incident process, and it is covered more fully in the incident-response runbook for agent sessions. The point here is narrower: once malware can punish revocation, "revoke the key" is no longer automatically step one.
Controls that remove the payoff
The way to make this class of attack boring is to remove what it is reaching for.
If the agent's configuration holds no credentials, because secrets live outside the agent's process, environment and files entirely, then a script that harvests ~/.claude and ~/.cursor finds references, not keys, and comes away with nothing to replay. If package installs run under egress policy, a preinstall hook that tries to phone home hits a denied destination and a log entry rather than an open network. And if writes to agent configuration are reviewed or blocked rather than silent, a payload cannot quietly plant a repository config that re-runs tomorrow.
None of these depends on catching the malicious package. They assume it got in, and make its presence worthless: nothing to steal, nowhere to send it, no way to persist.
A compromised npm package going straight for AI tool and MCP configs, with valid provenance and a revocation trap, is a preview, not an outlier. Agent configuration is the new high-value target: broad tokens in files the agent itself can write. Signing proves where a package came from, not what it does. The durable answer is to remove the payoff: keep credentials out of anything the agent or its dependencies can read, put installs under egress policy, and stop silent writes to agent config, so the next harvester walks away empty.
This is the supply-chain companion to why secret scanning won't save you from AI agents →.
Marshal keeps credentials out of anything the agent or its dependencies can read, and puts package installs under egress policy. Book a demo →