What is MCP security?
Model Context Protocol (MCP) security encompasses the measures and practices used to protect the integrity, confidentiality, and proper functioning of communication between large language models (LLMs) and the tools, plugins, data sources, and APIs with which they interact. As protocols such as MCP extend the capabilities of LLMs, these models gain the ability to carry out actions in real-world environments, access sensitive information, and invoke third-party extensions. Securing these interactions is essential to prevent exploitation, data leakage, and unauthorized actions initiated by the model or directed toward it.
MCP security concerns extend beyond traditional application security because models process both user prompts and contextual data returned by tool APIs. This makes them vulnerable to emerging attack types such as prompt injection and manipulation of tool outputs. The interconnected nature of MCP introduces multiple trust boundaries, and a weakness in any one of them can trigger cascading effects on security and privacy. An effective security approach must account not only for technical vulnerabilities but also for the dynamic and often unpredictable behavior of LLM agents and the ecosystems to which they connect.
Key MCP security issues and risks
Prompt injection and tool poisoning
Prompt injection happens when attackers create inputs, either visible to users or concealed within external content, that steer the model into performing unintended actions. These inputs may appear harmless, but they are designed to activate specific behaviors once interpreted by the LLM. For example, an attacker might embed a hidden instruction in a document or email. When processed by the assistant, that instruction could lead to data exfiltration or system actions that were never intended.
Tool poisoning is another major threat. It involves manipulating MCP tool metadata, including descriptions and parameters, to mislead the model into carrying out malicious actions. Because tools are often trusted by default, subtle metadata changes can remain unnoticed while still undermining system integrity.
Untrusted servers
MCP servers may run locally or be hosted in the cloud, and both deployment models introduce risks if the server is compromised or intentionally built for malicious purposes. An attacker could deploy an MCP server that appears legitimate and later modify its tools so they perform harmful actions, such as accessing confidential data or redirecting sensitive information.
The same risk applies to server updates. If tool behavior changes silently after installation, users or agents may unknowingly trigger dangerous operations. Malicious servers may also exploit naming collisions by using deceptive tool names to imitate trusted functionality.
Expanded attack surface
MCP expands the attack surface by linking LLMs to multiple services through APIs, tools, and data sources. Every integration creates an additional potential entry point for attackers. If any connected service is misconfigured or compromised, it may become a vector for manipulating the model, stealing data, or triggering actions in other services.
Because these components are interconnected, a single vulnerability can spread across multiple systems and services. This may involve weaknesses in prompt handling, server logic, or tool metadata. The risk grows as more services are brought into the model’s operational environment.
Lack of authorization
Poorly implemented authorization logic in MCP servers creates the conditions for the “confused deputy” problem. In such a case, an MCP server may act on behalf of a user while using privileges that exceed what that user should actually have. If the server does not properly verify the user’s identity and access rights, actions may be executed with the server’s elevated privileges instead of the permissions assigned to the requesting user.
Although MCP relies on OAuth for authorization, gaps in the specification and inconsistent implementation practices introduce vulnerabilities. Without strict enforcement of scoped access, models may invoke actions that should not be permitted.
Over-permissive access
MCP tools often request broad scopes for convenience, such as full access to Gmail or Drive even when only read permissions are required. This excessive access increases the impact of a breach because compromised tools can view or modify large volumes of sensitive data across services.
In addition to external threats, this also creates opportunities for privilege abuse by internal users or malfunctioning agents. Excess permissions may be used in unintended or unauthorized ways.
Supply chain risks
MCP servers and tools consist of code and dependencies that may themselves contain vulnerabilities. Attackers could inject malicious logic into dependencies or alter the codebase of a server component. In such a scenario, every user of that server could be affected.
Reducing these risks requires MCP developers to adopt secure software development practices. These include static analysis, software composition analysis, dependency verification, and signed builds. If an MCP server is deployed in the cloud, it should also support cryptographic verification so that clients can validate its identity.
10 key elements to secure in an MCP architecture
Protecting an MCP architecture requires securing every boundary where models, tools, users, and external systems interact. MCP creates execution paths that combine natural language, code, and privileged APIs. Each of the following elements represents a control point where failure can result in unauthorized actions, data exposure, or systemic compromise.
1. Authentication and authorization controls
MCP clients and servers must authenticate each other and strictly validate OAuth tokens. Tokens must be restricted by audience, limited by scope, and issued specifically for the MCP server. Authorization decisions must be enforced on the server side to prevent confused-deputy behavior and privilege escalation.
2. Input and output validation
All model inputs, including user prompts and tool responses, must be treated as untrusted. Servers should inspect and sanitize inputs to detect prompt injection patterns or malformed structures. Model outputs must be validated before being reused as tool inputs or downstream context.
3. Tool and metadata integrity
Tool definitions, descriptions, and parameters directly shape model behavior. These artifacts must be protected against tampering through signed manifests or trusted registries. Any modification to tool behavior or metadata should trigger review and reauthorization.
4. Logging, monitoring, and auditing
Every tool invocation should generate a structured audit record that includes identity, scopes, parameters, and results. Logs must be resistant to tampering and stored centrally to support incident response. Continuous monitoring enables the detection of anomalous or abusive activity patterns.
5. Network and deployment isolation
MCP servers should operate within isolated network segments and have only minimal access to internal services. A compromised MCP server must not allow lateral movement. Local servers should be sandboxed with restricted filesystem, process, and network privileges.
6. Supply chain and dependency security
MCP servers rely on third-party libraries and tools that may change over time. Dependencies should be scanned for vulnerabilities, pinned to specific versions, and verified through signed builds. CI/CD pipelines must be secured to prevent malicious code injection.
7. Rate limiting and abuse prevention
MCP endpoints must enforce request limits for each client, user, and tool. Rate limiting reduces the impact of automated attacks, model probing, and denial-of-service attempts. Usage thresholds must be enforced independently from model logic.
8. Secure transport and encryption
All MCP communications must use encrypted channels such as TLS to protect data in transit. Sensitive configuration data, tokens, and logs should also be encrypted at rest. Key management and rotation policies help limit the scope of damage after a compromise.
9. Continuous security testing
MCP implementations must be tested regularly using adversarial prompts, fuzzing, and penetration testing. Testing should cover prompt injection, tool misuse, and authorization bypass scenarios. Security assessments must be repeated after updates to tools or models.
10. Governance and compliance controls
MCP systems often handle regulated or sensitive data. Clear policies are required for data retention, access logging, and user consent. Governance ensures that MCP behavior remains aligned with legal, privacy, and organizational requirements.
MCP security best practices
1. Limit MCP permission scopes to the minimum necessary actions
Granting broad OAuth scopes from the outset, such as files:* or admin:*, increases the impact of token compromise and makes revocation more difficult. A better approach is for MCP implementations to follow a progressive scope model. Begin with a baseline set of low-risk scopes such as mcp:tools-basic, and request elevated scopes only when needed through targeted WWW-Authenticate challenges.
This approach reduces friction during initial setup, lowers the risk of privilege chaining, and improves audit clarity. Servers should support reduced-scope tokens and log every elevation attempt with scope details and correlation IDs. Clients should also cache denied scopes to avoid repeated elevation loops. Scope values in scopes_supported should not be unnecessarily expanded, because doing so normalizes over-permissioning and leads to abandonment of consent prompts.
2. Enforce strict server verification for all MCP endpoints
MCP servers must not forward tokens unless those tokens were explicitly issued for the MCP server itself. Accepting arbitrary access tokens, sometimes called token passthrough, weakens the server’s ability to enforce rate limits, validate requests, and maintain auditing. It also creates trust boundary violations because downstream APIs may rely on an incorrect identity or inaccurate behavioral assumptions.
To prevent this, the MCP server should:
- verify that the aud (audience) claim and other token claims match its own identity;
- reject tokens that are not scoped for the MCP server;
- avoid reusing tokens across services without verification.
3. Apply input validation to both user prompts and model outputs
Unvalidated data creates risk at both ingress and egress points in MCP interactions. Prompt injection may occur through user input or through tool responses, and malicious payloads may propagate across contexts when model output is treated as trusted input.
To reduce this risk, MCP servers should:
- validate incoming user prompts for known injection patterns or special tokens;
- inspect tool outputs before returning them to the model or exposing them to other systems;
- sanitize or reject unexpected responses that could trigger unintended behavior in downstream components.
4. Log all tool invocations using tamper-resistant storage
Strong logging is essential for accountability, incident investigation, and forensic response. Every tool invocation through an MCP server should be recorded together with relevant metadata, including:
- the identity of the MCP client and the user;
- the tool name and parameters;
- the requested scopes;
- the timestamp and result.
Logs should be stored in secure systems that resist tampering, such as append-only logs or write-once storage, with integrity checks and access controls in place. Without trustworthy logs, tracing misuse or auditing sensitive operations becomes significantly more difficult.
5. Regularly audit installed MCP tools and extensions
Tools in an MCP environment may change after installation. Updates can introduce new behaviors, permissions, or vulnerabilities. Attackers may exploit this by altering metadata, such as tool descriptions or parameters, or by injecting malicious logic through dependencies or dynamic configuration.
MCP server operators should:
- perform scheduled audits of all installed tools and extensions;
- revalidate declared permissions and descriptions against actual behavior;
- use static analysis and dependency scanning to detect changes or newly introduced risk;
- pin versions to prevent silent updates;
- monitor registry changes and trigger alerts when unexpected modifications occur.
6. Isolate MCP servers from sensitive internal networks
MCP servers should not be deployed in environments that provide unrestricted access to sensitive internal services. A compromised server could become a foothold for broader network intrusion.
To reduce this risk:
- deploy MCP servers in isolated network segments with strict ingress and egress controls;
- when using local MCP servers, sandbox them with minimal privileges, such as restricted filesystem and network access;
- use platform-specific sandboxing mechanisms such as containers, chroot jails, or application sandboxes;
- require authentication for local HTTP transports, or prefer stdio or Unix domain sockets with restricted access.
Local MCP servers should also present explicit consent dialogs before executing any configuration commands. The dialog should display the full command, warn about potential risks such as execution of rm -rf or curl for data exfiltration, and provide an option to cancel. This helps prevent unintentional code execution or malicious startup payloads.
