7 MCP Security Risks and 8 Ways to Mitigate Them

What is Model Context Protocol (MCP) Security?

Model Context Protocol (MCP) security involves safeguards that protect AI-to-tool connections. Because MCP was originally built for flexibility, it lacks built-in authentication or strict access controls. It is vulnerable to prompt injection, over-privileged AI agents, and credential leakage if left unmanaged.

A secure MCP implementation typically relies on least-privilege access, strong authentication, scoped authorization, user consent for sensitive actions, secure token handling, input and output validation, logging, monitoring, and isolation between tools. Organizations also need to treat MCP servers as part of the application attack surface, especially when they are built by third parties, installed from public registries, or connected to sensitive enterprise systems.

Key MCP security risks include:

1. Tool poisoning attacks: Malicious or compromised tools manipulate metadata or behavior to mislead AI agents into performing unauthorized actions or exposing sensitive data.
2. Over-privileged access: MCP servers or tools receive broader permissions than necessary, increasing the impact of prompt injection, misuse, or compromise.
3. Prompt injection: Untrusted content from tools, documents, or external systems influences model behavior and can trigger unauthorized tool calls or data exposure.
4. Unmanaged servers: Unapproved or poorly maintained MCP servers introduce unknown permissions, insecure code, and gaps in security monitoring.
5. Credential sprawl: Excessive API keys, OAuth tokens, and service credentials increase the risk of secret leakage and make credential management more difficult.
6. Rug pull attacks: Previously trusted MCP servers or tools change behavior after approval, introducing malicious functionality or expanded permissions.
7. Confused deputy problems: Trusted MCP components misuse their authority when identity or authorization context is not properly enforced.

Essential MCP security best practices:

1. Maintain an approved MCP server registry: Track trusted servers, ownership, permissions, versions, and review status to prevent unauthorized deployments.
2. Use least-privilege access for every MCP server: Limit each server and tool to the minimum permissions needed for its intended function.
3. Identity-aware execution (OBO): Execute tool calls using the requesting user’s identity to enforce existing authorization policies and improve auditing.
4. Validate tool metadata before approval: Review tool descriptions, parameters, and permissions to ensure they accurately reflect intended behavior.
5. Pin and monitor tool schemas: Lock trusted schema versions and review changes before deployment to detect unauthorized or risky modifications.
6. Add human approval for sensitive actions: Require explicit user confirmation before executing high-impact or irreversible operations.
7. Sanitize tool outputs before they enter model context: Treat tool responses as untrusted data by filtering malicious content, secrets, and prompt injection attempts.
8. Use policy enforcement at the gateway layer: Apply centralized authentication, authorization, monitoring, and policy controls between AI hosts and MCP servers.

Why MCP Security Matters 

MCP Expands the AI Attack Surface

MCP changes an AI application from a self-contained assistant into a connected system with access to files, APIs, databases, cloud services, business applications, and developer tools. Every MCP server, tool, resource, prompt, and transport mechanism becomes a potential entry point for abuse. A vulnerable or over-permissioned server can expose sensitive data, accept unsafe inputs, or allow attackers to influence how the AI system behaves.

This is especially important because MCP ecosystems often include multiple servers from different sources. Some may be internally developed, while others may come from open-source repositories, marketplaces, or third-party vendors. Without proper review, sandboxing, permission boundaries, and continuous monitoring, organizations can unintentionally give AI workflows access to systems that were not designed to be controlled by autonomous agents.

MCP Agents Can Take Real-World Actions

MCP not only gives models more information; it can also give them the ability to act. An MCP-enabled agent may be able to send messages, update tickets, query production systems, modify code, create cloud resources, run commands, or trigger business workflows. This makes authorization and consent critical because a mistaken or manipulated tool call can have operational, financial, or security consequences.

Security controls should distinguish between low-risk read-only access and high-impact write or execution capabilities. Sensitive actions should require explicit approval, scoped permissions, clear user visibility, and audit logs. Tools should be designed narrowly so the model can perform specific approved tasks rather than receive broad access to an entire system. This helps reduce the risk of accidental actions, privilege escalation, or unauthorized changes.

MCP Introduces New Prompt-Injection Paths

MCP creates new ways for malicious instructions to reach an AI system. Prompt injection can come not only from a user prompt but also from external content retrieved through tools, tool descriptions, resource data, documents, web pages, tickets, code comments, database records, or server-provided metadata. If the model treats that content as trusted instructions, an attacker may be able to manipulate tool selection, trigger unauthorized actions, or cause sensitive data to be exposed.

This makes separation of data and instructions a core MCP security requirement. External content should be treated as untrusted input, tool metadata should be validated, and the host should enforce policy rather than relying only on the model to decide what is safe. Strong MCP security also includes monitoring tool calls for abnormal behavior, limiting what each tool can access, and requiring user confirmation when a request could expose data or change an external system.

Related content: Learn more in our guide to AI cyber security.

How Agentic AI Impacts MCP Security

Agentic AI changes the MCP security model because AI systems can now plan, make decisions, chain multiple tool calls, and complete tasks with limited human involvement. Instead of invoking a single tool in response to a prompt, an agent may discover new tools, retrieve external data, choose execution paths, and perform sequences of actions across multiple systems. 

As autonomy increases, organizations must secure not only individual tool calls but also the agent’s decision-making process, permission boundaries, execution context, and ability to interact safely with untrusted data sources.

• Autonomous tool selection: Agents choose which tools to call based on available metadata, increasing the importance of accurate tool descriptions and validation.
• Multi-step execution chains: A single request may trigger multiple connected tool calls, allowing small errors to propagate across systems.
• Expanded privilege exposure: Agents that access many tools inherit a broader attack surface and require strict least-privilege controls.
• Higher prompt-injection risk: Instructions can originate from retrieved documents, APIs, websites, or tool outputs rather than only from users.
• Dynamic decision making: Agents may adapt their plans during execution, making policy enforcement more important than static workflows.
• Greater impact of compromised tools: One malicious or vulnerable MCP server can influence an entire chain of agent actions.
• Increased need for identity awareness: Every action should execute using the requesting user’s permissions instead of shared service accounts.
• Continuous authorization checks: Permissions should be evaluated throughout long-running tasks rather than only when execution begins.
• More complex audit requirements: Security teams need visibility into every decision, tool call, and downstream action an agent performs.
• Stronger human oversight: High-risk actions should include approval checkpoints before agents modify data, infrastructure, or business systems.

Key MCP Security Issues and Risks 

1. Tool Poisoning Attacks

Tool poisoning occurs when a malicious or compromised MCP server exposes tools with misleading names, descriptions, parameters, or behavior. Because AI agents often rely on tool metadata to decide which tool to use, an attacker can manipulate descriptions to make a dangerous tool appear harmless or to influence the model into using it in unintended ways.

For example, a tool may appear to retrieve a document, summarize a ticket, or check a repository, while secretly accessing sensitive files, leaking data, or triggering unauthorized actions. Tool poisoning can also happen when a legitimate tool is updated with hidden behavior after users have already approved it. To reduce this risk, organizations should validate tool definitions, review server updates, restrict tool permissions, and monitor tool calls for unexpected behavior.

2. Over-Privileged Access

Over-privileged access happens when MCP servers or tools receive broader permissions than they need to perform their intended function. This may include access to entire file systems, full database permissions, broad cloud roles, unrestricted API scopes, or write access where read-only access would be enough.

This risk is serious because AI agents may invoke tools automatically or semi-autonomously. A small prompt error, malicious instruction, or compromised server can become more damaging when the tool has excessive privileges. MCP tools should be scoped narrowly, separated by function, and granted only the minimum access required. High-risk actions should require explicit approval, and sensitive systems should use strong authorization, auditing, and policy enforcement.

3. Prompt Injection

Prompt injection is a major MCP risk because agents can receive untrusted content from external tools, files, websites, tickets, logs, documents, and databases. Malicious content can instruct the model to ignore previous rules, call specific tools, reveal secrets, or perform unauthorized actions.

In MCP environments, prompt injection is especially dangerous because the injected instruction may be combined with real tool access. A malicious document, for example, could tell the agent to retrieve confidential files and send them to an attacker-controlled endpoint. Organizations should treat all external content as untrusted data, separate instructions from retrieved content, validate tool inputs and outputs, and require human approval for sensitive tool calls.

4. Unmanaged Servers

Unmanaged MCP servers are servers that are installed, connected, or operated without proper inventory, ownership, review, or lifecycle controls. These may include local servers configured by individual users, open-source servers downloaded from public repositories, or experimental servers connected to production tools.

The risk is that unmanaged servers may have unknown permissions, insecure code, outdated dependencies, weak authentication, or hidden behavior. They can also create blind spots for security teams because tool calls and data access may happen outside approved monitoring channels. Organizations should maintain an MCP server inventory, define approval workflows, track versions, remove unused servers, and route enterprise MCP usage through controlled gateways or managed environments where possible.

5. Credential Sprawl

Credential sprawl occurs when MCP servers, clients, and tools require many different API keys, tokens, secrets, OAuth grants, and service credentials. These credentials may be stored in configuration files, local environments, developer machines, CI/CD systems, or server-side applications.

This creates risk because exposed or poorly scoped credentials can be used to access connected systems directly, outside the MCP workflow. It also makes revocation, rotation, and auditing harder. MCP deployments should avoid long-lived static secrets where possible, use scoped and audience-bound tokens, store secrets in secure vaults, rotate credentials regularly, and prevent tools from passing tokens through without proper validation.

6. Rug Pull Attacks

A rug pull attack happens when a trusted MCP server or tool changes behavior after it has already been approved or adopted. A server may initially appear safe, but a later update can introduce malicious code, new permissions, altered tool descriptions, or hidden data collection.

This is a supply-chain risk, especially when teams use community servers, third-party packages, or auto-updating components. A tool that once performed a simple read-only task may later gain write capabilities or begin exfiltrating data. To reduce this risk, organizations should pin trusted versions, review updates before deployment, verify package sources, monitor permission changes, and treat tool-definition changes as security-relevant events.

7. Confused Deputy Problems

A confused deputy problem occurs when an MCP server or proxy is tricked into using its authority on behalf of the wrong client or user. In practice, this can happen when a server connects to downstream APIs and does not properly separate client identity, user consent, redirect validation, or authorization context.

The result is that an attacker may cause a trusted MCP component to perform actions or obtain access that the attacker should not have. This is especially relevant in OAuth-based MCP flows, proxy servers, and systems that reuse static client identifiers or fail to validate tokens and redirect URIs correctly. Mitigations include per-client consent, strict redirect URI matching, proper OAuth state validation, token audience validation, and clear separation between user, client, server, and downstream API permissions.

8. Server-Side Request Forgery (SSRF)

Server-side request forgery (SSRF) occurs when an MCP server retrieves data or makes network requests based on user-controlled or model-generated input without properly validating the destination. An attacker can abuse tools that fetch URLs, download files, query APIs, or connect to internal services to access resources that should not be reachable. Because the request originates from the MCP server, it may bypass network controls and expose internal systems, cloud metadata services, or administrative interfaces.

For example, a tool designed to retrieve web pages could be manipulated into requesting internal endpoints, cloud instance metadata, or private APIs. If the server returns the response to the model, sensitive information may become part of the model context or be exposed to the user. Organizations should validate destination URLs, use allowlists for approved domains, block access to internal network ranges and metadata endpoints, enforce network egress controls, and sanitize tool inputs before making outbound requests.

9. Local Code Execution over stdio

Many MCP servers communicate with hosts over the standard input/output (stdio) transport by launching a local process. While this simplifies integration with desktop applications and developer tools, it also means the host executes code on the local system. Running an untrusted or compromised MCP server can therefore expose the host to arbitrary code execution, privilege abuse, credential theft, or unauthorized access to local files and services.

The risk increases when users install community servers, automatically update dependencies, or launch MCP servers without verifying their source. A malicious server can abuse the permissions of the user account running the process and interact with any resources that account can access. Organizations should install MCP servers only from trusted sources, verify package integrity, review server code before deployment when possible, run servers with the lowest practical privileges, isolate them using containers or sandboxing where appropriate, and monitor local MCP processes for unexpected behavior.

MCP Security Best Practices 

1. Maintain an Approved MCP Server Registry

Organizations should maintain a centralized registry of approved MCP servers, including each server’s owner, business purpose, exposed tools, connected systems, permission requirements, authentication method, deployment location, and review status. This prevents teams from connecting AI applications to unknown or unvetted MCP servers that may expose sensitive data or introduce unsafe tool behavior.

An approved registry also helps security and platform teams manage MCP at enterprise scale. Teams can track which servers are allowed for production use, which are limited to development, which are deprecated, and which require additional controls. The registry should include version history, update notes, known risks, and dependency information so organizations can respond quickly when a server becomes vulnerable or changes behavior.

The registry should also define onboarding and offboarding workflows. New MCP servers should go through security review before approval, while unused or risky servers should be removed from active use. For larger organizations, the registry can be integrated with an MCP gateway or internal developer portal so users select from trusted, pre-approved servers instead of installing arbitrary tools on their own.

2. Use Least-Privilege Access for Every MCP Server

Every MCP server should receive only the permissions required for its specific purpose. A documentation search server should not have write access to repositories, a ticket lookup tool should not be able to modify incidents, and a database query tool should not have broad administrative access. Narrow permissions reduce the impact of prompt injection, tool misuse, compromised servers, and accidental actions.

Least privilege should apply across all layers of the MCP workflow. This includes file-system access, network reachability, API scopes, database permissions, cloud IAM roles, OAuth grants, and the user identity behind each request. Where possible, organizations should separate read-only tools from write-capable tools and create purpose-built servers for specific tasks instead of giving one server broad access to many systems.

Permissions should also be reviewed over time. MCP servers often start with broad access during development and remain over-privileged after moving into production. Regular access reviews, logging, and permission-drift detection can help identify unused scopes, excessive roles, and tools that no longer match their original purpose.

3. Identity-Aware Execution (OBO)

Identity-aware execution means MCP tool calls should run on behalf of the actual user, workload, or agent identity rather than through a shared, highly privileged service account. In an on-behalf-of model, the MCP server carries the requester’s identity and authorization context into downstream systems, allowing existing access controls to determine what the action is allowed to do.

This is important because MCP tools often interact with systems that already have user-level permissions, such as file repositories, SaaS applications, ticketing platforms, cloud consoles, and databases. If all tool calls run through the same service account, the AI application may give every user the same level of access. Identity-aware execution helps ensure users cannot use an agent to access data, actions, or systems they would not normally be allowed to reach.

This model also improves auditability. Security teams can see who initiated a tool call, which agent or host was involved, what resource was accessed, what action was taken, and whether the action matched the user’s permissions. This makes incident investigation, compliance reporting, and abuse detection more reliable than logs tied only to a generic MCP service identity.

4. Validate Tool Metadata Before Approval

Tool metadata should be reviewed before a tool is approved for use because AI agents rely on metadata to decide when and how to call tools. Metadata includes the tool name, description, parameters, examples, required scopes, expected outputs, and embedded instructions. If this information is misleading, vague, or malicious, the model may call the wrong tool or perform an action the user did not intend.

Validation should confirm that the tool description accurately reflects the real behavior of the tool. A tool described as “read customer summary” should not also be able to export customer records, send emails, or modify account status. Parameter definitions should be narrow and explicit, with clear input types, allowed values, and guardrails that reduce ambiguity. High-risk parameters, such as file paths, URLs, commands, recipient addresses, or database queries, should receive additional review.

Organizations should also inspect metadata for hidden prompt-injection patterns. Tool descriptions should not contain instructions that override system policy, encourage the model to ignore user consent, or steer the model toward unnecessary data access. Metadata review should be part of MCP server onboarding and should be repeated whenever a tool definition changes.

5. Pin and Monitor Tool Schemas

MCP tool schemas should be pinned to trusted versions rather than updated automatically without review. A schema defines how the model understands a tool: what the tool is called, what it does, what inputs it accepts, what outputs it returns, and what permissions it may require. Even a small schema change can alter how the AI application behaves.

Pinning schemas helps prevent unexpected behavior from supply-chain changes, accidental updates, or rug pull attacks. For example, a tool that previously accepted a simple document ID might later accept a file path, URL, or command-like parameter. A tool description might also change from a narrow read-only function to a broader action-oriented capability. Without schema monitoring, these changes may go unnoticed until the tool is misused.

Organizations should monitor tool schemas for changes in descriptions, parameters, required permissions, output structure, and execution behavior. Material changes should trigger a review before the updated tool is allowed in production. For higher-risk environments, teams can use schema diffing, approval workflows, version pinning, and alerts to detect when a previously trusted tool no longer matches its approved behavior.

6. Add Human Approval for Sensitive Actions

Human approval should be required before MCP tools perform sensitive or irreversible actions. This includes sending messages, deleting files, changing code, modifying cloud infrastructure, updating access controls, approving transactions, interacting with production systems, or exposing regulated data. The more impact a tool call can have, the more important it is to place a clear approval step before execution.

Approval prompts should be specific and understandable. Instead of asking users to approve a vague “run tool” action, the system should show which tool will be used, what the tool will do, what data it will access, what system it will affect, and which identity will be used. This gives the user a meaningful opportunity to catch errors, suspicious behavior, or prompt-injection attempts before the action is completed.

Human approval should not be treated as a substitute for technical controls. It should work alongside least privilege, policy enforcement, logging, and safe tool design. For routine low-risk actions, approval can be lightweight or unnecessary. For high-risk actions, organizations may require step-up authentication, dual approval, change-ticket validation, or approval from a specific role.

7. Sanitize Tool Outputs Before They Enter Model Context

MCP tool outputs should be treated as untrusted input, even when they come from internal systems. Tool responses may contain malicious instructions, hidden text, sensitive credentials, malformed content, user-generated data, or external content copied from websites, documents, tickets, logs, or repositories. If this content is inserted directly into model context, the model may mistake hostile data for valid instructions.

Sanitization can include removing hidden prompts, stripping unsafe markup, escaping content, limiting response size, redacting secrets, filtering personally identifiable information, and labeling retrieved content clearly as data rather than instructions. For example, a support ticket may contain text that tells the agent to ignore prior rules and export customer data. The system should preserve the ticket as content to be analyzed, not as an instruction to be followed.

Organizations should also validate the structure and source of tool outputs. Outputs should match expected formats, avoid unnecessary sensitive fields, and be limited to the minimum data needed for the task. DLP checks, malware scanning, output allowlists, and content-risk scoring can further reduce the chance that tool responses become a prompt-injection or data-exfiltration path.

8. Use Policy Enforcement at the Gateway Layer

An MCP gateway can provide a centralized policy enforcement point between AI hosts and MCP servers. Instead of letting every AI client connect directly to every server, organizations can route traffic through a managed layer that applies authentication, authorization, tool allowlisting, rate limits, logging, approval rules, and data-protection policies.

Gateway enforcement is valuable because MCP environments can become fragmented quickly. Different teams may use different clients, servers, tool sets, and authentication methods. A gateway helps standardize controls across the organization, making it easier to decide which agents can use which tools, which users can access which servers, and which actions require approval or blocking.

The gateway can also inspect MCP traffic for risky behavior. It can detect unusual tool-call patterns, block dangerous combinations of tools, enforce tenant boundaries, redact sensitive outputs, prevent access to unapproved servers, and create consistent audit trails. In mature environments, the gateway becomes the place where security, platform, and governance teams define enterprise-wide rules for safe MCP adoption.

Monitoring MCP and OpenAI Agent Activity with Exabeam

As organizations connect OpenAI models to MCP servers, AI agents become a new class of non-human identity operating inside business systems at machine speed and scale. Exabeam delivers advanced user and entity behavior analytics (UEBA) that uses AI and automation to help security operations teams detect, investigate, and respond to threats involving users, entities, and AI agents through Agent Behavior Analytics (ABA). By baselining what normal behavior looks like and surfacing risky deviations, Exabeam gives teams the visibility needed to govern MCP-enabled OpenAI agents and the workflows they touch.

Key capabilities of Exabeam UEBA:

• AI agent behavior analytics: ABA extends UEBA to AI agents and other non-human identities, adding behavioral visibility, centralized monitoring, and investigation support so analysts can identify suspicious agent activity and respond with better context.
• Risk-based anomaly detection: New-Scale Analytics builds behavioral baselines and uses business context to refine risk scores, identifying subtle changes across users, entities, and non-human identities; when risk meets a set threshold, a case is opened for investigation.
• Entity context: Attack Surface Insights identifies entities in parsed logs and connects attributes and contextual data to build profiles that strengthen behavioral detections across on-premises and cloud environments.
• Automated investigation timelines: Automated timelines organize related detections chronologically to visualize the full scope of a threat, while activity summaries for anomalies and prebuilt playbooks reduce manual routines so teams respond faster.
• Flexible SIEM augmentation or replacement: New-Scale Analytics runs on top of an existing SIEM to add advanced behavioral analytics, while New-Scale Fusion provides a full-featured platform for a new deployment or a SIEM replacement.

Integrating ABA with Praxen and Observra

To secure AI agents, Exabeam combines runtime analytics with open-source frameworks for telemetry and verification. Integrating Agent Behavior Analytics (ABA) with Praxen and Observra creates a comprehensive security lifecycle for autonomous machine identities.

• Standardizing Agent Telemetry with Observra: Active AI agents generate complex, unstructured activity logs. Observra acts as an open-source SDK and logging library that captures runtime agent operations, including model calls, prompt details, tool usage, system costs, and errors. It normalizes this data into a structured event format, providing the consistent telemetry stream required for advanced threat detection.
• Verifying Agent Policies with Praxen: Before an agent is deployed, Praxen serves as an open-source reference implementation for Agent Behavior Verification (ABV). It compares the declared security policy of an AI agent against its actual underlying code, deployment state, and initial behavioral logs. This ensures that discrepancies, logic flaws, or unauthorized capabilities are flagged before the agent enters production.
• Continuous Behavioral Analysis with ABA: During active operations, the ABA engine ingests normalized telemetry from Observra and leverages the policy baselines established by Praxen. The engine applies machine learning models to build behavioral baselines for each agent, scoring risks and flagging real-time anomalies. If an agent drifts from its intended role, calls unapproved tools, or accesses unauthorized data, ABA immediately raises risk scores and triggers alerts.

This combined approach allows security teams to verify AI agent behavior prior to deployment and maintain continuous, baseline-driven visibility throughout active operations.

Exabeam offers a Model Context Protocol (MCP) server for developers that connects AI assistants directly to public API documentation, enabling teams to explore endpoints, analyze request and response schemas, and generate custom integration code through natural language conversation. In parallel, LogRhythm delivers a community-released SIEM MCP server that runs locally in on-premises environments to bridge security telemetry directly with chosen large language models, allowing analysts to run automated threat-hunting queries, triage active incidents, and summarize security alarms while keeping sensitive security logs inside the private.

To see how Exabeam helps security teams monitor and secure human and AI agent activity across the agentic enterprise, explore Exabeam’s UEBA capabilities. Read our MCP for Developers page to learn more on MCP as well.