Your CLAUDE.md Is a Wallet-Stealing Attack Surface

If you run an AI coding agent on the same machine that holds your wallet keys, you have a new attack surface — and it is invisible. In late May 2026, a supply-chain campaign called TrapDoor proved it by hiding malicious instructions inside the most boring file in your repo: CLAUDE.md. This is the hardening guide the security press did not write.

What happened: the TrapDoor campaign (late May 2026)

On May 25, 2026, the threat-research team at Socket disclosed a supply-chain campaign they named TrapDoor: more than 34 malicious packages — hundreds of published versions in total — spread across the three registries developers live in: npm, PyPI, and Crates.io. The packages masqueraded as mundane developer utilities and security tools. Once installed, they swept the machine for secrets: SSH keys, cloud credentials, source-control tokens, browser data, and wallet files.

What made TrapDoor different from the usual credential-stealer was a second, quieter payload aimed squarely at the way we work in 2026: it poisoned AI coding-agent instruction files. Credit where it is due — Socket’s automated scanners caught the first malicious release in under a minute, with a median detection time of about five and a half minutes across the campaign. The defenders were fast. But the technique is now public, and the technique is what should change how you set up your machine.

A note on dates and indicators: reporting placed the first malicious uploads in the May 19–22, 2026 window, with Socket’s public disclosure on May 25. Specific package names and indicators of compromise (IOCs) shift as registries pull artifacts and attackers re-publish. Treat any named package as a moving target — re-check current advisories from Socket and your registry rather than trusting a list that may already be stale. The hardening below does not depend on any single IOC.

How CLAUDE.md poisoning works (without the exploit recipe)

Your AI coding agent reads a project context file — CLAUDE.md for Claude Code, .cursorrules for Cursor, and equivalents in other tools — and treats it as trusted standing instructions. That is the whole point of the file: it tells the agent how your project works so you do not have to repeat yourself.

The trick is that text can carry characters your eyes never see. TrapDoor embedded zero-width Unicode characters — codepoints that render as nothing on screen but still tokenize as real text inside a language model. As Socket put it, these are “invisible characters that occupy no visible space on the page but still flow into a language model’s tokenizer.” A developer opens CLAUDE.md and sees a perfectly normal file. The agent reads a hidden paragraph that says, in effect, “run a routine security scan” — and that “scan” quietly collects and exfiltrates secrets.

That is the elegant, ugly core of it: the human and the machine are reading two different documents. You audit what you can see; the agent obeys what it can tokenize. No memory-corruption bug, no clever zero-day in the runtime — just a trust boundary that most of us never knew we had. We are not publishing a step-by-step recipe here, because you do not need one to defend against it. You need to know it exists and treat agent context like the executable code it effectively is.

Who’s actually targeted: Solana, Sui, and Aptos — be precise

Here is where accuracy matters, because the headlines blur it. TrapDoor’s wallet-stealing logic was chain-specific. One Rust build script (firing during cargo build) searched the local filesystem for Sui and Aptos wallet keystores, encrypted what it found, and shipped it out to public Gists. The broader campaign also targeted Solana developer environments. Across the reporting, the three chains named again and again are Solana, Sui, and Aptos.

What the evidence does not show is direct targeting of Bitcoin Core wallets or hardware-wallet seeds. We are not going to overstate that to scare you — Bitcoiners deserve the real threat model, not a borrowed one. The reason these three chains were in the crosshairs is mundane: their developer tooling commonly leaves plaintext or lightly-protected keystore files on disk inside project and home directories, exactly where a build script or a “helpful” agent can find them. It is an opportunistic harvest of low-hanging fruit, not a Bitcoin-specific operation.

But do not read that as “Bitcoiners are safe.” Read it as the warning shot. The technique is chain-agnostic. The moment your workflow leaves any spendable key on a machine that runs an agent — a Lightning node’s macaroons, a hot wallet’s wallet.dat, an exchange API key with withdrawal rights, an exported xprv — you are in the same blast radius. The attackers went after Solana, Sui, and Aptos because that is where the easy keystores were. Don’t be the easy keystore.

The evergreen lesson: any agent + a box with keys = the risk

Strip away the brand name and TrapDoor is just the first famous instance of a category that is not going away. AI agents are powerful precisely because they read instructions from files and act on them with your permissions, on your machine, against your filesystem and your network. That is also exactly what makes them a delivery vehicle for an attacker’s intent.

This is the same sovereignty principle we keep coming back to: resilience needs backups, and resilience needs boundaries. The internet has a backup in mesh networks; the grid has a backup in your own energy; fiat has a backup in Bitcoin. Your keys deserve a boundary, too. The single most important architectural decision you can make is to ensure that the machine doing untrusted work is not the machine holding your value. Air-gapping is not paranoia — it is just refusing to let one compromise become total loss. If you are running self-hosted AI for the right reasons — owning your compute instead of renting surveilled intelligence — then own its security posture too.

The hardening checklist (the part worth bookmarking)

This is the durable asset. TrapDoor will be patched and forgotten; these habits keep paying off. Work down the list — they compound.

1. Keep your keys off the dev box (do this first)

The machine where you run coding agents, install packages, and clone unknown repos is the last place your spending keys should live. Use a dedicated, ideally air-gapped, signing device or a hardware wallet. Sign transactions there, broadcast from elsewhere. No keystore on disk means nothing for a poisoned agent to steal. Every other item below is damage control for the keys you could not move; this item removes the prize entirely.

2. Scan your context files for invisible Unicode

Treat CLAUDE.md, .cursorrules, AGENTS.md, and any agent-instruction file as untrusted input — especially after you pull from a third party or run npm install. Run a zero-width Unicode scanner over them: a simple check that flags any non-printing codepoint (the U+200B / U+200C family and friends) that has no business being in a Markdown file. Several open-source linters and editor extensions now do this; pick one and wire it into your pre-commit hook so a poisoned file can never slip in silently. If a tool ever struggles to render the file faithfully, that is your tell.

3. Review CLAUDE.md like you review code

Agent-instruction files are executable in every way that matters — they steer a process with your permissions. So they belong in version control, in pull requests, and in code review like everything else. A diff that adds a “security scan” step, a network call, or an instruction to read credential paths should get the same scrutiny as a diff that adds curl | sh. View diffs in a tool that surfaces invisible characters. Never accept agent-context changes from an automated dependency update without reading them.

4. Pin your MCP servers and dependency versions

TrapDoor was a supply-chain attack — it rode in on packages and versions. Pin exact versions (lockfiles, hashes) rather than floating ranges, so an attacker cannot push a poisoned point-release into your build silently. The same goes for MCP servers: pin their versions, audit the ones you connect to your agent, and remove the ones you do not actively use. Every MCP server you wire in is another set of capabilities your agent can be tricked into abusing. Fewer, pinned, audited connections beat a sprawling, auto-updating toolbelt.

5. Sandbox the agent — and cut its network where you can

Run agents and untrusted builds inside a container or VM with the least privilege they can do their job with. Deny outbound network access by default and allow only what a given task genuinely needs; exfiltration is hard when there is nowhere to send the loot. Mount only the directories the task requires — your home directory full of keystores and SSH keys should not be in scope for a code agent at all. Sandboxing does not make you invincible, but it turns “total compromise” into “contained incident.”

6. Separate identities and rotate after exposure

Don’t reuse the SSH key, cloud credential, or API token that touches money on the machine that runs agents. Scope tokens narrowly, prefer short-lived credentials, and disable withdrawal permissions on any exchange API key the dev box can see. If you suspect exposure, assume everything that machine could read is burned: rotate keys and tokens, and move funds with a signer the compromised box never touched.

None of this is exotic. It is the same craftsman’s discipline we bring to firmware and hardware: assume the worst about your tools, verify instead of trust, and build the boundary before you need it. That ethos is exactly why we build open-source security tooling like the DCENT Toolbox — auditable, no telemetry, the kind of software you can read before you run. (It is open-source miner management, not an agent sandbox — but it comes from the same “don’t trust, verify” school.)

Keep your sats off the dev box

If you take one thing from TrapDoor, take this: the developers who lost keys were the ones who left them on the same machine that does risky work. The Solana, Sui, and Aptos crowd got hit this time because their tooling leaves keystores lying around — but the lesson belongs to all of us. The Bitcoiner’s instinct is the right one. Cold storage. Air gaps. Separate machines. Verify your tools. Self-custody was never just about not trusting a bank; it is about not trusting any single point of failure, including your own laptop and the very clever software running on it.

Run your agents. Self-host your AI — that is sovereignty too. Just give your keys their own boundary, and give your context files the same review you give your code. The attackers are betting you won’t. Prove them wrong.

Going deeper: see our broader work on running AI agents and self-hosted intelligence on your own hardware, the case for digital sovereignty and resilience backups, and the practical side of self-hosting AI as a pleb. For where the heat and compute go next, read heating your home with inference and our reality-check on what mining hardware can and cannot do for AI.

Frequently asked questions