AI-generated code often emerges as the villain in conversations about AI and software supply chain security. Hallucinated package names. Slopsquatting attacks. Insecure patterns lifted from training data of unknown provenance. These are real problems, and security researchers are right to name them.
But for platform engineers and DevEx leads, that conversation is also a distraction. The governance failure that will actually bite your team isn't about what AI writes. It's about what AI pulls, how fast, and whether your stack can keep up.
Developers make explicit dependency decisions at human speed. They choose a package, consider the version, and pull it with enough friction that a review process can, in theory, keep pace. AI coding assistants don't operate this way. They suggest, scaffold, and resolve dependencies as a background function of doing their job – and they do it with enough confidence that their recommendations land without the friction that would normally prompt a second look.
The result isn't just more dependencies. It's a qualitatively different kind of ingestion: a continuous, high-volume stream of packages entering the environment at a speed and scale that outpaces any review process your team designed before AI tools entered the picture. The governance controls you put in place when developers were the bottleneck now face a different constraint entirely – your ability to evaluate what's coming in before it's already inside.
To be fair, AI tools inherited this problem; they didn't invent it. Developers reached for the latest tag by default for years, grabbing the newest version on the logic that newer releases patch known CVEs, so newer meant safer. It was a reasonable shortcut that quietly traded reproducibility and stability for the assumption that upstream maintainers had things under control. Teams tolerated it because the pace of ingestion was slow enough that the risk felt abstract. What AI coding assistants do is adopt that same default behavior and execute it at a scale no human developer could match – across multiple ecosystems, for every file in a scaffold, without the occasional pause that made a developer reconsider. The mental model was already loose. AI just removed the friction that kept the consequences manageable.
The evidence is specific. An academic study found that nearly 20% of packages recommended by large language models didn't exist in any public registry. More troubling: 43% of those hallucinated packages appeared repeatedly across multiple prompts. This is a pattern predictable enough that a malicious actor could register those packages in advance and wait for a developer to pull. This is the slopsquatting attack surface, and it expands in direct proportion to AI adoption.
The signal from the field matches the research. One engineering team, already running their artifact repository significantly beyond its designed capacity, named AI-driven dependency explosion as the risk they were actively trying to get ahead of. Not a breach. Not a named vulnerability. The sheer volume of what AI coding tools would pull into their environment as adoption scaled. Their infrastructure had held up under human-speed development. AI-speed ingestion hadn't fully arrived yet – and they were already worried.
That's the right instinct. For teams with meaningful AI coding tool adoption, the governance problem is already compounding.
The failure isn't dramatic and doesn't announce itself with an incident. It accumulates across three specific breakdowns, each one a consequence of governance controls calibrated for a different kind of throughput.
Volume creates an attack surface nobody owns. More packages mean more CVE exposure, more policy exceptions, and more surface area for a malicious or compromised package to hide inside. When dependency ingestion was slow and deliberate, a team could maintain a reasonable mental model of what lived in their environment. AI-assisted development eliminates that. Packages accumulate faster than any manual review can track, and exceptions that were once edge cases become business as usual.
The Endor Labs 2025 State of Dependency Management Report found that only 1 in 5 dependency versions AI coding assistants recommended were safe to use – containing neither hallucinations nor known vulnerabilities. The reality of the situation is that with AI-generated code, more packages enter your environment than your current controls can evaluate.
Velocity breaks the timing assumptions your controls depend on. Most teams have security controls that activate at the build: scanning that runs after a package enters the environment, policies that evaluate after the pull happens. At human-speed ingestion, the gap between a package entering and a build running was small enough to manage. At AI speed, it isn't. A malicious or compromised package can move from first pull to build artifact before any downstream control flags it. The window that periodic scanning assumed would always exist has closed.
Opacity removes the human review that your policy controls assumed. Governance frameworks rest on an implicit assumption: a developer made a deliberate choice to pull each dependency, and that choice is reviewable and auditable. That assumption doesn't hold with AI coding tools. Ask a developer why version 2.3.1 of a specific package is in their project, and they may have no clear answer – the assistant chose it, they accepted the suggestion, and the reasoning never surfaced. The provenance trail that would normally anchor a trust decision is absent. Policy controls that gate explicit human decisions don't account for the implicit decisions AI tools make on a developer's behalf.
The three failure modes above share a common root: governance controls calibrated for human-speed dependency management running against AI-speed ingestion. The fix isn't better scanning or more thorough reviews. It's a different architecture for enforcement – one that matches the actual throughput of how your team now works.
Three requirements follow directly from the failure modes.
Enforcement has to happen at the point of first pull – not at the build, not post-merge. The moment a package arrives as a request is the only moment you can intercept it before it enters the environment. Every control that activates later operates on a package that's already inside. Quarantine and block capabilities that evaluate against your policies at request time close the gap that build-time scanning leaves open by design.
Re-evaluation has to be continuous, not periodic. Threat intelligence doesn't freeze when your weekly scan finishes. A package that passes on Tuesday may be flagged by Wednesday – because researchers publish a new CVE, because a maintainer account falls to credential stuffing, because a malicious version propagates through transitive dependencies before anyone notices. Continuous re-evaluation against evolving threat intelligence catches what point-in-time scanning cannot.
Coverage has to span all package formats, not just the ones your team uses most. AI coding tools pull across ecosystems without discrimination. A governance layer that covers npm but not PyPI, or Python but not Go, carries a structural gap that AI-assisted development will find. Unified enforcement across all formats – packages, containers, machine learning models – is the only way to apply consistent policy across the full surface area AI actually introduces.
Cloudsmith enforces policy at the point of first pull: when an open source package arrives as a request, it evaluates against your policies before it reaches the developer. Packages that have already cleared your policies deliver immediately; new packages clear checks before delivery. Artifacts in the platform re-evaluate continuously – as new threat intelligence arrives, and when policies change. With support for 30+ package formats in multi-format repositories, that enforcement applies across the full surface area AI-assisted development introduces – not a curated subset of it.
This isn't the argument that Cloudsmith stops AI from writing bad code. Code quality is a separate problem with its own tooling. The argument is more specific: Cloudsmith gives your governance controls the throughput and continuity they need to keep pace with AI-speed development. The controls your team built weren't wrong. They were calibrated for a volume and velocity that no longer reflects how your developers actually work.
The teams already feeling this problem are the ones with the highest AI coding tool adoption. They're a leading indicator, not an outlier. As AI-assisted development becomes the default, dependency ingestion volume scales with it. Governance controls that hold today may not hold next quarter.
The teams that get ahead of this don't run better scans at the build. They move enforcement earlier, automate re-evaluation, and put a platform in place that can handle what AI-speed development actually generates.
If your team has adopted AI coding tools and you haven't yet pressure-tested your artifact governance against the throughput they produce, that's the conversation worth having now.
