Nearly every organization is under intense competitive pressure to implement AI solutions. The open-source Model Context Protocol (MCP) standard has been a key enabler for this acceleration, serving as a “universal connector” to link AI systems with tools and data on the web, the cloud, or in-house repositories.

But like so many AI innovations, MCP was rushed to market with minimal security in place. Many organizations—especially smaller firms that may lack specialized AI security expertise—have implemented MCP with little regard for its impact on their cyber risk. While security features have since been added to the protocol, many implementations remain vulnerable to hackers.

Are you better off using MCP versus connecting your AI systems to external resources some other way? This article explores the pros and cons of using MCP, including best practices and potential alternatives.

Key takeaways

• MCP is a popular open-source standard that gives AI systems access to data and applications.
• When originally introduced in late 2024, MCP offered no native authentication. While security features have since been added, MCP remains weak on security by default.
• MCP users need to follow security best practices to avoid seriously escalating their AI cyber risk.
• Strictly governing MCP as a universal AI connectivity protocol can make easier to manage, monitor, log, and audit than relying on ad hoc API connectors that can introduce unknown vulnerabilities of their own.
• A range of alternatives to MCP are now available that offer improved security, manageability, and/or ease of use.

What is MCP and how does it work?

As autonomous AI systems perform real-world tasks, they need to connect to external tools, databases, and services. Often called “USB-C for AI,” Anthropic first introduced MCP in late 2024. It acts like a universal adapter that lets AI agents access documents, query databases, and use applications without the need to build special integrations for each service.

MCP uses a client-server architecture with three components:

1. The MCP host is the AI system a human user interacts with, such as Claude or ChatGPT.
2. Within the MCP host, an MCP client (a separate piece of software) connects to various MCP servers one-on-one to access or exchange data using a standard protocol. A single MCP host can host multiple MCP clients.
3. MCP servers are the data sources, tools, and APIs that AI models can access.

The AI model does not talk directly to the MCP server or to external sources. Instead, the MCP host mediates between the AI and the MCP client.

Developers can expose resources and tools (MCP servers) as JSON schemas, making MCP integrations programming language-independent as well as straightforward to code. Popular AI platforms like ChatGPT, Claude, Visual Studio Code, and Cursor all support (host) MCP.

Current MCP versions can reduce development time and code complexity while providing secure access to a limitless spectrum of data sources and applications that make agentic AI more capable and useful. But without proper precautions, MCP can vastly increase an organization’s cyber attack surface and leave sensitive digital assets wide open to unauthorized access and exploitation.

What are the main cybersecurity issues with MCP?

The major cybersecurity issue with MCP is its design, which by default connects AI agents directly to business-critical data sources with potentially no authorization, authentication, or input validation guardrails. This could greatly increase the risk of a major data breach and/or many other undesirable outcomes for AI stakeholders.

Vulnerabilities and misconfigurations that can impact MCP implementations include:

• Total lack of authentication. MCP was originally introduced with no built-in authentication mechanism. Some MCP servers may still lack authentication, enabling unauthorized users to connect to them at will.
• Over-privileged access permissions. MCP servers are commonly configured to provide admin-level access to MCP clients. This greatly increases the potential “blast radius” from a credential hack or other incident.
• Prompt injection attacks, such as placing malicious MCP commands in help desk tickets or other public documents. These commands can trick an AI agent into using its MCP connections to initiate unauthorized actions, such as locating and exfiltrating credentials or other sensitive data.

More generically, like any software, MCP’s source code can contain exploitable vulnerabilities. The MCP ecosystem is also vulnerable to software supply chain risks, such as malicious MCP servers or other compromised third-party tools.

How can MCP potentially improve AI security?

As just noted, using MCP in its default configuration significantly elevates AI cyber risk. But when implemented and managed as a privileged API layer with best-practice controls, MCP can be a more secure and manageable alternative to nonstandard methods for connecting AI systems to data sources.

Some of the ways that MCP can improve AI security in alignment with a zero-trust approach include:

• Enforcing least privilege by implementing MCP with fine-grained role-based access control (RBAC) that gives AI access to only the data and tools it specifically needs to operate.
• Sandboxing MCP servers in isolated/segmented environments to limit hackers’ ability to attack other assets if a server is compromised.
• Viewing MCP server outputs as untrusted and subject to validation and sanitization.
• Allowing AI to connect only to known, trusted MCP servers versus generic open-source tools.
• Managing credentials at the MCP server level instead of embedding API keys within prompts, which prevents credential leaks into browser histories, chat logs, or various model outputs.
• Monitoring AI outputs for unexpected behavior that could indicate an attacker is manipulating the AI system.
• Requiring human-in-the-loop approval for risky AI actions like sending emails or deleting data.

Governing MCP in a centralized, best-practice manner as a universal AI connectivity protocol is likely to be more secure and easier to manage, monitor, log, and audit than diverse API connectors that may introduce unknown vulnerabilities.

Why has MCP historically been implemented with lax security?

AI’s explosive growth has resulted in inconsistent and incomplete cybersecurity across AI systems, with few standardized controls. The demand for new capabilities has often made security an afterthought to be addressed “later,” creating numerous vulnerabilities that may remain unaddressed for some time.

Anthropic initially rolled out MCP to an eager AI community without even basic default security safeguards in place. Consequently, some MCP connections may have been retrofitted to use robust authentication while others continue to forego authentication and blindly trust in perimeter security (the opposite of zero trust).

There are three points within an MCP exchange where authentication can occur:

1. Between the MCP host and the AI. This link is controlled by the communication protocol used (mainly stdio for local servers or SSE/HTTP for remote servers) making it potentially more secure than other parts of the transaction if security considerations are addressed.
2. Between the MCP client and the MCP server. While MCP now offers authentication options and recommendations, it does not enforce any authentication by default. Developers are responsible for implementing robust authentication options like OAuth.
3. Between the MCP server and the IT infrastructure. This security link depends on the IT infrastructure the MCP server runs on, which may or may not offer best-practice cybersecurity controls.

By leaving security completely up to the implementer, many MCP setups will have critical vulnerabilities open to attackers for years into the future.

Marco Figueroa, GenAI Bug Bounty Programs Manager at Mozilla, expresses strong concern over the excessive—and often unrecognized—risks that businesses are taking by rolling out MCP and other AI tools with no governance or guardrails.

“When MCP was first released, I did the research and I thought, ‘This can’t be!’” Marco recalls. “How can you release something that doesn’t have authentication or authorization. The server could attack the client. The client could attack the server. And the information moves over clear text, over HTTP.”

How does Marco explain MCP’s rapid option despite its inadequate security?

“People were just trusting it by default because they’re vibe coding and they’re in YOLO (You Only Live Once) mode on everything,” states Marco.

What is the confused deputy problem with MCP?

Enforcing least privilege principles can be difficult with MCP because of the “confused deputy” problem. In this scenario, an MCP server with excessive privileges can execute an action requested by a lower privileged user. MCP doesn’t natively track user context between the host and the server, so the server cannot differentiate between users and could give all users the same access level.

This creates a privilege escalation vulnerability, greatly increasing the risk of unauthorized data access or other malicious actions. Rather than hack a data source directly, cybercriminals can use social engineering style prompt attacks or other methods to dupe the over-privileged “deputy” (the AI agent) into doing their bidding.

Recommended strategies for mitigating confused deputy related risk in MCP implementations include:

• Eliminating MCP server level “God tokens” and mapping each request to the user’s permissions.
• Using short-lived tokens and verifying that tokens are valid, not stolen.
• Validating all inputs and outputs to help block prompt-based attacks.
• Isolating local MCP servers with restricted file system access.
• Avoiding “token passthrough” where the MCP server forwards user credentials by default.

What are alternatives to MCP?

From API-based methods to newer agent-to-agent protocols, there are a range of established and emerging options to MCP for integrating AI with external data and services. These may offer streamlined implementation, improved performance, enhanced security, and/or other benefits.

Leading alternatives to MCP include:

• Traditional REST API calls, which for many use cases offer a simpler, faster alternative to MCP.
• Universal Tool Calling Protocol (UTCP), which supports direct agent-to-tool communication with no intermediary server. This can reduce latency by up to 50% over MCP.
• Google’s Agent2Agent (A2A) protocol, which targets communication between AI agents in addition to generic integrations. Based on JSON-RPC 2.0 over HTTPS, A2A has a growing partner ecosystem and is a trending choice for collaborative AI workflows.
• IBM’s Agent Communication Protocol (ACP), a RESTful model tailored for offline and edge computing scenarios, with support for several transport options.
• Agentica Framework from WrtnLabs, which was created as a direct replacement for MCP offering lower total cost of ownership plus support for multiple protocols, including OpenAPI, TypeScript, and MCP.
• Low-code and iPaaS platforms like Zapier, which feature a huge choice of pre-made, secure SaaS connectors that are ideal for quick integrations with no need to manage custom server code.
• Industrial strength AI gateways like TrueFoundry or Kong, which provide a robust, manageable transport layer between AI systems and data sources with better security than MCP.
• Emerging agent frameworks like Microsoft Semantic Kernel, which create a developer-controlled environment for governing agent security and behavior.

What are top MCP security best practices?

MCP security best practices align with zero trust principles, which treat all connections as untrusted. These controls proactively counter MCP’s “trust by default” approach. The most important steps are:

• Enforcing least privilege access and requiring authentications for all MCP connections so that AI can perform only essential actions.
• Rigorously validating all inputs among users and AI systems to reduce risk from prompt injection attacks and unauthorized data access.
• Establishing a formal governance or approval process for vetting new MCP servers, including third-party servers, before connecting to them. This can notably reduce AI supply chain risk.

Other key controls for MCP security include:

• Using short-lived authentication tokens instead of static credentials to reduce risk from AI credential theft attacks.
• Sandboxing or segregating MCP servers in containers to limit attackers’ lateral movement and reduce fallout from a data breach or anomalous AI actions.
• Logging all AI system prompts and queries along with associated interaction metadata for end-to-end monitoring, accountability, and forensics.
• Requiring human-in-the-loop validation for high-risk actions like deleting sensitive data, disabling services, approving large loans, etc.
• Patching MCP configurations regularly.
• Requiring service providers and other partners to demonstrate secure-by-default MCP implementations while avoiding untested open-source MCP servers that may introduce security flaws.
• Making AI connectivity part of threat modeling and penetration testing regimes.

For more information

Technical decision-makers and implementers looking at MCP and AI data access in general may be interested in these information sources:

• The official MCP security best practices documentation online
• The MCP Security Checklist on GitHub, maintained by SlowMist
• The Awesome MCP Security page on GitHub
• The OWASP Foundation’s dynamic AI Exchange, dubbed “the world’s first AI security guide” available free online
• The OWASP Top 10 for Agentic Applications 2026
• The OWASP Top 10 for Large Language Model Applications
• The OWASP AI Security Verification Standard, a structured checklist for validating AI security
• The OWASP AI Maturity Assessment (AIMA), a framework that helps businesses evaluate and improve the security, compliance, and trustworthiness of their AI systems.

What’s next?

For more guidance on this topic, listen to Episode 157 of The Virtual CISO Podcast with guest Marco Figueroa, GenAI Bug Bounty Programs Manager at Mozilla.