MCP security: risks of the Model Context Protocol and how to manage them

MCP security is the practice of securing the Model Context Protocol, the open standard that connects AI models to external tools, data sources, and services. MCP has become a common way to give AI applications access to the systems they need to be useful: a model can call an MCP server to query a database, read files, hit an API, or trigger an action. That connective tissue is powerful, and like any layer that grants an AI system access to real resources, it is a new attack surface that needs to be secured deliberately.

The appeal of MCP is standardization: instead of building a bespoke integration for every tool, developers expose tools through MCP servers that any compatible AI client can use. But standardizing how a model reaches external systems also standardizes a path an attacker can target. The security questions are the same ones that apply to any agentic AI, sharpened by the fact that MCP often connects models to sensitive systems with broad permissions. This article explains what MCP is, the risks it introduces, and how to manage them, building on the work we do through our AI security service.

What is the Model Context Protocol?

The Model Context Protocol is an open standard for connecting AI models to external capabilities in a consistent way. An MCP server exposes tools, resources, or prompts; an MCP client, typically an AI application, discovers and uses them. In practice this lets a model do things beyond generating text: retrieve documents, query systems, call APIs, and take actions, all through a common interface rather than one-off integrations.

From a security standpoint, the important consequence is that MCP turns a language model into a client of real systems. Whatever an MCP server can do, the model can potentially be made to do, if an attacker can influence the model's behavior. That places MCP squarely within the problem of agentic AI security, which we cover in securing AI agents.

Why MCP is a security concern

MCP introduces risk because it sits at the junction of two things that are dangerous together: a model that can be manipulated through language, and tools that can affect real systems.

• MCP servers grant access to real resources, so a compromised or manipulated connection can reach data and actions that matter.
• Permissions are often broad, granted for convenience during development and never scoped down for production.
• The model decides which tools to call, so manipulating the model through prompt injection can manipulate tool use.
• Third-party MCP servers introduce supply-chain risk, because you are trusting code and connections you did not write.
• Tool descriptions themselves are model input, so a malicious or compromised server can attempt to influence the model through the very metadata it provides.

MCP makes it easy to give a model access to everything. The security work is making sure the model only ever reaches what the task in front of it actually requires.

Common MCP security risks

The specific risks that arise with MCP map onto the broader agentic-AI risks, with a few that are particular to the protocol.

• Over-permissioned servers, where an MCP server can do far more than the application needs, expanding the blast radius of any compromise.
• Prompt injection into tool use, where attacker-controlled content steers the model into calling MCP tools for the attacker's ends.
• Malicious or compromised MCP servers, including third-party servers whose tool descriptions or behavior are hostile.
• Tool poisoning, where the metadata an MCP server exposes is crafted to manipulate the model that reads it.
• Credential and secret exposure, where MCP servers hold powerful credentials that become a high-value target.
• Insufficient logging, where MCP tool calls are not recorded in enough detail to detect or investigate abuse.

How to secure MCP

Securing MCP follows the same principle as securing any agent: constrain what the connection can do, and assume the model can be manipulated. The controls that matter most include the following.

• Scope MCP server permissions tightly, granting each only the access the application genuinely requires.
• Treat tool output and tool descriptions as untrusted input, never as trusted instructions.
• Require confirmation for consequential actions exposed through MCP, rather than allowing full autonomy.
• Vet third-party MCP servers before connecting them, and prefer servers you control for sensitive operations.
• Protect and rotate the credentials MCP servers hold, and isolate them from the model's reach.
• Log every MCP tool call with full context, so abuse can be detected and reconstructed.

Because these are architecture decisions, MCP security has to be designed in, not bolted on. We test whether these controls hold under attack through AI red teaming and AI penetration testing, and we assess the surrounding infrastructure through application and cloud security.

MCP and prompt injection

The defining MCP risk is the combination of prompt injection and tool access. If a model reading a document, email, or webpage can be made to follow hidden instructions, and that model can call MCP tools, the attacker can turn manipulation into action. The defense is not to try to make the model immune to manipulation, which is not currently possible, but to ensure that a manipulated model cannot do real harm: scoped tools, confirmation for consequential actions, and hard boundaries enforced outside the model. We explain why this cannot be solved in the prompt in prompt injection is not a prompt problem.

MCP makes AI applications far more capable, and far more connected to systems that matter. If you are using MCP to give models access to tools and data, see our AI security service and book a scoping call to discuss securing those connections.