Your AI agents are only as good as your APIs 

Here's an uncomfortable stat to start your week: Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. Not because the models aren't smart enough, but because of escalating cost, fuzzy value, and inadequate risk controls and governance.

In other words, the agents are fine. The foundation underneath them isn't.

And that foundation is your APIs. When an AI agent does something on your behalf, it does it through an API call: it pulls a customer record, triggers a payment, updates a system. The shiny new protocols agents use to reach your systems, like Anthropic's Model Context Protocol (MCP), don't invent a new door into the enterprise. They just wrap the APIs you already have and hand them to a machine that can call them thousands of times a second. 

Which means an agent inherits whatever your API is. Undiscovered, over-permissioned, inconsistent, unobservable? Congratulations! Your agent is all of those things too, only faster.

The structural problem: two teams, one surface

Often, an API starts with a developer measured on shipping it, not on stewarding it, so whether it's discoverable, least-privileged, or observable falls to someone else. That's a big part of how the estate above got undiscovered, over-permissioned and inconsistent in the first place.

Two other groups inherit the result, and staying in sync is everyone's intention and no one's job. One manages these APIs, running the gateways, catalogs, versions and rate limits. The other governs their security, setting the policies and auditing for compliance. Usually after the design is already set. Different tools, different owners, different metrics.

That split was survivable when APIs were quiet plumbing. It isn't now. The most damaging API incidents aren't exotic exploits. They're ordinary, well-formed requests that abuse legitimate functionality. You only catch those when management context and security posture come from the same picture. Point an autonomous agent at that gap and it'll find every seam, at machine speed.

What "agent-ready" actually means

The good news: getting ready for agents isn't a separate project. It's the same work as governing your APIs well. You just have to actually do it. A trustworthy agent needs the same three things a well-run API already provides:

• Bounded: least-privilege access, so a caller can only reach what its task needs.

• Observable: every call and its downstream effects traceable.

• Accountable: every action tied to a distinct, revocable identity. With machine identities now outnumbering humans 82 to 1, and most organizations admitting they lack identity controls for AI, this is where the exposure lives.

For Scandinavian organizations, this is also where the regulation is heading. NIS2 asks for the same things: access control, supply-chain security, and governance you can demonstrate, with accountability that now reaches the board. It's already law in Sweden and Denmark, and Norway is next, so the bar is set, and the work that makes you agent-ready is the same work that makes you NIS2-ready.

There's a practical pattern that ties it together, and it's one API teams already know: govern centrally, enforce at the edge. A federated control plane gives you one inventory, one policy model, and one view of risk across every gateway and cloud. Apply that same idea to agents (route their tool access through a governed MCP gateway) and your agents inherit the same controls as every other consumer. No special case. No blind spot.

Avella helps organizations design, secure and govern their API estates — so data and services can be exposed safely, at scale, and ready for whatever consumes them next.

Further reading: NIS2 Directive (EU) 2022/2555; Anthropic, "Introducing the Model Context Protocol" (2024); OWASP API Security Top 10 (2023) and OWASP MCP Top 10 (2025, beta). Statistics from Gartner and CyberArk as cited above.