--- title: "Agent Sprawl Is a Board Issue. Most Cannot Count Theirs." slug: "agent-sprawl-board-issue-enterprises-cannot-count-agents" author: "Mikel Amigot" date: "2026-08-31 12:00:00" category: "Premium" topics: "agent sprawl, AI agent governance, agent inventory, shadow AI, agent registry, enterprise AI governance, self-hosted AI agents, AI control plane" summary: "96% of enterprises run AI agents and only 12% have a centralized way to manage them. SAP, Gartner, AWS and OutSystems all published the same gap this year: deployment outran inventory. The fix is an owned control plane, and the registry has to sit inside your perimeter." banner: "" thumbnail: "" linkedin: | Four separate reports landed this year saying the same thing, and the number that should worry a board is not the adoption rate. OutSystems surveyed 1,900 IT leaders: 96% of organizations already run AI agents. Only 12% have implemented a centralized platform to manage them. 94% say sprawl is compounding complexity, technical debt, and security risk. SAP's LeanIX agentic AI survey found 98% have deployed agents or plan to — and less than half have visibility into an inventory of what they are running. Gartner expects the average global Fortune 500 enterprise to be running more than 150,000 AI agents by 2028, with only 13% of organizations believing they have the right governance in place today. Read those together. Adoption is effectively universal. Inventory is the exception. Shadow IT was unauthorized software. An unauthorized agent is different in kind: it holds credentials, calls tools, moves data, and takes actions on your behalf. You cannot audit what you cannot enumerate, and you cannot enumerate what lives in someone else's control plane. That last part is the architectural question most governance frameworks skip. If your agent registry, audit log, and policy engine are features of a managed platform, your inventory is only as complete as the vendor's export, and your retention is only as long as your contract. On ibl.ai you own all the code and the data. The registry, the logs, and the policy engine run inside your own perimeter, on your infrastructure, under your retention rules — model-agnostic across any LLM, with no per-seat pricing. Governance you cannot inspect is not governance. It is a vendor's policy, applied to your data. #iblai #AgenticAI #EnterpriseAI #AIGovernance #AgentSprawl #ShadowAI --- ## The Short Answer **Agent sprawl is the gap between how fast enterprises deploy AI agents and how fast they can inventory them: 96% now run agents, but only 12% have a centralized way to manage them. The fix is an owned control plane, not slower adoption. On ibl.ai you own all the code and the data, so the agent registry, audit log, and policy engine run inside your own perimeter.** Four independent reports published in 2026 — from OutSystems, SAP, Gartner, and AWS — converge on one finding. Deployment is close to universal. Inventory is not. That gap is what "sprawl" names. It is not a story about adopting AI too quickly. It is a story about adopting it without a registry. ## What is AI agent sprawl? Agent sprawl is what happens when AI agents get created, deployed, and connected across systems faster than the organization can inventory them, assign ownership, control their permissions, monitor their behavior, and retire them when they stop being useful. The comparison everyone reaches for is shadow IT, and it undersells the problem. Shadow IT was unauthorized *software* — something installed, sitting there, consuming a license. An unauthorized agent is a different category of object. It holds credentials, calls tools, reads and writes data, and takes actions in systems of record. It does not sit there. It acts. [AWS makes the same point](https://aws.amazon.com/blogs/industries/managing-ai-agent-sprawl-across-business-units/) in its guidance on managing agent sprawl across business units, naming the specific failure modes: duplicated capabilities, conflicting actions on shared systems, credential proliferation, and costs buried inside individual business-unit budgets. Their framing of the consequences is worth quoting for its precision — silent data corruption across organizational boundaries, and compliance violations when agents cross regulatory boundaries undetected. Both are failures of *visibility*, not of model quality. ## How many AI agents does a typical enterprise actually run? More than it can count, which is the entire point. [OutSystems surveyed 1,900 global IT leaders](https://www.outsystems.com/news/enterprise-ai-agent-report-2026) for its 2026 State of AI Development report, fielded between December 2025 and January 2026. It found 96% of organizations already using AI agents in some capacity, and 97% exploring system-wide agentic strategies. Against that, 12% had implemented a centralized platform to manage them. And 38% reported mixing custom-built and pre-built agents, producing stacks that are difficult to standardize or secure. [SAP's LeanIX agentic AI survey](https://news.sap.com/2026/08/agent-sprawl-why-ai-governance-is-now-board-level-issue/), covered by SAP in August 2026, found 98% of companies have already deployed AI agents or plan to — while **less than half have visibility into an inventory of AI agents**. The forward projection comes from Gartner. Speaking at a London conference in April, senior director analyst Max Goss put the 2028 figure at more than 150,000 AI agents in use at the average global Fortune 500 enterprise, with only 13% of organizations believing they have the right governance in place today. Goss named the resulting risks as misinformation, oversharing, and data loss. ## Why can't enterprises inventory their own AI agents? Because inventory was never a deployment requirement, and because agents arrive through more doors than software does. An agent can be built by a platform team, assembled by a business analyst in a low-code tool, bundled inside a SaaS product an department already pays for, or spun up by a developer against an API key. Four procurement paths, four owners, one shared blast radius. There is also a structural reason that governance frameworks tend to skip: **an inventory is only as complete as the control plane that produces it.** If your agents run inside a managed platform, your register of them is a vendor feature. You can enumerate what that vendor chooses to expose, retain logs for as long as your contract runs, and export in the shape the vendor supports. That is adequate for a single vendor. It fails precisely where sprawl lives — across the four or five platforms an enterprise is actually running. ## What does agent sprawl actually cost? The direct answer is that 94% of those 1,900 IT leaders told OutSystems that sprawl is increasing complexity, technical debt, and security risk. That is close to unanimity on a survey question, which is rare enough to take seriously. There is a second cost, and it lands earlier than most teams expect: agents that never reach production at all. A report from Ness Digital Engineering published in August 2026 — widely covered in the trade press, and cited here as reported — found roughly 99% of companies plan to put AI agents into production while only about 9–14% have fully done so. The report calls the gap between pilot and production "Death Valley." Read against the governance data, the two findings explain each other. Pilots stall at the point where someone asks who owns this agent, what it can reach, and how we would audit it — questions that have no answer when there is no registry to answer them from. The organizations crossing that valley did not have better models. Everyone has the same models. They had integration, governance, and ownership in place before scale, not after. ## Who should own the agent registry? This is the architectural question underneath the governance question, and it is the one that determines whether the rest of your controls are real. An agent registry is only useful if it is complete, durable, and inspectable. Those three properties are all consequences of where it runs.
Governance control Managed agent platform Platform you own and self-host
Agent inventory Complete for that vendor's agents only One registry across every agent you run
Audit log retention Vendor's retention window, vendor's schema Your SIEM, your retention policy
Policy engine Vendor's rules, applied to your data Your rules, enforced in your perimeter
Model choice per agent Vendor's supported list Any LLM, switchable without migration
Cost shape at scale Per-seat, multiplied by headcount Usage-based against a cap you set
That last row is where the economics invert. Per-seat pricing bills you for employees; agent workloads do not track headcount at all, so the two curves diverge the moment agents outnumber the people who launched them — and Gartner's 150,000-agent projection says they will. ## What should a board ask about agent sprawl? Five questions, in this order. Each one is answerable only if the one before it is. 1. **How many AI agents are running right now, and who owns each one?** If the answer is an estimate, sprawl is already the operating condition. 2. **What can each agent reach?** Credentials, systems of record, customer data, outbound actions. 3. **Where does the audit trail live, and how long is it kept?** If both answers name a vendor, so does your compliance posture. 4. **What happens when we change models?** A platform that makes this a migration project has locked you in whatever the contract says. 5. **What does this cost at ten times the agent count?** Per-seat pricing answers this badly. None of these require slowing adoption. They require a control plane that exists before the agents do. ## How does ibl.ai approach agent governance? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** Applied to sprawl specifically, that architecture changes what governance can see. The agent registry is a component you run, not a report you request. Every agent invocation logs to your own SIEM under your retention rules. Policy is enforced in your infrastructure by rules your team wrote. Guardrails are programmable rather than inherited — jailbreak and injection defense, PII redaction, role-based access control, and network isolation, configured to your risk profile instead of a vendor's default. Because the platform is model-agnostic, an agent's model is a configuration value. Changing it is not a migration, which means governance decisions about which model may touch which data stay yours to make. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. ## The gap is the story Adoption is settled. Somewhere between 96% and 99% of enterprises are running agents or committed to running them, depending on whose survey you read, and the surveys agree more than survey results usually do. Inventory is not settled. Twelve percent have a centralized way to manage what they have deployed. Less than half can produce a list. That is not a maturity curve that resolves on its own, because every quarter of unmanaged deployment makes the eventual inventory harder to build. Sprawl compounds in the same direction as technical debt, and for the same reason: the cost of ordering it later is always higher than the cost of ordering it now. The organizations that will be fine are not the ones that deployed fewer agents. They are the ones that owned the control plane before they needed it. *Related: [AI Agent Governance: Managing Autonomous AI Systems Responsibly](/blog/ai-agent-governance-managing-autonomous-systems) · [Shadow AI Is Enterprise AI's Biggest Security Threat](/blog/shadow-ai-enterprise-security-threat) · [AI Agent Management: Running Agents at Scale](/blog/ai-agent-management-running-agents-at-scale)* *Related: [Sovereign AI: 67 Countries In, Firms Stalled](/blog/sovereign-ai-outpacing-enterprise-ai-what-cios-can-learn) — the same governance gap, seen from the public-sector side.* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.