MCP Security: Risks, Attacks and How to Secure MCP Servers

MCP security is the set of controls that protect AI agents, the MCP servers they connect to and the data behind those servers from unauthorized access, prompt injection and data exfiltration. It differs from API security because a large language model reads every tool description and tool result a server returns, so text from one untrusted server can redirect what the agent does next.

Anthropic released the Model Context Protocol as an open standard in November 2024, and the current specification says MCP cannot enforce its own security principles at the protocol level; hosts, clients and servers have to. The OWASP MCP Top 10, now in beta, lists token mismanagement, tool poisoning and shadow MCP servers among the ten risks it tracks.

Bifrost, the open-source AI gateway, enforces these controls at one point in the path: it authenticates every caller, limits which tools each caller can see, and runs guardrails on tool arguments and results.

How does MCP security work?

MCP security works by placing a check at each trust boundary a tool call crosses: between the user and the host, between the host and each MCP server, and between each server and the APIs or files it reaches. The boundary teams miss most often is the return path, where text from a server flows back into the model's context.

Figure 1: The return path into the model, not the outbound call, is where most MCP attacks land.

An MCP server supplies three kinds of text the model reads: tool names and descriptions from tools/list, results from tools/call, and optional annotations. The specification tells clients to treat annotations as untrusted unless the server is trusted, and to keep a human in the loop who can deny any tool call. A local server adds a second exposure: launched over stdio, it runs with the user's own file and network access.

MCP security risks

MCP security risks fall into three groups: text that manipulates the model, credentials that reach further than intended, and servers running outside anyone's review. The table maps the risks teams meet first to how each attack works and the control that stops it, with IDs from the OWASP list where one applies.

The last two come from the MCP security best practices for revision 2026-07-28, which made MCP stateless: session hijacking guidance now applies only to protocol version 2025-11-25 and earlier, and the current risk is a state handle passed as a tool argument.

How does indirect prompt injection reach agents through MCP?

Indirect prompt injection reaches agents through MCP when instructions hidden in data a tool returns, such as a GitHub issue, an email or a web page, enter the model's context as part of a tool result. The model cannot reliably separate the user's request from text inside that result, so it may follow the attacker's instructions using the user's permissions.

The attack needs three conditions at once: the agent reads untrusted content, it can reach private data, and it has a tool that sends data out. Removing any one breaks the chain, so teams give read-only tools and outbound tools to different keys and inspect results before they reach the model.

Tool poisoning, rug pulls and tool shadowing

Tool poisoning is prompt injection placed in a tool's description instead of its results. Invariant Labs disclosed the pattern in April 2025: a harmless-looking add tool told Cursor's agent to read ~/.ssh/id_rsa and the MCP config file and pass them in a hidden argument, and the confirmation dialog did not show the full input. In a rug pull, a server changes a tool's description after the user approved it. In tool shadowing, one server's description changes how the agent uses a trusted tool from another server, for example by redirecting every email the agent sends.

What are shadow MCP servers?

Shadow MCP servers are MCP servers that employees add to their AI apps and coding agents without review by IT or security, so nobody tracks what they can reach or which credentials they hold. They matter because a local server runs third-party code with the user's privileges, and its API keys usually sit in plain-text config files.

Adding a server takes one entry in a host's JSON config. The specification requires clients that offer one-click install to show the exact command and get explicit approval first, and recommends sandboxed launch with minimal privileges, but a hand-edited config file skips that dialog entirely. The working control is an inventory of which servers run on which machines, with an allow or deny decision for each, as described in shadow AI governance for desktop and browser AI.

How are MCP servers authenticated?

Remote MCP servers are authenticated with OAuth 2.1. The server answers an unauthenticated request with 401 and a WWW-Authenticate header, the client discovers the authorization server, the user signs in through the authorization code flow with PKCE, and the client sends a short-lived Bearer token on every request. Local stdio servers read credentials from environment variables instead.

MCP authentication and MCP OAuth cover the flows in detail. For security, three rules decide whether a stolen or misused token does damage:

• Audience binding. Each token names one server through the RFC 8707 resource parameter, and the server rejects tokens issued for any other audience. Token passthrough, forwarding the client's token to an upstream API, is forbidden.
• Consent per client. A proxy server that uses one static client ID at a third-party authorization server must collect consent for each client, or it becomes a confused deputy that hands out tokens without consent.
• Minimal scopes. Servers advertise a small initial scope set and raise it through step-up challenges, so a leaked token cannot reach every tool.

For internal hops, such as a gateway calling an MCP server on the same network, teams often add mutual TLS (mTLS) so each side also proves its identity with a certificate.

MCP security best practices

MCP security best practices come down to four habits: treat every server as untrusted until reviewed, give each caller only the access its task needs, inspect what crosses the return path, and record every tool call. Most of these controls sit more naturally in an MCP gateway than in each host, because one policy then covers every client.

1. Inventory every server. List approved remote and local servers, and deny the rest.
2. Review and pin tool definitions. Read descriptions before approval, and re-review when a server reports a changed tool list.
3. Grant least privilege. Expose only the tools a workload needs, and separate read-only tools from tools that write or send data.
4. Use per-user credentials. Prefer OAuth tokens scoped to one user and one server over shared static keys.
5. Sandbox local servers. Run community servers in containers or a managed sandbox such as Google Cloud Run, with file and network access limited to what they need.
6. Inspect arguments and results. Check tool inputs for secrets and personal data before execution, and results for injected instructions before they reach the model.
7. Keep a human in the loop. Require confirmation for tools that delete records, move money or send data outside the organization.
8. Log every call. Record caller, tool, arguments and outcome for every call.

MCP security with Bifrost

Bifrost, the open-source AI gateway built by Maxim AI, enforces these controls on the path between hosts and MCP servers. Hosts connect to one /mcp endpoint, and Bifrost authenticates the caller, exposes only the tools that caller's virtual key allows, runs guardrails before and after each tool call, and logs the call.

Figure 2: Hosts reach only the tools their key allows, and guardrails inspect both the arguments going out and the results coming back.

• Authentication on both legs. Gateway authentication accepts virtual keys, OAuth 2.1 with PKCE, or both. Each upstream server uses one of six auth types, including per-user OAuth, so a client's token never passes through to an upstream server.
• Tool access. Tool filtering stacks client, request and virtual key allow-lists, and Virtual MCPs serve an approved subset of tools at /mcp/<slug>, reachable only through the keys attached to it.
• MCP guardrails. Enterprise rules with the mcp target run before a tool executes and after it returns, to block or redact arguments and results. Profiles include built-in secrets detection and providers such as AWS Bedrock Guardrails and Google Cloud Model Armor, and a CEL condition scopes a rule to one tool, as the MCP guardrails walkthrough shows.
• Explicit execution. By default Bifrost does not run the tool calls a model proposes; your application calls the tool execution API after review, and Agent Mode auto-runs only tools listed in tools_to_auto_execute.
• Logs. Each tool call is written as an MCP log entry, with selected request headers captured as metadata for tracing.

On laptops, Bifrost Edge extends the same gateway governance to endpoints: it inventories the MCP servers configured in Claude Code, Cursor and other supported apps and enforces an allow or deny decision on each device.

To review these controls against your own MCP servers, book a demo, or try the open-source gateway with the gateway quickstart.

Frequently asked questions

What does a MCP server stand for?

MCP stands for Model Context Protocol, the open standard Anthropic released in November 2024 for connecting AI applications to external tools and data. An MCP server is a program that exposes tools, resources and prompts over that protocol, so a host such as Claude Desktop or Cursor can discover and call them at runtime. The MCP overview explains the full architecture.

Is MCP secure by default?

No. The specification defines OAuth 2.1 authorization for HTTP transports but makes it optional, and it states principles such as user consent and untrusted tool descriptions that the protocol itself cannot enforce. An MCP deployment is only as secure as the host, server and gateway that implement those controls, so each server needs authentication, scoped access and review.

What is the difference between MCP security and API security?

API security protects endpoints that code calls with fixed, predictable requests. An MCP deployment also has to protect the model, because the model chooses which tool to call and reads server-supplied text as context. Authentication, input validation and rate limits still apply; MCP adds tool description review, inspection of results for prompt injection, and user consent before a tool runs.

Does an MCP gateway replace sandboxing local servers?

No. A gateway controls the traffic routed through it: who calls which tool, and which arguments and results pass. A local stdio server still runs on the user's machine with the user's privileges, so it needs a sandbox, approval before launch and a place in the inventory. An endpoint agent that enforces allow or deny per server closes part of that gap.

What is the OWASP MCP Top 10?

The OWASP MCP Top 10 is an OWASP project, currently in beta, that lists the ten most significant security risks in MCP deployments, from token mismanagement and secret exposure (MCP01) to context injection and over-sharing (MCP10). It includes tool poisoning, shadow MCP servers and missing audit telemetry, giving teams a shared vocabulary for threat models.

• mcp security
• mcp server security
• model context protocol security
• mcp security risks