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

At a glance

What this is: This is Checkmarx’s analysis of how agentic AI and AI-generated code are changing application security, with the key finding that governance, measurement, and validation are lagging delivery speed.

Why it matters: It matters to IAM practitioners because AI-assisted development expands the surface of identities, secrets, and delegated access that must be governed across development pipelines, workloads, and human decision points.

By the numbers:

• 81% of organizations knowingly ship vulnerable code.
• 54% of all code is now AI-generated, often without governance.
• 98% have experienced breaches in the past year.

👉 Read Checkmarx’s panel discussion and 2026 AppSec outlook on AI-generated code risk

Context

AI-generated code changes AppSec because it increases delivery speed while weakening visibility into what is actually being shipped. In practice, that means security teams are no longer only reviewing code quality, they are also trying to govern provenance, validation, and the decision rights behind release velocity. For IAM and NHI programmes, the same pattern shows up when development pipelines depend on secrets, service accounts, and machine identities that are not fully owned or measured.

The panel discussion also points to a deeper governance failure: organisations often disagree on the facts before they even disagree on the risk. That matters because security reporting, board assurances, and remediation priorities all depend on trusted evidence. The article’s starting position is typical for current AppSec maturity, not exceptional, which is precisely why the findings are relevant across identity, development, and security operations.

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 code assistants create new secret exposure risk for IAM teams?

A: Because they sit close to source code, environment files, local shells, and developer credentials. If the assistant can inspect those assets, then prompt manipulation can turn ordinary assistance into credential discovery and exfiltration. IAM teams should treat the assistant as a non-human identity with meaningful access, not as a passive UI feature.

Q: What do security teams get wrong about measuring application risk maturity?

A: They often confuse output with progress. High finding counts, more dashboards, or more scans do not prove risk is falling. Mature programmes track whether fix speed is improving, whether critical debt is shrinking, and whether teams are reducing exposure in the systems that matter most.

Q: How can organisations reduce shadow AI risk without slowing adoption?

A: Organisations should reduce shadow AI risk by discovering unsanctioned tools first, then creating a clear approval path for approved services. Security teams need logging, rate limits, and policy enforcement on AI usage so users can adopt tools safely. The objective is visible governance, not blanket prohibition.

Technical breakdown

Why AI-generated code changes AppSec governance

AI-generated code creates a governance problem before it creates a tooling problem. When output is produced by developers, assistants, and platform services together, organisations need to know who approved the logic, which dependencies were introduced, and what validation was applied before merge. In practical terms, this is less about model novelty and more about provenance, reviewability, and accountability. For identity teams, the same issue appears wherever human approval is replaced by delegated automation without clear ownership of the resulting access or behaviour.

Practical implication: tie code provenance and release approval to accountable owners, not to the presence of automated scanning alone.

How shadow AI changes control boundaries in software delivery

Shadow AI in AppSec is the use of AI tools or assistants without formal approval or oversight. That matters because the control boundary moves from the repository to the developer workflow, where unreviewed prompts, generated code, and unsanctioned assistants can shape production outcomes. The result is a governance gap, not simply a policy gap. In identity terms, this mirrors unmanaged NHI behaviour: systems are acting with implicit trust, but without lifecycle controls, attestation, or inventory discipline.

Practical implication: treat approved AI tooling as part of the software control plane and inventory it like any other privileged dependency.

Why vulnerability counts fail as a risk measure

Counting findings does not tell you whether the business is safer. A programme can generate large numbers of vulnerabilities and still leave the highest-risk issues untouched if severity, location, and remediation ownership are not tied to business context. That is why risk reporting must move from volume to consequence. In NHI and IAM programmes, the same lesson applies to service accounts, API keys, and access reviews: raw counts are not evidence of control effectiveness unless they show scope reduction and faster remediation.

Practical implication: replace raw vulnerability totals with metrics that track exposure, business impact, and time to verified remediation.

Threat narrative

Attacker objective: The attacker objective is to exploit weakly governed software delivery paths to gain durable access, expose sensitive data, or use the application as a launch point for broader compromise.

1. Entry begins when AI-generated or AI-assisted code enters the development workflow without formal governance or validation.
2. Escalation occurs when vulnerable logic, unapproved tools, or unmeasured dependencies are merged into production paths that carry secrets and privileged access.
3. Impact follows when attackers exploit the shipped weaknesses to breach applications, expose data, or reuse compromised access across the environment.

NHI Mgmt Group analysis

AI-generated code creates governance debt, not just development efficiency. When organisations cannot prove what was generated, reviewed, and approved, they inherit risk that is harder to assign, measure, and remediate. The problem is not the use of AI itself, but the lack of accountable controls around its output. For practitioners, the priority is to govern provenance before scale makes the gap invisible.

Shadow AI is the application-security version of unmanaged delegated identity. Developers will use whatever helps them ship, and that makes prohibition a weak control. The more durable model is approved usage with clear policy, logging, and validation. That intersection between AI tooling and identity governance is where AppSec becomes an IAM problem as much as a coding problem.

Vulnerability volume is a poor proxy for control maturity. Organisations can report thousands of findings and still fail to reduce exposure where it matters most. This article reinforces that risk reporting must tie technical defects to business context, because executives act on consequence, not counts. For practitioners, the lesson is to measure control effectiveness by exposure reduction and verified remediation.

AppSec and IAM are converging around the same accountability question. As AI systems generate code, recommend fixes, and influence release decisions, the identity of the actor behind the action matters more. That includes human developers, platform services, and the machine identities that move code through pipelines. Practitioners should treat software delivery as an identity-governed process, not a purely engineering workflow.

What this signals

The signal for practitioners is that AI-assisted delivery is turning software pipelines into identity-governed systems whether teams label them that way or not. As code generation, review automation, and release orchestration become more intertwined, the useful control question changes from ‘did we scan it?’ to ‘can we prove who or what changed production and why?’

Control provenance debt: when organisations cannot trace AI-assisted changes to an accountable approval path, they accumulate risk faster than they can explain it. That is where IAM, PAM, and NHI governance need to converge with AppSec, because secrets, build credentials, and deployment identities are now part of the same operational chain. The practical next step is to align policy, logging, and ownership across those layers.

Teams should also expect executive scrutiny to shift from tool counts to evidence of risk reduction. That means reporting on exposure removed, verified fixes, and the identities that control critical pipelines, rather than on the number of findings discovered. In practice, the strongest programmes will be the ones that can show which machine and human identities are allowed to move code into production.

For practitioners

• Establish approved AI-use policies for development Define which coding assistants, prompts, and generated outputs are permitted, then require logging and review for anything that touches production code or deployment logic. Make the approval path visible to developers so shadow AI is less attractive than sanctioned use.
• Bind release gates to provenance and validation Require evidence showing where code came from, what automated checks ran, and who accepted residual risk before merge or deployment. This is especially important when AI-generated code interacts with secrets, service accounts, or privileged pipelines.
• Measure remediation by exposure, not volume Track which vulnerabilities affect internet-facing systems, authentication paths, or high-value data, then measure time to verified remediation. Pair that with ownership data so unresolved issues cannot hide behind aggregated finding counts.
• Inventory machine identities in development pipelines Map the service accounts, API keys, tokens, and build credentials used by AI-assisted delivery systems, then review whether each has least privilege and a defined lifecycle. This reduces the chance that a compromised pipeline can reuse persistent access.

Key takeaways

• AI-generated code is creating a governance problem as much as a security problem, because organisations often cannot prove what was approved and by whom.
• The article’s own data show a wide gap between confidence and control, with vulnerable code still being shipped and AI-generated output spreading without governance.
• Practitioners should move from counting vulnerabilities to governing provenance, validation, and the identities that control software delivery.

Key terms

• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• 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.
• 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.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

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

• The panel’s full quotes on why developers normalise vulnerable code and how that affects remediation behaviour.
• The report-backed breakdown of how often organisations knowingly ship vulnerable code and how AI changes that pattern.
• The discussion of budget framing, tool underuse, and why security leaders struggle to justify AppSec investment to the business.
• The panel’s forward view on how agentic AI may change testing, remediation, and code validation workflows.

👉 The full Checkmarx post covers the panel debate, report findings, and AppSec governance implications in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle discipline. It helps practitioners connect identity controls to the broader security programmes that support software delivery and operational resilience.