AI-generated code is widening the application security gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Checkmarx's blog post: AI-generated code is accelerating software delivery, but governance, accountability, and automation are not keeping pace, allowing vulnerable code to enter production faster than security teams can control it.

Why it matters: For AppSec, IAM, and platform teams, the issue is not just code quality but control over who is accountable for AI-generated changes, what gets approved, and how enforcement scales across the pipeline.

By the numbers:

• 81% of organisations knowingly ship vulnerable code, according to Checkmarx's Future of Application Security report.
• Up to 45% of AI-generated code may be insecure, according to Checkmarx research cited in the article.

Context

AI-generated code is changing the software delivery model by compressing the time between idea, implementation, and deployment. That speed creates a governance problem when security review still assumes human pacing, manually curated backlogs, and end-of-sprint validation.

The identity angle is indirect but real: as code generation, review, and remediation become increasingly mediated by AI tools, teams need accountable ownership, policy enforcement, and traceability for what enters the codebase. Without that control plane, AppSec debt accumulates as quickly as the code itself.

Key questions

Q: How should teams govern AI-generated code when they cannot review every change?

A: Teams should shift from source-only assurance to runtime assurance. That means correlating deployments, traces, logs, and outcome metrics so behaviour can be validated after code is generated and released. The practical goal is not perfect review coverage, but a dependable record of what the system actually did in production.

Q: Why do AI-generated code changes increase application security risk?

A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.

Q: What are the signs that AI-assisted development is creating AppSec debt?

A: The clearest signs are growing backlog, findings that arrive after commit, repeated rework on the same classes of issues, and heavy dependence on late-stage scans. When developers routinely move on before vulnerabilities are resolved, the programme is no longer governing risk in real time. It is cataloguing it after the fact.

Q: What should security leaders do when AI agents are writing code across the development lifecycle?

A: Set explicit accountability for independent verification at each stage where code is generated, merged, and maintained. Leaders should require evidence that AI-authored changes were checked against security and access-control standards before release, because trust in provenance is not a substitute for trust in outcome.

Technical breakdown

Why AI-generated code widens the application security gap

AI coding tools optimise for functional output, not secure implementation. A model can produce code that passes tests and still introduce unsafe input handling, weak validation, insecure defaults, or dependency risk. That mismatch matters because security failures often emerge from interactions across files, libraries, and workflows rather than from a single obvious defect. At scale, the problem is not whether one snippet is vulnerable, but whether thousands of snippets are being created faster than review processes can verify them.

Practical implication: Treat AI-generated code as untrusted input until it has passed the same security scrutiny as human-written code.

Accountability, policy, and automation are three different controls

The article’s central governance point is that tooling alone does not solve AI-assisted AppSec. Accountability assigns a named owner for the quality and security of generated code, policy defines what tools, data, and patterns are permitted, and automation enforces those rules continuously. If any one of those layers is missing, the control plane breaks down: owners cannot act on findings, policies are advisory only, and scans arrive too late to matter.

Practical implication: Define ownership, allowed tool use, and enforcement paths as separate controls rather than one blended governance effort.

Why continuous review matters more than end-of-sprint scanning

Traditional AppSec assumes risk can be found and fixed in batches. AI-generated code breaks that assumption because generation happens continuously throughout the development cycle, often inside the IDE and pull request flow. That means security findings need to appear early enough for developers to fix them in context, before dependencies harden, context is lost, and remediation becomes rework instead of a quick correction.

Practical implication: Shift review left into the IDE and pull request stages so remediation happens while the code context is still fresh.

NHI Mgmt Group analysis

AI-generated code creates AppSec debt because governance still assumes human-paced development. The core failure is not that teams lack scanners, but that their control model expects security to catch up after code exists. When code production accelerates faster than review, backlog becomes structural risk rather than operational noise. The practitioner conclusion is simple: review cadence must match generation cadence, or the backlog becomes the control failure.

Accountability is the missing control plane for agentic coding workflows. Agentic coding tools can create, modify, and propose code, but they cannot own the resulting security risk. That shifts responsibility back to the organisation, which means the governance model must name owners, approval boundaries, and escalation paths. Without explicit ownership, findings drift, exceptions multiply, and no one is accountable for the code that ships.

Policy enforcement must extend to the full AI toolchain, not just the final code output. The article’s broader point is that security risk is introduced upstream through models, dependencies, and tool permissions as much as through source files. A named concept emerges here: AI-generated code governance debt: the accumulation of unmanaged risk when teams adopt generation at speed without equivalent enforcement, inventory, and traceability. The practitioner implication is to govern the entire generation path, not only the finished artifact.

Continuous enforcement beats periodic inspection when development becomes machine-speed. One-off scans and end-of-sprint reviews are built for slower release cycles. In AI-assisted delivery, the control needs to be embedded in the workflow so that detection, triage, and remediation happen before the change is fully absorbed into the codebase. The practical conclusion is that AppSec must behave like a real-time control, not a retrospective audit.

The real metric is whether security can keep pace with code creation. Organisations should measure whether generated code is being reviewed, triaged, and remediated at the same speed it is produced. If findings are consistently arriving after commit, then the programme is already behind the development system it is meant to govern. The practitioner conclusion is to judge AppSec by time-to-control, not only by scan coverage.

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 Security Platform Buyer's Guide

What this signals

AI-generated code governance debt: the problem is not simply that more code is being written, but that review, ownership, and policy enforcement are not scaling at the same rate. When generation outpaces governance, organisations inherit risk faster than they can classify or fix it.

For security leaders, the operational question is whether AppSec can act inside the development loop rather than after it. That shifts emphasis from scanning volume to control timing, because a vulnerability found late is already a governance failure, even if it is eventually remediated.

For practitioners

• Assign accountable AI code owners Name specific individuals responsible for the security and quality of AI-generated code, including escalation when risky output reaches review or release stages.
• Define allow and deny rules for AI coding tools Set explicit policy for which coding assistants, models, data sources, and prompt patterns are permitted, then embed those rules into engineering governance.
• Embed layered scanning in the development workflow Use multiple detection methods across IDE, pull request, dependency, and runtime checkpoints so findings appear before code is merged or deployed.
• Track acceptance and remediation of AI output Measure how often generated code is accepted, rejected, or remediated, and use those metrics to identify teams that need stronger review discipline.

Key takeaways

• AI-generated code can speed delivery and still widen AppSec exposure when review and governance are not scaled with it.
• The article ties the risk to organisational behaviour as much as tooling, with vulnerable code still reaching production at high rates.
• The practical answer is continuous enforcement, clear ownership, and policy applied across the full development workflow, not just at release.

Key terms

• Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
• AppSec Throughput Debt: The gap between the number of security findings a programme produces and the number it can meaningfully triage and fix. In AI-assisted development, that gap widens when code generation accelerates faster than review, remediation, and staffing capacity can scale.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Defense-in-Depth for Code Review: A layered review approach that uses multiple controls at different stages of development rather than a single end-of-pipeline scan. It is designed to catch different vulnerability types earlier, reduce noise, and preserve context for remediation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity for practitioners who need to connect identity control to wider security programmes. It helps identity, security, and platform teams align governance with modern development and automation patterns.