AI-driven AppSec is exposing a governance gap in secure code delivery

At a glance

What this is: Checkmarx’s panel and outlook data show AI-assisted delivery is accelerating the shipment of vulnerable code while weakening confidence in AppSec oversight.

Why it matters: This matters because IAM, NHI, and broader security teams all depend on trustworthy software delivery controls, and those controls fail when governance cannot prove what enters production.

By the numbers:

• 81% of organisations knowingly ship vulnerable code, according to Checkmarx.
• 54% of all code is now AI-generated, often without governance, according to Checkmarx.
• 98% experienced a breach in the past year, according to Checkmarx.

Context

Application security fails when teams can no longer verify what code is being produced, reviewed, and shipped. AI-assisted development increases speed, but it also creates a governance gap between code creation and code trust, especially when approval, testing, and accountability lag behind delivery.

The identity connection is indirect but real: software delivery pipelines, developer tools, and AI coding assistants introduce new trust boundaries for secrets, permissions, and change control. When those controls are weak, the problem is not just insecure code, but insecure decision-making about what the organisation is willing to release.

Key questions

Q: Where does AI-generated code fail in practice when teams lack governance?

A: It fails when teams can no longer tell which code paths were model-assisted, who approved the tool, or what data the tool could reach. In that state, review becomes partial and inconsistent. The practical risk is not just bad code quality, but the loss of accountable control over how software entered the pipeline.

Q: What do security teams get wrong about using vulnerability counts as the main measure of AppSec effectiveness?

A: A high alert count does not prove stronger security if teams cannot distinguish exploitable issues from low-value noise. Counting findings without context encourages volume over judgment, and it hides whether the programme can actually prioritise, fix, and track risk through the development lifecycle. Effective AppSec should reduce uncertainty, not just produce more detections.

Q: What are the signs that shadow AI is creating governance and compliance gaps?

A: Common signs include limited visibility into who is using AI tools, no reliable audit trail for prompts and outputs, unclear data residency, and inconsistent handling of sensitive information. If compliance, legal, and executive teams lack the same visibility as IT, the organisation already has a governance gap. Those conditions make it difficult to prove control or investigate misuse.

Q: How should security and development teams build shared accountability for application security without slowing delivery?

A: Treat application security as a shared engineering responsibility, not a security-team handoff. The most effective approach is to align incentives, use tools that help developers fix issues quickly, and create clear collaboration paths between engineering and security. When teams understand each other’s pressures and can resolve problems early, product security improves without adding avoidable friction.

Technical breakdown

Why AI-generated code creates an AppSec trust gap

AI-generated code changes the security model because it compresses the time between code creation and deployment while expanding the number of sources that can introduce defects. Traditional AppSec assumes human authorship, reviewable intent, and a stable chain of accountability. When assistants generate large portions of code, the organisation inherits code it did not fully author, understand, or validate. That weakens the value of simple vulnerability counts, because the real issue becomes provenance and control over what enters the repository and reaches production.

Practical implication: treat AI-assisted code as a governance problem, not just a scanning problem, and validate provenance before release.

Why vulnerable-code metrics fail to show business risk

Counting findings tells you how many issues exist, not which ones matter or whether release processes are absorbing known risk. In fast-moving delivery environments, vulnerability totals can rise or fall without reflecting exposure, exploitability, or business impact. That is why mature AppSec programmes need risk-weighted triage, context on where weaknesses sit in the stack, and evidence that remediation actually changed the release decision. Metrics that only measure discovery can be gamed, while metrics that measure material risk force accountability.

Practical implication: replace volume-based reporting with risk-based measures that show what is shipping, where it sits, and whether it was accepted.

How shadow AI turns development into an unmanaged trust boundary

Shadow AI in software delivery works much like shadow IT, but with faster adoption and less visibility. Developers will use whatever helps them ship, especially when approved tools are slow or inconvenient. That creates an unmanaged trust boundary where AI coding assistants, plugins, and generated snippets can affect code quality without policy, logging, or validation. The problem is not the existence of AI use. The problem is that organisations often lack a formal control point for approving, observing, and testing AI-assisted contributions before they become production risk.

Practical implication: define policy, logging, and test gates for AI-assisted development so unofficial tools cannot bypass governance.

NHI Mgmt Group analysis

AI-generated code has turned AppSec into a governance discipline, not a tooling contest. The article shows that the central failure is no longer whether scanners exist, but whether organisations can prove what was generated, reviewed, and accepted. That pushes AppSec closer to policy enforcement, release governance, and evidence collection than to point-in-time vulnerability discovery. Practitioners should treat AI-assisted development as a control design problem.

Measurement debt is now a security liability. When leaders report only the number of vulnerabilities found, they create a false sense of control that can survive even as risky code ships. The article’s data points to a widening gap between operational reality and executive reporting, which means the next control failure is often managerial before it is technical. Security teams need risk-weighted evidence, not vanity metrics.

Shadow AI in development is a visibility problem before it is a code-quality problem. If developers can bypass approved tooling with consumer AI assistants, the organisation loses the ability to enforce policy at the point of code creation. That is a governance gap with identity-adjacent consequences because the trust boundary now includes developer access, tooling permissions, and pipeline authorisation. Practitioners should govern the toolchain as tightly as the codebase.

AppSec programmes must now align engineering speed with verifiable trust. The panel’s strongest point is that organisations cannot keep rewarding velocity while expecting stable assurance outcomes. As AI compresses development cycles, the control model must move earlier in the lifecycle and tie release approval to observable evidence. The practical conclusion is clear: security teams need to govern trust at creation time, not after deployment.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Maturity Model

What this signals

AI-generated code has created a measurement problem as much as a security problem. When organisations optimise for delivery velocity without proving provenance, they create a governance debt that shows up later as untrusted code in production. For IAM and identity-adjacent teams, the lesson is that tooling permissions, pipeline access, and approval logic now matter as much as scan results.

Shadow AI will keep expanding until organisations govern the point of creation. One in five developers admits to using AI coding assistants without permission, and 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey. That is a strong signal that security programmes need earlier controls, not more after-the-fact reporting.

For practitioners

• Define policy for AI-assisted code creation Publish a formal rule set for when AI coding tools may be used, what data they can access, and how generated code must be reviewed before merge.
• Shift reporting from counts to risk Replace raw vulnerability totals with measures that show exploitability, business context, ownership, and whether risky code was accepted or remediated.
• Gate production on verified testing evidence Require test results, provenance checks, and approval evidence before code can move from repository to deployment, especially when AI helped generate it.
• Inventory shadow AI in the delivery chain Identify where developers are already using unapproved assistants, extensions, or browser-based tools so policy can be enforced where work actually happens.
• Tie AppSec metrics to business decisions Report which vulnerabilities are being accepted, why they matter, and who approved the release so leadership can compare risk across teams and products.

Key takeaways

• AI-assisted development is widening the gap between code creation and code trust, which makes governance and evidence more important than scan volume.
• The article’s data shows that vulnerable code is already being shipped at scale, so risk reporting has to move beyond raw counts to decision quality.
• Security teams need to control AI use at the point of code creation, because later-stage review cannot fully recover lost provenance or accountability.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• 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.
• AppSec governance: The set of policies, ownership rules, review gates, and evidence requirements used to control application security outcomes. In AI-heavy delivery environments, governance must operate earlier in the pipeline because late-stage review may no longer have enough time or context to be effective.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.

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 the NHI Foundation Level course if your programme needs a stronger foundation in governance for machine identities and AI-assisted workflows.