API strategy
Agents in production
API sprawl is a governance problem until agents start calling every endpoint. Why shadow APIs, unmanaged APIs, and inventory tools all break at agent scale.
How many APIs does your company run right now? Not the ones in the developer portal — all of them. The internal ones. The ones a team spun up for a partner three years ago. The one behind the mobile app that nobody has touched since the original engineer left. The staging endpoint that quietly serves production traffic because a client hard-coded it.
Most enterprises can't answer within an order of magnitude. That gap is API sprawl, and it's about to stop being an inventory problem and start being an access problem. Agents are entering these environments and asking the exact question governance teams have avoided: what capabilities does this company actually expose, and to whom?
This piece covers what API sprawl really is, why the standard fixes stall, what shadow APIs mean when agents are the caller, and what changes when tool discovery replaces documentation as the primary interface.
Sprawl gets described as a hygiene issue — teams that failed to keep their catalogues tidy. That framing is wrong and it leads to the wrong fixes.
Enterprise APIs accumulate the way filing cabinets accumulate. A team ships a service. Another team wraps it. A third team writes a partner-facing endpoint that quietly forks the contract. A fourth team decides the auth model is wrong and builds a shim. Nothing gets deleted, because deletion breaks something upstream that nobody can fully map. Each API was rational when it was built. The sprawl is the emergent property of hundreds of rational decisions across ten years.
A large enterprise typically runs somewhere between several hundred and several thousand distinct APIs across internal services, partner endpoints, mobile backends, legacy SOAP interfaces, and the graveyard of half-deprecated versions that still see traffic. Industry surveys from vendors like F5 and Salt Security put the number higher every year. Even without a specific figure, the shape of the problem is well understood: nobody at the top of the org chart knows.
The reason this matters now is not that sprawl got worse. It's that agents are about to start calling these APIs at machine speed, on behalf of users, without the tacit knowledge that human developers use to navigate the mess. A human developer knows to avoid payments-v1 because Slack folklore says it silently drops decimal precision. An agent reads the OpenAPI spec, sees a working endpoint, and calls it.
Within the sprawl sits a smaller, more dangerous set: shadow APIs. These are APIs that are running in production but aren't in the official inventory. Nobody wrote them down. They didn't go through the standard review. They may not be behind the gateway. They may not have current auth. They almost certainly aren't in the developer portal.
Shadow APIs come from four common places:
v1 was replaced by v2 five years ago. v1 still handles traffic because one enterprise customer never migrated.Humans navigate shadow APIs by not knowing they exist. That's the whole strategy. It works because no human developer has a strong incentive to systematically enumerate every endpoint your company runs.
Agents don't have that limitation. An agent that scans your OpenAPI catalogue, plus your network traffic, plus your gateway logs, plus your public documentation, will find every endpoint your organisation exposes — including the ones your platform team doesn't know about. This is discovery as an unintended side effect of tool generation. The Model Context Protocol (MCP) makes this discovery structured and shareable; agent frameworks make it repeatable.
The uncomfortable implication: the first honest map of your API estate is likely to be produced by an agent, not by your governance team.
Three responses to API sprawl are common. None of them survive contact with agent traffic.
The first response is to put every API behind a single gateway — Kong, Apigee, AWS API Gateway, or a mix. The gateway becomes the enforcement point for auth, rate limits, and logging. Anything not behind the gateway is by definition out of policy.
This works for the APIs you know about. It does nothing for the ones you don't. Shadow APIs, by definition, aren't behind the gateway. And the gateway doesn't tell you what your APIs do — only that they exist and receive traffic. Gateways front APIs; they don't describe capability.
The second response is to build an inventory. Postman, an internal developer portal like Backstage, internal wikis, or a spreadsheet with 400 rows nobody trusts. The catalogue is accurate on the day it's compiled and starts drifting immediately.
Inventory as a documentation exercise has the same failure mode as compliance documentation: it's maintained by a team that isn't the team shipping the changes. The service team ships a new endpoint on Monday. The inventory gets updated in six weeks, if at all. By the time it's in the catalogue, the endpoint has been renamed twice.
The recent generation of API security tools — Salt Security, Akamai API Security (which acquired Noname Security in 2024), and Harness (which acquired Traceable in 2025) — improve on manual cataloguing by scanning traffic to detect endpoints in use. That's a real improvement. But scanning gives you a list of paths, not a description of capability. It tells you what's running, not what an agent should be allowed to call.
The third response — the expensive one — is to decide the whole estate is unmanageable and commission a rewrite. Consolidate everything onto a modern platform. Retire the legacy. Impose a single style guide.
Rewrites of this scale run two to five years. They compete with every other engineering priority. They rarely finish. And they don't address the underlying accumulation dynamic: the day the rewrite ships, teams start accumulating new APIs on top of it, because the pressures that produced sprawl the first time haven't changed.
All three fixes share a common assumption: that the problem is the set of APIs. It isn't. The problem is the gap between what the APIs describe and what agents need to know to use them safely.
Before agents, sprawl was a governance headache. Costly, embarrassing during audits, occasionally the root cause of a breach. But mostly it stayed a background problem, because humans navigate around it.
Agents change three things.
First, they enumerate. An agent doesn't have the human instinct to avoid unfamiliar endpoints. If a tool definition exists, it will get called. This turns dormant APIs — endpoints that see almost no traffic — into live surface area. Rate limits and auth configurations that were fine at 100 requests a day get exercised at 100,000.
Second, they cross boundaries the org chart pretends aren't there. A human developer building an integration typically works inside one product, one team's APIs. An agent working on a user task doesn't respect those boundaries. It'll cheerfully string together a call to the CRM API, the billing API, the mobile backend, and a partner endpoint if the task needs it. The seams between systems — where documentation is thinnest and shadow APIs cluster — become the primary interface.
Third, they read specs literally. Documentation drift that a human forgives (the docs say email but the field is actually emailAddress, everyone knows) becomes a runtime error. Every inaccuracy in the spec becomes a production incident. This is the same dynamic covered in more depth in OpenAPI spec drift: why your contract lies before your agents break.
The combined effect is that sprawl stops being a slow governance problem and becomes an acute reliability problem. Agent projects that work in demo stall in production because the API estate they depend on isn't as mapped as the demo assumed.
The conversation about API sprawl tends to focus on unknown APIs — the shadow ones. Those matter. But the larger risk is the unmanaged API: the endpoint everyone knows about but no one owns.
Unmanaged looks like this:
An unknown API is contained by its obscurity. An unmanaged API is dangerous because it's documented enough to be called but not maintained enough to be trusted. Agents will find these first, because they read specs and take them at face value.
The fix isn't more inventory. The fix is a shift in what "managed" means. An API is managed when three things are true: someone owns the contract, drift between spec and behaviour is detected automatically, and the runtime enforces the auth and rate-limit model the spec claims. Anything short of that is sprawl regardless of whether it's in your catalogue.
The honest read of the last decade of API governance is that inventory-based approaches never caught up with the pace of API creation. Every year the estate grew faster than the map. Agents will end that particular pattern, not by making inventory better, but by making it irrelevant.
What replaces inventory is runtime tool definition. Instead of a static catalogue that describes what APIs exist, a runtime layer generates tool definitions from the codebases and specs that actually ship, holds them against production behaviour, and exposes only the capabilities the calling identity is allowed to use. Discovery becomes a runtime property. The map is generated from the territory, not maintained alongside it.
This reframes governance. The question is no longer "do we have a complete inventory?" — a question that has been unanswerable for a decade. The question is "for a given user, what capabilities does the platform currently expose to them, and can we verify that boundary at runtime?" That's a question you can actually answer.
It also reframes shadow APIs. If tool definitions are generated from the codebase and validated against runtime behaviour, an endpoint that exists but isn't in the tool catalogue isn't a shadow API in the old sense. It's just an endpoint that hasn't been made available to agents. The exposure decision is explicit, per capability, per identity, rather than emergent from whatever a network scanner found.
Everything above is why we built Pontil as a Tools-as-a-Service platform rather than another inventory tool. The problem isn't that enterprises can't count their APIs. It's that the surface area agents need — capability, auth boundary, runtime behaviour — was never something inventory tools tried to describe.
Pontil generates tool definitions from the codebases and APIs that already exist, keeps them aligned as products change, and runs the tool runtime that executes calls as the authenticated user. What an agent can reach is defined by what's been generated and permitted, not by what a scanner happened to find. That flips the sprawl problem: unmanaged APIs stay unmanaged until someone explicitly brings them into the tools layer, at which point they get a contract, an owner, and a runtime that enforces the boundary.
This is the shift covered in more depth in Why agent projects stall. Sprawl doesn't get solved. It gets bypassed, by making the tools layer — not the API estate — the surface agents actually interact with.
Within the next few years, a rapidly growing share of calls to a large enterprise's APIs will come from agents rather than humans. That follows from the shape of what agents do: they operate at machine speed on behalf of humans, so each human user generates orders of magnitude more API traffic than they did before.
When that shift happens, every unresolved API sprawl problem gets exposed at the same time. Rate limits set for human traffic get exercised. Auth models that assumed shared service accounts break under per-user delegation. Documentation drift that humans forgave becomes tool call failures. Shadow APIs get enumerated whether the governance team wanted them enumerated or not.
The teams that get through this cleanly won't be the ones with the best inventory. They'll be the ones who decided which capabilities to expose to agents deliberately, described those capabilities in a way runtime can hold them to, and stopped treating the rest of the API estate as though it were a product surface. Sprawl doesn't have to be solved. It has to be routed around, by a layer that says clearly what agents can reach and enforces it.
The question isn't how to catalogue every API. It's what belongs in the tools layer, and what should stay in the sprawl.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
