Every AI agent you deploy is a new integration. It is a set of connections, permissions, and API calls that something has to govern. Add agents faster than you govern them and you do not get an AI advantage – you get agent sprawl: more connections, more attack surface, and more ways for things to break at 2 a.m. The fix is not a better model. It is API governance.

This is not a new problem wearing a new label. It is the agentic-era version of one enterprises already know: API sprawl. F5 estimates roughly 200 million APIs in use in 2026, on a path toward nearly 2 billion by 2030 (F5, 2026). Most enterprises already cannot say precisely how many APIs they run. Agents make that worse, fast.

Here is why. A human calls one API at a time. An agent discovers tools, chains calls, and acts across systems – often with broad permissions and no one tracking what it touched. In Postman’s 2025 survey, 51% of developers named unauthorized or excessive API calls from AI agents as their top security concern, yet only 24% design APIs with agents in mind (Postman, 2025). You are pointing autonomous software at an estate that was built for humans.

Analysts are already naming the pattern. Forrester puts it bluntly: governance gaps drive “agentic sprawl,” and more than half of enterprises report it even after adopting a formal AI framework, because “a policy document can’t control an autonomous, tool-invoking system” (Forrester, 2026). That is the whole argument in one line: agents are not governed by intentions. They are governed by the control plane they run on.

For a CIO, enterprise architect, or integration lead, that reframes the problem. Agentic AI is not primarily a model decision. It is an integration and governance decision. This article makes the case for treating API management and API governance as the control layer for agents, shows what that means for your architecture, and gives you a decision framework you can apply before the sprawl outruns you.

Why Agent Sprawl Moved Up the Agenda

Bottom line: agent sprawl became a board-level issue the moment agents stopped being demos and started acting on real systems. Three things happened at once – adoption outran governance, agents multiplied connections, and the security bill came due.

Adoption outran governance

Enterprises spent 2025 and 2026 racing to deploy agents. Governance did not keep pace. Forrester’s read is that most organizations are stuck in pilots precisely because they lack orchestration and runtime governance, not because the agents do not work (Forrester, 2026).

The gap is structural. A policy document is written for people who can read it and choose to comply. An agent does not read your governance deck. It does what its permissions and its tools allow, at machine speed. When adoption runs ahead of the control plane, sprawl is the default outcome, not the exception.

Agents multiply connections, not just tasks

A single agent rarely touches a single system. It discovers tools, calls multiple APIs, chains those calls, and often spawns or invokes other agents. Each of those is a connection with a permission attached.

Now multiply that across teams. In practice, different teams build overlapping agents independently, with duplicate tools and unmanaged permissions and no shared registry of what exists. That is the same shadow-IT dynamic that produced API sprawl in the first place – only faster, because building an agent is now a natural-language task, not an engineering project.

The security bill is already arriving

APIs are the attack surface, and the numbers are moving in the wrong direction. Akamai’s research found average daily API attacks per organization rose 113% year over year (Akamai / SOTI, 2026). Broken authentication and unsafe consumption of APIs remain leading causes of breaches, per the OWASP API Security Top 10 (OWASP / Akamai, 2025).

Agents make this sharper because they consume APIs at scale and can leak or misuse credentials if their access is not scoped. Postman found nearly half of developers worry about AI systems accessing sensitive data or sharing API credentials (Postman, 2025). An ungoverned agent is not a productivity tool with a bug. It is a fast, tireless actor with keys to systems nobody fully inventoried.

Why vendors are reacting now

You can see the market pricing this in. MuleSoft’s 2026 Connect:AI series centered on Agent Fabric, positioned explicitly as an “Enterprise Agent Control Plane” – discover agents, register them, govern their access, and observe what they do (MuleSoft, 2026). As Salesforce’s Matt DeTroia framed it, “the challenge no longer lies in introducing AI. It’s in building the architecture to manage it once it’s everywhere” (MuleSoft Connect:AI SF, 2026).

Take that as market validation, not a product endorsement. When integration vendors start selling a control plane for agents, it confirms the underlying point: the industry has recognized that agent sprawl is an integration and governance problem. The next section unpacks why that framing is the correct one.

The Enterprise Problem Behind It: Sprawl Is an Integration Problem

Bottom line: agent sprawl is not a new problem. It is integration debt with an autonomous actor attached. If you already struggle to see and govern your APIs, agents will find every gap and act on it. The problem to solve is integration, not intelligence.

You cannot govern what you cannot see

The foundational issue is visibility. F5 estimates most APIs have a shelf life of about a year, and enterprises routinely run 10-20% more active APIs than they are aware of (F5, 2026). Shadow APIs – undocumented, unmanaged, sometimes forgotten – make up a large share of the estate.

Now hand that estate to agents. An agent does not know which APIs are sanctioned and which are shadow. It uses whatever it can reach. A discovery and inventory gap that was a manageable risk with human developers becomes an active liability the moment an autonomous system starts calling those endpoints on its own.

Sprawl is expensive before anything breaks

Integration debt has a running cost, not just a failure cost. Industry data points to roughly 30% of engineering time going to integration maintenance, with a meaningful share of automated connections failing quietly in the background (AMW Group, 2026). Enterprises now run an average north of 1,000 SaaS applications, and a large portion are not cleanly connected to anything (AMW Group, 2026).

That is the tax you pay for enterprise application integration that grew organically instead of by design. Every unmanaged connection is a small ongoing cost in maintenance, brittleness, and risk. Agents do not reduce that tax. They compound it, because each agent adds connections faster than any team can document them.

Why agents make integration debt dangerous, not just costly

There is a qualitative shift here, not only a volume one. Integration debt used to fail slowly and visibly – a broken sync, a stale report, a nightly job that did not run. A human noticed and fixed it.

An agent changes the failure mode:

• It acts on bad connections. A stale or wrong integration does not just produce a stale number. The agent takes action on it.
• It amplifies weak interfaces. An API with loose validation or broad scope is a minor risk when humans use it carefully. It is a real risk when an agent hits it thousands of times.
• It hides its own tracks. Without observability, you cannot reconstruct which connection an agent used or why it did what it did.

Agentic automation cannot outrun integration debt. It runs straight into it, faster.

The reframe that changes the roadmap

Put the pieces together and the conclusion is hard to avoid. The blocker for agentic AI is not model quality. It is:

Symptom teams blame	Actual root cause
“The agent is unreliable”	It is acting on untrustworthy or undocumented integrations
“The agent did something it shouldn’t”	Its API access was never scoped or governed
“We can’t scale past the pilot”	There is no inventory or control plane for the connections agents use
“Security flagged the project”	Sprawl created an attack surface nobody owns

Every one of these is an integration and governance problem in disguise. Which is why the answer is not another model or another agent framework. It is a control plane for the connections themselves – the subject of the next section.

API Management as the Control Plane for Agents

Bottom line: the control layer for agentic AI already exists, and most enterprises already own part of it. It is API management. The job now is to extend it from “managing APIs for developers” to “governing how agents discover, access, and use those APIs.”

What API management actually does

Strip away the vendor language and API management is the discipline of putting a governed layer between the systems you run and the things that call them. It handles the unglamorous controls that decide whether access is safe: authentication, authorization, rate limiting, versioning, monitoring, and lifecycle management from publication to retirement.

For years that layer existed mainly to serve human developers and their applications. The consumer has changed. The consumer is now an agent – and an agent needs the same controls, applied more strictly, because it moves faster and asks for more.

The four jobs a control plane has to do for agents

Whatever product you use, an effective control plane for agentic API integration has to do four things. This is the checklist, not a feature list:

1. Discover. Find every API and every agent in the estate, including the shadow ones. You cannot govern an inventory you do not have.
2. Register. Put approved APIs and agents in a single catalog, so there is one source of truth for what exists and what is sanctioned.
3. Govern. Enforce scoped, least-privilege access at runtime – which agent can call which API, under what identity, with what limits. Policy that is enforced by the gateway, not by a document.
4. Observe. Log every call an agent makes, so you can monitor behavior, prove compliance, and reconstruct what happened after the fact.

Discover, register, govern, observe. If your architecture cannot do all four for agents, you do not have a control plane. You have a hope.

This is what the market is now building

The pattern above is not theoretical. It is exactly how integration vendors are now structuring their agent tooling. MuleSoft’s Agent Fabric, for instance, is organized around discovery (agent scanners and a registry), orchestration, governance (a gateway with scoped agent identity and a “kill switch”), and observability (MuleSoft, 2026). Its A2A Bridge extends the same governed approach to agent-to-agent connections across platforms (MuleSoft, 2026).

Read that as convergence, not as a single right answer. Different vendors will implement discover-register-govern-observe differently, and the specific tool matters far less than whether your architecture delivers those four functions at all. The principle is portable. The product is a choice.

Design for agents, not just for humans

There is one architectural shift worth calling out, because most enterprises have not made it. Postman found that only 24% of teams design APIs with agents in mind, while 60% still design for humans only (Postman, 2025).

That gap matters. APIs built for human developers assume a careful, low-volume caller who reads documentation. Agents are the opposite: high-volume, literal, and only as safe as the interface allows. Designing APIs to be consumed by agents – clear contracts, strict validation, predictable errors, scoped permissions – is what turns a control plane from a gatekeeper into an enabler. It is the difference between an estate that can safely support agents and one that merely tolerates them until something goes wrong.

Governance, Security, and Cost Trade-offs

Bottom line: API governance is not free, and anyone who tells you otherwise is selling something. It adds friction and cost. The honest case is that the friction is cheaper than the alternative – and the alternative has a price tag that is already public.

What ungoverned access actually costs

Start with the downside, because it is quantified. Akamai’s 2026 study found 87% of organizations experienced at least one API security incident in the prior year, with a material average financial impact per organization (Akamai / Zuplo summary, 2026). Broken authentication alone accounts for roughly half of API breaches (Wallarm, 2026).

A caveat worth stating plainly: breach-cost estimates vary widely across vendor reports, so treat any single dollar figure as directional rather than precise. The direction, however, is not in dispute. APIs are now a primary attack surface, incidents are common, and each one carries real cost in remediation, downtime, and trust. Agents raise the stakes because they widen that surface and act on it autonomously.

The trade-offs nobody puts on the slide

Every control that makes agent access safer also costs you something. Pretending the trade-offs do not exist is how governance gets skipped, so name them:

The control	What it costs you	Why it is usually worth it
Scoped, least-privilege access	Slower agent setup, more configuration	Contains the blast radius when an agent misbehaves
Full observability and audit logs	Storage, tooling, and monitoring overhead	Turns an incident from “unknown” into “explainable and fixable”
Design-first API standards	Upfront design time before code	Prevents the sprawl and shadow APIs that cost far more later
Central registry and approval	Some loss of team autonomy and speed	Stops duplicate agents and unmanaged permissions

The pattern is consistent: API governance trades a known, upfront cost for a lower, more predictable long-run cost. Ungoverned sprawl does the reverse – it feels free now and bills you later, at a time you do not choose.

Cost control is part of governance, not separate from it

There is a second cost dimension specific to agents, and it is easy to miss. Agents consume compute and model tokens every time they run, and an ungoverned agent can run far more than it needs to. This is why FinOps-style controls are showing up inside agent platforms – routing simple requests to cheaper models, trimming prompts, and capping runaway usage (MuleSoft, 2026).

The lesson generalizes beyond any one product. Governance for agents is not only about security and access. It is also about spend. A control plane that cannot answer “which agent is costing us the most, and why” is only doing half its job.

The principle to hold onto

Governance is enforced by architecture, not by good intentions. Every trade-off above is really the same decision made once, up front, in the control plane – versus made badly, repeatedly, by every team that ships an agent without one. The first is a budget line. The second is a series of surprises. The final section turns this into a decision framework you can actually apply.

A Decision Framework for Enterprise Leaders

Bottom line: you do not need to boil the ocean. You need to decide, in order, whether you can see your connections, control them, and afford them – before you scale agents on top of them. Here is the sequence.

Step 1: Establish visibility before you add anything

You cannot govern what you cannot see, so inventory comes first. Before approving new agents, answer three questions honestly:

• Can you produce a current inventory of your APIs, including the shadow ones?
• Can you list every agent already running in your environment, and who owns each?
• Can you see, for any agent, which systems it can reach and under what identity?

If the answer to any of these is no, that is your first project. Not the next agent. Discovery is not glamorous, but every later control depends on it.

Step 2: Put the four control functions in place

Map your current state against the control plane functions from earlier, and be honest about the gaps:

Function	Question to answer	If the answer is “no”
Discover	Can we find all APIs and agents, including shadow ones?	Start here – nothing else works without it
Register	Is there one catalog of approved APIs and agents?	Build the single source of truth next
Govern	Is access scoped and enforced at runtime, not on paper?	This is your biggest risk – prioritize it
Observe	Can we log and reconstruct what every agent did?	Fix before any agent runs unattended

Work them in that order. Discovery and registration make governance possible; governance and observability make scale safe.

Step 3: Match governance rigor to the stakes

Not every agent needs maximum control. Over-governing a low-risk internal helper wastes effort; under-governing a customer- or finance-facing agent invites the incident. Calibrate:

Agent risk level	Example	Governance posture
Low	Internal, read-only, reversible actions	Light: registry entry, scoped read access, basic logging
Medium	Customer-facing or writes to business systems	Moderate: least-privilege access, full audit trail, human review on sensitive actions
High	Regulated, financial, or acts on core systems	Maximum: strict scoping, approval gates, complete observability, constrained autonomy

Step 4: Decide build vs. buy vs. extend

Most enterprises already own an API management layer. The realistic question is rarely “build a control plane from scratch.” It is:

1. Extend what you have if your current API management platform can be pushed to discover, register, govern, and observe agents. Cheapest path when it fits.
2. Buy a dedicated agent control plane if agent governance is a first-class need and your existing tooling cannot cover it. Faster, but adds a platform to own.
3. Build selectively only for the gaps a product cannot close in your specific environment. Rare, and rarely the whole thing.

The wrong move is a fourth option nobody chooses on purpose: do nothing, and let each team improvise. That is not a decision. It is how sprawl wins by default.

The one question that orders everything

If you take a single question into your next architecture review, make it this: can we see, scope, and audit every connection an agent uses – today? If yes, you can scale agents with confidence. If no, you have found the work that has to come first. Everything in this framework is just a structured way of getting to yes.

Summary and Practical Checklist

The argument in one line: agent sprawl is integration debt with an autonomous actor attached, and API governance is the control layer that keeps it manageable.

Five takeaways to leave with:

1. Agents are integrations. Every agent is a bundle of connections, permissions, and API calls. Treat it as an integration problem, because that is what it is.
2. Sprawl is the default, not the exception. Adoption outruns governance, agents multiply connections, and shadow APIs fill the gaps. Without a control plane, sprawl wins by default.
3. The blocker is not the model. Unreliable agents, security flags, and stalled pilots are usually integration and governance problems in disguise.
4. API management is the control plane. Discover, register, govern, observe. If your architecture cannot do all four for agents, you do not have control – you have hope.
5. Governance is a budget line, not a wish. It has a real, upfront cost. Ungoverned sprawl has a larger, unpredictable one that arrives on someone else’s schedule.

The pre-agent readiness checklist

Run this before you approve the next agent:

• Inventory every API, including shadow APIs, in one place.
• Inventory every agent already running, with a named owner for each.
• Map what each agent can reach, under what identity and permissions.
• Scope all agent access to least privilege, enforced at the gateway – not in a policy document.
• Log every agent action so behavior can be monitored and reconstructed.
• Set cost controls so no single agent can run up unbounded spend.
• Match governance rigor to each agent’s risk level.
• Decide build vs. buy vs. extend deliberately, before teams improvise their own.

If most boxes are unchecked, the finding is not “we are behind on AI.” It is “we have an integration and governance gap that agents will find first.”

FAQ

What is agent sprawl?

Agent sprawl is the uncontrolled growth of AI agents across an enterprise – multiple teams building overlapping agents, each adding connections, permissions, and API calls that no one tracks centrally. It is the agentic-era version of API sprawl and shadow IT. The risk is not just clutter: ungoverned agents act on systems autonomously, so sprawl becomes an active security and reliability problem rather than a passive one.

Why is agent sprawl an integration problem rather than an AI problem?

Because agents create value by connecting to systems, and they fail by connecting to them badly. Most agent failures – unreliable output, unauthorized access, stalled pilots – trace back to untrustworthy data or ungoverned API access, not to the model itself. A better model on a poorly integrated, ungoverned estate simply takes wrong actions faster. Fixing the integration and governance layer is what makes agents safe to scale.

What is the difference between API management and API governance?

API management is the operational layer that controls how APIs are accessed – authentication, authorization, rate limiting, versioning, monitoring, and lifecycle. API governance is the set of standards and policies that decide how APIs should be designed, secured, and managed consistently across the organization. In practice they work together: governance defines the rules, and API management enforces them at runtime. For agents, you need both – rules that are actually enforced by the gateway, not just written down.

How do we start governing AI agents without slowing everything down?

Start with visibility, not restriction. Inventory the APIs and agents you already have, put them in one registry, and scope access to least privilege for the highest-risk agents first. Match governance rigor to risk – keep it light for low-risk internal agents and strict for anything customer-facing or regulated. This sequencing gives you control where it matters most without adding friction everywhere, and it usually surfaces duplicate or shadow agents you did not know were running.