TL;DR: 64% of developers now use agentic AI tools, with documentation, test generation, and code review emerging as the top use cases, according to Sonar’s State of Code Developer Survey, but effectiveness remains uneven and high-risk patching is still relatively rare. The security issue is not agent adoption itself, but the absence of deterministic verification as autonomous workflows scale.
At a glance
What this is: This is Sonar’s analysis of how developer use of agentic AI is shifting from simple assistance to goal-driven workflows, and the key finding is that verification remains weaker than adoption.
Why it matters: It matters because identity, access, and approval boundaries are now being stretched by software that can act with more autonomy, which changes how IAM, NHI, and human oversight must be governed across development pipelines.
By the numbers:
- 64% of developers now use AI agentic tools, showing that autonomous workflows are moving into everyday development work.
- 68% of developers use agents for documentation creation, making it the most common agentic use case in the survey.
- Only 52% of developers rate agents as highly effective for automated code review, leaving a visible trust gap in verification workflows.
- Only 28% of developers use agentic AI for security vulnerability patching, suggesting teams still reserve high-risk remediation for human control.
👉 Read Sonar's State of Code survey findings on agentic AI and verification
Context
Agentic AI changes software delivery because it can plan and execute multi-step work rather than merely suggest a single next action. In development environments, that shifts the control problem from prompt quality to governance of action, approval, and verification across the pipeline. The primary issue is not whether AI can generate output, but whether organisations can bound what that output is allowed to change.
For identity practitioners, the intersection is direct. Agentic systems that create code, trigger tests, or review changes can behave like non-human identities when they are granted persistent credentials, tool access, and execution rights. That means IAM, PAM, and NHI governance now need to cover not just human developers, but the systems acting on their behalf, especially where autonomous actions can move from suggestion to code commit without enough review.
Sonar’s starting point is typical of where most engineering teams now are: adoption is rising faster than deterministic verification. That imbalance is familiar across identity programmes as well, where access is often easier to grant than to continuously prove safe.
Key questions
Q: How should security teams govern AI-enabled workflows that can act on their own?
A: Treat them as identity-governed execution paths, not just software features. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.
Q: Why do AI coding tools increase verification risk in CI/CD pipelines?
A: They increase risk because they can produce plausible output faster than humans can inspect it, which raises the chance that defects, insecure patterns, or brittle fixes pass through review. The main issue is not speed alone, but the shrinking window for independent validation before code reaches production.
Q: What breaks when autonomous coding agents are given broad access?
A: Control breaks down when the agent can move across tools and repositories without tight limits on scope, attribution, or revocation. Broad access turns the agent into an uncontrolled identity layer, making it harder to know what was changed, who approved it, and whether the permissions still match the task.
Q: How do organisations reduce the risk of AI-generated code reaching production?
A: They need policy-driven gates that require tests, static analysis, and human approval for high-risk changes before deployment. The best control is not more generation tooling, but a stronger assurance layer that stops unsafe changes from crossing the release boundary.
Technical breakdown
How agentic coding workflows change control points
Agentic AI in development is different from a chatbot because it can chain actions across tools, such as generating code, running tests, and opening or updating pull requests. That creates a runtime control problem, not just a content-generation problem. The system needs permissions, execution context, and guardrails that define what it can touch, when it can act, and how its actions are validated. In identity terms, the agent is operating with delegated authority that may outlive the original human prompt. The main architectural risk is that speed increases faster than review discipline.
Practical implication: bind agent actions to scoped permissions, short-lived credentials, and explicit approval gates before code reaches a protected branch.
Why verification becomes the real security layer
Deterministic verification means the output is checked by a control that does not depend on the agent’s own judgment. In software delivery, that includes automated tests, policy checks, static analysis, and approval workflows that can fail closed. This matters because agentic systems can produce plausible but incorrect outputs at scale, and human review alone does not keep pace once workflows become continuous. The article’s core signal is that generation is now abundant, while trust in the resulting code is not. That gap is where security debt accumulates.
Practical implication: treat verification as a mandatory control plane, not a downstream best-effort review.
What happens when autonomous tools hold NHI-like access
When an AI agent can act across repositories, CI systems, ticketing tools, and cloud services, it effectively behaves like a non-human identity with delegated access. If that access is persistent, overly broad, or hard to attribute, the organisation loses clarity over who or what made a change. That is where NHI governance becomes relevant to AI delivery. The same lifecycle concerns that apply to service accounts, tokens, and workload identities now apply to agent credentials and tool permissions. Without lifecycle visibility, the agent becomes another uncontrolled identity layer.
Practical implication: inventory agent credentials alongside other NHIs and enforce lifecycle ownership, revocation, and auditing.
NHI Mgmt Group analysis
Agentic coding is becoming an identity governance problem, not just a productivity trend. Once software can create, test, and review code across multiple systems, it needs governed credentials and bounded authority like any other non-human identity. The security question is no longer whether the agent is helpful, but whether its access can be constrained, attributed, and revoked with the same discipline applied to service accounts. Practitioners should treat agentic workflows as part of the identity estate.
Verification bottleneck: the central failure mode is assuming generation and correctness scale together. Sonar’s data shows adoption climbing while confidence in review and patching remains lower, which means organisations are still adding output faster than they can prove safety. That creates a governance gap where the pipeline accelerates but the assurance layer does not. The practical conclusion is that delivery speed must be matched by automated, deterministic control checks.
Agent autonomy exposes the limits of human-in-the-loop security oversight. Human review works when decisions are discrete, but agentic systems can make repeated low-level choices too quickly for manual oversight to be the primary safeguard. That does not eliminate human accountability, but it changes the control model toward policy enforcement and machine-verifiable checks. Security teams should assume the review process is a backstop, not the main barrier.
Named concept: verification debt describes the growing gap between AI-generated output and the controls needed to prove it is safe. The more organisations rely on agents for routine development work, the more unresolved review, testing, and policy enforcement accumulate as hidden risk. This is especially relevant where software changes can affect authentication, secrets handling, or access paths. Practitioners should measure verification coverage as a governance metric, not just a DevOps metric.
What this signals
Verification debt: agentic adoption is creating a measurable gap between code generation speed and the controls needed to prove safety. Security and engineering leaders should watch for this debt wherever AI can create change faster than policy can block or validate it, especially in repositories that touch authentication, secrets, or release pipelines.
The governance response should not be to slow AI adoption everywhere, but to define where autonomous tools may operate without crossing into high-risk change sets. That means binding agent use to scoped credentials, explicit ownership, and auditable verification steps, with identity controls applied to the agent as a governed workload.
For teams building programme roadmaps, the practical signal is simple: if you cannot show who authorised an agent, what it was allowed to change, and what verified the result, the control model is incomplete. That gap belongs on the same risk register as any other unmanaged non-human identity.
For practitioners
- Scope agent permissions to specific development tasks Limit each agent to the repositories, pipelines, and tools required for a single workflow, and remove broad standing access that is not tied to an approved use case.
- Require deterministic verification before merge Pair every agent-generated change with automated tests, policy checks, and static analysis that must pass before a pull request can be merged.
- Inventory agent credentials as NHIs Track tokens, service accounts, and delegated access used by agents in the same inventory as other machine identities, with clear ownership and revocation paths.
- Set explicit guardrails for high-risk code changes Require additional approval for security patching, authentication logic, secrets handling, and production-bound changes even when an agent proposes the change.
Key takeaways
- Agentic AI changes software governance because autonomous workflows now need identity, access, and verification controls of their own.
- The survey shows adoption is ahead of assurance, with code review confidence lagging behind everyday agent use and high-risk patching still mostly human-controlled.
- Teams that want the productivity gains must pair agent permissions with deterministic verification, or they simply move risk from creation into remediation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack surface, NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic coding workflows raise tool misuse and autonomy control risks central to this article. | |
| NIST AI RMF | GOVERN | The article is fundamentally about governance for autonomous AI-enabled workflows. |
| NIST CSF 2.0 | PR.AC-4 | Agent workflows rely on governed access and least privilege across development tools. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is the core control for constraining autonomous tool use and repository access. |
| ISO/IEC 27001:2022 | A.5.15 | Access control policy is directly implicated when agents receive delegated development permissions. |
Apply least privilege to agent credentials and remove standing access where task-scoped access will do.
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Deterministic Verification: A verification method that produces the same enforced result every time when the required proof is present, instead of relying on human judgement or probabilistic signals. It is useful for high-blast-radius access changes because it removes discretion from the decision point.
- 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.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
What's in the full report
Sonar's full report covers the operational detail this post intentionally leaves for the source:
- Chapter-level survey results on agent adoption, effectiveness, and team size differences across SMB and enterprise environments.
- The underlying methodology and respondent breakdown behind the 1,100-plus developer sample.
- The wider State of Code findings on technical debt, trust gaps, and the engineering productivity paradox.
- The article series context covering daily AI coding habits, verification, and shadow AI in development teams.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in the context of modern security operations. It gives practitioners a structured way to govern delegated access across human and machine workflows.
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org