GenAI code security is stuck while syntax quality keeps improving

At a glance

What this is: Veracode’s Spring 2026 testing shows AI coding assistants are far better at producing valid code than secure code, with security performance still stuck around 55% while syntax correctness exceeds 95%.

Why it matters: For IAM, NHI, and broader application security teams, this means developer productivity gains can scale insecure code faster unless security review, SAST, and secure prompting are built into the workflow.

By the numbers:

• AI coding assistants now achieve syntax correctness rates exceeding 95%.
• Across all models and tasks, only 55% of generation tasks result in secure code.
• Veracode has evaluated over 150 large language models in its longitudinal study.
• Java tasks produced only a 29% security pass rate, the worst language result in the study.

Context

AI-assisted coding now creates a governance gap between functional output and secure output. When models reliably produce code that compiles but not code that resists known weakness patterns, the control problem shifts from code generation to code assurance.

For identity and access teams, the relevance is indirect but real: insecure application code often becomes the entry point for credential theft, broken authorization, and abuse of downstream services. The article’s core message is that security debt can be created at developer speed unless review, testing, and policy checks move earlier in the pipeline.

Key questions

Q: What fails when AI-generated code is functionally correct but not secure?

A: Functionally correct code can still introduce injection, logging, and cryptographic weaknesses that become exploitable after deployment. The failure is governance, not compilation. Teams that treat syntax as a proxy for safety miss the point that security must be verified separately before code is merged or released.

Q: Why do secure code pass rates stay flat even as model capability improves?

A: Because models are trained and rewarded mainly for output quality, not for security outcomes. They learn common coding patterns from historical repositories, including insecure ones, and they are rarely optimised against dataflow-heavy weaknesses. Better reasoning helps, but it does not remove the need for independent security controls.

Q: What do teams get wrong about securing AI coding assistants?

A: Teams often focus on code output and ignore the agent boundary, where file reads, tool outputs, and external content shape the next action. That misses the real control point. The right question is whether untrusted input can influence privileged behaviour before the code is even written or committed.

Q: How should security teams govern AI-generated code in production pipelines?

A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact. Require human approval, traceable authorship, scoped workload identities, and evidence of intent before production promotion. The goal is to preserve provenance and limit blast radius when generated logic behaves unexpectedly.

Technical breakdown

Why syntax correctness does not equal secure code

Large language models are optimised to generate code that satisfies the prompt and passes obvious correctness checks. Syntax correctness measures whether the code is well-formed and likely to run, while security quality measures whether the code exposes known weaknesses such as injection, unsafe logging, or weak cryptography. Those are different objectives, and current models are better at the first than the second. The article’s testing shows that functional improvement can climb while security plateaus, because the model is rewarded for producing plausible code rather than defensible code.

Practical implication: treat AI-generated code as untrusted input until it passes security review and automated scanning.

Why dataflow-heavy vulnerabilities remain the hardest problem

Cross-site scripting and log injection require the model to track how input moves through multiple steps, not just match a local pattern. That means following tainted data across variables, transforms, and render points, then deciding whether sanitisation happens at the right boundary. LLMs are weak at persistent, cross-statement reasoning, which is why they can appear competent on simple SQL patterns but fail on issues that depend on context. This limitation is architectural, not just a training-data issue.

Practical implication: use SAST and code review to catch dataflow flaws that code completion systems routinely miss.

Why productivity metrics can hide a security regression

AI coding tools are usually judged on speed, developer satisfaction, and whether the output works. Security is harder to measure, slower to validate, and often invisible until an incident occurs, so it loses in the optimisation hierarchy. That creates a governance blind spot: a team can improve delivery velocity while quietly increasing vulnerability density. The article shows that the market has rewarded code production at scale without attaching equal weight to secure-by-default generation.

Practical implication: add security pass rate and remediation effort to the same scorecard as developer productivity.

Threat narrative

Attacker objective: Exploit insecure generated code to reach sensitive data, tokens, or privileged application functions at scale.

1. Entry occurs when insecure AI-generated code is accepted into the application baseline because it appears functionally correct and passes basic checks.
2. Credential or data compromise can follow when that code exposes injection, logging, or access-control weaknesses that attackers can exploit.
3. Impact is amplified because the same productivity workflow can replicate the flaw across many repositories and teams at developer speed.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Security pass rate is the real control metric, not syntax quality: code that compiles can still be a liability if it embeds known weaknesses. The article shows that the industry has over-indexed on productivity indicators while security outcomes remain flat. For practitioners, the lesson is to govern AI coding as a risk engine, not a productivity toy.

Model scale is not solving application security by itself: the testing shows that larger or newer models do not automatically improve secure coding outcomes. That means organisations should stop assuming capability releases will close the gap on their own and instead design compensating controls around the coding workflow. The stronger signal is governance discipline, not model hype.

Secure code generation is a software assurance problem, not just an AI problem: the failures on XSS and log injection are the same classes of weaknesses that code scanning, review, and secure development practices were built to catch. In practice, this connects application security, DevSecOps, and IAM because insecure code often becomes the path to authorisation failure or token abuse.

Productivity-security debt is the named concept practitioners should track: faster code creation can silently accumulate vulnerable code faster than teams can review it. That debt is especially dangerous when AI-assisted development becomes normalised across large engineering estates. The practical conclusion is to measure and cap security debt at the point of code generation, not after release.

Human review remains the governance boundary: no current AI assistant can be treated as a security control for code quality. The article reinforces that review, testing, and policy enforcement must sit before merge, because post-hoc cleanup cannot keep pace with machine-generated volume. Security teams should treat the pipeline as the control surface.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Security Platform Buyer's Guide

What this signals

Productivity-security debt: when AI coding systems improve delivery speed faster than security review keeps pace, organisations accumulate vulnerable code faster than they can remediate it. That changes the unit of governance from “developer throughput” to “secure throughput”, and the control point moves upstream into the IDE and CI pipeline.

The most important operational shift is that AI-generated code should be treated as a higher-risk input class, not a separate coding style. Teams that already govern secrets, access review, and application security should extend the same discipline to generated code paths, especially where application flaws can expose tokens, sessions, or authorisation boundaries.

For practitioners

• Embed mandatory SAST in AI-assisted pipelines Run static analysis on every AI-generated change before merge, with gates for injection, logging, and cryptography weaknesses. Do not rely on developer judgment alone when the code originated from a model.
• Require secure prompting and threat-aware review Tell developers to ask models for secure-by-default patterns and to validate outputs against the application’s trust boundaries, especially where user input reaches rendering, logging, or database queries.
• Measure security pass rate separately from productivity Track the percentage of AI-generated snippets that pass security review, not just delivery speed or acceptance rates. Use that metric to decide where AI assistance is safe to expand and where it needs tighter supervision.
• Prioritise high-risk languages and patterns Place extra review on Java code and on flows that involve XSS, log injection, or legacy string-concatenation patterns, because the study shows those areas remain the weakest.

Key takeaways

• AI coding assistants are improving at producing syntactically valid code, but the study shows that secure code generation is still stuck near the same level it held two years ago.
• The gap matters because insecure generated code can scale across engineering teams faster than review processes can catch it, especially in dataflow-heavy vulnerability classes.
• Security teams should move controls upstream into prompting, static analysis, and pre-merge review so productivity gains do not turn into security debt.

Key terms

• AI-generated code: Software produced wholly or partly by an AI model or agent rather than a human developer. The security concern is not authorship alone, but whether the resulting logic, access control, and dependency choices have been independently verified before release.
• Security Pass Rate: Security pass rate is the proportion of evaluated outputs that meet a defined security standard without introducing a vulnerability. In code-generation contexts, it is a useful measure because it separates syntactic correctness from actual security quality and helps compare models under the same test conditions.
• Dataflow-heavy vulnerability: A defect that depends on how data moves through an application rather than on a single obvious code pattern. Cross-site scripting and log injection are typical examples because the risk emerges from context, propagation, and boundary handling, not just from one bad line of code.
• Secure-by-default generation: An AI output posture in which the model tends to produce safe patterns without explicit security prompting. It implies that secure output is the baseline behaviour, not the result of an extra review step, and the article shows current models have not reached that state.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org resources that connect identity governance to the broader security disciplines your programme depends on.