MCP Server Security: 7 Risks and an Audit Checklist for European Teams

TL;DR: MCP servers can read files, call APIs, execute commands, and expose credentials. Why this matters: approve servers, scope permissions, and log tool calls before connecting them to sensitive work.

The Model Context Protocol (MCP) is one of the most consequential infrastructure decisions a technical team can make when deploying AI tools in 2026. MCP servers extend what AI assistants like Claude can do: they can browse the web, read files, query databases, execute code, and call third-party APIs on behalf of the user. This makes them genuinely useful and also genuinely dangerous if deployed without a security review. Why this matters: a single unsecured MCP server can expose credentials, file systems, and client data, creating both operational and regulatory liability that most engineering teams have not yet accounted for.

A malicious or compromised MCP server can expose tools, prompts, or resources that push the model toward actions the user did not intend. It can also access any files, APIs, or credentials that the deployment grants to it. For a 25-person engineering team in Warsaw or a professional services firm in Brussels relying on AI tools for sensitive client work, this is not a theoretical risk. It is an operational security gap that needs a structured response.

Source basis: the Model Context Protocol authorization specification, MCP security best practices, Anthropic's Claude Code security documentation, Anthropic's Claude Code MCP documentation, and OX Security's April 2026 MCP STDIO command-injection advisory.

Current Risk as of May 2026: STDIO Command Injection

This article is a baseline MCP hardening guide, not a live incident advisory. Still, any current MCP security review must account for the April 2026 OX Security disclosure covering command-injection and remote code execution risks around MCP STDIO configuration in multiple AI ecosystem tools.

The practical lesson is not that every MCP server is unsafe. It is that MCP servers are software supply-chain components with privileged access paths. A server that accepts user-controlled command or args values, constructs shell commands from untrusted input, or lets prompts modify .mcp.json without meaningful review can become an execution boundary, not just an integration boundary.

For European SMEs, treat MCP approval like approving a privileged CI integration or database connector. Baseline hardening covers normal deployment controls: trusted servers, scoped tokens, OAuth hygiene, logging, and version pinning. Vulnerability response covers active exposure: remove affected versions, disable risky STDIO configurations, review .mcp.json changes, and verify whether any MCP server accepted arbitrary command construction.

Risk 1: Tool Description Injection

The most serious and least understood MCP risk is tool description injection. When an MCP server registers its tools with an AI model, it provides natural-language descriptions of what each tool does. The AI model reads these descriptions to decide when and how to call the tool. If a malicious MCP server, or a compromised one, provides a description that contains instructions to the model rather than a description of the tool's purpose, the model may follow those instructions.

The defence against tool description injection starts with provenance: only connect to MCP servers whose source code you have reviewed or whose publisher you trust completely. For enterprise teams, this means maintaining an approved MCP server list and prohibiting employees from connecting to arbitrary community-published servers.

Checklist item 1: Review the complete tool description text in every MCP server before connecting. This text should describe what the tool does, not how the model should behave. Any description that includes phrases like "you should", "always", "never tell the user", or instruction-format language is a red flag.

Risk 2: Credential and Session Token Access

MCP servers that have access to the file system can potentially read credential stores, session tokens, and configuration files that contain secrets. If the MCP server is granted broad file system permissions, a compromised server can read ~/.ssh/, ~/.aws/credentials, .env files, or any local credential cache.

This risk is compounded when AI coding assistants are granted wide file access to be maximally helpful. A developer who connects Claude Code or a similar tool to an MCP server that provides filesystem browsing may be inadvertently giving that server a path to credential files stored in their home directory.

Checklist item 2: Scope MCP server file system access to the minimum required directory. For a coding assistant, this is typically the project root. Review the MCP server's declared permissions in its configuration file before connecting, and reject any server that requests home directory access unless there is a specific, understood reason for it. On macOS, use sandbox profiles or permission boundaries to enforce directory scope at the OS level.

Risk 3: Token Passthrough and API Proxy Risk

MCP servers that proxy requests to third-party APIs must not accept arbitrary tokens from clients and pass them downstream. The MCP security best practices describe token passthrough as an anti-pattern because it can bypass rate limits, request validation, traffic monitoring, audit trails, and token audience checks.

For European teams, proxying API requests also carries a specific GDPR implication. If personal data flows through an MCP server to a third-party API based outside the EU, that transfer requires appropriate safeguards under GDPR Chapter V. An MCP server that makes undocumented API calls to services outside your approved processor list with personal data embedded in queries is a data protection incident waiting to happen.

Checklist item 3: For each MCP server connected to production systems or handling real data, document every external API endpoint the server can call. Verify that access tokens are issued for the MCP server as the intended audience, that personal data cannot flow to services outside your approved data processing list, and that network egress is restricted where code review cannot guarantee this.

Risk 4: Weak OAuth and Authorization Metadata

MCP authorization is based on OAuth 2.1 patterns. The current authorization specification requires protected MCP servers to implement OAuth 2.0 Protected Resource Metadata, clients to use it for authorization server discovery, and authorization servers to expose metadata through OAuth Authorization Server Metadata or OpenID Connect discovery. Access tokens must be sent in the Authorization: Bearer header, not in query strings.

For public clients, MCP clients must use PKCE and verify PKCE support before proceeding. Implementations must use HTTPS for authorization server endpoints, with redirect URIs limited to HTTPS or localhost. MCP servers must validate that tokens were issued specifically for them as the intended audience.

Checklist item 4: Reject MCP servers that skip metadata discovery, accept query-string tokens, do not validate token audience, or cannot explain how PKCE and secure token storage are handled.

Risk 5: STDIO Command Construction and RCE Exposure

The April 2026 advisory changed the MCP risk conversation because it highlighted a concrete failure mode: applications accepting MCP STDIO configuration with user-controlled command values and executing those values as subprocesses. This is especially risky when configuration is exposed through a web UI, generated by an assistant, or stored in a project-level .mcp.json file that developers approve too quickly.

Claude Code asks users to approve MCP servers and can use project-scoped MCP configuration. That approval step is useful, but it is not a substitute for code review. A developer who approves an MCP server without reading the command, arguments, package source, and permission scope may still approve a path to local command execution.

Checklist item 5: Do not allow arbitrary command construction from user input. Where STDIO MCP servers are required, use strict command allowlists, pin package versions where practical, review .mcp.json in pull requests, and reject configurations that pass untrusted values into shell commands. Never place secrets in MCP configuration.

Risk 6: Overprivileged Execution Context

Some MCP servers execute code or shell commands on behalf of the AI model. If that execution happens with the privileges of the current user, a compromised server can do anything the user's account is authorised to do: delete files, modify configurations, make outbound network connections, or read data from connected services.

The principle of least privilege applies here as it does anywhere in security. An MCP server that executes shell commands should run as a restricted user with no access to production credentials, no outbound network access except to explicitly approved endpoints, and no write access to directories outside the task scope.

Checklist item 6: Run MCP servers that execute code or commands as a dedicated low-privilege service account. Use Docker containers, devcontainers, or operating-system sandboxing to restrict what the process can access. Isolate high-risk MCP servers from production credentials and log all command executions to an audit trail that the MCP server process itself cannot modify.

Risk 7: Missing Update and Provenance Verification

MCP servers sourced from community repositories, npm packages, or GitHub can change after you have reviewed them. A server you audited last month may have received an update that introduced new tool descriptions, new external API calls, or new permission requests. Most teams do not re-audit their MCP dependencies after initial setup.

Additionally, for teams using package managers to install MCP servers, supply chain attacks are a live threat. A compromised package maintainer can publish a malicious update that passes basic functional testing while introducing a security exploit.

Checklist item 7: Pin MCP server dependencies to specific versions in your configuration, and review the diff before approving any version upgrade. For high-trust MCP servers, meaning those with database, credential, or write access, treat version upgrades with the same review process as a code change in your primary application. Subscribe to security advisories from MCP server publishers where available.

EU AI Act Classification for MCP-Enabled Systems

Under Regulation (EU) 2024/1689, the EU AI Act, the AI component of a system is assessed for risk based on the system's purpose and the decisions it makes, not just the model itself. An AI system that includes MCP servers providing access to personnel records, financial data, or medical information may qualify as a high-risk system under Annex III depending on the deployment context.

High-risk classification triggers requirements including: conformity assessment, technical documentation, logging of system operation, human oversight mechanisms, and registration with the EU AI Act database. Teams deploying MCP-enabled AI systems in HR, financial services, or healthcare contexts should conduct a formal risk classification check before deployment.

For most internal operational deployments (coding assistance, document drafting, customer communication support), MCP-enabled systems will not reach high-risk classification. But the assessment is not optional. Documenting the classification decision and its rationale is a compliance requirement under Article 9 of the regulation for in-scope operators.

Pre-Deployment Security Checklist

Before connecting an MCP server to a production AI deployment:

• [ ] Source code reviewed or publisher explicitly trusted
• [ ] All tool description text audited for injection-format language
• [ ] File system permissions scoped to minimum required directory
• [ ] External API endpoints documented and GDPR transfer basis confirmed
• [ ] OAuth metadata discovery, PKCE, HTTPS or localhost redirects, and token audience validation confirmed where authorization is used
• [ ] Token passthrough rejected; tokens must be issued for the MCP server
• [ ] .mcp.json reviewed before project-level trust is granted
• [ ] No arbitrary STDIO command construction from user input
• [ ] Strict command allowlists used where command execution is unavoidable
• [ ] No secrets stored in MCP configuration
• [ ] MCP server runs as least-privilege account or in sandboxed container
• [ ] High-risk MCP servers isolated from production credentials and sensitive data stores
• [ ] Claude Code approval prompts and trust verification reviewed by a human before accepting a server
• [ ] Command execution logged to tamper-evident audit trail
• [ ] Version pinned and upgrade review process defined
• [ ] EU AI Act risk classification documented for the overall system
• [ ] Personal data handling reviewed for GDPR Article 28 controller-processor requirements if using a third-party MCP server

A team that completes this checklist before connecting an MCP server to any AI tool used in a business context has addressed the primary attack surface. This does not require dedicated security staff. It requires a structured two-hour review session before deployment.

Ready to review your team's AI tool security posture in more detail? Start with the First AI Movers AI Readiness Assessment.

Frequently Asked Questions

Are MCP servers safe if I only use trusted publishers?

Trusted publishers reduce supply-chain risk, but they do not remove deployment risk. Anthropic's Claude Code security documentation says Anthropic does not manage or audit MCP servers. Scope file system access, run servers with least privilege, and audit before each version update. Security posture is a property of how you deploy, not just of which server you choose.

What is the difference between MCP security and Claude Code's built-in permissions?

Claude Code has its own permission system for controlling what files and bash commands it can access, configured in settings.json. This is separate from MCP server permissions. An MCP server connected to Claude Code can potentially bypass the Claude Code permission layer if it is granted access at the OS level. The two permission systems must be configured consistently. Do not grant an MCP server more file system access than you would grant Claude Code directly.

How does a small team without a security professional conduct this audit?

The checklist above is designed to be completed by a developer or technical lead without security specialisation. The most important steps are: read the MCP server source code before deployment (or use only publishers whose code you can read), restrict file system permissions in the MCP configuration file, and document what external APIs the server calls. Eighty percent of the risk reduction comes from these three actions.

Further Reading

• Claude Code Security and Data Privacy for European Teams
• AI Vendor Evaluation Scorecard: 8 Criteria for European SMEs
• Shadow AI Detection and Governance for European SMEs