MCP Server Security: How to Protect the New AI Attack Surface

What an MCP server is#

An MCP server is an endpoint that speaks the Model Context Protocol, an open standard that lets AI assistants such as Claude, ChatGPT, and Copilot call tools and read data on a user's behalf. If you have never worked with it, the simplest way to picture MCP is as a universal adapter between an AI model and the outside world. Instead of every assistant inventing its own way to talk to your calendar, your database, or your ticketing system, they all speak one protocol, and anything that implements that protocol can plug in.

A server advertises a set of tools, which are named functions the AI can invoke, such as send_email, query_database, or create_ticket. Each tool comes with a plain language description that tells the model when and how to use it. The model reads those descriptions, decides which tool fits the task, and asks the server to run it with specific arguments. The server executes the action against the real system and hands the result back. Servers can also expose resources, which are pieces of data the model can read, and prompts, which are reusable instructions.

Under the hood, the exchange is ordinary JSON-RPC, a lightweight format where a client sends a method name and parameters and the server returns a result. A server can run locally on your own machine and talk to the assistant over standard input and output, or it can run as a remote service reachable over HTTP. The remote case is where most of the security questions live, because a remote MCP server is a network service that can act on real systems, and network services get found.

MCP went from a niche idea to something you see everywhere in the space of about a year. The protocol was introduced in late 2024, the major assistants added support through 2025, and thousands of community servers now exist for everything from GitHub and Slack to internal company tools. That adoption curve is the reason security matters now rather than later. A great deal of new code that can take real actions is being written quickly, often by people who are focused on capability rather than on locking the door behind it.

Why an MCP server is a new and serious attack surface#

A traditional web API waits for a human developer to call it in a predictable way. An MCP server is different, because the caller is an AI model that decides on its own which tool to invoke, based on text it reads at the moment. That text can come from the user, from a document, from a web page, or from another server. The server is handing action taking power to a component that can be steered by whatever content happens to be in front of it. That is the heart of why MCP is a new kind of exposure rather than just another API.

Because a tool call is a real action, a misconfigured server does not just leak a response, it can send an email, move money, delete a record, or read a private file. If an attacker can influence what the model decides to do, they can turn the server against its own user. The AI becomes a confused deputy, an actor with legitimate access that is tricked into using that access for someone else. The blast radius is whatever the server's credentials can reach.

This is not theoretical. Through 2025, security researchers scanning the internet reported finding thousands of MCP servers exposed with no authentication, effectively open remote controls for whatever those servers could touch. Separately, a command injection flaw in a widely used MCP proxy package allowed a malicious server to run operating system commands on the machine connecting to it, and researchers demonstrated tool poisoning attacks that hid instructions inside tool descriptions to exfiltrate data. Different mechanisms, one theme. The action taking power that makes MCP useful is the same power an attacker wants.

The main ways MCP servers go wrong#

Most real incidents fall into a handful of patterns. These map onto categories in the OWASP MCP Top 10, the first security framework written specifically for the protocol, and understanding them in plain language is the fastest way to know what to check on your own server.

Unauthenticated exposure

The most common and most damaging mistake is a server that answers tool requests without asking who is calling. Anyone who discovers the endpoint can list its tools and run them. The protocol itself is trivial to speak, so there is no obscurity to hide behind. The snippet below shows the entire attack for an unauthenticated server. One request lists the tools, and from there every one of them is available.

# The MCP protocol is a simple JSON-RPC exchange over HTTP.
# A client asks a server to list the tools it offers:
POST /mcp
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/list"}

# An unauthenticated server hands its full toolset to anyone who asks:
{
  "jsonrpc":"2.0","id":1,
  "result":{"tools":[
    {"name":"run_sql","description":"Run an arbitrary SQL query"},
    {"name":"send_email","description":"Send an email as the user"},
    {"name":"delete_file","description":"Delete a file by path"}
  ]}
}

Overly broad or state changing tool permissions

A server often starts with one modest job and quietly accumulates tools and permissions as features are added. A credential that was meant to read a single calendar ends up able to create, delete, and share across an entire account. When a server exposes tools that change state or destroy data alongside the harmless read tools, any compromise of the model, or any successful manipulation of it, inherits that full range of power. The fewer destructive tools a server offers, and the tighter their permissions, the smaller the damage when something goes wrong.

Tool poisoning and hidden prompt injection

Because the model chooses tools by reading their descriptions, those descriptions are an attack channel. Tool poisoning is the practice of planting instructions inside a tool's description or metadata, text the user never sees but the model obeys. A description that looks like a friendly explanation can quietly tell the model to read a private file and attach its contents to an unrelated call. The same idea appears as prompt injection, where hostile instructions ride in on data the server returns, such as a web page or a support ticket, and the model treats that content as commands. In both cases the attacker never needs to log in. They only need the model to read their text.

Tokens that are not bound to the server

An access token is a credential the server uses to prove it is allowed to act. If a token is not bound to the specific server it was issued for, meaning nothing ties it to that one audience, a token stolen or misdirected from one service can be replayed against another. Long lived tokens with no expiry make this worse, because a single leak becomes a permanent key. Token binding and short lifetimes turn a leaked credential into a brief, contained problem instead of an open door.

Shadow MCP servers on forgotten subdomains

Developers stand up MCP servers on laptops, staging boxes, and spare subdomains to try things out, and those servers often outlive the experiment. A shadow MCP server is one running somewhere in your estate that no one is formally tracking. Nobody patches it, rotates its tokens, or notices when it drifts into being reachable from the internet. It is the MCP version of the abandoned subdomain that turns into a takeover, except this endpoint can take actions rather than just serve a page.

Best practices to secure an MCP server#

Securing an MCP server is mostly about applying long standing API discipline to a component that can now act on its own. The Model Context Protocol specification spells out the authorization model, and the practices below cover the ground that matters most in day to day operation.

Controls worth putting in place

• Require strong authentication on every request. The specification recommends OAuth 2.1 with PKCE, a modern authorization standard where the client exchanges a code that expires quickly for an access token and PKCE stops that code being stolen in transit. A reachable server should never list or run a tool for an unauthenticated caller.
• Give every token least privilege scopes. A scope is a label on a token that limits what it can do. Issue the narrowest scope each task needs, and bind the token to the specific server it was issued for so it cannot be replayed elsewhere.
• Do not expose destructive tools broadly. Keep tools that delete, send, or spend behind stricter authorization, require explicit confirmation before they run, and leave them out of any server that does not truly need them.
• Validate and monitor tool descriptions. Treat descriptions as untrusted content, pin them to a known good version, and alert when one changes, since a silent edit is how tool poisoning arrives.
• Rate limit, log, and keep an inventory. Cap how often tools can run to blunt automated abuse, record every call with its identity and arguments, and maintain a live list of every MCP server you operate so none of them become shadow endpoints.

Authentication does more than keep strangers out. A protected server answers an anonymous request with a clear challenge that points the client to where it can authenticate, and only serves tools once a valid, scoped, audience bound token arrives. The difference between the two states is stark.

# A protected server rejects the same request until the client proves who it is.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://api.example.com/.well-known/oauth-protected-resource"

# The client completes an OAuth 2.1 + PKCE flow, then retries with a
# token that is scoped to only the tools it needs and bound to this server:
POST /mcp
Authorization: Bearer <token scoped read-only, audience=api.example.com>

Why a normal web scan misses this#

A typical website scanner looks at the pages your site serves and the HTTP response headers that come with them. That is the right lens for checking things like a Content Security Policy or an HSTS header, but it tells you nothing about an MCP server. The risks in MCP live one layer down, in the protocol conversation. Whether your endpoint demands authentication, which tools it advertises, what those tool descriptions actually say, and whether its tokens are scoped and bound are all invisible to a scan that only reads a web page.

That gap is exactly why shadow servers and unauthenticated endpoints survive so long. Your normal monitoring reports everything as healthy because the website is fine. The MCP endpoint sitting on a subdomain is a separate service with its own behavior, and nothing in a page level check ever knocks on its door.

To see your MCP surface you need a check built for the protocol. The SiteSecurityScore MCP scanner connects to your endpoint the way a real client would and surfaces the issues in this guide as findings, from missing authentication to overly broad tools and suspicious tool descriptions. If you want the AI assistant to run those checks for you inside your editor, the guide on adding a security scanner to Claude Code with MCP walks through the setup, and the SiteSecurityScore MCP connector is what powers it. For the full catalog of risks behind these checks, read the companion OWASP MCP Top 10 guide.

FAQ#