MCP Security: Top 6 Risks and AI Security Best Practices
December 23, 2025
MCP Gateway, MCP Security, MCP Server, MCP Tools, MCP Use Cases, MCP Use Cases, Model Context Protocol (MCP)
What Is MCP Security?
The Model Context Protocol (MCP), an open standard that allows AI agents to connect to and interact with external tools, databases, and services. MCP security involves managing risks like prompt injection and unauthorized access to credentials through its direct pathways to enterprise resources. Its main goal is to secure the new, direct pathways MCP creates between AI models and enterprise resources, which bypass traditional security boundaries.
Key risks facing MCP servers include:
Prompt injection: Malicious prompts can trick an AI agent into performing unintended or harmful actions.
Credential theft: MCP servers may store API keys and tokens, making them a target for attackers.
Server compromise: Malicious or vulnerable MCP servers can be deployed to poison data or execute harmful code.
Supply chain attacks: Downloading unverified MCP servers from unofficial sources can introduce malware.
Try Obot Today
⬇️ Download the Obot open-source gateway on GitHub and begin integrating your systems with a secure, extensible MCP foundation.
MCP separates the AI model from the external tools it uses. It does this through a two-part architecture: the MCP client and the MCP server. The client interfaces with the language model, while the server handles communication with external tools or services. This setup prevents the AI from directly interacting with tools, adding a layer of control and abstraction.
A typical request follows this flow:
A user sends a request to the MCP client.
The client references its list of available MCP servers and the tools each one supports.
It sends this information, along with the user’s request, to the language model.
The model responds with the name of the tool to use and the parameters required.
The MCP client forwards this to the correct MCP server.
The server executes the task and returns the result.
The client sends the result back to the model, which generates a response for the user.
MCP clients can connect to multiple MCP servers at once. These servers may run locally, where the host is under the user’s control, or remotely, hosted by a third party. Local servers typically run OS commands or custom code, and they carry different security considerations than remote servers. While remote servers do not run on the user’s infrastructure, they still pose a risk if they access sensitive data or respond with malicious output.
One of the core security concerns with MCP is the confused deputy problem, where an MCP server unintentionally performs actions on behalf of a user with broader privileges than the user should have. Since MCP servers act as intermediaries between AI models and external tools, it’s critical they execute actions only with the user’s explicit permission and limited scope.
The current MCP authorization framework relies on OAuth, but the specification includes implementation details that clash with common enterprise access control practices. For example, enterprise environments often expect tight integration with identity providers and fine-grained access control that MCP’s model doesn’t yet fully support.
2. Supply Chain Risks
MCP servers are essentially software modules that users download and run, often from public repositories. This makes them prime targets for supply chain attacks, where malicious actors compromise the server code before or after installation.
Attackers can tamper with the source code, inject backdoors, or modify dependencies to introduce vulnerabilities. Even seemingly minor misconfigurations in build pipelines can expose users to significant risk. Notably, unsigned MCP components or ones without verified integrity checks are especially dangerous.
3. Unauthorized Command Execution
Many local MCP servers are designed to execute operating system commands or run scripts based on model instructions. When implemented carelessly, these servers can be vulnerable to command injection, where malicious input is interpreted as executable code.
For example, if user input is directly passed to subprocess.call or a shell command without validation, an attacker can craft input that executes arbitrary commands. This kind of vulnerability is especially dangerous on local servers with elevated permissions.
4. Prompt Injection
Prompt injection remains one of the most difficult vulnerabilities to fully prevent in AI systems. In the context of MCP, it becomes even more dangerous because injected prompts can trigger the server to perform real-world actions like calling APIs, modifying data, or running commands.
Attackers can design prompts that exploit the model’s behavior, such as obfuscated text that hides secondary instructions. A user might innocently paste such a prompt into the MCP client, thinking it performs a benign action, when in fact it also includes hidden logic that creates security issues, like leaking data or provisioning unauthorized accounts.
5. Tool Injection
Malicious or compromised MCP servers can exploit the tool selection mechanism used by AI models. Since the model chooses tools based on descriptions provided by the server, an attacker could create a tool injection scenario where a tool with a misleading name or description is selected inappropriately.
For example, a tool claiming to retrieve weather data might secretly collect system logs or send sensitive information to a remote endpoint. The tool may pass initial inspection but later be updated to behave maliciously, exploiting the user’s trust in the original version.
6. Sampling Misuse
MCP supports sampling, a feature that allows servers to request language model completions via the MCP client. While this helps decentralize cost and centralize control, it also creates an avenue for abuse if a malicious server sends prompt data to the model that results in harmful behavior or data leakage.
A compromised server could use sampling to manipulate the AI model indirectly or to extract private user information via crafted prompts. This turns the user’s own LLM against them.
Best Practices for MCP Security
Get Your Free Enterprise MCP Playbook
Take the next step in operationalizing the MCP Maturity Model: Obot’s Enterprise MCP Playbook outlines detailed stage definitions, architecture patterns, governance checklists, and guidance on moving from early experiments to a fully scaled, AI-ready platform.
Here are some of the ways to improve security in MCP-based systems.
1. Enforce Least-Privilege Scopes Per Tool and Resource
MCP servers should adopt a progressive scope model that limits initial access to only low-risk operations. Begin with minimal scopes (e.g., discovery or read-only access) and request additional privileges only when needed. This reduces the impact of token compromise and avoids granting unnecessary permissions up front.
To implement this:
Use targeted scope challenges when privileged actions are required.
Accept down-scoped tokens to support reduced access levels.
Avoid publishing wildcard or omnibus scopes in scopes_supported.
Log all scope elevation events with correlation IDs for auditing.
Least-privilege design also makes token revocation easier and reduces user friction during consent flows.
2. Require Signed MCP Server Artifacts and Verify at Startup
MCP clients should verify the authenticity and integrity of MCP server artifacts before execution. Require all servers to be signed using cryptographic signatures and validate these signatures at startup.
Unsigned or tampered binaries introduce risk of arbitrary code execution. By enforcing signature checks:
You reduce exposure to supply chain attacks.
You ensure only vetted code is executed.
You can build trust policies around verified publishers or build pipelines.
For servers installed from public sources, verification should be automatic and mandatory.
3. Terminate All Model/Tool Egress Through Policy-Enforced Proxies
MCP systems should prevent direct model-to-tool or tool-to-internet communication unless it passes through a controlled proxy. This proxy should enforce access policies, inspect traffic, and log outbound requests.
Benefits include:
Preventing exfiltration of sensitive data via tool responses or sampling prompts.
Enforcing tool-specific egress rules.
Blocking outbound access to unauthorized or malicious endpoints.
This is especially important for remote servers or tools capable of calling external APIs.
4. Log Every Tool Invocation with Hashed Inputs/Outputs
All MCP tool executions should be logged, including the name of the tool, hashed input parameters, and hashed outputs. These logs support forensic analysis, auditing, and detection of misuse or anomalies.
Hashing inputs and outputs protects user privacy while still enabling:
Replay detection
Behavioral analysis
Tracking of abnormal tool usage patterns
Logs should include timestamps and correlation IDs to tie invocations to specific model requests.
5. Rotate and Short-Lived Credentials, Never Passthrough Raw User Tokens
MCP servers must avoid token passthrough, where raw user access tokens are sent directly to downstream APIs. Instead:
Use short-lived, scoped tokens issued explicitly to the MCP server.
Rotate credentials frequently to minimize exposure.
Validate token audience and claims before use.
Passing raw tokens undermines auditability and violates trust boundaries between components. The server should always act as the authoritative party when accessing external resources, not just forward credentials it cannot validate.
6. Deny by Default, Explicit Per-Tool Allowlists and Schemas
MCP clients should deny tool invocations by default and require explicit allowlists for each permitted tool. Allowlisting should include:
Tool names and versions
Parameter schemas with allowed types and constraints
Permitted scopes or actions
This limits the risk of unauthorized or unexpected tool execution, especially from malicious or tampered servers. Allowlists must be centrally managed and reviewed regularly.
7. Regularly Fuzz and Red Team Tools, Fix Injection Sinks First
Security testing of MCP tools should be ongoing. Use fuzzing and red teaming to uncover:
Command injection vulnerabilities
Prompt injection handling weaknesses
Misuse of sampling or system calls
Prioritize fixing injection sinks, as they can be exploited to gain control over local systems or exfiltrate data. Tools accepting model input as parameters should be hardened and validated against malformed or malicious content.
8. Continuously Inventory and Kill “Shadow” MCP Servers
Maintain an inventory of all MCP servers deployed in your environment. Identify and disable “shadow” servers, including those:
Running without user consent
Installed outside of approved channels
Exposing tools not listed in official configs
To do this:
Scan for running MCP processes and open ports
Verify server origins and integrity
Audit recent installations and configuration changes
Unauthorized servers present serious risk, particularly if they run on localhost and have access to sensitive commands or files. Killing unverified servers helps contain potential compromise.
