Model Context Protocol (MCP) is emerging as a popular framework to standardize wrapping resources to access LLMs. We can use it both locally and remotely.

Like all flexible frameworks, MCP is susceptible to poor cybersecurity outcomes from suboptimal design choices. This isn't a problem with the MCP standard itself. Flexibility often leads to inappropriate combinations of choices — in other words, anti-patterns.

We'll discuss one particular anti-pattern and demonstrate how to address it with a proven solution: delegating security to your existing API (application programming interface) infrastructure.

Addressing unintended access

MCP can proxy raw access to resources that lack appropriate controls for the access channel you're implementing.

For local use this isn't an issue. MCP encourages local communications between clients and servers using stdio (standard input/output) streams. The MCP process runs as the user, maintaining their underlying privileges. You'd have to deliberately expose escalated privileges — a topic outside this article's scope.

The real issue is with remotely accessible MCP servers. When we design MCP servers to access various resources through native communication channels, these channels often lack equivalent access controls for the MCP use case.

Let's examine this in detail: your database may have access controls for system accounts and your file storage may have controls for system users, but MCP allows a broader set of users to access LLMs or AI agents that need these resources.

Bridging broad user privileges with narrow system access isn't trivial. Solving all the necessary security concerns would likely take a lot more effort than implementing the MCP solution. You might also face cybersecurity concerns like data and command injection.

Security Statistics: Recent research found that 43% of assessed MCP servers contained injection flaws.

Leveraging API infrastructure

Fortunately, we've solved this challenge before. When API-based architectures first emerged, bridging restricted resources to broader user channels was a cornerstone problem.

Today, API architectures are mature, well-established and central to digital transformations. Instead of re-architecting these solutions for MCP, we can reuse them.

• If you have API layers deployed across your internal resources, reuse them. If not, deploy an API solution.

• Assess your MCP server's user access requirements and configure your API solutions accordingly. Your existing APIs may need to be adjusted for more granular requirements.

• Keep your MCP server lightweight and focused on its primary function — translating query protocol between the LLM/agent and backend resource. Delegate access control to the API layer, along with traffic management, telemetry and other architectural concerns.

• Treat your MCP server as an API client with specific access requirements. Configure your API layer accordingly.

This approach maintains consistent, uniform access channels without creating side channels into backend resources. This is the core of the MCP API delegation pattern — and it means your MCP server only needs to bridge the MCP protocol to the API protocol.

Implementing the bridge

With your API layer between the MCP server and resources, you now need to bridge MCP to your backend API. Fortunately, this is straightforward.

We can translate API architecture concepts directly to MCP concepts. Reference solutions already exist for reusable MCP servers that dynamically translate MCP protocol to OpenAPI-compliant endpoints.

Trade-offs to consider

While the API delegation pattern offers robust security, you should consider these trade-offs:

• The additional API layer adds latency.

• Increased architectural complexity.

• Greater dependency on API gateway availability.

• The potential costs of API management infrastructure.

However, for most enterprise deployments, these trade-offs are acceptable given the security and governance benefits.

Taking action

We can avoid implementing custom MCP servers and re-implementing access control by reusing existing API architecture.

Start by auditing your current API infrastructure. If you don't have one, implement an API architecture first. Then deploy reusable MCP servers over those APIs and configure your existing API architecture to support the MCP use case.

By delegating security and access control to proven API infrastructure, you'll build uniform, secure, scalable MCP deployments without reinventing the wheel.