TL;DR: AI-generated and AI-assisted code now accounts for 42% of committed code, while Sonar says its users are 24% more likely to report lower vulnerability rates and 20% more likely to report lower defect rates, underscoring that verification has become the real bottleneck in modern software delivery, according to Sonar. The security shift is no longer about producing more code faster, but about embedding automated guardrails for human and agentic workflows before defects, secrets, and architectural drift reach production.
At a glance
What this is: Sonar’s year-in-review argues that AI code assurance has become the verification layer for modern software delivery as AI-assisted code volume rises and review bottlenecks shift downstream.
Why it matters: IAM and security teams should care because agentic development tools now consume and produce code, secrets, and architecture decisions in workflows that need governed verification, not just faster generation.
Context
AI code assurance is the control layer that checks software before it reaches production, and it matters more as human developers and AI agents generate code at the same time. When creation accelerates faster than review, the security problem shifts from authoring defects to governing verification, secrets handling, and architectural integrity across the delivery pipeline.
This article sits at the intersection of software supply chain security, application security, and agentic AI governance. The key governance gap is not whether AI can write code, but whether organisations can verify what those human and machine workflows produce before it becomes a production dependency.
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 does agentic coding increase security risk even when generated code looks correct?
A: Agentic coding increases risk because the agent can act, not just suggest. It can install packages, edit files, call tools, and open pull requests using a developer's permissions. That means a prompt injection, malicious dependency, or bad instruction can become an actual change, while traditional review and CI often see the result only after the risky actions already happened.
Q: What are the most important failure modes in AI-assisted software delivery?
A: The main failures are secret leakage, insecure code patterns, and architectural drift. These problems emerge when verification is bolted on after code is already in motion rather than embedded in the same workflow that creates the code.
Q: What should teams do when AI tools can modify code autonomously?
A: Require those tools to operate within a defined architectural blueprint, approved tool access, and explicit human escalation paths for sensitive changes. The point is to govern delegated action before autonomous edits accumulate into production risk.
Technical breakdown
AI-generated code needs verification at the point of creation
Traditional code scanning assumes review happens after code exists in a repository or pull request. AI-assisted development compresses that window, because code may be produced by an IDE agent, refined by another tool, and pushed before a human reviewer sees the context. AI code assurance shifts verification left and inward, so the control is exercised during generation, not after release. That matters because defects, insecure patterns, and architecture violations are easier to block when the workflow still has context. The article’s own framing shows why this is becoming a governance layer rather than a tool feature.
Practical implication: move code verification into IDE, PR, and agent workflows instead of relying on post-commit review alone.
MCP changes how AI tools consume security controls
Model Context Protocol lets AI tools call external systems and retrieve structured context, which means the verification layer can sit inside the agent’s workflow instead of outside it. In practice, that turns code analysis into an available tool for the model rather than a separate checkpoint for humans. The architectural issue is governance of delegated action: if the agent can consult analysis before making or proposing changes, then the quality gate becomes part of the machine’s operating context. That is useful, but it also means access, scope, and trust boundaries around the agent have to be explicit.
Practical implication: govern what AI coding agents can query, what context they can see, and which checks they can invoke.
Expanded secrets detection is a supply chain control, not a cosmetic feature
Secrets exposure remains one of the most common ways software delivery turns into an incident, because API keys, passwords, and tokens often move through code, IDEs, and CI/CD before anyone notices. The article’s emphasis on broader secrets pattern coverage reflects a basic control reality: if credential detection is too narrow, teams discover leaks after the repository becomes a distribution point. In software supply chain terms, this is about stopping sensitive material from entering the build and deployment path at all. That is especially relevant when AI systems generate or refactor code at scale, because they can reproduce insecure patterns quickly.
Practical implication: scan for secrets continuously in IDE, repository, and pipeline stages, with revocation tied to detection.
Threat narrative
Attacker objective: The objective is to convert accelerated software delivery into a broader attack surface by getting insecure code or exposed secrets into production systems.
- Entry occurs when AI assistants, IDE plugins, or coding agents generate or modify code before a human reviewer has full context.
- Credential exposure or insecure pattern propagation follows when secrets, tokens, or flawed logic are introduced into source, pull requests, or CI/CD workflows.
- Impact occurs when those weaknesses reach production, creating vulnerable code, leaked credentials, or architectural drift that is expensive to unwind.
Breaches seen in the wild
- JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
- Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Verification is now the governing control point in AI-assisted development. The article reflects a structural shift: teams are producing more code with AI, but the limiting factor is no longer output volume. It is whether the workflow can verify quality, security, and architecture before code becomes a dependency. For NHI Mgmt Group, that makes verification a governance discipline, not a late-stage review activity. Practitioners should treat automated code assurance as part of delivery control design, not as an optional add-on.
Agentic development creates a new trust boundary around code generation. When a coding agent can propose changes, consult tools, and iterate without waiting for a human at every step, the organisation is delegating part of the secure development process to software. That raises a governance question similar to NHI control design: who can act, on what scope, with what evidence, and under what review model? The relevant concept here is verification trust gap: the distance between code creation and code validation grows as autonomy increases. Practitioners should close that gap with workflow-native controls.
Secrets detection and architecture checks are converging into one supply chain governance problem. The article bundles secret leakage, architectural drift, and AI-generated code under the same operational reality: high-velocity creation can outpace all three forms of verification. That matters because controls often fail when they are treated as separate domains instead of a single integrity chain. For teams managing application security and identity-adjacent secrets, the implication is clear: governance must follow the code from generation through release, not stop at a single scanner.
MCP-based analysis points to a broader pattern of tool-mediated assurance. AI agents are increasingly consuming external context to make better decisions, which means security controls themselves become callable services in the workflow. This is an important design pattern for agentic AI governance because it shifts assurance closer to the point of action. The practitioner takeaway is to treat tool exposure, context scope, and verification authority as first-class controls, not implementation details.
The market signal is consolidation around platform-level verification. The article shows that code quality, security scanning, supply chain checks, and agent support are being pulled into a more integrated delivery control layer. That does not eliminate specialised controls, but it does mean practitioners will increasingly evaluate whether their security checks can operate across human and machine workflows together. Teams should expect verification to become a platform requirement rather than a point product conversation.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Verification trust gap: as AI-generated code volume rises, the control problem moves from producing code to proving code is safe before it reaches production. That changes how engineering, AppSec, and platform teams should design their gates, because the decisive control is increasingly in the workflow rather than after the workflow.
Sonar’s emphasis on integrated assurance reflects a broader market pattern: organisations are trying to unify code review, secrets detection, and architectural governance across human and machine contributors. Teams should expect the next round of control design to focus on where verification lives, who can trigger it, and how quickly it can stop risky changes.
For practitioners
- Embed verification inside developer and agent workflows Run code quality and security checks in the IDE, pull request, and pipeline stages where AI-generated code first appears, not only after merge.
- Define guardrails for AI coding agents Restrict which analysis tools agents can query, what repository or project context they can see, and which changes they can propose without human review.
- Expand secrets detection across the delivery chain Continuously scan source, build logs, and CI/CD outputs for API keys, passwords, and tokens, and tie detection to revocation workflows.
- Treat architecture as a governed control Define the intended component boundaries and dependency rules, then verify each pull request against that blueprint so AI-generated changes cannot silently create architectural drift.
Key takeaways
- AI-assisted development is pushing security teams toward verification-first controls because the main bottleneck is no longer code generation.
- Secrets, architectural drift, and insecure patterns become harder to stop once AI tools can create and route code at high speed.
- Governance now has to follow the code through IDE, pull request, and pipeline stages, or verification will always lag behind delivery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly centres on leaked secrets in code and pipelines. |
| NHI-07 — Long-Lived Secrets | Verification gaps let long-lived credentials persist inside development workflows. | |
| Recommendation — Scan code and build paths for exposed secrets and revoke credentials when leakage is detected. Reduce secret lifetime in development workflows and enforce rotation when credentials reach the pipeline. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic coding workflows raise control questions about delegated authority and scope. |
| Recommendation — Constrain agent privileges so automated coding tools cannot exceed approved action boundaries. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Secret leakage and credential exposure map directly to attacker credential access and exfiltration paths. |
| Recommendation — Map exposed development secrets to TA0006 and TA0010 and prioritise rapid containment. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s governance problem includes who and what may act inside AI-assisted workflows. |
| Recommendation — Review workflow permissions so AI tools only access the code and analysis they actually need. | ||
Key terms
- AI Code Security: AI code security is the practice of finding and controlling vulnerabilities introduced by generative coding tools and AI-assisted development workflows. It combines AppSec, policy enforcement, and runtime validation so machine-generated code is checked for unsafe logic, hallucinated dependencies, and secret exposure before production.
- Agentic Analysis: Agentic analysis is a context-aware verification approach that checks code changes made by an AI agent against project data, dependencies, and build context. It is more precise than a file-local linter because it can model cross-file behaviour and security-relevant data flow.
- Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.
- Architectural Drift: The gradual divergence between the system structure a team intends and the structure that the codebase actually expresses. It usually emerges through shortcuts, duplicated logic, and boundary violations that accumulate over time until the code becomes harder to understand and change safely.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security and identity practitioners build the control thinking needed for human and machine workflows.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org