MCP Security: Solving Unintended Access with the API Delegation Model

SECTION 1

MCP in 2026: An Unavoidable Standard, an Expanding Attack Surface

The Model Context Protocol (MCP) has established itself as the standard framework for encapsulating resources, databases, file systems, business APIs, and making them accessible to large language models (LLMs) and AI agents. Adopted by every major model and tool vendor, it is used both locally and remotely, and its ecosystem has exploded: the public MCP server registry grew from about 1,200 entries in early 2025 to more than 9,000 by mid-2026. That growth has a flip side: every published server is a potential entry point into enterprise resources.

Like any flexible framework, MCP is exposed to cybersecurity failures that stem from inadequate design choices. This is not a flaw in the standard itself: flexibility often leads to inappropriate combinations of choices, in other words, anti-patterns. The numbers confirm it: research has shown that 43% of evaluated MCP servers contained command injection vulnerabilities.

We will examine the most widespread anti-pattern, unintended access to resources, and show how to solve it with a proven solution: delegating security to your existing API infrastructure.

SECTION 2

The Unintended Resource Access Anti-Pattern

MCP can grant direct access to resources that lack appropriate controls for the access channel you are implementing. To understand the risk, you have to distinguish two very different deployment modes.

### Local usage: privileges inherited from the user

Locally, MCP encourages client-server communication over standard input-output streams (stdio). The MCP process runs under the user's identity and inherits their privileges: the exposure perimeter is that of the workstation, and you would have to deliberately expose elevated privileges to create additional risk. This mode remains reasonably manageable.

### Remote servers: the real weak link

The problem concerns MCP servers accessible remotely over streamable HTTP. When an MCP server reaches resources through their native communication channels, those channels often lack access controls equivalent to the MCP use case: your database knows system accounts, your file storage knows system users, but MCP opens those resources to a much broader population of users, LLMs, and agents. Bridging broad user privileges to restricted system access is anything but trivial: handling all the necessary security concerns, authentication, fine-grained authorization, logging, protection against data and command injection, would often require more effort than the MCP implementation itself. This is precisely where parallel access paths that escape all governance are born.

SECTION 3

What the MCP Specification Now Mandates: OAuth 2.1, PKCE, and RFC 8707

The standard has matured considerably on the security front. Since the 2025-06-18 revision, and then the stable 2025-11-25 version of the specification, any MCP server exposed on the network must rely on OAuth 2.1 with mandatory PKCE, implement Protected Resource Metadata (RFC 9728) for authorization server discovery, and clients must use Resource Indicators (RFC 8707) to bind each token to the precise resource it targets, which neutralizes token theft and reuse across servers.

### Why authentication is not enough

These requirements settle authentication and token issuance, but they say nothing about what matters most to the enterprise: who is allowed to do what, on which resource, within which rate limits, with what traceability. Fine-grained authorization, quota management, abuse detection, and auditing remain entirely the implementer's responsibility. Reinventing that layer for every MCP server would be costly and fragile, yet this problem has already been solved elsewhere.

@cite:le-protocole-model-context-au-dela-de-la-tendance

SECTION 4

The API Delegation Model: Reusing Proven Infrastructure

When API-oriented architectures emerged, bridging restricted resources to broader user channels was exactly the same fundamental problem. The answers have existed ever since: API gateways, identity management, OAuth scopes, quotas, rate limiting, telemetry. These building blocks are mature, well tooled, and central to digital transformations. Rather than re-architecting these solutions for MCP, let's reuse them.

### Four implementation principles

First, if API layers already exist in front of your internal resources, reuse them; if not, deploy an API solution first. Second, evaluate your MCP server's user access requirements and configure the API layer accordingly, your existing APIs may need more granular scopes to distinguish an AI agent from a classic application client. Third, keep the MCP server lightweight and focused on its primary function: translating the request protocol between the LLM or agent and the backend resource, delegating access control, traffic management, and telemetry to the API layer. Fourth, treat your MCP server as an API client with specific access requirements, with its own credentials and its own limits.

This approach maintains uniform, consistent access channels without creating secondary paths to backend resources. This is the core of the MCP API delegation model: the MCP server should do nothing more than bridge the MCP protocol to the API protocol.

@cite:securiser-ses-apis

SECTION 5

Implementing the MCP-API Bridge and Weighing the Trade-Offs

With the API layer between the MCP server and the resources, all that remains is bridging MCP to your backend API, and that is the easy part. API architecture concepts translate directly into MCP concepts: an endpoint becomes a tool, an OpenAPI schema becomes the description of its parameters. Reference solutions exist to dynamically generate MCP servers from OpenAPI specifications, and the leading API gateways on the market now natively offer MCP exposure of their APIs, with the same security, quota, and audit policies as for any other client.

### Latency, complexity, dependency: the accepted trade-offs

The delegation model is not free. The additional API layer adds latency to every tool call; the architecture grows more complex; API gateway availability becomes a critical dependency; and API management infrastructure has a cost, in licenses as in operations. For most enterprise deployments, these trade-offs remain broadly acceptable given the benefits: a single governance point, consistent policies, and a centralized audit surface for all AI agent access.

SECTION 6

An Action Plan for Secure, Governed MCP Deployments

The approach comes down to four steps. First, audit your current API infrastructure: coverage of sensitive resources, scope granularity, rate-limiting and logging capabilities. If that infrastructure does not exist, implement an API architecture before any remote MCP deployment. Then deploy reusable MCP servers on top of those APIs, generated from your OpenAPI specifications or exposed by your gateway, rather than custom servers that each reimplement their own access control. Finally, configure the API layer for the agentic use case: dedicated scopes, quotas suited to bursts of tool calls, alerts on abnormal behavior.

This technical foundation must come with governance: an inventory of authorized MCP servers, a security review before any production rollout, and continuous monitoring of tool calls, just like any other API traffic. AI agents multiply machine-to-machine interactions; without centralized visibility, drift goes unnoticed.

By delegating security and access control to proven API infrastructure, you get uniform, secure, and scalable MCP deployments, without reinventing the wheel, and without turning every new MCP server into security debt.

@cite:les-agents-ia-ne-doivent-pas-etre-un-cauchemar-de-securite

FAQ

Frequently asked questions