GenAI code security is stuck while syntax quality keeps improving

At a glance

What this is: This update examines why GenAI coding tools still generate insecure code at scale, with security pass rates stuck near 55% despite major gains in syntax correctness.

Why it matters: It matters because IAM, application security, and engineering teams must treat AI-generated code as untrusted input that can introduce access-control, injection, and secret-handling defects into production systems.

By the numbers:

• Veracode’s latest testing found that AI coding assistants now achieve syntax correctness rates exceeding 95%, while security pass rates remain stuck at approximately 55%.
• Veracode tested 80 coding tasks across 4 programming languages and 4 critical vulnerability types in its Spring 2026 update.
• Veracode has evaluated over 150 large language models in this longitudinal study of AI code security.

👉 Read Veracode's Spring 2026 GenAI code security update

Context

GenAI code security is now a governance problem, not just a code-quality issue. When AI-generated code looks syntactically correct but still embeds insecure patterns, teams inherit hidden risk that standard functional testing will not expose. For IAM and PAM programmes, the concern extends to how insecure application logic handles secrets, authentication flows, and privilege checks.

The article’s core finding is that model capability and security quality are diverging. That matters for identity-adjacent workloads because code that manages sessions, service accounts, API keys, and delegated access can be shipped faster than security teams can review it. The baseline assumption that “working code” is close enough to “safe code” is no longer a reliable operating model.

This pattern is typical of AI-assisted development at scale: productivity rises first, while security controls lag behind. In practice, that means software teams need compensating controls that sit outside the model itself, including secure prompting, SAST, and code review focused on identity and secret-handling logic.

Key questions

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.

Q: Why do AI coding agents complicate secrets management?

A: AI coding agents complicate secrets management because they combine prompting, execution, and environment setup in one workflow. If secrets are copied into prompts, .env files, or repositories, they become easy to duplicate and hard to audit. The problem is not the agent alone, but the speed at which it can spread access material across tools.

Q: What do teams get wrong about syntax correctness in AI-generated code?

A: They confuse code that runs with code that is safe. High syntax correctness only shows that the output is structurally valid, not that it resists injection, preserves data boundaries, or handles secrets correctly. Security validation has to be separate, because functional tests alone will not detect many of the most damaging failures.

Q: Should organisations require human review for AI-generated authentication code?

A: Yes, especially when the code touches login flows, session creation, token issuance, or authorisation logic. Those paths determine who can access what, so an error can create direct privilege exposure. Human review should verify intent, dataflow, and boundary checks, not just whether the code meets the functional requirement.

Technical breakdown

Why secure code lags behind syntax correctness

Large language models are optimised to produce output that compiles, reads naturally, and satisfies the immediate task. Security is a separate property. A model can generate a syntactically valid function that still contains SQL injection, cross-site scripting, unsafe logging, or weak cryptography. That gap persists because model evaluation usually rewards functional success, not resilience against abuse. In identity-heavy code paths, insecure defaults can become credential leaks, broken access checks, or unsafe token handling.

Practical implication: test AI-generated code for security properties, not just compilation and unit-test success.

Why dataflow bugs remain hard for generative models

The weakest results in the report are in cross-site scripting and log injection, which both depend on tracking how untrusted input moves through a system. That requires dataflow reasoning across functions, variables, and output sinks. Current LLMs are good at local patterns, but they are not reliably maintaining the longer-range context needed to know whether data has been sanitised at the right boundary. In practice, this is the difference between a code snippet that looks correct and one that preserves trust boundaries.

Practical implication: pair AI-assisted development with SAST and review steps that specifically trace input, transformation, and output paths.

Why AI-assisted development changes identity and secrets risk

When AI tools accelerate code generation, they also accelerate the spread of insecure identity handling if teams are not explicit about controls. Code that touches service accounts, API keys, session tokens, OAuth flows, or authentication middleware is especially sensitive because a small mistake can create broad access exposure. The technical issue is not that the model understands identity, but that it can reproduce insecure patterns from its training data unless constrained by guardrails and review.

Practical implication: require special review for any AI-generated code that creates, stores, or validates credentials, tokens, or access logic.

Threat narrative

Attacker objective: The attacker objective is to exploit insecure AI-generated application code to gain unauthorized access, manipulate data flows, or expose secrets and privileged paths.

1. Entry begins when developers accept AI-generated code into application workflows without a dedicated security review, allowing insecure patterns into the codebase.
2. Escalation occurs when the model reproduces weak handling of input, logging, cryptography, or access logic, turning code generation into security debt.
3. Impact follows when those flaws reach production and expose credentials, enable injection, or weaken authentication and authorisation controls.

NHI Mgmt Group analysis

Productivity has outpaced security in GenAI code generation. The article shows that syntax quality can improve while security quality stays flat, which means the industry has learned to measure the wrong success criteria. Security teams should not treat AI-generated code as inherently better than human code, because the real issue is whether it preserves trust boundaries, not whether it compiles.

AI-generated code creates a new identity risk surface wherever credentials, tokens, or access checks are touched. That is where NHIs and human identity controls intersect with application security. If developers use AI to build authentication logic, secret storage, or service-account workflows, the model can propagate unsafe patterns at machine speed. Practitioners should treat these code paths as identity-critical, not ordinary application code.

Context-aware reasoning is the missing control, not more model hype. The persistent failures in XSS and log injection show that models still struggle with multi-step dataflow, which is exactly where many real security failures live. This points to a governance gap: enterprises need compensating controls that assume model output is incomplete until validated through security tooling and review. The practical conclusion is that human oversight remains a security requirement, not a fallback.

Security benchmarking for AI code needs to become a procurement and risk-management criterion. If vendors compete on speed and syntax but not on secure-code performance, enterprises will keep absorbing hidden remediation cost. That makes transparent benchmarking, secure prompting, and enforced review part of the control stack. The practitioner takeaway is straightforward: measure AI tooling against security outcomes before it becomes embedded in delivery pipelines.

What this signals

Secure-by-default AI coding remains a control problem, not a model-quality problem. As long as security outcomes sit outside the optimisation target, enterprises need compensating controls that assume AI output is incomplete. For identity-heavy systems, that means explicit checks around secrets, tokens, and access-control logic before code is allowed into delivery pipelines.

Code generation is now part of the identity attack surface. When AI tools help write authentication or secret-handling code, they become upstream contributors to access risk. That should push security teams to bring IAM, application security, and platform engineering into the same review loop, because the failure mode is shared even when the tooling is not.

The next maturity step is to measure AI-assisted development by security defect density, not just delivery velocity. That requires linking static analysis, code review, and secret-scanning results to the places where AI is used most heavily, then watching whether remediation keeps pace with generation. If it does not, the organisation is just scaling insecure code faster.

For practitioners

• Block direct promotion of AI-generated code into production paths Require security review before AI-generated code can reach repositories that handle authentication, session management, token issuance, or secret storage. Treat those components as high-risk because insecure patterns there have outsized blast radius.
• Run SAST on all AI-assisted pull requests Add static analysis to the merge gate so insecure constructs are detected even when the code compiles cleanly. Prioritise rules that catch injection, unsafe logging, weak crypto, and access-control mistakes.
• Mandate secure prompting for identity-sensitive code Tell developers to ask models for parameterised queries, safe output encoding, minimal secret exposure, and explicit authorisation checks whenever code touches identity or data-handling logic.
• Create a separate review path for secrets and access logic Any code that creates, reads, rotates, or forwards secrets should receive targeted review from security or platform engineers, because generic code review often misses latent identity exposure.

Key takeaways

• GenAI coding tools still improve how fast code is written, but they have not materially improved how securely code is written.
• The most serious failures cluster around dataflow-dependent flaws and identity-sensitive code paths, where weak handling of secrets or access logic can create broad exposure.
• Enterprises need compensating controls such as SAST, secure prompting, and mandatory human review before AI-generated code reaches production.

Key terms

• GenAI Code Security: GenAI code security is the discipline of governing code produced by generative AI so that it is not only functional, but also safe to ship. It combines model evaluation, workflow verification, remediation prioritisation, and policy controls around where AI-generated code is allowed to enter production.
• Dataflow analysis: Dataflow analysis tracks how data moves through code from source to sink, including transformations, sanitisation, and storage. It is essential for finding vulnerabilities such as cross-site scripting and log injection because those flaws depend on whether untrusted input reaches a dangerous output location intact.
• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Secrets handling: The set of practices used to create, store, transmit, and rotate credentials such as API keys, tokens, and certificates. Poor secrets handling in generated code can create standing access, leak privileged credentials, and undermine both application security and broader identity governance.

What's in the full report

Veracode's full update covers the operational detail this post intentionally leaves for the source:

• The full benchmark methodology across 80 tasks, 4 languages, and 4 CWE types, including how secure and insecure outputs were scored
• The language-by-language and CWE-by-CWE breakdowns that show where AI-generated code fails most often in practice
• The model-by-model comparison across major releases, including the reasoning-model outliers and their security pass rates
• The analysis of how training data, workflow incentives, and dataflow limitations combine to keep security performance flat

👉 Veracode's full update includes the model comparisons, vulnerability breakdowns, and testing methodology behind the findings.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security for practitioners who need to control access risk across modern environments. It gives security and identity teams a practical way to connect governance with the systems now shaped by AI-assisted development.