“REST is dead.” “MCP will be gone within a year”. “Tooling is the new sprawl layer.”

These are all takes we’ve read recently on the issues people are facing when it comes to connecting AI to APIs. Kelsey Hightower, for example, recently opened some interesting debate around the future of REST and MCP on Bluesky and why he’s bullish on JSON-RPC.

It can be difficult to cut through all of the noise and see where we might be heading next, so a better approach might be to look at where we are right now and how we got here. At our 2025 Platform Summit, Axway’s Rogier van Boxtel joined us to share thoughts on that based on discussions with a number of large organizations about how they create, use, and secure APIs.

He presented the idea that, in a nutshell, MCP is the next level of API sprawl. When we introduce more abstraction, as MCP does, we risk losing sight of the systems operating below the surface. If we’re being optimistic, we might see this risk as an opportunity. (Not least because the same agentic systems could be used to monitor and enforce governance at scale.)

API sprawl is a troubling issue that’s only getting worse thanks to a few API trends that are currently emerging such as MCP and AI agents. Below, we’ll explore how finally getting the problem of sprawl under control might just hold the key to where this space is heading next.

API Sprawl Is a Huge Problem

Van Boxtel kicks off his talk by walking through some API history markers, including the shift from SOAP to REST and adoption of API-first businesses in the 2010s, through to the adoption of microservices and API standards from 2016 to 2020. And, although API sprawl didn’t originate with microservices, it led to exponential API growth that has exacerbated the problem.

Quoting a VansonBourne study, van Boxtel mentions that “Almost 80% of enterprise decision-makers said that they don’t know how many APIs they have…which is quite scary.” As he says, “If you don’t know how many APIs you have, you also don’t know the quality of them. Do they meet security requirements? Do they meet design requirements? Should they be made available at all? Who’s using them?”
He outlines how API sprawl can present serious problems as development teams across multiple geographies end up working on tens, or even hundreds of internal and external APIs, with downstream applications increasingly impacted as a result.

He concludes that “until we come up with something other than agile DevOps ways of working, this will be the reality for the foreseeable future. So I’m afraid I’ll probably retire with this reality!” It’s a light-hearted remark, but one that reflects the reality of how ingrained current practices are. As such, we may need to find new or supplementary approaches to combat sprawl.

When companies are dealing with only a handful of APIs, combatting the problem of API sprawl is fairly simple: maintaining a centralized catalog of APIs, their functions, maintainers, and so on. For large organizations, however, the reality of API governance looks very different.

Ongoing API Governance Challenges at Scale

Traceable’s 2025 Global State of API Security Report found that 55% of respondents manage over 500 APIs, and 54% cite preventing API sprawl as their top API security challenge. Governance helps to regain oversight but, as van Boxtel observes, large organizations are struggling to meet the governance challenges that have intensified in the 2020s.

The result, as per that same report, is that 57% of organizations reported at least one API-related data breach in the past two years — clear evidence that weak governance leaves APIs exposed, and puts companies at risk. And, with 67% of respondents actively adopting generative AI, that increased attack surface demands stricter governance over AI-related APIs.

“I’m afraid that the AI era we are now entering, with MCP coming up a lot, won’t exactly help us to limit the governance challenges,” van Boxtel observes. “Quite the opposite, I think.”

Relaying an anecdote from consultation with Shell, van Boxtel describes a senior manager pushing all APIs through a DevOps pipeline, creating a report showing the number of APIs published in a certain period of time, then requesting follow-up meetings about them.

When requesting meetings regarding the security, business impact, and so on of those APIs, he noticed many of them being rolled back prior to them taking place. That’s not to say that the developers didn’t have faith in their work, but wanted some extra time to review their APIs when more attention was shone on them. The process generated an additional layer of accountability.

We can’t necessarily generalize from one case study, but it’s interesting to consider this as a microcosm of developers deploying APIs first and asking questions later. In breaking down monolithic architecture, that’s certainly a mindset that microservices have encouraged.

Automating API Analysis

Although conducting one-on-one API reviews is helpful, it isn’t a particularly scalable approach. Since analyzing reports about tens, or even hundreds, of APIs being released on a weekly basis isn’t viable, automation is key. “In my view,” van Boxtel asserts, “you should have as much automatic discovery as possible using agents or something like that to push things into service registries.”

But he goes on to point out that, while that’s possible for some elements of API development, you can’t easily automate the entire process. “MCP, for example, is still an emerging standard,” he observes, and is not yet ubiquitous. Its formal governance model was still evolving as recently as July 2025. So, observability tools can’t rely on a consistent interface and logs across different systems.

“The challenge,” he continues, “is that you need a single, company-wide governance layer on top of what is probably a multi-integration platform IT landscape…And the reality is that there is often more than one API gateway involved, event management platforms to consider, and often some legacy ESB. Not to mention the introduction of AI…”

With all of these factors coming together, it significantly raises the bar for governance. The above diagram offers a template for what automating some of these processes might look like: a federated API management layer or gateway, with discoverable assets in a service registry, with productized APIs made available to end users (internal or external) via a marketplace.

However, as van Boxtel points out above, the introduction of AI complicates matters further.

AI Could Be the Sugar and the Medicine

“In the next couple of months, or maybe years,” van Boxtel imagines, “we’re going to have managed MCP servers where everybody is well-organized and adhering to company standards, we’ll have some third-party MCP servers, then we’ll have a lot of unmanaged MCP servers.”

It’s a layout that closely mirrors the structure many organizations already have in place today: managed APIs, third party APIs, unmanaged shadow APIs, and other digital assets. But where APIs expose data, MCP exposes actions. And that comes with a very different risk profile.

At Axway, he jokes, “the marketing department likes to say that MCP is API sprawl squared.” Research by Metosys suggests that 43% of MCP servers are vulnerable to auth flaws, and that 33% allow unrestricted network access. With these extra layers of ambiguity in play, combatting API sprawl becomes more critical, not less.

We’re currently seeing the rise of agentic AI, which has a reputation for acting unpredictably, and event-driven systems being chained together with the likes of Arazzo workflows in real time. It’s perhaps never been more important to make sure that our proverbial ducks are all in a row.

While managing API sprawl has long been a problem, the trends shaping 2026 threaten to make the outcomes of failing to address it far more catastrophic. As a result, taming the chaos through strong governance, thoughtful automation, and greater accountability becomes more vital. That may be just the pressure that teams need to finally bring API sprawl under control.