TL;DR: Across more than 150 large language models, only 55% of AI-generated code passes basic security tests while syntax correctness exceeds 95%, according to Veracode, leaving security teams with fast-moving code that often looks right but still ships known flaws. The core problem is that speed now outpaces trust, and manual review cannot keep up with machine-scale code generation.
At a glance
What this is: Veracode argues that AI-generated code is outpacing security controls, with security pass rates far below syntax correctness and exploitable flaws still making it into production.
Why it matters: IAM, AppSec, DevSecOps, and security leaders need governance that treats AI-assisted code as untrusted until it is verified, because speed now outstrips human review capacity.
By the numbers:
- Across more than 150 large language models tested, only 55% of AI-generated code passes basic security tests.
- Those same models achieve syntax correctness rates above 95%.
- For SQL injection, AI models achieve an 82% security pass rate.
- For cross-site scripting, the security pass rate is just 15%.
Context
AI-generated code now creates a trust gap when code can appear correct, compile cleanly, and still embed known vulnerabilities. The problem is not only code quality, but governance over what enters the software supply chain, how it is verified, and how teams prove that production code is secure enough to rely on.
This matters to security programmes because AI-assisted development changes the risk boundary between development and assurance. When review, testing, and release gates remain human-paced while code generation becomes machine-paced, organisations need controls that operate at the same speed as the code factory rather than after the fact.
Key questions
Q: What breaks when AI-generated code is only checked after commit?
A: Post-commit controls miss the moment when risky code is created, so secrets, insecure patterns, and policy violations can enter the repository before security ever sees them. That makes audit evidence incomplete and weakens defensibility. The practical failure is timing, because detection after commit cannot prove that policy was enforced at generation time.
Q: Why does high syntax accuracy not mean AI-assisted code is safe to deploy?
A: Syntax accuracy only shows that code is structurally valid. Secure deployment also depends on correct input handling, context-sensitive validation, logging hygiene, and safe use of dependencies. A model can generate code that compiles cleanly and still introduce a known vulnerability, which is why security verification must be separate from functional correctness.
Q: What are the signs that AI-assisted coding is creating more security debt than it removes?
A: Warning signs include a rising volume of code changes with the same or similar flaws, security teams struggling to keep pace with review and remediation, and developers accepting suggestions without critical scrutiny. If output quality looks good but vulnerability rates stay high, the tool is improving speed while leaving the underlying security posture unchanged or worse.
A: Preventative guardrails should come first because runtime scanning only sees what already exists. AI-assisted development compresses the time between creation and exposure, so the most effective control point is before code is committed or deployed. Runtime testing still matters, but it cannot substitute for generation-time policy and architectural constraints.
Technical breakdown
Why syntax correctness does not equal secure code
AI coding models are good at reproducing patterns that look syntactically valid, but syntax only answers whether code is formed correctly. Security depends on context, data flow, input handling, and privilege boundaries, which are much harder for pattern-matching systems to reason through. That is why a model can produce code that passes compilation and unit tests while still introducing injection flaws, unsafe logging, or weak validation. The core architectural issue is that correctness checks and security checks are not the same control, even when they happen in the same pipeline.
Practical implication: Treat syntax validation as a hygiene step, not evidence that AI-generated code is safe to merge.
Where AI-assisted development breaks the secure SDLC
AI-assisted development increases output volume without reducing the number of places where security can fail. Secure code review, manual testing, and late-stage sign-off all assume that humans can inspect a manageable flow of changes. Once AI tools accelerate the flow, those controls become bottlenecks and teams start accepting risk by default. The article’s core point is that insecure code does not need to be novel to be dangerous. Well-known flaws become more dangerous when they arrive faster than the organisation can govern them.
Practical implication: Move security enforcement earlier in the SDLC and automate gates so untrusted code is blocked before release.
Why known vulnerability patterns still dominate AI code output
The models perform relatively better on common, heavily represented patterns such as SQL injection because training data and examples are plentiful. They perform far worse on subtler issues like cross-site scripting and log injection, where security depends on precise context and downstream behaviour. That pattern shows the limit of autocomplete-style generation: it mimics common anti-patterns and safer-looking snippets, but does not reliably reason about misuse in edge cases. In practice, this means attackers benefit most where the control surface is least visible.
Practical implication: Focus testing and guardrails on the vulnerability classes most likely to survive pattern-based code generation.
Threat narrative
Attacker objective: Exploit insecure AI-generated code to gain application-level footholds, steal data, or expand compromise through production systems.
- Entry occurs when AI coding tools generate application code that developers accept into the codebase because it looks syntactically correct and passes basic checks.
- Credential and data-path abuse follows when subtle flaws such as XSS or log injection create opportunities for attacker-controlled input, malicious output handling, or downstream compromise.
- Impact arrives when vulnerable code is merged and deployed at scale, turning development velocity into a repeatable path for exploitation across production systems.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
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
AI-generated code has turned software trust into a control-plane problem: the issue is no longer whether code can be written quickly, but whether the organisation can prove it is safe before it ships. Security assurance built for human-paced development cannot absorb machine-scale output without stronger policy gates, automated evidence, and release-time enforcement. The practitioner conclusion is simple: trust must be earned at the point of creation, not assumed at merge time.
Security debt is now being industrialised by AI-assisted development: the more code a team generates, the more latent flaws it can introduce into systems already carrying unresolved weakness. That changes software governance from backlog management to exposure management, because dormant defects become easier to create, harder to review, and faster to exploit. Practitioners should treat code provenance and verification as first-class security controls, not development preferences.
Secure prompting is becoming part of the security control surface: if developers rely on AI tools without consistent security guidance, the toolchain itself becomes a source of repeatable risk. This is where software governance intersects with identity and access control, because code-generation workflows are only as trustworthy as the permissions, policy, and approval paths surrounding them. The practical implication is that AI-assisted development needs governed usage, not informal adoption.
Code review alone is no longer a sufficient compensating control: once vulnerable output arrives at high speed, manual review becomes selective triage rather than true assurance. The industry needs continuous scanning, build-time blocking, and auditable proof that high-risk flaws were intercepted before deployment. For security leaders, the question is not whether AI-generated code should be used, but whether the surrounding controls can keep pace with its production rate.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: AI Coding Agents Security Guide
What this signals
AI-generated code is turning application governance into a verification problem: organisations that rely on manual inspection are discovering that release gates built for human throughput cannot keep up with machine-scale output. The practical shift is toward policy-controlled generation, automated scanning, and evidence that unsafe code was stopped before deployment.
Security debt now behaves like a production multiplier: every additional line of generated code can expand the exposed surface if governance does not keep pace. That means software teams need to manage code provenance and review confidence as risk indicators, not just development metrics.
As a control issue, AI-assisted development sits uncomfortably close to the trust assumptions behind DevSecOps. If the programme cannot prove what was generated, what was checked, and what was blocked, then code velocity is simply masking unresolved exposure.
For practitioners
- Standardise secure prompting for developers Define approved prompt patterns that instruct AI coding tools to avoid insecure defaults, risky dependencies, and unsafe data handling.
- Block known-flaw patterns at build time Use automated SAST and dependency scanning in the pipeline so code with high-risk vulnerabilities cannot proceed to release.
- Prioritise exploitable debt in critical assets Rank remediation by exposure, exploitability, and business criticality instead of trying to fix every finding at once.
- Require auditable verification for AI-assisted code Capture evidence that AI-generated changes were tested, reviewed, and approved under a policy that can be shown to auditors and boards.
Key takeaways
- AI-generated code is not just accelerating delivery. It is also accelerating the introduction of familiar vulnerabilities into production workflows.
- The gap between syntax correctness and security correctness is now a governance failure, not a tooling curiosity.
- Automated enforcement, secure prompting, and auditable verification are the controls that change the risk equation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, OWASP ASVS, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about insecure application code entering production at scale. |
| Recommendation — Enforce application software security controls in the SDLC and block known-flaw code before release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The post centres on secure coding failures and verification of generated code. |
| Recommendation — Use secure coding and architecture requirements to verify AI-generated code before deployment. | ||
| NIST CSF 2.0 | PR.DS-10 — Data in transit is protected | The article repeatedly cites exposed code paths that can lead to insecure data handling. |
| Recommendation — Map AI-assisted development controls to protective safeguards that preserve software integrity. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | The article is fundamentally about testing and verifying software before release. |
| Recommendation — Apply developer testing and evaluation controls to catch AI-generated flaws before production. | ||
| MITRE ATT&CK | TA0001;TA0009 — Initial Access; Collection | The breach examples and risk narrative involve exploitable code paths leading to attacker access and data collection. |
| Recommendation — Map exploit-prone generated code to attack paths that begin with application compromise and end in collection. | ||
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 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.
- Secure Prompting: Secure prompting is the practice of giving AI coding tools explicit constraints that steer output toward safer patterns. It is a governance control, not a style preference, because prompts can influence how models handle authentication, input validation, logging, and other security-sensitive behaviours.
- Build Gate: A build gate is a pipeline control that decides whether a release can continue based on defined security conditions. In practice, it should be explicit, severity-based, and consistent across CI systems so teams do not disable it or treat it as noise. It is a policy checkpoint, not a scanner.
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. It is designed for teams that need to connect identity controls to broader security and governance programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org