AI code verification is lagging behind agent-generated output

At a glance

What this is: Sonar is seeking survey responses on how AI-generated code changes are moving through review, verification, and production in modern development workflows.

Why it matters: For IAM, PAM, and security teams, the issue is that software change pipelines increasingly shape trust decisions, so weak verification can translate into broader identity, secrets, and access control exposure.

By the numbers:

• 42% of committed code was AI-generated in last year’s State of Code survey.
• Only 48% of software developers always verified AI output before committing it.
• The survey reached more than 1,100 professionals, giving the findings a broad practitioner base.

👉 Read Sonar's call for responses to the next State of Code developer survey

Context

AI-generated code changes the control problem because the volume, speed, and authorship of software changes no longer map neatly to traditional human review expectations. The core governance question is not whether AI can produce code, but whether teams can still prove what changed, who reviewed it, and what risk was accepted before release.

In identity and security programmes, software delivery is a privilege-bearing workflow. When AI systems write more of the code and agents shape how work is reviewed, organisations need stronger controls over review integrity, change accountability, and the handling of secrets or access logic embedded in code. That makes the article relevant to both application security and the broader governance of AI-assisted development.

This starting position is now typical across teams adopting AI coding tools, but the review-pressure problem becomes sharper as agentic workflows scale.

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 coding assistants create new security review risks?

A: They can produce code that looks correct but still contains weak authentication, unsafe data flows, or hidden secret handling mistakes. Because the output is generated by pattern completion rather than system understanding, review teams must validate intent and trust boundaries. The risk rises fastest where code touches identities, credentials, and deployment automation.

Q: How do you know if AI code review controls are working?

A: Look for reduced defect density in AI-assisted pull requests, faster closure of high-severity findings, and fewer escaped issues in authentication, authorisation, and session workflows. If review volume is rising faster than remediation speed, the controls are not keeping pace. A working control plane reduces both findings and the time they remain open.

Q: Should security and engineering teams separate code generation from approval rights?

A: Yes, for any change that can affect authentication, secrets, permissions, or production access. Separation of duties reduces the chance that one automated path can create and authorise risky changes end to end. That principle becomes more important as agentic workflows compress the time between writing, review, and release.

Technical breakdown

Why AI-generated code strains review controls

AI-generated code increases the number of changes per pull request and compresses the time available for meaningful review. The technical issue is not just code quality, but review depth, because reviewers must validate intent, logic, security impact, and dependency changes at higher speed. When code arrives in larger batches, teams often rely on sampling, trust cues, or automated checks that do not fully understand business context. That creates a gap between apparent verification and actual assurance.

Practical implication: security teams should treat review throughput and review depth as measurable controls, not informal team habits.

What changes when AI reviews AI-generated code

When the same or similar model helps write and review code, the workflow can become self-reinforcing. Model-based review tools may detect syntax or known patterns, but they do not provide independent judgment unless they are constrained by policy, test evidence, and human sign-off. The risk is circular validation, where a generator and reviewer share the same blind spots. That is especially problematic for security-sensitive code paths such as authentication, secrets handling, and access checks.

Practical implication: require independent validation for security-critical changes instead of accepting model-to-model review as sufficient assurance.

Verification controls for agent-driven development pipelines

Agentic development expands the number of places where trust must be checked, including code generation, pull-request creation, automated review, and merge approval. The main control challenge is preserving traceability across those steps so teams can still answer who approved what, when, and on what basis. Effective pipelines combine policy gates, test coverage, protected branches, and exception handling for high-risk paths. Without that traceability, AI adoption can outpace governance even when the code itself looks clean.

Practical implication: map review approvals, policy exceptions, and merge rights to a traceable control chain for agent-driven changes.

NHI Mgmt Group analysis

AI-assisted development is becoming an identity and governance problem, not just a code-quality problem. When agents generate more of the software estate, the organisation is no longer governing only human developer behaviour. It is governing machine-assisted change, review trust, and the privilege to introduce code into production. That makes this topic relevant to IAM, PAM, and application governance because code pipelines increasingly decide who or what can alter business-critical controls. Practitioners should treat AI coding as a governed access path, not a productivity feature.

Verification debt: the real risk is not AI code volume alone, but the gap between generation speed and review capacity. Last year’s survey data already showed that committed code can become AI-heavy while verification remains inconsistent. Once that gap widens, teams tend to compensate with optimism, automation, or incomplete review rituals. The result is governance debt that accumulates quietly until a sensitive change escapes detection. Practitioners should measure verification capacity against actual code flow, not against team confidence.

Self-review by AI tools can create false confidence in security-critical change management. A model can check for known patterns, but it cannot independently challenge the assumptions embedded in the code it helped create. That limitation matters most where the code touches authentication, credential handling, entitlement logic, or secret storage. NHI Mgmt Group’s position is that agentic tooling should be constrained by independent policy enforcement, not allowed to define its own acceptable risk. Practitioners should separate generation, review, and approval into distinct trust boundaries.

Software delivery pipelines are now part of the organisation’s control plane. As AI systems take on more writing and review tasks, the pipeline becomes a place where access, accountability, and integrity need explicit governance. This is where application security intersects with identity security, because merge rights, branch protection, and review authority are privileged decisions. Teams that still treat developer workflow as a purely engineering concern will miss the governance implications. Practitioners should bring AI-assisted development into the same control thinking they already apply to privileged access and change approval.

What this signals

Verification debt: as AI-generated code scales, the limiting factor becomes review integrity, not code production. That shifts the programme question from "how much code can we ship" to "how much of that code can we actually validate before release," especially where code touches secrets, identity checks, or privileged operations.

Teams should expect AI-assisted development to pull application security and identity governance closer together. Review approvals, branch protection, and exception handling are now part of the trust boundary, which means access control concepts need to be applied to software delivery workflows as rigorously as they are applied to runtime systems.

For practitioners

• Measure review integrity alongside delivery speed Track the percentage of AI-authored changes that receive independent human review before merge, then compare that rate with the volume of AI-generated commits and the number of exceptions granted in protected branches.
• Separate generation, review, and approval duties Prevent the same identity, tool, or model chain from writing code, validating it, and authorising release for security-sensitive paths such as authentication, secrets handling, and privilege checks.
• Apply stricter controls to sensitive code paths Require extra test evidence, targeted review, and explicit sign-off for code that changes access logic, token handling, secret storage, or permission checks, because these patterns create downstream identity risk.
• Instrument agent-driven change traceability Log which system generated the change, which reviewer approved it, which policy allowed it through, and whether any manual override was used, so audits can reconstruct the full decision path.

Key takeaways

• AI-generated code is turning review quality into a core governance control, not a secondary engineering habit.
• The gap between code generation speed and verification capacity is where security and accountability begin to fail.
• Security-sensitive code paths need independent validation, traceable approval, and separation of duties even when AI tools accelerate delivery.

Key terms

• 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.
• Agent-Driven Development Pipeline: A software delivery workflow where AI systems generate, modify, or help assess code before it is merged. The governance challenge is preserving traceability, separation of duties, and review integrity across generation, validation, and approval steps.
• Review Integrity: The degree to which code review can independently detect unsafe, incorrect, or policy-breaking changes. Strong review integrity depends on human judgment, evidence, and traceability, not simply on whether a tool or model has produced an approval signal.
• Change Accountability Chain: The auditable sequence showing who or what created a code change, who reviewed it, who approved it, and what policy allowed it through. It is a governance control that becomes more important as automation compresses the time between writing and release.

What's in the full report

Sonar's full survey call-out covers the operational detail this post intentionally leaves for the source:

• The questionnaire prompts on AI-authored changes reaching production without separate human review.
• The specific comparison between AI writing and AI reviewing, including how teams are handling self-review concerns.
• The timing and effort questions around whether productivity gains have plateaued as agents become part of the workflow.
• The 20-minute response path for practitioners who want to contribute to the next State of Code dataset.

👉 Sonar's survey request covers how AI code review, verification pressure, and production flow are changing for developers.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle controls. It gives security and identity practitioners a shared basis for governing privileged change in modern environments.