What is MCP, and how do MCP servers create risk?

The question Which tools can our agents call?

What MCP is

The Model Context Protocol (MCP) is an open standard for connecting AI applications to outside data and tools. Anthropic open-sourced it on 25 November 2024. The launch included SDKs and ready-made servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. The specification is now on its 2026-07-28 revision.

MCP has three roles. The host is the AI application, such as a coding agent or an IDE. The client is the connector inside the host. The server is a separate program or service that offers capabilities: resources (data), prompts (templates) and tools (functions the model runs). Tools carry most of the risk, because calling one makes something happen.

How an agent loads its servers

Each client keeps a list of servers in a config file. Claude Code, for example, reads .mcp.json in a project's root and ~/.claude.json in your home folder. Each entry names a command to run, such as npx with a package name, or the URL of a remote server. Entries can also set environment variables, which is where the specification tells local servers to look for credentials.

When the client starts, it launches its local servers. Most run as child processes that talk over standard input and output. Each server sends back its tool names and descriptions. Those go into the model's context, and the model reads them as instructions.

So which tools can your agents call? Every tool on every server in every config file on every machine, plus any remote connectors set up in the apps. Project config files travel with the code. Claude Code asks before it uses servers from a project's .mcp.json in interactive sessions. Its documentation notes that in claude -p runs and Agent SDK sessions, it loads them without asking.

Five ways MCP servers create risk

Poisoned tool descriptions

A tool's description is text the model reads and the user often can't see in full. In April 2025, Invariant Labs showed how to hide instructions there, and called it tool poisoning. Their demo server offered a simple add tool. Its description told the agent to read ~/.cursor/mcp.json and ~/.ssh/id_rsa, then pass both out in a parameter named sidenote.

A poisoned description can also hijack other servers' tools. In the same research, a fake tool's description made Cursor send every email to the attacker, even when the user named another recipient. The specification itself says to treat descriptions of tool behaviour as untrusted unless they come from a trusted server. Tool poisoning is a form of prompt injection.

Rug pulls and poisoned packages

Approval happens once, but code keeps changing. Invariant Labs noted that a server can change its tool descriptions after you approve it. Packages can change too.

In September 2025, Koi Security found postmark-mcp on npm. It was Postmark's official MCP server code, published under the same name by someone with no link to Postmark. Versions 1.0.0 to 1.0.15 worked normally. Version 1.0.16 added one line that blind-copied every email the server sent to phan@giftshop[.]club. Koi counted about 1,500 downloads a week. Postmark said it had nothing to do with the package. When Koi contacted the developer, he deleted it from npm, which left every installed copy in place.

Config can be swapped as well. In August 2025, Check Point Research showed that Cursor trusted an approved MCP entry by its name. An attacker could commit a harmless entry to a shared repository, wait for a teammate to approve it, then change the command. Cursor 1.3 fixed this (CVE-2025-54136). Any change to an entry now needs a fresh approval.

Over-broad tokens in config files

The specification tells local servers to read credentials from the environment rather than use its authorization flow. In practice, tokens end up in the client's config file or in the shell environment the server inherits. Claude Code's own example adds a server with --env AIRTABLE_API_KEY=YOUR_KEY.

Config files sit in known places, and MITRE ATLAS lists reading them as a technique: AML.T0083, Credentials from AI Agent Configuration. The MCP project's guide warns against reusing a personal, broad-scope token across servers. GIRD's open-source Blindspot check lists the MCP servers on one computer and flags tokens sitting in their config files. Where those keys travel next is covered in where AI agents leak your keys.

Local servers run as you

A local MCP server is an ordinary program, not a sandboxed plugin. The MCP project's security guide spells out what that means. You download code from the internet and run it as a child process of your user account. It inherits your environment variables and can read anything your account can read, including SSH keys and cloud credentials. It can connect anywhere. None of that is governed by the protocol.

All configured servers also share one model context. So one malicious server can steer how the agent uses every other server's tools. For the full reach of an agent's process, see what an AI coding agent can reach on a laptop.

Remote servers

A remote server runs no code on your laptop, and it can use the protocol's OAuth-based authorization instead of a stored token. The MCP project's guide prefers the remote version where one exists. You still trust its operator with whatever the agent sends. The connection can also be an attack path. In July 2025, JFrog disclosed CVE-2025-6514 (CVSS 9.6) in mcp-remote, a proxy that lets local clients reach remote servers. A malicious server could make it run operating system commands on the user's machine. Version 0.1.16 fixed it.

What the specification asks of clients

The specification is frank about its limits. Its security section says tools represent arbitrary code execution, and that hosts must get explicit user consent before invoking any tool. It also says MCP cannot enforce these principles at the protocol level. Implementers should build them into their apps.

Three parts of the guidance matter most to a security team:

• Authorization is optional. Where it is used, over HTTP, it follows OAuth 2.1. Servers must not accept tokens that weren't issued for them. The Security Best Practices page calls passing tokens through an anti-pattern.
• Consent before code runs. A client that offers one-click installs must show the exact command and get explicit approval. It should warn that servers run with the client's privileges, and sandbox them where it can.
• Narrow scopes. The same page recommends a minimal starting scope, with step-up requests later. It lists wildcard or omnibus scopes as a common mistake.

These are rules for the people who build clients. Whether your developers' clients follow them, and how your developers answer the prompts, is for you to check.

How to control which tools your agents can call

Treat MCP servers as software your developers install, because that is what they are. The MCP project's advice for organisations starts with an inventory and an allow list. Four controls cover most of the risk.

1. Inventory every server. Config files live in known locations, so your MDM can collect them from every laptop. Record each server's source, version, owner and tokens, and include remote connectors. GIRD's 19-day case study covered one company's engineering laptops. MCP connector entries went from 20 in week one to 22 in week two, across 9 services. Pair this with an inventory of the agents themselves; see shadow AI agents.
2. Allow list approved servers. Publish a short list, with the criteria a new server must meet, and block the rest where your clients allow it. Match on what runs, not on the name. Claude Code's admin guide warns that matching on a server's name "is not a security control", since a user can call any server github. Match the exact command or URL.
3. Pin versions. Install exact versions, never latest, so a bad release can't arrive on its own. A pinned npx package usually still resolves its dependencies fresh at install. A container image pinned by digest freezes the whole tree. Prefer clients that ask again when a tool definition changes.
4. Scope tokens. Give each server its own token with the smallest scope that works, such as a fine-grained token for one repository. Keep long-lived secrets in the operating system's secret store where the client supports it. Rotate a server's tokens when you remove it. More in least privilege for AI agents.

Then log which server and tool each agent called, and when. If a server later turns out to be malicious, that record shows what it touched.