The attack disguises an AI agent configuration change as an ordinary project-file change: a poisoned .cursorrules or CLAUDE.md arrives through a pull request, package, or packaging flow. Client-side configuration enforcement should check these agent configuration files before commit, merge, or packaging, validating their source, structure, policy alignment, remote URLs, hidden characters, and high-risk instructions. That puts the control before TrapDoor enters the repo or release path, instead of waiting until a developer opens an AI assistant.
The package half of TrapDoor relies on 34+ lookalike utilities such as eth-wallet-sentinel, crypto-credential-scanner, and solidity-deploy-guard being pulled into projects. Reputation, maintainer history, registry age, install-script and binary analysis, and known-malware verdicts should run before a developer or agent adds any of these packages - not after postinstall or import-time code has already executed.
TrapDoor hides its instructions in zero-width Unicode so they are invisible in a normal diff. Per-prompt content and obfuscation analysis is built for exactly this: detecting encoding tricks, hidden instructions, and Unicode manipulation in whatever text reaches the model. Flagging or stripping invisible Unicode in a configuration file before the assistant reads it removes the carrier the attack rides on.
Even once a poisoned file is in front of the assistant, inference-time input validation can neutralize it. The control inspects and filters inputs for prompt-injection patterns - instructions to ignore prior commands, character obfuscation, and disguised task switches - and treats the file's contents as data to be sanitized rather than commands to be obeyed, so a hidden "run a security scan and upload" line never becomes an action.
Both halves of the campaign end in exfiltration - credentials to GitHub Pages and Gists, validation calls to AWS and GitHub APIs. Default-deny egress from agent sandboxes, dependency-install jobs, and build steps, with an allowlist limited to required registries, breaks the upload step even when the stealer code or the fake "security scan" runs.
TrapDoor executes at postinstall on npm, at import time on PyPI, and during build.rs compilation on Rust. Running installs and builds in ephemeral sandboxes with lifecycle scripts disabled by default, no developer home directory mounted, no SSH material, and no long-lived secrets contains that automatic execution even when a malicious package is pulled in.
An assistant that reads SSH keys and wallet files, runs a "scan," and makes outbound network calls is performing high-risk actions, whatever the prompt calls them. Classifying secret access, shell execution, and network egress as high-risk - and gating them behind explicit approval - gives the runtime a basis to refuse a "security scan" it was never actually asked to perform.
Once TrapDoor indicators are known, dependency mapping helps turn them into a scoped investigation: which projects or lockfiles reference malicious packages, which repos added .cursorrules or CLAUDE.md, and which CI caches, containers, or developer machines may have touched those artifacts. This is a supporting inventory control: it turns an IOC list into trackable cleanup work rather than detecting or blocking the attack by itself.
Cleanup has to go past uninstalling packages. Responders must remove poisoned instruction files, Git and shell hooks, systemd units, and cron entries, delete attacker SSH keys, rotate every exposed credential, and review outbound logs for what already left.