AI now writes roughly half of all committed code. The rate at which that code passes security testing has not improved in a year. For a commercial product team, that combination is a manageable engineering problem. For an agency operating a system of record under an authority to operate, it is a compliance and mission-risk problem that arrives whether or not anyone planned for it.
Interclypse builds software for federal and state customers. The figures below are not industry color for us. They are inputs to how we staff reviews, structure pipelines, and scope what we will and will not put in front of a government buyer.
The number that has not moved
Veracode's 2026 GenAI Code Security Report tracked more than 100 models across four testing snapshots. The finding, in the company's own summary: the average security pass rate sits at 56 percent, virtually unchanged from 55 percent in the first report.
The testing methodology matters for interpreting that. Each model was evaluated on code completion tasks across multiple languages, under standardized conditions, with no security-specific prompting. Veracode then ran its static analysis tooling against the output to detect known vulnerability classes including SQL injection (CWE-89), cross-site scripting (CWE-80), log injection (CWE-117), and insecure cryptographic algorithms (CWE-327). Each task could be completed securely or insecurely.
The contrast inside the results is the whole story:
Model choice moves the number without solving the problem. In the Summer 2026 dataset, GPT-5.5 led at a 68% security pass rate, six of eleven tested models clustered between 50 and 53%, and models purpose-built for code averaged 51%. The best available model still fails roughly one security task in three.
Language matters more than most buyers expect. Java sits last by a wide margin at a mean security pass rate of only 30%, despite being a cornerstone of enterprise and government systems with decades of established secure coding practice behind it. Agencies running Java estates should read that figure carefully.
Failure is also uneven by vulnerability class. Cryptographic implementation checks passed roughly 87% of the time and SQL injection defenses roughly 83%, which suggests models have absorbed the large body of public secure-coding examples for those specific patterns. Cross-site scripting performs substantially worse. Averages conceal that spread, and a review process calibrated to the average will under-inspect the categories that fail most.
A second dataset, and an honest disagreement
The Cloud Security Alliance reached a similar conclusion by a different route, finding that between 45% and 70% of AI-generated code samples fail security tests depending on conditions, in its research note on AI code vulnerability debt. That note also cites Georgia Tech's Vibe Security Radar project tracking 35 CVEs in a single month, March 2026, directly attributable to AI coding tools, with researchers estimating the true count across the broader open source ecosystem is five to ten times higher.
Veracode's 44% and CSA's 45 to 70% range are not the same measurement. Reporting a single number from either study as "the" failure rate overstates precision. We cite the range and name the source.
Why the rate is the wrong thing to focus on
The security pass rate held roughly flat while the volume underneath it expanded enormously. That is the actual shift. A stable failure rate applied to two or three times the code produces two or three times the vulnerabilities entering the pipeline.
The downstream evidence supports that reading. The 2026 Verizon Data Breach Investigations Report, as cited by Veracode, found software vulnerabilities are now the top breach entry point at 31%, surpassing stolen credentials. Veracode's separate 2026 State of Software Security Report found 82% of organizations now carry security debt, an 11% increase year over year.
Independent telemetry points the same direction. Analyses aggregating pull request data and organizational surveys report that a large majority of organizations have experienced at least one production incident traceable to AI-generated code. Those figures come from vendor and aggregator sources with varying methodology, and we treat them as directional rather than precise.
The newer exposure: agentic tooling and MCP
Code generation is the visible half of the problem. The connective layer between AI agents and enterprise systems is the half that has moved fastest and been governed least.
The Model Context Protocol became the default mechanism for connecting agents to tools, data, and APIs across essentially every major AI client within eighteen months of its introduction. Security governance did not keep pace. The Cloud Security Alliance's agentic MCP security best practices guide documents that between January and February 2026, researchers filed over 30 CVEs targeting MCP servers, clients, and infrastructure components, with the highest-severity finding carrying a CVSS score of 9.6 against the widely deployed mcp-remote proxy package.
CSA's separate research note on systemic MCP design flaws describes an architectural issue disclosed in April 2026 affecting an estimated 200,000 vulnerable instances across a supply chain spanning more than 150 million package downloads.
Three specifics are directly relevant to any agency evaluating agentic tooling:
Authentication and scoping were originally optional. The MCP 1.0 specification carried no mandatory authentication requirement for server connections and no mechanism for granular per-operation permission scoping. Any agent connecting to a server received the full capability set that server exposed. The 2026 specification update introduces incremental scope consent, allowing clients to request only the minimum access needed per operation. Deployments that have not upgraded remain exposed to the original attack surface in full.
Tool descriptions are an injection surface. Agents select and invoke capabilities based on tool description metadata, which flows directly into the model context window. An attacker who can modify a description can redirect agent behavior. Prompt injection through this path requires no malware and no stolen credentials.
Default configurations have leaked. Documented incidents include admin panels bound to all interfaces on first deployment, exposing agent conversation histories, environment variables containing API keys and database credentials, tool configurations including shell execution and file write capabilities, and complete system prompts.
For a public sector environment, that last item is the one that ends conversations. An exposed agent configuration with shell execution available inside a boundary is a finding with immediate reporting obligations.
How Interclypse accounts for these figures
Our position is straightforward. Generated code is untrusted input until it has passed the same verification we would apply to code from any external source. That is not a policy we adopted because of the research. The research is why we can now put numbers behind it for a customer.
What that means concretely in our delivery practice:
Static analysis is a gate. Every change enters review with SAST results attached, regardless of authorship. A 56% baseline pass rate means the expected value of an unreviewed generated change is a coin flip on OWASP exposure.
Software composition analysis covers dependencies pulled in by generation. AI-suggested imports bring transitive dependency risk that authorship-based review does not catch. Package provenance is verified before a dependency reaches a build.
Language-specific review weighting. Given Java's 30% mean pass rate, Java changes in our public sector work receive deeper security review than the pass-rate average would suggest. We calibrate to the worst-performing category rather than the mean.
Vulnerability-class weighting. Review checklists emphasize the classes where models measurably underperform, particularly output encoding and cross-site scripting defenses, rather than distributing attention evenly.
Agentic tooling is scoped, pinned, and isolated. MCP server versions are pinned and verified with the same rigor as any software dependency. Auto-approval is disabled. Agent configuration paths are included in code review. Where agents operate on customer data, they operate with explicitly enumerated permissions rather than inherited capability sets.
Review capacity scales with generated volume. The failure mode we work hardest to avoid is the one DORA identified: output rises, the review pipeline stays the same size, and the speed gain converts into a queue and then into production incidents.
We take the position that a government buyer should be able to ask a contractor what percentage of delivered code was AI-assisted, what verification it passed, and what the agentic tooling in the delivery pipeline was permitted to touch. We build so those questions have answers.
If you are evaluating software or delivery services for a federal or state environment, these questions surface the difference between a considered posture and an unexamined one:
A vendor that cannot answer question one cannot meaningfully answer any of the others.