Every software team that has handed its developers AI coding agents has also handed attackers a new entry point — one that bypasses the developer security training organizations have spent years building.

That is the structural reality laid out by Socket’s Brad Arkin in a post published June 23: AI agents are pulling packages into environments that no scanner is watching, resolving dependencies before security teams can see them, and doing so at a scale and speed that human review processes were never designed to match.

The practical consequence is visible across 2026’s supply chain incident record. According to Phoenix Security’s 2026 supply chain report, the first half of 2026 has already produced more than 2.6 times the campaign volume and 4.5 times the package compromise volume of all of 2025 combined — and AI coding agents, as both targets and unwitting delivery mechanisms, are a documented accelerant.

Developer Security Training Cannot Guard an Agentic Workflow

For years, the primary behavioral defense against open-source supply chain attacks has been developer friction: a human engineer pausing to check a package’s download count, verify its maintainer history, or question an unfamiliar name before running npm install. AI coding agents do none of that.

Where a human developer might hesitate at an unfamiliar package name, an agent resolves the dependency and moves on. The agent is doing exactly what it was built to do — reduce friction, maintain momentum, keep the build moving. That efficiency is the attack surface.

Arkin, who deployed Socket at a global enterprise before joining the company as an advisor, described the gap in direct terms: the agent environment is the place “almost nobody has mapped, and it is growing fastest.” Organizations that believe their supply chain posture is strong because their developers follow careful review practices may be exposed through the AI-assisted portion of their workflow in ways that existing audits do not capture.

Attackers Are Engineering Packages Specifically for AI Agents

The clearest evidence that attackers have adapted to this target is the PromptMink campaign, documented by ReversingLabs and attributed to Famous Chollima, a North Korean threat group focused on cryptocurrency and fintech developers.

The campaign, which researchers traced back to at least September 2025, went beyond traditional typosquatting — publishing packages with names that closely mimic popular libraries. PromptMink used a technique ReversingLabs calls “LLM Optimization (LLMO) abuse and knowledge injection”: crafting package README files with language specifically designed to appear authoritative to a large language model resolving dependencies, rather than to a human developer reading documentation.

The bait package, @solana-launchpad/sdk, was paired with a malicious dependency chain that included infostealers capable of credential exfiltration, SSH key deployment for persistent remote access, and data archiving. Over time, the attackers rotated through multiple malicious dependencies and expanded across npm, PyPI, and Rust, pivoting to compiled Rust payloads via NAPI-RS to reduce payload size and complicate detection.

The confirmation that the campaign reached AI agents came in January 2026, when researchers found a legitimate project developed for the Solana Graveyard Hackathon that had included @solana-launchpad/sdk as a dependency. The repository’s history showed the dependency had been added in a commit co-authored by Claude Opus.

“This transforms the technique from social engineering to a combination of LLM Optimization abuse and knowledge injection,” the ReversingLabs team concluded. “The goal is to make the LLM likely to recommend using the malicious package by making the documentation as believable and as appropriate as possible in the project that the specific LLM coding agent is working on.”

Slopsquatting: When AI Hallucinations Become Attack Vectors

Beyond bait packages crafted to deceive AI agents, a second attack class has emerged that exploits a different AI failure mode: hallucination.

AI coding agents regularly suggest package names that do not exist. USENIX Security 2025 research, testing 16 large language models across 576,000 samples, found that roughly 19.7% of AI-generated package recommendations referenced packages that do not exist in registries — invented by the model based on statistical patterns from training data rather than confirmed by a registry lookup.

Aikido Security researcher Charlie Eriksen coined the resulting attack class “slopsquatting.” Rather than relying on a human developer mistyping a package name — the traditional typosquatting premise — slopsquatting requires only that an AI agent consistently hallucinate a particular name, which the attacker then registers with a malicious payload.

What makes slopsquatting structurally dangerous is the predictability of AI hallucinations. When researchers re-ran identical prompts ten times each, 43% of hallucinated package names appeared on every single run. An attacker needs only to run a few dozen prompts against a popular model, identify the names that consistently recur, and register them before anyone else does.

In January 2026, Eriksen registered an npm package called react-codeshift — a name that doesn’t exist but that a language model had generated by conflating two real tools, jscodeshift and react-codemod. Before he could defensively claim the name, the hallucinated reference had already spread to 237 GitHub repositories via AI-generated agent skill files, and daily download attempts from autonomous agents were recorded immediately after registration.

“This was a hallucination,” Eriksen said. “It spread to 237 repositories. It generated real download attempts. The only reason it didn’t become an attack vector is because I got there first.”

The traditional protection against typosquatting — npm’s collision detection for names similar to existing packages — provides no defense against slopsquatting. Hallucinated names are brand-new strings with no collision to detect.

Clinejection: How One GitHub Issue Became a Supply Chain Attack on 5 Million Developers

The Clinejection incident, disclosed in February 2026, illustrated how AI agents integrated into CI/CD pipelines multiply the risk beyond individual developer machines.

On February 9, 2026, security researcher Adnan Khan disclosed a vulnerability chain in the Cline AI coding tool’s GitHub repository. Cline had added an AI-powered issue triage workflow in December 2025 that used Anthropic’s claude-code-action to automatically respond to GitHub issues — configured with allowed_non_write_users: “*” (meaning any GitHub user could trigger it) and –allowedTools “Bash,Read,Write,Edit,…” (giving the agent arbitrary code execution on the runner).

An attacker crafting a GitHub issue title with embedded instructions could trick the agent into running npm install from an attacker-controlled commit, executing a malicious preinstall script. From there, a GitHub Actions cache poisoning technique using Cacheract exploited the shared cache scope between low-privilege and high-privilege workflows, allowing the attacker to eventually exfiltrate npm, VS Code Marketplace, and OpenVSX publication credentials from the nightly release pipeline.

Eight days after public disclosure — while one npm token had not been properly revoked during credential rotation — an unknown actor published an unauthorized cline@2.3.0 to npm. The modified version installed OpenClaw, an open-source AI agent with command execution and file system access, on every developer machine that updated during an eight-hour window. Cline has more than five million users.

As Snyk researcher Stephen Thoemmes observed, the attack required no novel technique — only the composition of well-understood vulnerabilities (indirect prompt injection, cache poisoning, credential model weaknesses) into an exploit triggered by a single GitHub issue. The entry point was natural language rather than code.

“A prompt injection scanner won’t catch cache poisoning,” Thoemmes noted. “A CI/CD hardening guide won’t account for natural language being an attack vector.”

What the Postinstall Hook Actually Does — and Why It Matters

Every supply chain attack described above delivers its payload through a structural feature of the npm ecosystem: the postinstall hook.

When a developer or CI/CD pipeline runs npm install, npm automatically executes any postinstall or preinstall scripts defined in a package’s package.json file — before application code runs and before most static analysis or software composition analysis tools can inspect what just arrived. The hook runs with the same filesystem and environment access as the developer process, meaning it reaches API keys, cloud credentials, SSH keys, and CI/CD tokens stored in the local environment.

Running npm install –ignore-scripts blocks this delivery mechanism for most packages. However, the control has documented bypasses, including packages that use native extensions (binding.gyp) to circumvent the flag, and CVE-2025-69263 demonstrated that a malicious .npmrc in a git dependency can override the git binary entirely. Behavioral detection — monitoring what packages actually do at the code level, rather than checking names against CVE databases — is the structural answer. The flag is a partial control.

This is the technical mechanism Socket has built its business around: analyzing the behavior of open-source dependencies before they enter a codebase, rather than waiting for a CVE to surface.

What the CISA Advisory Said About Agents and Package Registries

On May 1, 2026, CISA, the NSA, and their Five Eyes partners — the cybersecurity agencies of Australia, Canada, New Zealand, and the United Kingdom — jointly published “Careful Adoption of Agentic AI Services,” the first coordinated multi-government security guidance specifically addressing agentic AI deployments.

The advisory explicitly confirmed the attack class described in this article: “Poor or deliberately misleading tool descriptions can cause agents to select tools unreliably, with persuasive descriptions chosen more often” — a direct acknowledgment that LLMs can be socially engineered through documentation, precisely the mechanism PromptMink was already exploiting.

The guidance recommended that organizations maintain trusted registries of approved third-party components, restrict AI agents to allow-listed tools and versions, and require human approval before high-impact actions. It characterized prompt injection as the “most persistent and difficult-to-fix threat” to agentic deployments, with no single control sufficient.

The advisory’s framing was deliberately cautious: “Until security practices, evaluation methods and standards mature, organisations should assume that agentic AI systems may behave unexpectedly and plan deployments accordingly, prioritising resilience, reversibility and risk containment over efficiency gains.”

How Do Developers and Teams Protect Themselves?

Security researchers and the CISA/Five Eyes guidance converge on several controls that remain effective even as attackers evolve their techniques.

Treat AI-agent-suggested packages as a distinct review category. Every dependency an AI agent suggests or installs autonomously should be treated as untrusted by default until its publisher, version history, and transitive dependencies are reviewed. This is the same standard developers apply to any new third-party code — the gap is that agent-generated additions often bypass the moment of human review entirely.

Enforce registry policies at the CI/CD level, not only at the developer workstation. Controls applied only where human developers work do not intercept packages introduced by agents operating in CI/CD pipelines or sandbox environments. Socket Firewall, npm’s staged publishing feature (generally available since May 22, 2026), and similar registry-level controls enforce policies regardless of how a dependency was introduced.

Restrict agents to pre-approved dependency lists in sensitive environments. An AI agent that cannot install packages not on an approved allowlist cannot install a malicious package, regardless of what the LLM suggests. The CISA advisory frames this as a human-approval requirement for high-impact actions.

Implement Software Bill of Materials practices. SBOMs make agent-introduced dependencies auditable after the fact. Development teams that cannot see what their agents installed cannot respond to incidents involving those installations.

Use behavioral detection. Traditional software composition analysis tools check dependency names against CVE databases, which publish only after a vulnerability is disclosed. The supply chain attacks that reached TanStack, Mastra, and Cline in 2026 carried no CVE at the time of attack. Behavioral analysis tools — checking what packages actually do rather than what they are named — can flag suspicious behavior before any CVE exists.

The central challenge Arkin identified in his June 23 post remains: code now enters development environments in more places than security teams have mapped. The build pipeline is the easy win. Developer laptops are the quiet gap. Agent environments are the gap growing fastest — and for now, the gap most organizations have not yet treated as part of their attack surface.

Frequently Asked QuestionsDo AI coding tools like GitHub Copilot, Cursor, or Claude Code automatically verify packages before suggesting or installing them?

Most AI coding agents do not perform a live registry lookup to verify that a suggested package exists, is maintained by a known publisher, or has not been flagged for malicious behavior before recommending or installing it. The agent generates package names based on statistical patterns from its training data. Research published at USENIX Security 2025 found that roughly one in five AI-generated package recommendations references a package that does not exist — a rate that attackers can exploit by pre-registering those hallucinated names with malicious payloads. Some tools, such as Claude Code CLI, OpenAI Codex CLI, and Cursor with MCP-backed validation, have begun adding real-time validation steps, but researchers note these controls reduce rather than eliminate the risk.

What is slopsquatting, and how is it different from typosquatting?

Typosquatting relies on a human developer mistyping a package name — registering reqeusts to catch people who mistype requests. Registries like npm defend against this with collision detection that blocks names too similar to existing packages. Slopsquatting bypasses that defense entirely: the attacker does not create a variant of an existing name but instead registers the specific name an AI model has been observed to hallucinate. Because hallucinated names are brand-new strings with no collision, they pass registry filters. And because the same hallucination recurs consistently — 43% of hallucinated package names appeared identically across ten repeated runs of the same prompt in research — an attacker can identify high-probability targets by simply running popular prompts and harvesting the names that keep appearing.

How do I know if an AI agent introduced a malicious package into my codebase?

Review your dependency manifest and lockfile for packages added during AI-assisted coding sessions, and cross-reference against a behavioral analysis tool such as Socket, Snyk, or Aikido rather than relying solely on CVE databases. Check for packages with very recent publication dates, unfamiliar maintainers, or download counts inconsistent with their claimed purpose. Also audit CI/CD pipeline logs for npm install or pip install commands executed by agentic workflows rather than human developers — these are the installs most likely to have bypassed human review. The CISA/Five Eyes guidance also recommends reviewing AI agent configuration files (such as CLAUDE.md or .cursorrules) for hidden instructions that could redirect agent behavior.

What did the U.S. government say developers should do about AI agents and supply chain risk?

The May 2026 joint advisory from CISA, the NSA, and the Five Eyes alliance recommends treating AI coding agents as untrusted components by default rather than extensions of trusted developer judgment. Specifically: maintain a trusted registry of pre-approved third-party components and restrict agents to that list; require human approval before any agent takes a high-impact action such as installing a new dependency in a production pipeline; give agents the minimum tool access required for their task rather than broad permissions; and invest in monitoring and logging for all agent interactions, since agentic systems’ decision processes are difficult to inspect after the fact. The advisory explicitly states that organizations should plan for unexpected agent behavior, prioritizing the ability to reverse agent actions over the speed gains agents provide.