AI-first engineering and autonomous agents change code governance

At a glance

What this is: This case study shows how autonomous agents are being used to patch code, resolve Jira stories, and remove technical debt at scale in a large engineering organisation.

Why it matters: It matters to IAM and security teams because AI agents operating inside engineering workflows need governed identities, scoped access, and verification loops before they become a source of uncontrolled change.

By the numbers:

• Cisco's internal guilds now attract over 500 engineers monthly.
• Its Webex community has 4,000 members sharing real-time AI breakthroughs.

👉 Read Sonar's case study on AI-first engineering and autonomous code remediation

Context

AI-first engineering is the use of AI systems, including autonomous agents, inside the software delivery lifecycle to automate work that once sat with human developers. The governance issue is not only code quality, but who or what is allowed to make changes, under what conditions, and with what verification before those changes reach production. This is a primary concern for identity, access, and privileged workflow control.

The Cisco example is typical of the new operating model being tested across large engineering organisations. What makes it notable is the combination of autonomous action, ticketing-system access, and structured review, which brings identity governance directly into software delivery.

The technical debt problem also intersects with non-human identity governance because the agent is effectively operating as a workload identity inside development tooling. That means access scope, session boundaries, and auditability become as important as the code fix itself.

Key questions

Q: How should security teams govern AI agents that can read tickets and open pull requests?

A: Treat the agent as a governed non-human identity with separate permissions for reading, analysing, and writing. Require explicit approval before code changes are created or merged, log every context source the agent used, and limit the ticket types that can invoke it. The goal is to preserve accountability while still reducing routine triage effort.

Q: Why do autonomous SOC agents create governance risk?

A: Because they do more than summarise alerts. They can sequence investigations, move across tools, and influence response decisions, which shifts the control problem from alert handling to authority, auditability, and accountability for actions taken across the security stack.

Q: What breaks when AI remediation runs faster than code review?

A: Review quality breaks first, followed by change provenance and rollback confidence. If reviewers cannot inspect enough AI-generated changes with sufficient context, unsafe fixes can slip through, and the organisation loses its ability to explain or reverse what the agent changed.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

How autonomous coding agents work inside Jira and SonarQube

Coda is described as a full user inside Jira, not a passive assistant. It receives a story, retrieves issue detail from SonarQube, plans a fix, patches code, upgrades dependencies, and returns a pull request for review. That pattern matters because the agent is acting across multiple systems with delegated access, which makes it closer to a governed workload identity than a chat-based copilot. The key architectural shift is that the agent is not just generating text. It is initiating state changes in engineering systems, which raises the bar for authentication, authorisation, and audit logging.

Practical implication: treat AI coding agents as scoped non-human identities with explicit access boundaries and revocation paths.

Why a three-stage verify loop reduces agentic engineering risk

Cisco's investigate, plan, and implement loop is a control pattern for reducing bad automation outcomes. Investigate gathers context from issues and documentation. Plan creates a human-readable change plan and checks. Implement runs in a fresh agent session so the execution step is separated from the planning step. That separation reduces the chance that a single session error, context drift, or hidden instruction carries straight into code changes. It also creates a clearer audit trail, which is essential when agents are making repeated changes across a large development estate.

Practical implication: split planning and execution into separate sessions so reviewable artefacts exist before code is changed.

Why technical debt and AI governance are becoming the same conversation

Technical debt management and AI governance are converging because AI can only move quickly in environments with clean issue data, structured documentation, and predictable review controls. When AI agents depend on well-formed ReadMe files, issue metadata, and code quality signals, poor governance becomes an operational bottleneck. At the same time, the more work you hand to an agent, the more important it becomes to define what it may touch, how it proves a fix, and when a human must intervene. The governance model is therefore part of the engineering stack, not an overlay on top of it.

Practical implication: align code quality governance, ticket hygiene, and agent access policy as one control surface.

Threat narrative

Attacker objective: The objective is not classic data theft, but uncontrolled code alteration through a trusted agentic workflow that can bypass normal human pacing and oversight.

1. Entry occurs when an autonomous agent is granted operational access to Jira, SonarQube, and source repositories as part of the engineering workflow.
2. Escalation occurs when the agent can plan, patch, and open pull requests across multiple codebases without tightly bounded session controls.
3. Impact occurs when automation accelerates changes faster than human review can reliably validate, increasing the risk of unsafe or unintended code becoming production-bound.

NHI Mgmt Group analysis

Agentic SDLC requires identity controls, not just code controls. When an autonomous agent can open Jira items, inspect SonarQube data, and generate pull requests, it is operating as a non-human identity inside the delivery pipeline. That means access governance, session scoping, and revocation become part of software engineering oversight. The practitioner takeaway is straightforward: if the agent can change code, it must be governed like any other privileged workload.

Technical debt automation creates a new governance debt if review is not redesigned. Clearing 27,000 issues faster is useful only if the organisation can still explain what changed, why it changed, and who approved it. AI-assisted remediation tends to raise throughput faster than manual review processes can adapt, which creates a control mismatch. Teams should measure review capacity, provenance, and rollback readiness alongside productivity.

Structured verification is the named concept this article points to. The investigate, plan, and implement loop turns agentic engineering into a repeatable control pattern rather than an open-ended automation experiment. The important point is not the loop itself but the separation of intent from execution, which helps preserve auditability and limit unintended changes. Practitioner conclusion: agentic development scales only when verification is designed as a first-class control.

AI-first engineering is becoming an identity programme as much as a development programme. The moment developers delegate work to agents, organisations inherit questions about entitlements, privilege boundaries, and accountability for machine-made changes. That is why IAM, PAM, and NHI governance now intersect with DevOps governance. The field should stop treating these as adjacent concerns and start treating them as one operating model.

The real risk is not that agents write code, but that they inherit trust too easily. Once an agent can act on Jira tickets and repository state, the trust boundary shifts from the human developer to the system that issued the delegation. That makes lifecycle control, approval design, and auditability central to safe adoption. Practitioners should assume the trust model is under redesign, not simply being automated.

What this signals

Structured verification will become the baseline for agentic engineering programmes. Teams that want the velocity gains from AI-assisted remediation will need to prove that planning, execution, and review are separated in a way auditors can follow. The operational question is no longer whether agents can fix code, but whether the organisation can still explain and reverse what they changed. That is where governance maturity will be measured.

Agentic development exposes a control gap between human review capacity and machine output. Once pull request volume rises faster than reviewers can meaningfully inspect it, the programme needs a new control model, not more informal diligence. The likely next step is tighter policy around delegated access, stronger evidence capture, and more machine-readable change provenance. The organisations that prepare now will absorb AI-driven throughput without losing control of change quality.

For practitioners

• Register AI coding agents as governed non-human identities Assign explicit ownership, least-privilege entitlements, and revocation procedures for every agent that can touch Jira, code repositories, or build systems. Map the agent's permissions to the specific systems it needs and remove standing access where possible.
• Separate planning from execution for every autonomous change Require a documented plan, validation checks, and a fresh execution session before code changes are applied. Keep the plan artefact in the ticket so reviewers can compare intent with implementation.
• Tie pull request review capacity to agent output volume Measure how many AI-generated changes reviewers can reliably inspect per day and cap agent throughput if review quality degrades. Use code review SLA data to decide when additional automation is increasing risk rather than productivity.
• Govern tool access as part of DevOps policy Review the permissions that let agents query SonarQube, read documentation, and open pull requests. Treat those entitlements like privileged workflow access, and log every delegated action for audit and rollback.

Key takeaways

• Autonomous coding agents are becoming governed actors inside the SDLC, which means identity controls now sit alongside code quality controls.
• The evidence in this case is scale plus speed, with 27,000 debt issues cleared in three months and productivity gains reaching 3x.
• Safe adoption depends on separating planning from execution, limiting delegated access, and preserving an auditable trail for every AI-made change.

Key terms

• Agentic SdLC: An agentic software development lifecycle is a delivery model where AI agents can carry out parts of engineering work with delegated system access. The governance challenge is that these agents do not just assist humans. They can take actions in ticketing, code, and review systems that need explicit control and auditability.
• Technical debt automation: Technical debt automation is the use of software or AI to identify, prioritise, and remediate code quality issues at scale. It speeds up cleanup, but it also increases the need for change control, because the volume of automated fixes can overwhelm review processes if the workflow is not designed carefully.
• 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 article

Sonar's full case study covers the operational detail this post intentionally leaves for the source:

• How Cisco structured the investigate, plan, and implement workflow for agentic remediation
• The SonarQube telemetry and coding-assistant integration pattern used to prioritise technical debt
• The practical setup behind Coda's Jira-based task assignment and pull request generation
• The implementation details behind the 27,000-issue cleanup pilot and productivity gains

👉 The full Sonar article covers the Cisco workflow, agent behaviour, and technical debt pilot in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align delegated access, auditability, and lifecycle control across modern identity programmes.