AI-generated code is widening the application security gap

At a glance

What this is: This is an analysis of how AI coding tools accelerate delivery while also increasing the volume, speed, and persistence of application security risk.

Why it matters: It matters because IAM, PAM, and security teams increasingly have to govern non-human actors and workflows that create code, produce secrets exposure, and bypass traditional review timing.

By the numbers:

• 81% of organizations knowingly ship vulnerable code.
• 45% of AI-generated code may be insecure.

👉 Read Checkmarx's analysis of AI-generated code risk and AppSec governance

Context

AI-assisted development changes the security baseline because code can now be generated continuously, not just written manually. That shifts application security from periodic review to governance of a high-volume production pipeline, where the primary problem is not whether code runs but whether it enters the codebase with unresolved risk.

The identity dimension is real even in a software security topic. AI coding tools, MCP servers, and developer workflows behave like non-human entities that need policy, traceability, and accountability, otherwise the organisation inherits a growing body of machine-produced code with no clear owner for security decisions.

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-assisted coding tools complicate security assurance for enterprise software?

A: They increase code output faster than teams can prove the output is safe. Security assurance is slower because it depends on review, testing, and validation of behaviour, especially where access and trust are encoded in the application. The gap widens when organisations treat generation speed as the same thing as control maturity.

Q: What do teams get wrong about scanning AI-generated code at the end of a sprint?

A: Teams often assume one strong scan can compensate for rapid code generation, but that model is too late for modern workflows. By the time a sprint-end scan finds a problem, developers may have moved on, context has been lost, and the fix becomes slower and more expensive than catching the issue earlier.

Q: How can organisations tell whether AI governance is actually working?

A: Organisations can tell AI governance is working when they can inventory every agent, explain its purpose, show who owns it, and prove that permissions are tightly scoped. If those four things are missing, the programme has policy language but not operational control. Auditors will notice the gap quickly.

Technical breakdown

Why AI-generated code increases application risk

AI coding tools optimise for function, not for security intent. Large language models can generate syntactically correct code that still contains insecure patterns, weak input handling, unsafe dependencies, or missing validation. The problem compounds because the output arrives faster than manual review can scale, so insecure code is not an exception but a repeatable by-product of production velocity. In AppSec terms, the issue is not model failure alone, but the mismatch between generation speed and assurance capacity.

Practical implication: teams need security controls that operate during authoring and commit, not only after merge.

Accountability, policy, and automation as the three control gaps

The article’s core governance model is that AI-generated code fails when accountability, policy, and automation are separated. Accountability defines who owns the risk. Policy governs which tools, outputs, and data paths are allowed. Automation enforces security at a cadence that matches continuous code generation. Without those three controls working together, security reviews become delayed, fragmented, and easy to bypass as code volumes rise.

Practical implication: security leaders should map named owners, enforced policy, and pipeline automation to the same AI-assisted development workflow.

Why continuous review beats end-of-sprint scanning

A single scan at the end of a sprint cannot keep pace with a workflow where code is produced, modified, and re-generated many times before release. Continuous review distributes detection across the IDE, pull request, and pipeline stages, which improves the odds that vulnerabilities are caught while context still exists. That matters because once code is merged, the remediation cost rises and the developer context starts to disappear.

Practical implication: move review left and make it continuous, otherwise the backlog will keep growing faster than remediation capacity.

Threat narrative

Attacker objective: The attacker objective is to exploit insecure code that enters the software supply chain faster than security teams can review and correct it.

1. Entry occurs when AI-generated code is introduced into the development workflow through the IDE, pull request, or automation pipeline.
2. Escalation follows when insecure patterns, unsafe dependencies, or weak validation are accepted because no accountable review path blocks them in real time.
3. Impact arrives when vulnerable code ships into production, increasing the chance of exploitation, rework, and accumulated security debt.

NHI Mgmt Group analysis

AI-generated code creates governance debt, not just code debt. The article shows that the main failure is not output quality alone but the absence of accountable control over how AI-generated code is accepted into the software lifecycle. When code is produced faster than teams can review it, governance becomes the limiting factor, not developer productivity. For application security teams, the practical conclusion is that AI output must be treated as governed production material, not disposable draft code.

Continuous assurance is now the only defensible AppSec posture for AI-assisted development. End-of-sprint scanning assumes risk accumulates slowly enough to be caught in batches, but AI-driven workflows break that assumption. Security findings arrive after context has shifted, which increases remediation time and weakens root-cause visibility. For practitioners, the field is moving toward always-on validation across the IDE, pull request, and pipeline.

Agentic coding tools introduce a non-human identity problem inside software engineering. Once tools can generate, transform, and submit code, the question becomes who or what is authorised to create changes, under which policy, and with what traceability. That is an identity governance problem as much as an AppSec problem, because machine-produced changes need provenance, ownership, and bounded authority. For IAM and security leaders, this is where NHI governance intersects directly with software delivery.

Policy without enforcement and enforcement without context both fail at scale. The article’s three-gap model is useful because it shows why isolated tooling improvements do not fix the underlying condition. A policy document without runtime enforcement is advisory only, while automated tooling without ownership produces noise. For security programmes, the conclusion is to align policy, telemetry, and remediation ownership inside one operating model.

AI software leads represent the control point organisations have been missing. The article’s accountability theme points to a specific governance role: someone must own the security and quality outcomes of AI-generated code. That role does not remove developer responsibility, but it stops diffusion of ownership across teams and tools. For practitioners, the lesson is to formalise responsibility before AI-generated code volume makes attribution impossible.

What this signals

The practical signal for application security programmes is that AI-assisted development compresses the time available to prove a control is effective. If review, policy enforcement, and remediation are not tied to the same workflow, teams will continue to measure output volume while risk quietly accumulates underneath it. The governance problem is therefore operational, not theoretical.

Governance drift: when machine-generated code enters the pipeline faster than ownership can be assigned, the organisation starts creating control debt alongside software debt. That drift will increasingly affect IAM-linked workflows too, because AI tools and MCP-connected services depend on traceable authority, not just functional access.

Security leaders should expect more demand for evidence that development controls are continuous, attributable, and enforceable. In practice that means tighter linkage between AppSec telemetry, developer identity, and approval paths, with more emphasis on what was permitted, by whom, and at what stage rather than on post hoc cleanup.

For practitioners

• Assign an accountable AI software lead Name a specific owner for the security and quality of AI-generated code, with authority to block release when accepted risk exceeds policy. Tie that role to engineering performance goals and secure development standards so accountability is not symbolic.
• Build policy gates for AI tool usage Create allow and deny lists for coding assistants, model endpoints, and MCP servers used in development. Require visibility into what tools are approved, what data they can access, and what outputs may be merged into the codebase.
• Move AppSec checks into the developer workflow Run security validation in the IDE and pull request stage, not only at sprint end. Use layered detection so known patterns, contextual vulnerabilities, and dependency risks are evaluated before code is committed.
• Track AI output acceptance and remediation latency Measure how often AI-generated suggestions are accepted, how many are rejected for security reasons, and how long it takes to remediate findings after generation. Those metrics show whether governance is reducing risk or simply documenting it.

Key takeaways

• AI-generated code is now an application security governance problem because speed has outpaced review, ownership, and enforcement.
• Checkmarx cites 81% of organisations knowingly shipping vulnerable code, while its research indicates 45% of AI-generated code may be insecure.
• The most effective response is to assign accountability, enforce tool policy, and embed continuous security checks directly into the development workflow.

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.
• 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.
• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• 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.

What's in the full article

Checkmarx's full article covers the operational detail this post intentionally leaves for the source:

• Gartner's specific guidance on AI software leads and how responsibility should be assigned in engineering teams.
• The Checkmarx One workflow details for combining ASPM, centralized AI-BOM visibility, and enforcement across the AI toolchain.
• Examples of developer assist, triage assist, and remediation assist in the pull request and IDE workflow.
• The layered detection approach that blends deterministic and AI-driven analysis to reduce false positives.

👉 Checkmarx's full article covers the accountability, policy, and automation gaps in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that supports modern security programmes. It helps practitioners connect identity control to the broader governance challenges created by AI-assisted development.