In April 2025, security researchers gave a name to a threat that had already been quietly working: "slopsquatting," the practice of registering the fake package names that AI coding assistants routinely hallucinate. It's a small term for a large problem. Agentic AI now writes, tests, and merges code faster than any human reviewer can keep up with, and it does so by trusting package names it generates itself — names that sometimes don't exist until an attacker claims them. Sonatype, the company behind Nexus Repository and over a decade of open-source supply chain research, recently published a guide on securing agentic AI development, effectively admitting that scanning code after a human commits it no longer covers how software actually gets built anymore. This post walks through what that guide gets right, where it falls short for teams running autonomous coding agents in real pipelines, and what an agentic development security tool needs to do that traditional software composition analysis was never designed for.
What Is Agentic AI Development, and Why Does It Break Traditional AppSec?
Agentic AI development is the practice of letting AI agents autonomously write, execute, and commit code with minimal human review in the loop, and it breaks traditional AppSec because those tools were built to check work after a person did it — not to govern an actor that installs its own dependencies, runs its own shell commands, and opens its own pull requests. Tools like Claude Code, Cursor's agent mode, GitHub Copilot Workspace, and Devin can now go from a one-line prompt to a merged feature branch touching dozens of files in a single session. A human engineer adding a new npm package used to trigger, at minimum, a pause to read the README. An agent evaluating the same decision does it in milliseconds, based on pattern-matching against training data, and it will happily run pip install or npm install on a package name it half-remembers or invents outright. Traditional SCA tools scan a manifest file after the fact. They were never built to sit between an agent's decision and the moment that decision executes.
The result is a compressed blast radius. What used to take a sprint — someone proposing a dependency, a teammate reviewing it, CI catching an obvious problem — now happens in the time it takes an agent to finish a task. Sonatype's own 2024 State of the Software Supply Chain report, its tenth annual edition, found that it identified over 512,000 malicious open-source packages that year, a 156% jump from 2023. That number reflects human-speed attacks against human-speed adoption. Agentic development multiplies both the attack surface and the speed at which a bad package gets pulled into a codebase, which is exactly why a category built specifically around governing agent behavior — not just scanning its output — has become necessary.
What Does Sonatype's Guide Get Right About Securing Agentic AI?
Sonatype's guide correctly reframes the problem around provenance and continuous policy rather than a one-time approval gate, and that's the right instinct. The guide pushes teams to verify where a component actually came from before an agent (or a human) pulls it in, to maintain a live software bill of materials rather than a point-in-time snapshot, and to treat AI-introduced dependencies as a distinct risk category worth tracking separately from human-introduced ones. That last point matters more than it sounds: if you can't tell which dependencies an agent added versus which ones a person chose, you can't audit agent behavior at all, and you certainly can't answer a customer's security questionnaire or a SOC 2 auditor's question about how AI-generated code enters production.
The guide also acknowledges — correctly — that policy needs to run continuously, not just at merge time, because agentic pipelines can reintroduce a flagged package in a later session even after a human removed it once. That's a real failure mode teams are already hitting: an agent re-adds a dependency it "remembers" from an earlier attempt, unaware a teammate deliberately pulled it out for a licensing or CVE reason two days earlier.
Where Does Sonatype's Approach Fall Short for Agentic Workflows?
Sonatype's approach falls short because its enforcement model is still built around Nexus Lifecycle and Nexus Repository — tools designed to gate what a human pulls through a managed repository proxy, not what an autonomous agent installs directly from a terminal, a container, or a Model Context Protocol tool call that never touches the repository manager at all. Agentic coding tools frequently shell out directly (npm install express-validator, curl | bash, a Python subprocess call) or reach through an MCP server to fetch code, data, or another tool's output. None of that traffic necessarily flows through a Nexus proxy where a policy engine built for human developer workflows can intercept it.
There's also a governance gap around the agent itself. Sonatype's guide talks about the components an agent introduces, but it doesn't provide the agent-identity layer needed to answer basic questions: which agent, running under which credentials, took which action, in which session, and did a human approve it? As of mid-2025, MCP servers — the connectors agents use to reach databases, internal APIs, and third-party tools — have already been shown to be spoofable, and several malicious MCP packages have been published to npm and PyPI posing as legitimate integrations. A guide focused on component scanning doesn't cover that surface, because it isn't a component in the traditional dependency-tree sense — it's a live, permissioned actor a scanner never sees.
How Many AI-Generated Dependencies Are Hallucinated or Malicious?
A meaningful share of them, and the numbers are large enough that "hallucinated package" has become its own research category. A 2025 study out of the University of Texas at San Antonio, which analyzed roughly 576,000 code samples generated by 16 popular LLMs, found that commercial models hallucinated non-existent package names in 19.7% of outputs and open-source models did so in 21.7% of outputs. Across that dataset, researchers catalogued over 205,000 unique hallucinated package names — and critically, many of those names repeated consistently across runs and models, meaning an attacker doesn't need to guess: they can query the same models researchers did, find the predictable hallucination, register the package on npm or PyPI, and wait for an agent to install it into someone's production build.
Layer that against Sonatype's malicious-package numbers — 512,000-plus identified in 2024 alone — and the exposure compounds. Every hallucinated name is a candidate for slopsquatting; every agent session that runs unattended is a chance for one of those names to get installed before anyone reviews it. This isn't hypothetical: security researchers demonstrated working slopsquatting proof-of-concepts against multiple coding assistants within weeks of the term being coined in April 2025, confirming the gap between "AI suggested this" and "a human verified this" is already being actively exploited.
What Should an Agentic Development Security Tool Actually Do?
An agentic development security tool should enforce policy at the moment an agent takes an action, not after the fact, and treat every agent as an identity with scoped, auditable permissions rather than an extension of whatever credentials a human happened to have open. Concretely, that means five things a component scanner alone doesn't do:
- Real-time provenance checks before install. When an agent runs a package install command, the tool needs to verify the package's source, maintainer history, and publish date against known-good signals before the install completes — not flag it in a dashboard the next morning.
- Agent identity and permission scoping. Every autonomous session should run under a distinct, revocable identity with its own least-privilege scope, so a compromised or misbehaving agent session can be killed without cutting off a human developer's access too.
- MCP and tool-call vetting. Since agents increasingly reach the world through MCP servers rather than direct package managers, the tool needs visibility into what those servers do, not just what's listed in package.json.
- Immutable, per-session audit trails. Every dependency an agent adds, every command it runs, and every file it touches needs to be logged and attributable to that specific session — the artifact a SOC 2 auditor or an incident responder actually needs six months later.
- Human-in-the-loop gates for high-risk actions. A new dependency, a new outbound network call, a new credential use — these should pause for approval by default in agentic pipelines, with the threshold configurable per team rather than fixed by the tool vendor.
None of this replaces traditional SCA — CVE scanning and license compliance still matter. But it's a different layer, sitting closer to execution than to the repository manager.
How Safeguard Helps
Safeguard was built for exactly this gap: securing the software supply chain at the point where AI agents actually act, not just at the point where a human commits code. Instead of bolting agent awareness onto a scanner designed for manual pull requests, Safeguard treats every agentic session as a first-class, tenant-scoped identity — one with its own credentials, its own permission boundaries, and its own complete audit trail from first prompt to final commit.
In practice, that means Safeguard evaluates a dependency the moment an agent tries to install it, checking provenance, maintainer reputation, and known-malicious or hallucination-prone patterns before the package ever lands in a working tree, rather than surfacing the problem in a nightly report after it's already merged. Every MCP server and external tool call an agent makes is visible and policy-checked, so a spoofed or malicious connector doesn't get an automatic pass just because it wasn't a line item in a manifest file. Safeguard generates a live SBOM that distinguishes AI-introduced components from human-introduced ones, which turns "did an agent add this?" from a forensic question into a filter. And because every agent action is logged immutably and mapped to a specific session and identity, security teams get the audit trail SOC 2 and customer security reviews actually require — attributable, timestamped, and impossible to quietly overwrite.
For teams that have already adopted agentic coding tools — or are about to — the choice isn't whether to add a governance layer, it's whether to add one built for how agents actually operate. Safeguard is that layer: enforcement at the point of action, identity for every agent, and provenance verification that runs in real time instead of catching up after the fact.