MCP Security: Risks, Real Incidents and Best Practices (2026)

Model Context Protocol (MCP) lets AI agents call external tools through MCP servers, which often run with OAuth tokens, database credentials or cloud access. The main MCP security risks are poisoned tool descriptions, servers that accept unauthenticated calls, malicious or vulnerable server packages, indirect prompt injection through tool results, and over-broad permissions. The controls that reduce them start with an inventory of every MCP server in use, an allowlist of approved servers and tools, least-privilege credentials, and inspection of tool calls and results at runtime.

Updated October 11, 2026. First published March 24, 2025. This guide now covers the incidents and research published since then, including Pillar's own MCP disclosures, and the MCP specification released on July 28, 2026.

Key takeaways

• An MCP server acts with its own credentials, not the caller's. The two remote-server flaws Pillar disclosed in 2026 (Dolt MCP and Grafana MCP) both let an unauthenticated caller run tools with the server's credentials. Treat every MCP server as a privileged service.
• Tool descriptions are instructions to the model. A server can change what it tells the agent after it has been approved. Pillar found a live campaign in August 2026 whose server stayed harmless for its first three tool calls and then told the agent to collect SSH keys and cloud credentials.
• Approval is not a one-time event. Servers update, packages change hands and descriptions change at runtime. An allowlist needs version and behavior checks, not only names.
• Most enterprises don't know which MCP servers are running. Developers, and increasingly non-developers, add servers to Claude Code, Cursor, VS Code and Claude Desktop configurations without review. Inventory comes first.
• The protocol itself is tightening. The July 2026 specification adds stricter authorization checks and removes the session-ID mechanism that both Pillar disclosures abused. Servers built on older versions still need checking.

What is MCP, and how does it work?

MCP is an open protocol, released by Anthropic in November 2024 and now governed under the Linux Foundation, that standardizes how AI applications connect to tools and data. It has three parts:

• MCP clients and hosts: the AI applications that call tools, such as Claude Code, Cursor, VS Code, Claude Desktop and custom agents.
• MCP servers: programs that expose tools (actions), resources (data) and prompts to the client. A server can run locally on a developer's machine, communicating over standard input and output, or remotely over HTTP.
• The systems behind the server: email, files, databases, cloud APIs and SaaS applications, reached with credentials the server holds.

When a user asks an agent to do something, the model reads the list of tools and their descriptions, chooses a tool and sends a call. The server runs it with its own credentials and returns a result, which the model reads as input for its next step. Every part of that loop is a place an attacker can step in: the tool list, the description, the call, the server's authentication and the result.

MCP security best practices

Use this as a checklist. Each item maps to one or more of the risks below.

1. Inventory every MCP server in use, on developer machines and in repositories, with the client it is configured in, its launch command or URL, its version and its source package.
2. Approve servers against an allowlist, and block or flag any server that is not on it. Decide who can approve a server and how a request reaches them.
3. Allow tools, not just servers. Approve the read tools a team needs and deny write or destructive tools (for example, allow issue search but deny delete) unless there is a reason.
4. Pin versions and re-check every update. An approved server can ship a new version with new tools, new network destinations or new instructions.
5. Give each server the least privilege it needs, with its own scoped credential. Don't reuse a personal token with full access across several servers.
6. Keep secrets out of MCP configuration files. Use environment variables or a secret manager, and scan configuration files for hardcoded tokens.
7. Require authentication on every remote server, and test that a rejected request is really rejected: the request must stop, not return an error and continue.
8. Inspect tool descriptions, calls and results at runtime, not only the user's prompt. Instructions hidden in a tool description or a tool result are the main way an MCP server steers an agent.
9. Turn off auto-approval for tool calls in agent settings, at least for write actions, and enforce it through managed settings that users can't change.
10. Validate server-supplied URLs and hosts. A server that fetches a URL taken from the request can be turned against cloud metadata endpoints and internal services.
11. Log every tool call with the user, agent, server, tool, arguments and result, and send it to your SIEM.
12. Red-team agents through their tools, including a poisoned description, an injected tool result and an unapproved server, before release and after changes.

MCP security risks

Real MCP incidents and vulnerabilities

The three Pillar disclosures share a pattern: the caller supplies the instruction, and the MCP server supplies the authority. Each server ran a request with its own credentials without confirming who had sent it.

How to enforce an MCP server allowlist

1. Find the configurations. MCP servers are declared in each client's own settings files: Claude Code, Cursor, VS Code, Windsurf, Claude Desktop and others, at user, project and managed levels. Collect them from developer machines and from repositories, where project-level files are committed.
2. Identify each server. Record the client, the launch command or remote URL, the package and version, and who installed it.
3. Match each server against a vetted list. For each server, know what its tools can do (read, write, destructive), which network destinations it declares and which it actually contacts, who publishes it, and any known findings.
4. Decide per server and per tool. Approve, approve with restrictions (for example, read tools only) or deny. Groups can have different lists; a data team and a platform team rarely need the same servers.
5. Enforce where calls pass. For agents and applications that reach models through an AI gateway or an API, enforce the server and tool allowlist there. On developer machines, write the approved list into the client's managed settings through MDM so users can't override it, and block user-initiated installs where the client supports it.
6. Re-check on every update. Treat a new version of an approved server as a new server until it has been checked, and alert when a server outside the list appears.

Where to enforce MCP security

There is no single control point, because MCP traffic takes different paths:

• At the AI gateway or API: covers agents and applications you build, where calls go through LiteLLM, Kong, TrueFoundry or another gateway. This is where a server and tool allowlist and tool-result inspection are easiest to apply centrally.
• On the developer machine: covers coding agents such as Claude Code, Codex CLI and Cursor, which start local MCP servers that never cross a gateway. Controls here are configuration posture (which servers are configured, whether auto-approval is on) and the agent's pre-tool hooks.
• In repositories and CI: covers MCP configuration committed to projects, which an agent picks up when someone opens the repository.

Most enterprises need all three. The AI gateway guardrails guide covers the gateway path, and the AI coding agent security comparison covers the endpoint.

How the MCP specification changed in 2026

The MCP specification released on July 28, 2026 added six authorization changes. Among them, clients must validate the authorization server's issuer, which closes OAuth mix-up attacks, and the Mcp-Session-Id mechanism was removed. The sampling and roots features are deprecated, with at least 12 months before removal. Governance of the protocol moved to the Linux Foundation. Servers built on earlier versions keep their old behavior until they are updated, so check which specification version each approved server implements.

How MCP risks map to OWASP and MITRE ATLAS

The SAIL framework places these controls across the AI lifecycle, from inventory and posture to runtime.

How Pillar secures MCP

• Discovery: Pillar finds MCP servers configured on developer machines and in repository configuration files for Cursor, VS Code, Visual Studio, Windsurf, Codeium and Claude Desktop, and flags unapproved MCP clients.
• MCP intelligence: every server found is matched against Pillar's MCP catalog of more than 23,000 analyzed MCP servers, with a risk score, tool capabilities split into read and write or destructive, and declared and observed network destinations.
• Posture findings: findings such as MCP auto-approval enabled and channel-capable MCP servers show which configurations need fixing.
• Runtime enforcement: the MCP server allowlist and per-server tool permissions are one of Pillar's runtime guardrails, set in the Pillar console like any other guardrail, and enforced through LiteLLM and Pillar's API. Pillar also inspects tool descriptions, calls and results for poisoning and injection.
• Research: Pillar's researchers disclosed the Deadbugz campaign and the Dolt MCP and Grafana MCP vulnerabilities in 2026, and test agents' tools through red teaming.

Next steps

• Find the MCP servers your developers are running with Agentic Endpoint.
• Enforce MCP allowlists at your gateway with Runtime Guardrails.
• Read the research: Deadbugz, Dolt MCP and Grafana MCP.