AI code verification is lagging behind agent-generated output

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonar's research: AI-generated code is changing review workflows, with last year's survey showing that verification practices are not keeping pace with the volume and speed of AI-produced changes.

Why it matters: This matters because IAM, NHI, and application security teams increasingly need to govern code provenance, review accountability, and release trust when both humans and agents contribute to production changes.

By the numbers:

• 42% of committed code was AI-generated, according to Sonar's State of Code survey.
• Only 48% of software developers always verified AI output before committing, according to Sonar's State of Code survey.

Context

AI-assisted development changes more than authoring speed. It shifts the control problem from whether code can be produced quickly to whether the organisation can still verify what is being promoted, reviewed, and trusted before release. That matters for application security, but it also matters for identity governance when autonomous or semi-autonomous systems contribute to code that later runs with service credentials, API access, or deployment rights.

Sonar's survey call is focused on what happens after code is written, which is the right place to look. When more changes arrive from agents, the review function absorbs more volume, more ambiguity, and more responsibility for proving that code is safe enough to ship. The underlying concern is not AI novelty, but whether human review and change control still hold when the generation rate accelerates faster than governance processes.

The most important shift is that code review is no longer just a peer-quality exercise. It is becoming a security control boundary for AI-generated changes, and that makes the organisation's verification model more important than the model that produced the code.

Key questions

Q: What breaks when AI-assisted code is merged without provenance controls?

A: When AI-assisted code is merged without provenance controls, teams lose attribution, review evidence, and incident reconstruction capability. Investigators cannot tell whether a bug, policy breach, or vulnerability came from a developer, a plugin, or an external model. That makes audits incomplete and remediation slower.

Q: Why does AI-assisted development create a governance problem beyond code quality?

A: AI-assisted development changes who creates code, how fast it moves, and how difficult it is to trace. That creates a governance problem because security teams can inherit accountability without having equivalent visibility or control over the generation and approval process. The challenge is not just code quality, but enforceable oversight across the lifecycle.

Q: How can security teams tell whether code verification is keeping pace with AI output?

A: Look for smaller pull requests, stable review times, lower duplication rates, and declining defect escape rates. If review time rises while AI adoption increases, the control model is already lagging. For identity-heavy code, also watch for repeated changes to authentication, token logic, and privilege enforcement.

Q: What should organisations do first to avoid bottlenecks from AI-generated code?

A: The first move is to upgrade pipeline capacity around the places where volume accumulates, especially testing, integration, and release coordination. If those controls stay unchanged, code production outpaces validation and deployment discipline. Organisations should introduce automation, smarter resource allocation, and streamlined release management before AI output becomes the new normal.

Technical breakdown

Why AI-generated code stresses review controls

AI-generated code changes the economics of review because the reviewer is no longer assessing only human intent and coding style. Large language model output can be syntactically correct, structurally plausible, and still contain insecure logic, weak validation, or unsafe dependencies. That means the review step must detect issues that are harder to spot because the code appears polished. In practice, review becomes a control over trust, provenance, and completeness rather than a simple correctness check. For identity-aware systems, that matters when generated code touches secrets, tokens, service accounts, or authorization flows.

Practical implication: security teams should treat code review as a policy control for AI-assisted changes, not just a developer workflow.

Why AI reviewing AI creates accountability risk

When the same model class that helped write code is also used to review it, the organisation can inherit correlated blind spots. The problem is not that AI cannot assist with inspection, but that it can normalise its own patterns and miss unsafe assumptions repeated across generated output. This creates a governance gap around accountability, because responsibility for the decision to merge still sits with the organisation even if the first pass is automated. For IAM and NHI teams, that same pattern appears when automation reviews automation without an independent trust anchor.

Practical implication: require an independent human or rule-based checkpoint for high-risk AI-generated changes.

How production trust breaks when verification lags generation

The security issue is not simply that more code is produced, but that more code can reach production without a proportionate increase in review depth. Once that happens, trust shifts from validated change to assumed quality, which is a fragile operating model in environments that depend on fast releases. If agent-generated changes can bypass meaningful human review, the organisation loses a clear line between authored code and accepted risk. That is especially important where code controls access, privilege, or data handling logic.

Practical implication: align release gates to the risk of the change, not to whether it was human-written or agent-written.

NHI Mgmt Group analysis

AI-generated code creates verification debt: once agents increase the volume and speed of changes, the organisation accrues a control burden that conventional review processes were never sized for. The issue is not just output quality, but the widening gap between what is produced and what can be meaningfully checked. Practitioners should treat this as a governance debt problem, not a tooling problem.

Code review is becoming an identity and trust control: when generated code later runs with deployment rights, service credentials, or access to production data, review is indirectly governing machine behaviour. That makes code provenance part of identity governance, especially where build pipelines, secrets, and runtime entitlements intersect. Teams should align code review with the access model the software will inherit.

AI reviewing AI needs an independent trust anchor: correlated generation and evaluation can hide systematic errors that look consistent across both steps. A separate control plane, whether human approval, policy enforcement, or static analysis, is needed to break that correlation. Practitioners should not assume model-assisted review restores assurance simply because it adds speed.

Verification lag is now the real control failure: the decisive risk is not that AI writes code, but that organisations accept more changes than their verification model can actually examine. That shifts the security question from authoring to acceptance, and acceptance is where release trust is won or lost. Teams should measure whether review capacity rises with generation volume, not after it.

Agentic development changes the shape of software governance: as code generation becomes routine, security and engineering leaders must reframe release controls around provenance, review independence, and exception handling. Existing workflows can still work, but only if they are redesigned for AI-era throughput. Practitioners should update governance now, before verification becomes a bottleneck that silently weakens control.

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 Agent Observability, Audit and Incident Response Guide

What this signals

Verification debt is now a software governance problem: the more code agents generate, the more organisations need a clear acceptance model that proves changes were reviewed independently before release. Without that, review becomes ceremonial and security inherits blind trust in code provenance.

AI code review should be treated as a control boundary, not a productivity feature: once generated changes touch secrets, auth paths, or deployment logic, review quality becomes part of the access model for production systems. That is where identity governance and application security now meet.

Practitioners should expect pressure to increase on change control, release approvals, and policy enforcement as AI-generated contributions rise. The right response is to tighten acceptance criteria for sensitive changes rather than assume generic code review will scale on its own.

For practitioners

• Separate generation from approval Require an independent reviewer or policy check for AI-generated changes before merge, especially for code touching secrets, authentication, privilege, or data handling logic.
• Risk-rank review depth Apply stricter review and testing gates to changes that modify access control, deployment paths, or production-facing automation, because those changes can amplify AI coding mistakes.
• Track verification coverage Measure how often AI-authored changes receive full human review, and compare that rate with the proportion of AI-generated commits moving through the pipeline.
• Review AI-assisted review workflows Assess whether model-assisted code review is being used as a decision aid or as a substitute for accountable sign-off on high-risk changes.

Key takeaways

• AI-generated code changes the security meaning of code review, because the control now has to validate trust, provenance, and risk rather than just style or correctness.
• The survey data in Sonar's previous round showed a clear gap between AI output and verification behaviour, with 42% of committed code generated by AI and only 48% of developers always verifying before commit.
• Teams should raise the assurance bar for changes that affect secrets, authentication, deployment paths, or production data, because those are the places where verification lag becomes a release risk.

Key terms

• AI-Generated Code: Code produced wholly or partly by a model or agent rather than authored line by line by a human developer. The governance issue is not provenance alone, but whether the resulting change can be independently reviewed, tested, and accepted with the same assurance as human-written code.
• Verification debt: The accumulated gap between the identities an organisation manages and the confidence it can still have in validating them at the moment of access. It grows when verification, entitlement review, and offboarding do not keep pace with identity sprawl.
• Review Independence: The degree to which the person or system checking a change is separate from the person or system that produced it. Independent review matters because correlated generation and evaluation can miss the same flaws, especially in access control, secrets handling, and deployment logic.
• Control boundary: The line that defines who can administer, observe, and change a system. For NHI and IAM programmes, the control boundary matters because auditors and risk teams care about where authority sits, not just where the software runs. Clear boundaries make assurance easier; blurred ones create governance debt.

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 practitioners who need to connect access, automation, and governance across modern delivery pipelines.