Top 8 MCP Security Risks and 9 Ways to Prevent Them

What Is MCP Security?

Model context protocol (MCP) security focuses on securing the connection between AI agents and external tools, data, or APIs to prevent unauthorized actions, data exfiltration, and AI-specific threats like prompt injection.

MCP is an open protocol that lets AI applications connect to external tools, data sources, and services. Because MCP allows agents to discover and invoke tools dynamically, it creates risks beyond traditional API security: the model may decide which tool to call, what data to pass, and how to act on tool outputs. Security needs to cover the full MCP chain: the client, server, tool definitions, permissions, authentication, authorization, transport, logging, and runtime behavior.

A secure MCP implementation should apply least privilege, strong authentication, explicit user consent for sensitive actions, tool allowlisting, input/output validation, secret isolation, logging, monitoring, and clear separation between data and instructions.

Key MCP security risks include:

• Prompt injection attacks: Attackers can craft malicious prompts to trick the LLM into using tools inappropriately.
• Tool poisoning: Malicious or compromised tool definitions manipulate the model into performing unintended or harmful actions.
• Credential theft and token exposure: API keys, OAuth tokens, or secrets passed through MCP connections can be intercepted or leaked via tool outputs.
• Insecure authorization: Missing or improperly enforced access controls allow agents to invoke tools or access data beyond their intended scope.
• Supply chain risks: Compromised third-party MCP servers or tool packages introduce malicious behavior into otherwise trusted agent workflows.
• Remote code execution and unsafe tool execution: Tools that run code or system commands can be exploited to execute arbitrary instructions on the host environment.
• Sensitive data exposure: Tool outputs containing personal, financial, or proprietary data can be exfiltrated through the model’s responses or logged insecurely.
• Over-permissioned agents: Agents granted broader tool access or capabilities than their task requires increase the blast radius of any compromise or misbehavior.

In this article:

• Why MCP Security Matters
• MCP Security vs. Traditional API Security
• Main MCP Security Risks and Issues
• 9 Ways to Prevent MCP Security Risks

Why MCP Security Matters

MCP security matters because MCP connects AI systems to real tools, data, and business systems. Once an AI assistant can call tools, read files, query databases, or trigger workflows, security failures can lead to real-world impact, not just a bad model response.

• Expands the attack surface: MCP connects AI apps to external tools, APIs, files, and data sources, creating new targets across clients, servers, and tool connections.
• Turns prompts into actions: In MCP-enabled systems, a malicious or manipulated prompt may influence the model to call tools, pass sensitive data, or perform unintended actions. Prompt injection and indirect prompt injection are especially serious.
• Increases the risk of data exposure: If MCP tools have broad permissions, an attacker may access files, credentials, customer data, source code, or internal systems through the AI assistant’s tool access.
• Introduces supply-chain risk: MCP servers and tools may come from third parties. If a tool’s metadata, description, or behavior is malicious or changes after approval, the AI system can be tricked into unsafe behavior through tool poisoning or similar attacks.
• Weakens access control and auditing: Poor MCP design, such as excessive permissions or unsafe token handling, can make it harder to enforce least privilege, track actions, and investigate incidents.
• Affects enterprise readiness: Businesses need AI agents to be reliable, permissioned, monitored, and auditable. MCP security supports AI tool integrations without exposing critical systems to unauthorized access or automated misuse.

MCP Security vs. Traditional API Security

MCP security includes many traditional API security controls, but it is broader because the caller is often an AI agent rather than a deterministic application. In a traditional API integration, developers usually define when an API is called, which endpoint is used, what parameters are sent, and how the response is handled.

In MCP, the model may choose tools based on natural-language instructions, tool descriptions, retrieved context, and prior outputs. That means security must account not only for API requests, but also for how tool metadata, prompts, external content, and model reasoning influence tool use. This is as a new attack surface where AI agents dynamically execute tools and where risks combine prompt injection, supply-chain attacks, and confused-deputy problems. A confused deputy attack occurs when an AI agent is tricked into using legitimate permissions on behalf of untrusted sources, such as malicious prompts, documents, or sites.

Traditional API security focuses on authentication, authorization, transport security, rate limits, input validation, and secure token handling. MCP still requires these controls, but they are not enough on their own. The MCP specification notes that MCP can enable arbitrary data access and code execution paths, and that implementers must build consent, authorization, access controls, and data protection into their applications because the protocol itself cannot enforce every security principle.

A key difference is that MCP tool definitions are part of the security boundary. In a normal API, documentation helps developers understand an endpoint, but it usually does not directly decide runtime behavior. In MCP, the model uses tool names, descriptions, schemas, and returned content to decide what to call and how to act. If those descriptions are malicious, misleading, or changed after approval, the model can be manipulated into unsafe tool calls.

Main MCP Security Risks and Issues

1. Prompt Injection Attacks

Prompt injection occurs when an attacker places malicious instructions in user input, documents, emails, web pages, tool outputs, or other content that the AI system processes. In MCP environments, this is especially risky because the model may interpret those malicious instructions as legitimate commands and use connected tools to act on them.

Indirect prompt injection is particularly dangerous because the malicious instruction may be hidden in external content rather than typed directly by the user. This can lead to unintended actions, data exfiltration, misleading outputs, or manipulation of later interactions.

Impact
Prompt injection can cause the AI assistant to call MCP tools in unsafe ways, leak sensitive data, ignore system instructions, bypass approval flows, or perform actions the user did not intend. In enterprise environments, this may expose customer data, source code, credentials, internal documents, or business systems.

Mitigations

• Treat external content, retrieved documents, emails, web pages, and tool outputs as untrusted data.
• Separate instructions from data clearly in prompts and tool responses.
• Use prompt-injection detection and filtering for both direct and indirect prompt injection.
• Require explicit user confirmation before sensitive tool calls, such as sending emails, modifying files, deleting data, or accessing restricted systems.
• Limit which tools can be called from untrusted contexts.
• Validate tool inputs and outputs before passing them back to the model.
• Log tool calls, arguments, returned data, and approval decisions for auditing.
• Use least-privilege permissions so injected prompts cannot access more than necessary

2. Tool Poisoning

Tool poisoning occurs when malicious instructions are hidden in MCP tool metadata, such as the tool name, description, parameter schema, or return values. Because LLMs use this metadata to decide which tools to call and how to use them, poisoned tool descriptions can manipulate the model into unsafe behavior.

Impact
Tool poisoning can cause the model to misuse trusted tools, exfiltrate data through normal-looking tool calls, prefer a malicious tool over a legitimate one, or follow hidden instructions that users and developers did not approve. A related “rug pull” risk occurs when a previously approved tool changes its description or behavior after installation.

Mitigations

• Review tool names, descriptions, schemas, and return values before approval.
• Treat tool metadata as part of the security boundary, not just documentation.
• Pin trusted tool definitions using hashes or version locks.
• Alert on changes to tool descriptions, schemas, permissions, or server behavior.
• Use tool allowlists instead of allowing arbitrary MCP servers.
• Block or quarantine tools with hidden instructions, suspicious descriptions, or unexpected schema changes.
• Keep sensitive tools isolated from general-purpose or untrusted MCP servers.
• Re-review tools after updates, dependency changes, or server ownership changes.

3. Credential Theft and Token Exposure

Credential theft and token exposure occur when MCP servers, clients, logs, prompts, tool outputs, or connected systems leak API keys, OAuth tokens, session tokens, personal access tokens, or other secrets. MCP increases this risk because tools may access multiple systems and may pass data between the model, client, server, and external APIs.

Impact
Exposed credentials can let attackers access internal APIs, cloud services, code repositories, email accounts, databases, customer data, or other protected systems. Over-scoped or long-lived tokens increase the damage because a single leaked token may grant broad or persistent access.

Mitigations

• Never place secrets in prompts, tool descriptions, source code, or tool responses.
• Use secret managers or secure vaults for API keys and tokens.
• Use short-lived, scoped, per-server credentials.
• Avoid sharing one token across multiple MCP servers.
• Redact secrets from logs, traces, errors, and model-visible outputs.
• Rotate credentials regularly and immediately after suspected exposure.
• Enforce token audience validation so tokens issued for one MCP server cannot be reused against another service.
• Prefer OAuth/OIDC flows over static personal access tokens where possible.
• Monitor for unusual token use, abnormal tool calls, and unexpected access patterns.

4. Insecure Authorization

Insecure authorization happens when an MCP server fails to verify who is making a request, what resource they are allowed to access, or whether the requested action was approved by the user. MCP proxy servers can also introduce confused-deputy issues if they act with broad privileges instead of enforcing per-client and per-user consent.

The official MCP security guidance specifically calls out confused-deputy risks and recommends per-client consent and proper authorization controls.

Impact
Attackers may gain access to APIs or data they should not be able to use, perform actions as another user, bypass consent, or exploit a trusted MCP server to access downstream services. Weak authorization also makes auditing and incident response harder because actions may not be tied clearly to the correct user, client, or permission grant.

Mitigations

• Require authentication for MCP clients, users, and servers where applicable.
• Enforce authorization on every tool call, not only at server connection time.
• Use per-user and per-client consent for sensitive actions.
• Validate OAuth token audience, scopes, issuer, expiration, and resource indicators.
• Use narrow OAuth scopes and avoid broad “full access” permissions.
• Apply role-based or attribute-based access control for tools and resources.
• Re-check authorization before high-risk actions such as write, delete, transfer, deploy, or send.
• Do not rely on the model to enforce permissions.
• Maintain audit logs that map each action to user, client, server, tool, input, and authorization decision.

5. Supply Chain Risks

Supply chain risks arise when MCP servers, tools, packages, dependencies, registries, or updates are malicious, compromised, abandoned, or poorly reviewed. MCP servers may come from public registries or third parties, and an installed tool can later change its behavior or metadata. Untrusted or compromised MCP server packages and tool-definition changes as major risks.

Impact
A compromised MCP server can steal data, execute commands, expose credentials, poison tool metadata, or manipulate model behavior. In enterprise environments, supply-chain compromise can spread quickly because one malicious tool may be connected to sensitive systems, developer environments, repositories, or internal APIs.

Mitigations

• Install MCP servers only from trusted sources and approved registries.
• Verify package signatures, checksums, maintainers, and repository history.
• Pin versions and avoid automatic updates for sensitive MCP servers.
• Review dependency trees and scan for known vulnerabilities.
• Monitor for changes in tool definitions, requested permissions, and network behavior.
• Use software composition analysis and vulnerability scanning in CI/CD.
• Maintain an internal allowlist of approved MCP servers and versions.
• Remove unused or abandoned MCP servers.
• Run third-party MCP servers in isolated environments with minimal permissions.

6. Remote Code Execution and Unsafe Tool Execution

Remote code execution and unsafe tool execution occur when MCP servers execute commands, scripts, shell operations, package managers, interpreters, or local processes in unsafe ways. This is especially risky for local MCP servers that run on developer machines or servers with access to files, credentials, and internal networks. Sandbox escapes and local MCP servers with broad host access can enable file traversal, credential theft, or arbitrary code execution.

Impact
Attackers may execute arbitrary commands, install malware, read or modify files, steal credentials, pivot into internal networks, tamper with repositories, or compromise developer and production environments. In AI coding environments, unsafe tool execution can turn a malicious prompt or poisoned tool into real system compromise.

Mitigations

• Avoid shell execution where possible; use safe APIs instead of command strings.
• Strictly validate and sanitize all tool inputs before execution.
• Use command allowlists and fixed argument templates.
• Block dangerous commands, shell metacharacters, path traversal, and arbitrary script execution.
• Run MCP servers in containers, sandboxes, restricted users, or isolated VMs.
• Restrict filesystem access to only required directories.
• Disable network access unless the tool explicitly requires it.
• Apply timeouts, resource limits, and execution quotas.
• Separate high-risk execution tools from tools that handle sensitive data.
• Log command execution, arguments, outputs, and exit status.

7. Sensitive Data Exposure

Sensitive data exposure occurs when MCP tools reveal confidential information to the model, user, logs, other tools, external APIs, or attackers. This may include credentials, personal data, customer records, financial information, source code, internal documents, database results, or proprietary business data. MCP increases exposure risk because tools can retrieve data from many connected systems and the model may pass that data into other tool calls.

Impact
Sensitive data exposure can cause privacy violations, regulatory issues, customer harm, intellectual property leakage, credential compromise, and loss of business trust. Data exfiltration through legitimate-looking channels, such as search queries or email subjects, as a specific MCP risk.

Mitigations

• Classify data by sensitivity and restrict which MCP tools can access each class.
• Apply least-privilege access to files, databases, APIs, and SaaS systems.
• Mask or redact secrets and sensitive fields before returning data to the model.
• Prevent sensitive data from being sent to untrusted tools or external services.
• Use data-loss prevention checks on tool inputs and outputs.
• Require user approval before sending, exporting, or sharing sensitive data.
• Limit result sizes and avoid bulk extraction unless explicitly authorized.
• Keep sensitive tools isolated from untrusted or general-purpose tools.
• Monitor for unusual data access, bulk reads, and suspicious exfiltration patterns.

8. Over-Permissioned Agents

Over-permissioned agents occur when an MCP-enabled assistant or server has broader access than needed, such as full mailbox access instead of read-only access, write access where read access is enough, or filesystem access beyond a required directory. The main recommendations are minimum permissions, scoped per-server credentials, narrow OAuth scopes, and short-lived tokens.

Impact
If the model is manipulated, compromised, or simply makes a mistake, excessive permissions increase the blast radius. An over-permissioned agent may delete files, modify systems, send unauthorized messages, expose data, change configurations, or trigger business workflows without proper authorization.

Mitigations

• Grant each MCP server and tool only the minimum permissions required.
• Use read-only access by default.
• Separate tools by risk level, such as read, write, admin, payment, deployment, or identity tools.
• Require step-up authentication or explicit confirmation for high-impact actions.
• Use per-tool, per-user, and per-session authorization checks.
• Avoid broad OAuth scopes and long-lived credentials.
• Review permissions regularly and remove unused access.
• Use policy engines or gateways to enforce tool-level access control.
• Set rate limits and action limits to reduce automated misuse.
• Test agents under adversarial prompts to verify they cannot exceed intended permissions.

9 Ways to Prevent MCP Security Risks

These best practices are based on the official MCP specifications, OWASP MCP Security Cheat Sheet, and Microsoft Azure MCP security guidance.

1. Apply Least Privilege to Every MCP Agent

MCP agents, clients, and servers should have only the permissions required for the specific task they perform. Each tool should be scoped by user, role, workspace, resource, action, and environment. For example, a file-search tool should only access approved directories or document collections, a database tool should only expose approved read queries, and a workflow tool should only trigger the specific actions needed for the user’s role.

Least privilege is especially important in MCP because the model may dynamically choose tools and parameters. If an agent has broad access, a prompt injection, poisoned tool, or model mistake can turn a narrow user request into a high-impact security event. Broad filesystem access, unrestricted network access, admin API tokens, wildcard OAuth scopes, and shared service accounts should be avoided.

MCP servers should use scoped credentials, short-lived tokens, per-user authorization, and separate permissions for read, write, delete, execute, and external-send actions. Dangerous capabilities, such as command execution, data export, credential access, permission changes, and destructive operations, should be separated into dedicated tools with stricter approval and monitoring. Permissions should be reviewed regularly and reduced when tools, users, or workflows no longer need them.

2. Require Explicit User Consent for Sensitive Actions

MCP clients should require user approval before connecting new servers, installing local servers, granting new permissions, or executing sensitive tool calls. Sensitive actions include sending emails, deleting files, modifying records, running commands, making purchases, changing permissions, or transmitting data outside the organization. The user should see what action will happen, which tool will be used, what parameters will be sent, and which account or system will be affected before approving. OWASP warns against auto-approving tool calls without showing full parameters and recommends human approval for sensitive or destructive calls.

Consent is especially important for local MCP servers because connecting one may execute code on the user’s machine. The official MCP security guidance says clients should show the exact command that will run, identify it as potentially dangerous, require approval, and allow cancellation before configuring a local server. It also says MCP clients should re-prompt when tool definitions change, because a previously approved tool may later become unsafe or behave differently.

3. Validate and Sanitize Tool Inputs

MCP servers should treat all tool inputs as untrusted, even when they come from the model. Model-generated arguments may be influenced by prompt injection, malicious documents, poisoned tool outputs, or user-supplied content. Every tool should validate parameter types, allowed values, length limits, file paths, URLs, SQL fragments, shell arguments, and destination domains before execution. OWASP recommends validating all inputs at the MCP server layer and warns against passing raw shell commands or unsanitized file paths.

Tool outputs should also be sanitized before being placed back into the model context. Retrieved documents, web pages, emails, database rows, and tool return values may contain hidden instructions such as “ignore previous instructions” or “send this data elsewhere.”

OWASP recommends treating every tool response as untrusted user input, making it clear to the model that tool responses are data rather than instructions, and stripping or escaping instruction-like markup before reinserting outputs into context. Microsoft describes indirect prompt injection as malicious instructions embedded in external content, such as documents, web pages, or emails, that can cause unintended actions.

4. Isolate MCP Servers

MCP servers should run in isolated environments with minimal filesystem, network, process, and credential access. Local MCP servers are especially risky because they may run on the same machine as the user and may have access to local files, environment variables, SSH keys, browsers, credential stores, and internal network services. The official MCP security guidance warns that local MCP servers without sandboxing can enable arbitrary command execution, data exfiltration, privilege escalation, and data loss.

In practice, isolation means running servers in containers, sandboxes, restricted user accounts, chroot-style environments, or platform application sandboxes. Filesystem access should be limited to approved directories, network access should be blocked or allowlisted by default, and sensitive host resources should not be mounted unless required.

For local servers, the MCP guidance recommends sandboxed execution with minimal default privileges, restricted access to filesystem and network resources, explicit grants for additional privileges, and use of stdio, Unix domain sockets, IPC controls, or authorization tokens to prevent unauthorized local access.

5. Use Strong Authentication and Authorization

MCP systems should authenticate the user, the client, and the server, then authorize each requested action according to the user’s permissions. For HTTP-based MCP transports, the official authorization specification says MCP auth implementations must use OAuth 2.1 with appropriate security measures, and it describes authorization-code flows for cases where an agent acts on behalf of a human user.

MCP servers should avoid token passthrough. The official MCP security guidance defines token passthrough as an anti-pattern where an MCP server accepts tokens that were not issued for that server and passes them to downstream APIs. This can bypass security controls, weaken auditing, and allow a stolen token to be used through the MCP server as a proxy. MCP servers must not accept tokens that were not explicitly issued for them, and they should validate token audience, issuer, scopes, expiry, client identity, and user identity before acting.

6. Secure MCP Configuration Files

MCP configuration files should be treated as sensitive security artifacts because they may define server commands, environment variables, tool endpoints, tokens, local paths, and trust decisions. They should not contain hardcoded secrets, broad API keys, refresh tokens, or unrestricted startup commands. OWASP warns not to store secrets in MCP server code, configs, or environment variables, and recommends verifying server sources, pinning tool descriptions and schemas, and detecting poisoned tools before use.

Configuration changes should be reviewed, version controlled where appropriate, and protected by file permissions. Local MCP configuration should show users the exact command being executed and warn about dangerous command patterns such as sudo, destructive file operations, network exfiltration commands, or access to sensitive locations such as home directories and SSH keys. The official MCP guidance recommends re-consent and guardrails before executing local server commands, because malicious startup commands can exfiltrate data or damage the host system.

7. Monitor Tool Calls and Agent Behavior

MCP deployments should log and monitor every tool invocation, including the user, client, server, tool name, parameters, timestamp, result status, approval decision, and downstream system touched. Logs should be centralized, searchable, and protected from tampering. Secrets and personal data should be redacted. OWASP recommends logging all MCP tool invocations with full parameters, user context, and timestamps, feeding logs into a SIEM, alerting on unusual patterns, and conducting regular audits and simulated attacks.

Monitoring should focus not only on authentication failures, but also on abnormal agent behavior. Examples include a summarization tool making outbound network calls, a read-only workflow attempting writes, an unusual spike in tool calls, calls to new or rarely used tools, admin-level queries, repeated access to sensitive files, or tool responses containing instruction-like language. Microsoft’s Azure MCP guidance recommends runtime monitoring and behavior detection because poisoned tools may appear normal while quietly exfiltrating data or triggering unsafe follow-on actions.

8. Vet Third-Party MCP Servers

Third-party MCP servers should go through supply-chain review before approval. Teams should verify the publisher, repository, package provenance, license, maintenance history, dependencies, update behavior, and requested permissions. Tool manifests, descriptions, schemas, and return formats should be inspected because they influence model behavior. Microsoft describes tool poisoning as a supply-chain risk because assistants trust MCP servers, manifests, and tool responses in a way similar to how applications trust third-party libraries or containers.

Organizations should maintain an internal allowlist or registry of approved MCP servers, versions, hashes, owners, and permissions. Any change to tool descriptions, schemas, commands, package versions, or hosted server behavior should trigger review, because a server can behave safely during approval and later change in a “rug pull.” Microsoft recommends pre-deployment inspection, source verification, version review, change control, and an internal tool registry that tracks approved MCP servers and changes over time. OWASP warns not to install MCP servers from unverified public registries without review and not to assume an approved tool is still the same tool later.

9. Create a Trusted MCP Registry

Organizations should maintain a trusted MCP registry that lists approved MCP servers, tools, versions, owners, permissions, risk levels, and allowed use cases. The registry should act as the official source of truth for which MCP integrations may be installed, which environments they may run in, which users or teams may use them, and what data or systems they are allowed to access.

A trusted registry helps reduce supply-chain risk by preventing users or agents from connecting to unknown public MCP servers without review. Before a server is added, security teams should inspect the publisher, source repository, package integrity, dependencies, startup commands, authentication model, requested permissions, tool descriptions, schemas, and return formats. Because tool metadata can influence model behavior, the registry should store reviewed versions of tool names, descriptions, parameter schemas, and return schemas, not just package names.

The registry should also support version pinning, hash verification, change detection, and re-approval workflows. If a hosted MCP server changes its tool definitions, package version, permissions, endpoint, command, or behavior, clients should treat it as a new security decision and require review before continued use. This helps defend against rug-pull scenarios where a tool appears safe during approval but later changes into a malicious or unsafe integration.

MCP Security with Cequence

The Cequence AI Gateway brings every control in this article into a single enforcement point for MCP traffic. It sits at the intersection of AI agents and the applications, APIs, and data they reach, authenticating clients and servers, validating token audience and scope, and enforcing least privilege on every tool call rather than only at connection time.

The gateway inspects what passes between the model and its connected tools, separating instructions from data, flagging poisoned tool definitions and unexpected schema changes, and requiring explicit approval before high-impact actions such as write, delete, or external send. Because it governs MCP calls outside the model itself, it closes the gaps that native LLM guardrails and static configuration leave open.

Behavioral detection sets the gateway apart. A poisoned agent can look perfectly normal while it quietly exfiltrates data, and an over-permissioned agent can drift outside its intended scope without ever tripping an authentication check. Cequence learns how each agent, tool, and server should behave, then watches runtime activity for the anomalies that static rules miss: a summarization tool making outbound calls, a read-only workflow attempting writes, a sudden spike in sensitive reads. That continuous visibility turns MCP from an opaque set of dynamic tool calls into traffic security teams that can monitor, audit, and trust, giving enterprises the confidence to deploy AI agents without exposing the systems behind them.

Learn more about the Cequence AI Gateway