Skip to content
ComplianceMCPEnterprise AI

From APIs to Agents: MCP Signals a New Infrastructure Boundary

From APIs to Agents: MCP Signals a New Infrastructure Boundary

Luke
•4 min read
From APIs to Agents: MCP Signals a New Infrastructure Boundary

MCP is not just another integration

The last decade taught organisations how to scale software safely: API gateways, IAM, service meshes, audit trails, and operational controls around predictable services. Agentic AI breaks that predictability. Execution paths aren’t fixed, tool choice is probabilistic, and the “business logic” can shift at runtime.

MCP matters because it standardises the interface layer where models discover, select, and invoke tools. In doing so, it turns ad-hoc agent integrations into a composable ecosystem.

A central registry makes it clear that MCP servers are designed to be discoverable and reusable, not stitched together as one-off integrations.

A useful way to judge whether something is a passing fad is to ask whether it develops real governance, versioning discipline, and ecosystem plumbing.

MCP has already shown several of these signals:

  • date-based versioning with explicit negotiation expectations
  • a published roadmap and SEP-style standardisation track
  • an official registry for server discoverability and moderation
  • and, as of December 2025, neutral stewardship under the Linux Foundation’s AAIF

That’s the pattern you see when a protocol is being positioned as a common foundation that multiple organisations are expected to depend on.

Spec evolution shows where the industry is heading

The March and June 2025 spec updates pushed MCP toward enterprise reality: structured outputs, richer tool descriptions, and OAuth-based authorisation with explicit security considerations.

The November 2025 revision extends this trend. It introduces better authorisation discovery (including OIDC discovery), incremental consent patterns, tighter guidance on naming and metadata, and improved elicitation semantics.

All of these improvements make MCP easier to operate, but that’s not the core point. More importantly, MCP provides a standardised integration point where organisations can apply governance, control, and accountability as AI systems interact with the rest of the stack. This is critical for successful enterprise adoption.

Runtime guardrails are necessary yet still insufficient

Runtime guardrails matter. You need detection and blocking for prompt injection, data leakage, unsafe tool use, and the usual failure modes.

But if you stop there, you’re treating symptoms. The deeper issue is control and evidence:

  • Who was allowed to call which systems, under what identity?
  • What consent was granted, and was it bounded?
  • Can you audit the chain of actions and outputs as evidence of control?

Even mainstream coverage of MCP security concerns highlights a core risk: the payload itself can be weaponised, and misconfigurations become a new attack surface as MCP-exposed systems proliferate.

So yes - runtime guardrails. But also system-level identity, policy, and observability.

MCP as the new “gateway boundary”

In the old world, “the boundary” was the network edge or the API gateway. In the agentic world, a critical boundary sits between models and the systems they act upon.

This is where governance needs to live:

  • system identity and provenance
  • authorisation and scope boundaries
  • observability and audit trails across actions
  • safe patterns for user elicitation and consent

The protocol’s direction of travel - authentication maturity, registries, and standardisation - is consistent with this boundary becoming first-class infrastructure.

Scaling pressure forces MCP deployments toward cloud-style operation.

The MCP community is actively exploring transport changes aimed at statelessness and horizontal scaling, with work targeted for SEPs in early 2026 and a tentative spec release around June 2026.

This reflects a simple reality: MCP servers will need to behave like normal internet infrastructure. They will need to run as shared, scalable services, not as fragile, one-off deployments built around individual agents.

Practical takeaway

If you’re adopting MCP (or anything like it), treat it like infrastructure:

  • plan for identity and authorisation as first-class concerns
  • assume connected systems will multiply
  • design for auditability, evidence, and human-in-the-loop override — not just blocking bad prompts
  • expect the transport and ecosystem to keep evolving

Flexible, composable building blocks may feel like upfront work, but they will save time, cost, and frustration later.

 

References & Further Reading

 Model Context Protocol (MCP)

  • Anthropic. Model Context Protocol Specification – Versioning (current version: 2025-11-25). https://modelcontextprotocol.io/specification
  • Anthropic. MCP Changelog – 18 June 2025. https://modelcontextprotocol.io/changelog/2025-06-18
  • Anthropic. MCP Changelog – 25 November 2025. https://modelcontextprotocol.io/changelog/2025-11-25
  • Anthropic. Model Context Protocol Roadmap and Standardisation Process (SEPs). https://modelcontextprotocol.io/roadmap