The AI wave is here. Whether it’s lightweight code completion inside developer integrated development environments to quickly flesh out a function or building entire applications from large prompts using AI-native tools, most development teams now rely on AI to move faster. Productivity gains are undeniable. But as AI accelerates software creation, it is also accelerating the creation of new security risks via AI-assisted coding. And as this becomes the default for many development teams, there is a hidden risk creeping into enterprise software: the dependencies that AI suggests — including packages, libraries, and modules — are often unsafe.
According to Endor Labs’ 2025 State of Dependency Management report, just one in five dependencies proposed by AI coding tools meet safety standards. In other words, 80% introduce risk, whether that’s through known vulnerabilities, non-existent “hallucinated” packages or third-party modules with unclear provenance. This risk compounds another troubling trend: research across academic and industry studies consistently shows that 25–75% of AI-generated code contains security vulnerabilities, depending on the language, dataset, and validation methodology used.
In other words, unsecured output is not an edge case. It’s common. When flawed code combines with unvetted dependencies, development teams face a double exposure: weaknesses in both what is written and what is silently pulled into their applications.
AI-assisted development is a new kind of dependency explosion
AI coding agents are redefining how software gets written. They autocomplete code, suggest dependencies, and scaffold entire modules with a few keystrokes. However, what may initially seem like convenience can quickly become a liability. Endor Labs found that roughly 34% of suggested dependencies didn’t exist at all in public registries — they were hallucinations. Even more alarming: between 44-49% of AI-imported dependency versions had known vulnerabilities.
Unlike traditional development workflows, engineers may not always manually select or review these imports any longer. Dependencies are often added automatically as part of AI-generated templates or code scaffolding. Developers may not discover them until well after the code has been committed, assuming they notice at all. That means security risk accumulates quickly, without the usual friction that prompts review or scrutiny.
Meanwhile, the ecosystem supporting AI-driven development — specifically the growing network of Model Context Protocol (MCP) servers — is still immature. MCP, an open standard introduced in late 2024, allows AI agents to connect to outside tools and data sources in real time.
In theory, MCP represents the furthest possible version of “shift left” for application security: pushing SCA, SAST, and dependency analysis all the way to the moment code is conceived, not after it’s written, committed, or deployed. Instead of scanning finished artifacts, security controls can operate inline as AI agents assemble logic, select libraries, and generate code paths in real time.
But while this model is powerful in concept, today’s MCP ecosystem introduces new supply chain risks of its own. The same mechanisms that allow tools to plug directly into AI-driven development also expand the attack surface, creating fresh trust and provenance questions that organizations must address alongside any shift-left gains.
To understand the scope of this risk, Endor Labs analyzed more than 10,000 GitHub repositories using MCP servers and found:
● 41% lack explicit licensing, limiting compliance visibility and enterprise suitability.
● 82% of MCP servers use sensitive APIs that require careful security controls to avoid vulnerabilities.
● Each MCP server contains an average of one to five vulnerable dependencies, depending on the language it’s written in.
This data shows that AI-driven development is rapidly expanding software supply chains, often without explicit awareness or approval. Each time a developer hits “generate,” new, largely unvetted links may be introduced; ones that security teams never explicitly approved.
Don’t fly blind: Why controls matter more in AI-assisted development
Most application-security and dependency-scanning tools weren’t designed with AI-generated code in mind, but that doesn’t mean they’re irrelevant. The real challenge is when and how they’re used. AI-assisted workflows dramatically increase the speed and volume of code creation, which means security issues must be caught earlier, not downstream after a commit. When developers rely on AI agents without guardrails, insecure patterns, vulnerable dependencies, or poorly understood libraries can be introduced before traditional scanners ever run.
Manifest-based tools and static analysis still work, but only if AI code assistants are prompted to surface dependencies clearly and teams shift existing security checks further left in the development process. Otherwise, issues remain buried in generated code and are only detected late, when fixes are slower, costlier, and more disruptive.
The takeaway isn’t to abandon established security tooling, but to adapt it. Organizations that combine better AI prompting, earlier scanning, and tighter feedback loops can dramatically reduce risk. Those that don’t risk creating blind spots not because their tools are outdated, but because their workflows haven’t evolved to match AI-driven software development.
Securing AI-driven code
AI-assisted programming doesn’t have to become a permanent security liability. But it does demand a shift in how organizations manage dependencies and govern development workflows from reactive scanning to real-time validation.
There is real promise here. In testing, when AI agents were built with generic tools through MCP, the number of safe dependency selections rose dramatically. Nearly 57% of dependency versions were deemed safe when agents used basic validation tools. That’s nearly a three-fold improvement over unguided AI selection. While not a complete solution, this demonstrates that embedded guardrails can dramatically improve outcomes when security is integrated directly into the AI workflow.
To reduce risk while leveraging AI productivity, development teams should focus on four key actions:
● Treat AI-generated code as untrusted third-party code. Apply the same guardrails you would to any external contribution — SAST, SCA, and secrets scanning must run on all AI-generated code prior to merge (better: prior to commit).
● Establish a strong prompt culture. Train developers to create secure, specification-driven prompts that embed organizational standards and dependency-hygiene requirements directly into the instructions they give AI tools.
● Secure the AI software supply chain. Treat MCP servers as a new class of dependency. Maintain allow lists, enforce licensing review, scan MCP tools before adoption, and monitor for typosquatting or impersonation risks.
AI isn’t magic, don’t treat it like so
AI is transforming how software gets built, and that’s a tremendous opportunity. But with great power, comes great responsibility: every suggested dependency and every autopopulated import is a potential entry point for vulnerabilities, supply chain attacks, or compliance failures.
If everyone wants to reap the benefits of AI, we must also embed security, governance, and visibility into the heart of AI-driven workflows. Only then can we ensure that “fast code” doesn’t mean “unsafe code.”
