PromptMink: Malicious Packages Built to Persuade AI Coding Agents
ReversingLabs reports that the North Korea-linked PromptMink campaign used credible-looking npm and PyPI packages, polished documentation, and rotating malicious dependencies to reach AI-assisted development workflows. One observed crypto trading agent added a malicious package in a commit co-authored by Claude Opus. The defensive lesson is that package selection by an AI coding agent must be governed like a supply-chain decision, not treated as ordinary autocomplete.
The lure was written for humans and models. Detailed README files and convincing task descriptions made the packages look useful to coding agents searching for crypto or validation utilities.
The campaign separated credibility from payload. First-layer bait packages such as @solana-launchpad/sdk looked legitimate, while second-layer packages such as @validate-sdk/v2 carried the infostealer behavior and could be rotated when detected.
The payload kept evolving. ReversingLabs observed obfuscated JavaScript, PyPI variants, bundled Node executables, and Rust-based NAPI add-ons that could steal .env and .json files, exfiltrate projects, and add attacker SSH keys.
The AI-assisted workflow is the entry point. One autonomous crypto trading project added the malicious dependency in a February 28 commit co-authored by Claude Opus. The model did not need to write malware; the agent only needed to accept a plausible dependency.
Hallucinated dependencies make the pattern easier. In slopsquatting, agents invent package names and may later install them once an attacker registers the name.
The control boundary has to move earlier. Defenders need package intelligence before a dependency enters the manifest or lockfile, plus containment while installation runs.
This is the closest preventive control. PromptMink relied on packages that looked useful and credible before the malicious dependency executed. Package reputation, maintainer history, registry age, binary payload analysis, transitive dependency review, and known-malware verdicts should be available inside the coding-agent workflow before the agent can add @solana-launchpad/sdk, @validate-sdk/v2, or a lookalike package to a project.
The observed compromise entered through an AI-assisted dependency change. Static admission gates should treat AI-authored or AI-materially-modified dependency manifests, lockfiles, build scripts, and package imports as higher-risk changes, then fail closed on unapproved packages, suspicious transitive dependencies, hallucinated names, install scripts, bundled binaries, or newly introduced credential-access code.
PromptMink payloads stole environment files, compressed source projects, and added SSH keys after installation or import. Running dependency installation in an ephemeral, restricted environment with no long-lived secrets, no developer home directory, no SSH material, disabled lifecycle scripts by default, and tightly controlled network access reduces the damage even when a malicious package is selected.
The campaign is a direct AI software supply-chain compromise. Dependency security controls should pin versions and hashes, require lockfile review, scan npm and PyPI packages for malware and suspicious binaries, verify source repositories, and block untrusted transient dependencies from entering AI-generated or AI-assisted development pipelines.
Evidence-Bound Promotion & High-Risk Human Approval
High
Adding a new dependency to a crypto trading agent is not a low-risk edit, especially when an AI agent proposed or co-authored it. Promotion should be bound to evidence: the exact package name and version, dependency tree, registry metadata, malware scan result, reviewer identity, and artifact digest. High-risk dependency additions should require named approval before merge or release.
The later PromptMink variants exfiltrated secrets and source projects to attacker infrastructure. Default-deny egress for agent build sandboxes, dependency-install jobs, and test execution makes credential theft and project exfiltration much harder even if malicious code runs.
A coding agent should not have the same autonomy for reading code as it has for adding dependencies, running npx, modifying lockfiles, or executing package install scripts. Classifying package installation, dependency changes, and build-script execution as high-risk actions gives the runtime a policy basis to require approval, restrict tools, or deny the action.
Once a PromptMink package or C2 domain is confirmed, defenders need more than an IOC list. Dependency mapping answers the operational question: which repos, lockfiles, CI caches, containers, notebooks, agents, and developer machines contain it, and therefore need isolation, secret rotation, or log review.
PromptMink did not stop at package installation. Some variants added SSH keys, stole environment files, and left attacker-controlled access paths. Response has to remove malicious packages and lockfile entries, delete unauthorized SSH keys or scheduled persistence, rotate exposed secrets, and inspect project archives or outbound logs for exfiltration.
What Defenders Should Do Now
Search source repos, lockfiles, package manifests, CI caches, developer machines, and artifact registries for PromptMink indicators, including @validate-sdk/v2, @hash-validator/v2, @solana-launchpad/sdk, scraper-npm, and known C2 domains such as validator[.]uno.
Require AI coding agents to check package reputation and malware verdicts before adding any new npm, PyPI, Rust, or GitHub dependency. Do not let an agent install a package solely because the README looks relevant.
Block or review dependency changes generated by agents unless the exact package version, lockfile diff, transitive dependency tree, registry age, maintainer history, and binary contents have been checked.
Run package installs and tests in ephemeral sandboxes with no production secrets, no SSH keys, no writable developer home directory, lifecycle scripts disabled by default, and outbound network access limited to approved registries.
Hunt for post-install behavior: new SSH authorized keys, unexpected project ZIP archives, reads of .env or wallet files, outbound traffic to unfamiliar domains, and large transfers from developer or CI machines.
Turn hallucinated dependency names into a control. If an agent proposes a package that does not already exist in an approved registry or internal allowlist, fail closed and require explicit human review before install.
1 additional consideration
LLM-facing package documentation abuse
Beyond the techniques mapped above, teams should also treat package documentation, READMEs, examples, and registry descriptions as an influence surface for AI coding agents. PromptMink shows that attackers can optimize the words around a package so the agent is more likely to choose it before traditional malware analysis ever runs.
Recommendation: Score package documentation for agent-targeted persuasion signals, unsupported capability claims, unnatural keyword stuffing, fabricated benchmark language, and mismatch between documentation promises and code behavior. Feed those signals into package-vetting and AI-generated-change admission gates.
Conclusion
PromptMink is a clean example of how AI-assisted development changes software supply-chain risk. The attacker does not need to defeat a model directly; it is enough to make a malicious dependency look like the best answer to the agent's coding task. AIDEFEND ↗ maps the defensive baseline clearly: vet packages before selection, gate AI-generated dependency changes, isolate installation, restrict egress, classify package installation as a high-risk agent action, map affected systems, and clean up persistence quickly when a malicious package is found.