# Agent sprawl is an architecture problem, not a security gap

New research finds most enterprise AI agents run without a shared owner. The fix on offer is a better registry. The sprawl was an architecture decision, made once per system of record.

> By Saad Bin Shafiq, Founder of Nodes · Aug 9, 2026
> Canonical: https://www.nodes.inc/blog/agent-sprawl-is-an-architecture-problem


---
Every enterprise that deployed AI agents this year now has an inventory problem. A run of enterprise surveys published this year describes the same shape from different vendors: most large organizations run agents nobody has fully cataloged, security teams cannot say how many exist, and the agents that do get counted rarely share a governance model. The fix taking hold in the market is a registry, a control plane that discovers, tags, and monitors every agent running inside the enterprise. That fixes visibility. It does not touch the reason the agents multiplied in the first place. No enterprise woke up and chose to run hundreds of disconnected agents. It ran one system of record after another that shipped its own.

## What the surveys found

Two reports published this year describe the same enterprise from two different vendors. [IBM's Institute for Business Value](https://newsroom.ibm.com/2026-06-08-new-ibm-study-finds-cios-and-ctos-face-growing-ai-control-gap-as-enterprise-deployment-scales), working with Oxford Economics, surveyed senior technology executives across dozens of countries and industries and found that most CIOs and CTOs are held accountable for AI systems they do not fully control, and that only a small minority keep a current, complete inventory of the agents already running inside their walls. [OutSystems](https://www.outsystems.com/news/enterprise-ai-agent-report-2026/) surveyed a comparable population of global IT leaders and found the same pattern from the buying side: agentic AI adoption has gone mainstream, and nearly all of those leaders now worry that the resulting sprawl is adding complexity, technical debt, and security exposure faster than governance can absorb it.

Read past the headline framing and the two reports describe the same mechanism, and it is [the same one behind every system of record shipping its own native agent](/blog/waiting-for-native-agents-is-the-wrong-bet): each one is scoped to its own system, reports through its own console, and knows nothing about the agent sitting one system over. The fleet nobody can inventory was never assembled as a fleet. It was a pile of point solutions that each arrived looking like the smallest, least risky choice available at the time.

## Why a registry fixes the symptom

A registry answers a real question: which agents exist, what can they touch, and who owns each one. That is worth having. It is also the same fix IT bought for shadow SaaS a decade ago, and it worked the same way then: it made the sprawl visible without making it smaller. An inventory does not stop the next system of record from shipping its own agent next quarter, because the incentive that produced the first wave of agents has not changed. Every vendor that owns a system of record wants its agent to be the one an enterprise standardizes on, so every one of them ships one, scoped to its own data, built to its own release calendar, governed through its own console. A registry sitting on top of that catches the drift after the fact. It cannot prevent it, because the agents were never designed to be governed as one system.

An architecture that does not produce this problem looks different from the start. Instead of one agent bolted onto each system of record, Nodes runs a single [context graph](/blog/context-graph-vs-retrieval-pipeline) across every system of record an enterprise operates, and a small set of agents reason over that one graph instead of one silo apiece. Nobody inventories this fleet later, because it was never assembled from independently shipped point solutions bought on different budgets in different quarters. It behaves as one system because it was built as one system: single-tenant, VPC-resident, with no data egress, customer-owned weights, running inside the customer's own cloud. Every workflow it proposes across those connected systems pauses for a human to approve, edit, or decline before anything executes. That single design choice removes the need most of the registry market exists to fill, because the fleet it replaces was never fragmented into separate purchases to begin with.

This is also why sprawl is the wrong word for what the surveys found. Sprawl describes growth that outran a plan. What the two reports are describing did not outrun a plan. It was never governed by one plan. Every system of record made its own agent decision, on its own timeline, and the enterprise absorbed the sum as though it reflected a single strategy. It reflected a dozen strategies, filed under one label, and the label is doing more work than the strategy is.

## Where this argument runs out

The registry case still deserves its due. An enterprise that already has three dozen agents scattered across a dozen systems cannot wait for an architecture migration before it gets visibility into what those agents can already touch. A control plane that discovers and tags existing agents is the honest, immediate answer to the accountability gap the surveys describe, and it should exist regardless of what an enterprise decides to build next. The mistake is treating that control plane as the destination instead of the bridge.

The harder question is what happens at the next system of record. A registry cannot stop a vendor from shipping agent number forty-one next quarter, because the registry does not own the decision to buy that agent. It only counts it after the purchase clears. An intelligence layer that already reasons across every connected system removes the reason to buy agent forty-one, but only for the systems it already connects to. Bringing a new system of record into that graph is still real integration work. It does not happen instantly, and no enterprise should be told otherwise. What changes is the shape of the decision in front of the buyer. Instead of evaluating whether to add one more standalone agent to an already ungoverned pile, the enterprise is deciding whether to extend a graph it can already govern.

There is a review cost buried in the old shape of that decision that rarely makes it into the governance conversation, and it does not require every agent to be a new vendor to add up. A native agent bundled into an existing system of record may skip the new contract and the new data processing agreement, but turning on a new agentic capability inside a platform an enterprise already runs still needs its own scope decision: what can this specific capability reach, and who signed off on it. An independently purchased point agent needs that same review plus a new contract and a new vendor relationship. Either way, when three of four agents reviewed this quarter are, in practice, reasoning over adjacent slices of the same employee or the same account, the enterprise is running that scope decision three separate times for access it has effectively already reviewed once. The registry counts each agent correctly. It has no mechanism for asking whether the third review added anything the first one had not already covered.

That collapse is not hypothetical. When a new workflow is scoped to a system already inside a shared graph, the security team is reviewing an addition to a boundary and a data flow it has already cleared, not scoping access from a blank page. The reviewer's question shrinks from what can this new capability reach, asked and answered from zero, to does this new workflow change what the already governed graph can reach, which is a narrower and cheaper question to keep answering every quarter.

That distinction gets more valuable as the number of connected systems grows, not less. An enterprise running three systems of record can probably track three agents from memory. An enterprise running ten to fifteen, a more typical range for a large enterprise than three, cannot, and every quarter without a shared graph adds one more agent nobody assigned to own.

## The proof, such as it is

Nodes runs single-tenant and VPC-resident inside the customer's own cloud, with no data egress. Thirteen agents drive sixteen decisions across three pillars, Hire & Develop, Operate & Run, Sell & Grow, reasoning from one calibrated model over one context graph rather than from separately shipped point agents bolted onto each system of record. Every workflow it proposes across those systems pauses for a human to approve, edit, or decline before anything executes, and the decision carries a record of what was read, what was proposed, and what a human did with it.

None of this replaces the registry an enterprise already needs for the agents it has today. It changes what the enterprise buys next. The question worth putting to a vendor selling agent number forty-one is not only [what the agent can see](/blog/what-agentic-should-mean-to-a-buyer). It is whether the workflow needs to exist as a separate purchase at all, whether anyone [checked which agent actually took the action](/blog/agent-identity-is-the-missing-governance-surface), or whether it belongs inside a system the enterprise can already govern.

The two reports landed the same season, and they will not be the last. Every quarter, another system of record ships another agent, and another vendor sells a better way to see the pile. Seeing the pile is worth doing. It is not the same project as declining to build the pile in the first place, and the next contract on a CIO's desk is the one that decides which project this quarter was.

## Sources

- [New IBM study finds CIOs and CTOs face growing AI control gap as enterprise deployment scales](https://newsroom.ibm.com/2026-06-08-new-ibm-study-finds-cios-and-ctos-face-growing-ai-control-gap-as-enterprise-deployment-scales)
- [Agentic AI goes mainstream in the enterprise, but sprawl raises concern, OutSystems research finds](https://www.outsystems.com/news/enterprise-ai-agent-report-2026/)

*Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.*