On February 14, 2024, a developer at a mid-size fintech asked GitHub Copilot to "write a function to query the users table by email." The suggestion compiled, passed code review, and shipped: a string-concatenated SQL query with no parameterization. Nobody flagged it, because it looked exactly like the boilerplate a human would type at 4 p.m. on a Friday. That's the quiet risk behind AI pair programming — not that it writes broken code, but that it writes plausible code, fast enough that review habits can't keep up.
This isn't a one-off anecdote. Researchers have spent the last four years running AI coding assistants through the same benchmarks used to grade human developers, and the results are consistent: a meaningful share of AI-suggested code contains the exact vulnerability classes security teams have been fighting for two decades. Below, we walk through what the data actually says, where the risk concentrates, and why "autocomplete anxiety" has become a real line item in AppSec planning for 2026.
How often do AI coding assistants suggest vulnerable code?
Roughly 4 in 10 AI-generated code samples contain an exploitable weakness, based on the two largest independent studies to date. The earliest rigorous measurement came from NYU and Stanford researchers in "Asleep at the Keyboard?" (Pearce et al., 2021), which prompted GitHub Copilot with 89 scenarios spanning MITRE's top 25 CWEs and generated 1,689 programs. Roughly 40% contained a vulnerability that a static analyzer could confirm as exploitable.
That number hasn't moved much with newer models. Veracode's 2025 GenAI Code Security Report tested over 100 large language models across 80 curated coding tasks and found that 45% of the resulting code samples failed to satisfy basic security checks, reintroducing OWASP Top 10-class flaws like cross-site scripting and injection. The report's more uncomfortable finding: model size and release date were not reliably correlated with better security outcomes. A model released in 2025 was not meaningfully safer than one released two years earlier on several vulnerability classes.
Which vulnerabilities show up most often in AI-suggested code?
The same handful of CWEs dominate every study: hardcoded credentials, injection flaws, and weak cryptography. In the Veracode dataset, CWE-798 (use of hardcoded credentials) and CWE-259 (hardcoded passwords) appeared disproportionately often because models trained on public code repositories learned from millions of tutorial snippets where "just hardcode the API key for now" is the norm. Cross-site scripting (CWE-79) and SQL injection (CWE-89) showed almost no improvement across model generations — Veracode found models fixed injection-style flaws correctly less than 55% of the time even in 2025, a number that has been essentially flat since earlier benchmarking rounds. Insecure use of cryptographic primitives (CWE-327), such as suggesting MD5 or ECB-mode AES for "hashing a password," also recurs across nearly every model family tested, likely because those primitives are still common in the training corpus's older StackOverflow answers.
Can AI assistants recommend software packages that don't even exist?
Yes, and this is where autocomplete risk becomes a supply chain problem rather than just a code-quality one. A 2024 academic study, "We Have a Package for You!" (Spracklen et al.), generated over 576,000 code samples across 16 popular LLMs and found that commercial models hallucinated non-existent package names in about 5.2% of samples on average, while open-source models hallucinated at a much higher rate — 21.7% on average, in some cases exceeding that. Across the full dataset, researchers catalogued more than 205,000 unique hallucinated package names, and critically, many of those hallucinations were repeatable: the same fake package name showed up across multiple prompts and even across different models.
That repeatability is what makes "slopsquatting" viable as an attack: an adversary registers the hallucinated package name on npm or PyPI, waits, and lets developers who trust their AI assistant's suggestion pip install or npm install a payload straight into their dependency tree. Because the package name came from an autocomplete suggestion rather than a Google search, it often skips the mental "does this look right?" check a developer would apply to an unfamiliar library.
Does using an AI assistant change how developers behave, not just what code they write?
Yes — developers using AI assistants tend to write less secure code and become more confident that it's secure. A 2023 Stanford study, "Do Users Write More Insecure Code with AI Assistants?" (Perry, Srivastava, et al., presented at CCS 2023), ran a controlled study where participants completed security-relevant programming tasks with and without an AI assistant. Participants who used the assistant were significantly more likely to write SQL injection-vulnerable code and, notably, were more likely to believe their vulnerable code was secure compared to the control group. The false confidence effect is arguably the more dangerous finding: it suggests AI assistants don't just introduce bugs, they suppress the healthy skepticism developers would otherwise apply to unfamiliar code.
Are newer, more capable models actually getting safer?
Not meaningfully, at least not yet. Despite dramatic gains in benchmark reasoning and coding-competition scores between 2023 and 2025, Veracode's longitudinal comparison found no statistically significant security improvement across model generations for several major CWE categories, including XSS and log injection. Some newer models actually regressed on specific tasks, likely because reinforcement-learning fine-tuning optimized for functional correctness and instruction-following rather than for security posture. In practice, this means "just wait for GPT-6 or Claude Opus 6 to fix it" is not a viable security strategy — the vulnerability rate is a property of training data and optimization targets, not raw model capability, and it isn't closing on its own.
Why are security teams calling this "autocomplete anxiety"?
Because AI-assisted development has outpaced the review processes meant to catch its mistakes. Snyk's 2023 AI Code Security Report surveyed developers and found that roughly three-quarters were using AI coding tools regularly, while more than half of organizations had no formal policy governing how those tools should be used or reviewed. A large share of developers admitted to bypassing existing security policies specifically to get an AI suggestion into production faster. The anxiety isn't hypothetical: teams know code is being generated at a volume no manual review process was sized for, they know roughly 4 in 10 suggestions carry latent risk, and they know their existing SAST/SCA tooling was built around human commit cadences, not autocomplete-speed iteration loops.
How Safeguard Helps
Safeguard treats AI-generated code the same way it treats any other unverified input to your software supply chain: nothing merges without a pipeline check that confirms what it actually contains, not what a suggestion claimed it was. That means scanning every commit and pull request — regardless of whether a human or a Copilot-style assistant authored it — for hardcoded secrets, injection patterns, and weak cryptographic primitives before it reaches a protected branch, closing the gap that "looks right" code review misses.
On the supply chain side, Safeguard validates every dependency an AI assistant suggests against real package registries and known-good version histories before it's allowed into a build, directly countering the slopsquatting risk created by hallucinated package names. Combined with automated SBOM generation, this gives security teams a verifiable record of exactly what entered the codebase and where it came from, human-typed or model-generated.
Finally, Safeguard's policy engine lets teams set enforceable gates — block hardcoded credentials, require parameterized queries, flag unverified new dependencies — so that the pace of AI-assisted development doesn't have to come at the cost of the checks that catch what autocomplete gets wrong. The goal isn't to slow developers down; it's to make sure the 40-45% failure rate researchers keep finding in AI-suggested code never becomes your organization's production incident.