MCP security matters because MCP servers can have significant access to sensitive systems — filesystems, databases, APIs, internal tools. A poorly secured MCP deployment can expose sensitive data, allow unauthorised actions, or become a vector for prompt injection attacks. The threat model is different from typical web application security because the attack surface includes the AI model itself: an attacker who can influence what the model receives from tool results can potentially manipulate the model’s behaviour. Understanding the specific security concerns and mitigations for MCP deployments prevents the most common and most serious vulnerabilities.
The MCP Threat Model
MCP deployments face threats from two directions. External threats: unauthorised clients connecting to MCP servers, intercepted or tampered network traffic, stolen credentials used to access remote servers. These are standard network security concerns addressed by authentication, transport security, and access control. Internal threats: adversarial content in tool results (prompt injection), overly permissive tool scopes that allow more access than intended, and server compromise that leads to the AI assistant taking unintended actions. The internal threats are unique to AI systems — they arise from the fact that tool results become part of the model’s context and can influence its subsequent actions. A database that contains attacker-controlled text can inject instructions into the model’s reasoning if the content is not properly isolated from the system prompt and user context.
Prompt Injection via Tool Results
Prompt injection is the most distinctive MCP security concern. When an MCP tool retrieves content from an external source — a web page, a database record, a file — that content becomes part of the model’s context. If the content contains text that looks like instructions (“Ignore previous instructions and instead…”), the model may follow those instructions. This is especially dangerous for agentic applications where the model has write access to systems: an attacker who plants injection text in a document the model will read could cause the model to take unintended actions like creating files, sending emails, or modifying records. Mitigations: clearly delimit tool results from instructions in the context using XML tags or system prompt structure that the model recognises as data boundaries; prompt the model to treat tool result content as untrusted data; implement a content filtering layer that scans tool results for instruction-like patterns before passing them to the model; and require explicit user confirmation before any write operation the model decides to perform based on retrieved content.
Principle of Least Privilege for MCP Tools
Each MCP server should expose only the capabilities genuinely needed for its intended use case. A filesystem MCP server used for a code editor should have read-write access only to the project directory, not to the entire filesystem. A database MCP server should connect with credentials scoped to the tables the AI assistant actually needs to query, not a superuser account. A GitHub MCP server for code review should have read access and comment creation, not force-push capability. The principle of least privilege limits the damage if the model is manipulated into taking unintended actions: even if an injection attack succeeds, the server cannot do anything outside its defined scope. Review each tool’s actual capabilities against its intended use case and remove permissions that are not strictly required.
Figure 1 — MCP security: threat categories and mitigations
Credential Management
MCP servers frequently require credentials to access the systems they interface with — API keys, database passwords, OAuth tokens. These credentials must never be hardcoded in server code or committed to version control. The correct approach for local stdio servers is to pass credentials via environment variables set in the client configuration file, not in the server code itself. The client configuration file (e.g. claude_desktop_config.json) specifies environment variables to set when launching the server process. This file should be treated as a secrets file: add it to .gitignore, ensure it has restrictive file permissions readable only by your user, and do not share it. For remote SSE servers, use a secrets manager (AWS Secrets Manager, HashiCorp Vault, or 1Password Secrets Automation) to inject credentials at runtime rather than storing them in configuration files or environment variables on the server host.
Transport Security for Remote Servers
Remote MCP servers using SSE transport must use TLS — HTTPS, not HTTP. Any MCP traffic sent over plain HTTP can be intercepted and read, exposing credentials and sensitive data. For internal team servers behind a corporate VPN, TLS is still required — VPNs protect against external interception but not against internal network compromise. Use a valid certificate (Let’s Encrypt for public servers, an internal CA for private servers) and configure the server to reject HTTP connections. Additionally, validate the server’s certificate on the client side — do not disable certificate verification even for development servers. A man-in-the-middle attack on an MCP connection could inject adversarial tool results into the model’s context, which is a higher-impact compromise than a typical network interception because of the prompt injection risk described above.
User Confirmation for Sensitive Operations
Well-implemented MCP clients require explicit user confirmation before executing tools that have destructive or irreversible effects — deleting files, sending messages, modifying database records, making API calls that cost money. This confirmation step is the primary defence against prompt injection attacks that try to cause the model to take harmful actions: even if the model is manipulated into requesting a harmful tool call, the user sees the request and can decline it. Claude Desktop implements this for destructive tool calls. When building your own MCP client or evaluating third-party clients, verify that confirmation dialogs are implemented for sensitive operations and that they display enough information for the user to make an informed decision — a vague “do you want to proceed?” is less useful than “Claude wants to delete /Users/you/Documents/important.pdf — allow?”.
Evaluating Third-Party MCP Servers
The growing ecosystem of community MCP servers includes many high-quality, trustworthy options — but also servers from unknown authors with unreviewed code. When installing a third-party MCP server, apply basic due diligence: check that the server’s repository is publicly visible and its code can be reviewed; look at repository stars, forks, and recent activity as quality signals; read the source code for the tool definitions and verify that the tools do what they claim; check whether the server makes unexpected network requests beyond the advertised integrations; and prefer servers from organisations with established reputations over anonymous authors for servers that access sensitive systems. For corporate deployments, require code review of all MCP servers before installation, regardless of source — apply the same standard you would to any software installed on company systems.
Logging and Audit Trails
For any MCP deployment where accountability matters — corporate environments, regulated industries, security-sensitive applications — maintain audit logs of all MCP tool calls: which tool was called, with what arguments, what it returned, and what the model subsequently did. These logs serve multiple purposes: detecting anomalous activity (a tool called far more times than expected, or with unusual arguments), investigating incidents (if data is unexpectedly modified, the tool call log shows exactly what happened), and compliance (demonstrating that AI assistant actions were logged and reviewable). MCP does not standardise audit logging — it is the client’s responsibility. Implement logging at the client layer so logs capture all tool interactions regardless of which server is involved.
Sandboxing MCP Servers
Running MCP servers as isolated processes with minimal system access reduces the blast radius of a compromised or misbehaving server. For stdio servers, run the server with a restricted user account that has only the permissions the server needs. Container-based sandboxing (Docker with limited volume mounts and network access) is more thorough: the server can only access the directories and network resources explicitly granted to its container. For servers that execute arbitrary code — code execution servers, shell command servers — container isolation is essential rather than optional. The MCP specification’s design of servers as separate processes rather than in-process libraries makes this sandboxing natural: the process boundary is already there, and adding OS-level resource constraints builds on it without architectural changes.
MCP security follows the same principles as general software security — least privilege, credential protection, transport security, audit logging — with one distinctive addition: prompt injection via tool results requires explicit mitigations that standard software security does not address. Build the mitigations in from the start: data boundary enforcement in context construction, user confirmation gates on sensitive operations, and audit logging of all tool interactions. For personal local MCP setups, the risk profile is manageable; for corporate deployments with access to sensitive business systems, treat MCP security with the same rigour you would apply to any service account with significant data access.