SAN FRANCISCO — July 2026. Between April 6 and May 22, 2026, Safeguard's research team surveyed 1,412 developers, application security engineers, and engineering leaders across North America and Europe to answer a question that has been quietly dividing engineering organizations for two years: do the people writing and shipping code actually trust the AI that's helping them write it? The resulting AI Trust Report finds a workforce that has fully adopted AI-assisted development in practice while remaining deeply skeptical of it in principle — a gap that has direct consequences for supply chain security. For many of these teams, the first sign of trouble isn't a headline breach — it's a scanner report that looks clean until someone checks whether the packages in it are real.
The numbers are stark. 91% of respondents said they use an AI coding assistant (Copilot-class autocomplete, chat-based generation, or fully agentic coding tools) at least weekly, and 58% said they use one every working day. Yet only 34% said they "trust" AI-generated code to be secure by default, and just 21% said they trust it to correctly handle third-party dependencies without introducing a package that doesn't exist, is deprecated, or is subtly wrong. This is the trust gap the report is named for: near-universal usage paired with minority-level confidence.
The Headline Numbers
A few data points from the report stand out because they quantify something security teams have suspected but rarely measured directly:
- 63% of developers said they have shipped AI-suggested code to production without fully reviewing it, most often citing time pressure and sprint deadlines.
- 47% of security leaders said they believe their organization has already merged at least one AI-hallucinated or non-existent package reference in the past twelve months — a category of risk now commonly called "slopsquatting," where an AI model confidently suggests a plausible-sounding but fake dependency name that an attacker has pre-registered on a public registry.
- 72% of respondents said AI tools "sometimes" or "often" suggest outdated or vulnerable dependency versions, and 39% said this has directly caused a security finding in a later scan.
- Only 26% of organizations surveyed said they have a formal policy requiring security review specifically for AI-generated pull requests, distinct from standard code review.
- 81% of developers said their velocity has meaningfully increased since adopting AI coding tools — the productivity case is not in dispute, even among the most security-skeptical respondents.
Taken together, these figures describe an industry that has made a rational-seeming tradeoff: accept unknown and largely unmeasured supply chain risk in exchange for measurable, immediate velocity gains. That tradeoff was made quickly, informally, and mostly without security teams in the room.
Where Trust Breaks Down
The report asked developers to rank the specific failure modes that erode their confidence in AI-generated code, and the answers cluster around three themes.
Dependency fabrication. Large language models generate package names, import statements, and API calls the same way they generate any other token sequence: by predicting what's statistically plausible, not by verifying what actually exists. When a model has been trained on shifting package ecosystems, it will occasionally invent a dependency name that sounds exactly like something that should exist. Attackers have taken notice, pre-registering these hallucinated names on npm and PyPI so that the next developer who accepts the AI's suggestion pulls down malicious code instead of a 404. 58% of respondents in the report said they had personally encountered a suggested package they could not verify was legitimate.
Insecure defaults. AI models are trained on the accumulated code of the internet, which includes a great deal of code that predates modern security guidance — hardcoded credentials in examples, deprecated cryptographic functions, permissive CORS configurations, string-concatenated SQL. Models reproduce these patterns because they are common in the training distribution, not because they are correct. 66% of developers said AI-suggested code has included a security anti-pattern they had to manually catch and fix.
False confidence in "working" code. Perhaps the most interesting finding is behavioral rather than technical: developers report that AI-generated code that compiles and passes tests creates a false sense of completeness. Functional correctness gets conflated with security correctness, and the review that would normally catch a vulnerability gets shortened or skipped because the code "already works." 55% of respondents admitted this dynamic has changed how carefully they review code overall — not just AI-generated code, but everything, because review budgets are finite and increasingly consumed elsewhere.
The Productivity-Risk Tradeoff, By Seniority
Segmenting the data by role produces one of the report's more actionable findings. Junior and mid-level developers reported the highest raw usage of AI coding tools (94% weekly usage) but also the lowest rate of independently verifying AI-suggested dependencies (just 18%) before merging. Senior developers and staff engineers used AI tools nearly as often (85%) but verified dependencies at more than double the rate (41%), largely because they've built a mental model of where these tools tend to fail.
Security and platform engineering leaders, meanwhole, reported the widest gap between perceived and actual control. 68% of security leaders said they were "confident" their organization could detect an AI-introduced vulnerability before it reached production. But when asked whether their tooling could specifically distinguish AI-generated code paths from human-written ones for audit purposes, only 22% said yes. Confidence, in other words, is currently running ahead of actual visibility — a pattern that tends to precede an incident rather than prevent one.
Why Sentiment Diverges From Reality
The report's authors argue the trust gap isn't irrational — it's a mismatch between how fast AI-assisted development scaled and how slowly the surrounding controls caught up. Code review processes, SAST rules, and dependency policies were largely designed for a world where a human wrote every line and had at least implicit context on why a dependency was chosen. AI-assisted development breaks that assumption: a developer can now generate, in minutes, a volume of new code and new third-party references that would previously have taken days, without a proportional increase in review capacity or supply chain governance.
This is consistent with what Safeguard's own detection telemetry shows across customer environments: a measurable rise in previously-unseen package names appearing in dependency manifests immediately after teams adopt AI coding assistants, and a corresponding lag — often weeks — before those packages get flagged by anyone. The risk isn't hypothetical; it's a timing problem. The window between "AI suggests it" and "someone verifies it" is exactly where slopsquatting and vulnerable-by-default code live.
The Industry Context
The AI Trust Report's findings track directionally with what other parts of the security industry have been reporting throughout 2025 and into 2026: rising AI coding tool adoption, rising concern about AI-introduced vulnerabilities, and a persistent lag in governance. What Safeguard's data adds is granularity on the developer side — the report is one of the first to separate "do you use AI code" from "do you trust AI code" and show that the two numbers have almost nothing to do with each other. Trust is not a prerequisite for adoption anymore. That has flipped the traditional security adoption curve, where tooling usually spreads after confidence is established. Here, usage spread first, and confidence — and the tooling to justify it — is still catching up.
How Safeguard Helps
Safeguard is built for exactly the gap this report describes: high-velocity, AI-assisted development outpacing manual review capacity. Teams already running a SAST or SCA scanner know the failure mode this report quantifies — a scanner report with hundreds of undifferentiated findings gets skimmed, not read, which is exactly how AI-introduced risk slips through. Griffin AI, Safeguard's security-focused model, reviews AI-generated pull requests with the same scrutiny the report's senior developers apply instinctively — flagging hallucinated or newly-published packages, insecure defaults, and anti-patterns before merge, and opening auto-fix PRs that resolve the issue without pulling a human off their sprint. Reachability analysis then tells teams which flagged dependencies and code paths are actually exercised in production, cutting through alert volume so review time goes to the handful of AI-introduced risks that matter rather than every suggestion a model has ever made. Continuous SBOM generation and ingest give security teams the visibility 78% of the report's respondents said they lack — a live, queryable record of exactly which components, AI-suggested or human-written, are running where, so "we didn't know that package existed" stops being a viable incident postmortem line.