Search GitHub for MCP server implementations and you'll find an unsettling pattern. Developers grafting old API security patterns onto MCP servers as if the architecture hadn't fundamentally changed. It has.
An MCP server is not an API gateway. It's a tool broker for an AI assistant. That distinction matters because the threat model is completely different, and most teams haven't caught up.
MCP servers aren't traditional APIs. They operate with delegated permissions, dynamic tool architectures, and chained invocations. This breaks old security assumptions. You need context-aware authorisation, compartmentalised backends, and ironclad session isolation.
The permission model flipped and nobody noticed
The OWASP Practical Guide for Secure MCP Server Development (February 2026) spells this out. Every tool your AI assistant touches (Slack, databases, file systems, Jira) moves through the protocol. And unlike traditional APIs, MCP servers run with delegated user permissions. A user authenticates once to the AI assistant. That authentication propagates to the MCP server, and the server is expected to trust it. This isn't a REST API where you're typically one client calling one service. This is an AI making decisions about what tools to call, chaining them together, and the MCP server has to decide in real time whether Claude should be allowed to execute that request.
And the AI isn't a person. It doesn't have inherent permissions. It only has the permissions you've delegated to it through the MCP connection. If you've granted Claude access to your Slack workspace to read channels, the MCP server for Slack now has to reason about whether this specific Claude invocation should be able to read this specific channel. The server can't assume the user said "yes" to everything. It has to be smarter than that.
Chained calls turn a single flaw into a cascade
Most teams building MCP servers started with REST API security: authentication, authorisation checks at the endpoint level, maybe some rate limiting. For a traditional API serving humans clicking buttons in a browser, that works. MCP adds dynamism that breaks those assumptions in two specific ways.
Claude doesn't call a single tool and stop. It calls one tool, gets the result, reasons about what to do next, calls another tool. The output from the first becomes context for the second. An AI can synthesise information across tools in ways humans typically don't: pull data from a database, feed it into a search tool, use the results to trigger an automation, all in a single agentic flow. That's powerful. It's also a massive amplification of attack surface. A vulnerability in one MCP server's authorisation logic cascades across all downstream calls. If Claude calls your database tool and the tool returns data it shouldn't have, and then Claude feeds that data to your email tool, you've potentially leaked confidential information through a chain you didn't explicitly authorise.
Then there's dynamic discovery. Tools are discovered at runtime. Claude asks an MCP server: "What can you do?" The server responds with a list of available tools, their signatures, descriptions. Claude then decides which ones to invoke based on the user's request. That means the server can't rely on a static ACL. It has to answer "can this user run this tool right now?" on the fly, every time.
So what do you actually build?
The OWASP practical guide forces you to acknowledge that your threat model is different. Start with this question: what is the MCP server authenticating? Not what credentials is it checking, but what is it actually confirming? You're not authenticating the AI. You're authenticating the user who owns the AI session. Their permissions. And then you're trusting the AI to respect those permission boundaries even as it chains tools together and makes decisions.
Compartmentalise your backends. If you're building an MCP server that connects to multiple backends, don't collapse all of them into a single tool namespace. Separate them. Make each backend call go through its own authorisation gate. An agent calling your Jira tool shouldn't casually have access to your database tool. Different security boundaries. Full stop.
Make authorisation context-aware. Can this user call this tool? Not as a static yes/no, but given the parameters they're passing. If someone asks Claude to "get all customer records", the MCP server for your database should refuse, even if the user has read access in theory. Scope constraints. Rate limits tied to user, not just connection. Audit logs that capture what parameters were passed, not just which tool was called.
Validate before it hits the backend. MCP servers are often built as lightweight wrappers around existing APIs. Fine. But you can't assume the underlying API will reject malformed requests or dangerous parameters. Validate everything the AI tries to do before it reaches the backend. Sanitise inputs. Check parameter ranges. Confirm the operation makes sense given the current state.
Enforce session isolation. If Claude is operating on behalf of multiple users in a multi-tenant application, the MCP server has to maintain ironclad session boundaries. One user's tool output should never leak into another user's context. A REST API is stateless and doesn't care about session continuity. An MCP server is operating within a specific user's conversational context. Mixing them is how data leaks happen.
The audit trail stops with you
Here's what keeps me up at night about MCP deployment. The AI assistant logs its tool calls. The backend systems log their API requests. But the MCP server is the translation layer, the place where an AI's decision meets a human's permission boundary. If something goes wrong (an unauthorised data access, a privilege escalation, an accidental automation that shouldn't have run), the MCP server is where you'll find the truth of what happened.
Most teams aren't instrumenting that layer properly. Build MCP servers like they're security gateways, because that's what they are.
Related
- Everyone’s Installing MCP Servers from GitHub for the supply chain risks of third-party MCP servers
- Now It’s Agent Skills for the same supply chain problem applied to agent skills