You Can List Your AI Tools. You Cannot List Your Agents.

Ask a platform team for a list of AI coding tools in use and you will usually get one. Seats, vendors, renewal dates, an owner for each contract. Ask the same team for a list of agents operating inside the codebase and the answer changes shape. There is a number, but it is an estimate. There is a list, but it was assembled by hand and is already out of date. And for a meaningful share of the entries, nobody can say which team is accountable for what that agent does next.

That gap has a name now, and it matters more than it sounds. A tool is procured. An agent acts. When an agent opens a pull request, touches a credential, or runs unsupervised against a service at two in the morning, the question that has to be answerable is not which vendor supplied it. It is who owns it.

For most of the last two years, AI adoption in engineering was measured in seats. A company chose a coding assistant, bought licences, assigned them to developers, and reviewed utilization before renewal. Governance meant deciding who was allowed a seat and what data the vendor could see. That model was imperfect but tractable, because the assistant only acted when a person was in the loop, and the person was the accountable party.

Agents break that arrangement in a specific way. An agent is configured once and then acts repeatedly, often without a human present for each action. It holds credentials of its own. It can be invoked from a CI pipeline, a chat command, a scheduled job, or another agent. It can be created by any engineer with repository access in an afternoon, and it leaves no procurement trail when it is.

The result is what the industry has started calling AI agent sprawl: the population of things acting on your codebase grows faster than the population of things you bought. Seat inventories still work. They just no longer describe the surface that needs governing. Most treatments of the subject frame it as a security exposure, which is where the term came from, but in an engineering organization the first symptoms show up in delivery data long before they show up in an audit.

Evidence that the gap is real, rather than theoretical, has accumulated quickly. The Cloud Security Alliance surveyed 228 IT and security professionals in January 2026 and found that 85% of organizations were already running AI agents in production, with code generation among the most common uses, while responsibility for how those agents authenticate and access systems was split across security, development, engineering and IT with no single function holding clear ownership.[1] Only 57% of respondents expressed moderate or high confidence that agent access was properly scoped.

Gravitee’s February 2026 survey of more than 900 executives and practitioners put a number on the monitoring side of the same problem: on average, respondents reported that only 47.1% of their organization’s AI agents were actively monitored or secured, and just 21.9% treated agents as independent identities rather than sharing credentials with humans or with each other.[2] Vendor-sponsored research deserves the usual discount, but the direction is consistent across sources, and it matches what the code itself shows. GitGuardian’s analysis of public GitHub found 24,008 unique secrets exposed in MCP-related configuration files, of which 2,117 were valid credentials, alongside an 81% year-on-year rise in leaked AI service secrets to just over 1.27 million occurrences in 2025.[3] Configuration files are where agents are defined. Secrets appear in them because the agent needed access and someone granted it quickly.

The security consequences of unowned agents are well covered elsewhere. The engineering consequences are discussed less, and for an R&D organization they arrive sooner.

Concurrent agents create conflicts that reviewers absorb. A July 2026 study of 33,596 agent-authored pull requests across 2,807 repositories found that 40.2% of repositories contained agent-authored pull requests whose active windows overlapped exactly, and that the textual merge conflict rate roughly doubled when the overlapping pull requests came from different agents rather than the same one: 41.7% against 19.8%.[4] Nobody planned that collision. It happened because two agents were pointed at the same repository by two different people, and no single view existed in which both were visible.

Review capacity is spent on output with no accountable requester. When an agent opens a pull request and the reviewer cannot tell who asked for the change or why, the review becomes archaeology. The same dataset shows how uneven agent output already is: merge rates ranged from 49.6% for one agent to 86.6% for another.[5] An organization that cannot attribute pull requests to a configured agent and a named owner cannot tell the difference between an agent that is earning its review time and one that is consuming it. That distinction is the subject of AI Is Writing More Code. Review Is Becoming the Bottleneck.

Spend accumulates against no cost centre. An agent left running against a scheduled job continues to consume tokens whether or not its output is ever merged. Because the agent is not a seat, it does not appear in a licence review, and because it has no owner, there is no one for a finance partner to ask. This is the same failure that makes AI budgets hard to forecast, described in more detail in High Token Usage Is Not Waste. Unaccepted Output Is., except that the unattributed portion grows on its own.

Access outlives purpose. An agent built for a migration that finished in March may still hold write access to the repository in August. Retiring an agent requires knowing it exists, knowing what it can reach, and knowing who is entitled to switch it off. The Cloud Security Alliance’s May 2026 review of non-human identity governance, citing World Economic Forum analysis, reports that 51% of organizations have no clear ownership of AI identities and that only around 20% have a formal process for offboarding and revoking API keys.[6] This is the engineering face of what identity teams call non-human identity management, a term worth knowing if the conversation reaches your security function (see the Milestone glossary for the adjacent delivery metrics).

Gartner’s forecast that more than 40% of agentic AI projects will be cancelled by the end of 2027 names three causes: escalating costs, unclear business value, and inadequate risk controls.[7] All three are downstream of the same missing artefact. You cannot control a cost you cannot attribute, demonstrate value you cannot measure, or apply a control to a thing you have not recorded.

The instinct in most organizations is to respond to sprawl with policy. Write an AI usage standard, require approval before an agent is created, circulate it, and treat the problem as governed. This rarely holds, for the same reason that a cloud spending policy never stopped anyone from launching an instance. The people creating agents are not trying to evade a rule. They are solving a delivery problem in the tool in front of them, and the agent is a side effect.

What works better is a record. A policy tells people what they should have done. A record tells the organization what exists right now, and makes the missing owner visible as a gap rather than a violation. Registries succeed where standards fail because they are populated by observation rather than by compliance.

Five facts make an agent governable. Fewer than five and something important stays unanswerable.

The first three fields are what a security or platform team would ask for. The last two are what makes the record useful to an engineering leader rather than a compliance exercise. An agent with a clean permission scope that produces a stream of pull requests nobody merges is not a governance success. It is a cost with a tidy audit trail.

A record is a starting state. What keeps it accurate is a loop that runs continuously, in the same shape Milestone applies to AI spend: observe, evaluate, govern, improve. Applied to agents, it resolves into five control points.

Discover has to be automatic. Any step that depends on an engineer remembering to declare an agent will undercount, and the agents most worth finding are the ones created fastest. Detection works from the evidence agents leave behind: commit and pull request authorship, bot accounts, tool telemetry, pipeline invocations, configuration files entering the repository.

Register is where the owner is assigned. This is the step organizations skip, and skipping it is what converts a list into an inventory that nobody acts on. An agent without a named owning team should be treated as an exception with a deadline, not as an acceptable state.

Scope sets what the agent can reach and how much it can do unsupervised. The useful move here is to separate access from autonomy. An agent may legitimately read a security-sensitive service while still being barred from merging a change to it without senior approval.

Observe is where the record earns its keep. Access data tells you what an agent could do. Delivery data tells you what it actually did, and whether the output survived. Acceptance rate, review depth, rework and 30-day code survival are the signals that distinguish a productive agent from a busy one.

Retire is the least developed practice in most organizations and the one that compounds. Retirement is not only revoking a token. It includes reassigning ownership of the code the agent produced, because that code still has to be maintained by someone after the agent that wrote it is gone.

The final piece is a posture, and posture should follow evidence rather than enthusiasm. DORA’s 2025 research, based on responses from nearly 5,000 technology professionals, found that AI functions as an amplifier of existing organizational conditions, and that AI adoption continued to show a negative relationship with software delivery stability in the absence of strong controls such as automated testing, version control and fast feedback.[8] Roughly 30% of respondents reported little or no trust in AI-generated code. Granting broad autonomy to an agent in an environment without those controls amplifies the weakness rather than the capability.

A workable model ties autonomy to two things the record already holds: the risk of what the agent can reach, and the quality history of what it has produced.

Figure 3  Agent posture by scope risk and observed quality.

The value of stating this as a matrix is that it makes the default explicit. An agent with no quality history and access to a payments service is not neutral. It is the highest-risk configuration in the estate, and it is also the most common outcome of an afternoon’s enthusiasm.

Milestone treats the agent, rather than the seat, as the unit of record. Agents Registry maintains a live inventory of the agents operating in the codebase, holding identity, owning team, permissions, cost, risk level and governance status in one place, and detecting agents from their activity rather than waiting for them to be declared.

Agent Observability supplies the outcome half of the record: contributions, acceptance rates and the collaboration signals that show where human effort is going. Agent Governance turns those signals into a posture, classifying each agent as one to expand, monitor or restrict based on contribution rate, acceptance rate and autonomy level, with policy checks applied before merge rather than in a retrospective review.

The cost field connects through AI Spend Hub and Human & Agent Spend, which attribute token, tool and agent costs against the work they produced, including autonomous agent runs, retries and loops. Teams sizing the opportunity before committing to a programme can start with the engineering efficiency ROI calculator.

Agent sprawl is usually framed as a security exposure, and it is one. But the reason it persists is more ordinary. Organizations adopted a governance model built for seats and applied it to something that acts on its own, and the artefact that model never produced was a record of what exists.

The organizations that will scale agents without losing control are not the ones with the strictest policy. They are the ones that can name every agent in the codebase, name its owner, and show what its work was worth. That is a smaller ambition than a governance framework, and a much more useful one.

1. What is AI agent sprawl?

AI agent sprawl is the uncontrolled growth of AI agents operating inside an organization’s systems without a central record of what exists, who owns it, what it can access, or what it costs. In engineering it typically appears as agents created by individual teams inside coding tools, CI pipelines and scheduled jobs, none of which leave a procurement trail.

2. How is an agent registry different from a tool inventory?

A tool inventory records what the organization bought: vendors, seats, contracts and renewal dates. An agent registry records what is acting: each configured agent, its owning team, the repositories and credentials it can reach, its autonomy level, its spend and the quality of its output. One organization can hold four coding tools and several hundred distinct agents.

3. Who should own an AI agent inside an engineering organization?

Ownership should sit with the team that operates the agent and benefits from its output, not with a central AI function. Central teams are well placed to define the record, the risk tiers and the enforcement points, but an owner who cannot change the agent’s configuration or switch it off is an escalation contact rather than an owner.

4. Can agents be discovered automatically, or do teams have to declare them?

Both, but declaration alone undercounts. Agents leave evidence in commit and pull request authorship, bot accounts, tool telemetry, pipeline invocations and configuration files, and detection from that evidence catches agents that were never declared. Declaration is useful for recording intent, purpose and ownership once an agent has been found.

5. What should happen when an AI agent is retired?

Revoke its credentials and repository access, remove it from any pipeline or scheduled job that invokes it, and reassign ownership of the code it produced to a team that will maintain it. The last step is the one most often missed, and it is the reason retired agents keep generating maintenance work long after their access is gone.