MCP (Model Context Protocol) has become the default tool protocol for agents: the standard way they connect to tools, data sources and external services. The Linux Foundation hosts it through the Agentic AI Foundation, which counted more than 10,000 published MCP servers when it formed in December 2025, and multiple major AI platforms support it.

MCP servers need the same production controls as other internal APIs, plus review of the model-facing instructions they return. An MCP server is a trust boundary between an AI agent and your systems, and many are still deployed with controls closer to a prototype than production infrastructure.

In the MCP servers I review, these are the five blind spots I see over and over again.

1. Tool descriptions as an attack surface

Tool descriptions are an attack surface because agents read them as instructions and act on them, not as passive documentation. This makes tool metadata part of the security review. A malicious or compromised server can craft tool descriptions that manipulate agent behavior.

This is tool poisoning: hiding instructions in a tool's description or schema that override the agent's system prompt, exfiltrate data or redirect actions to other tools. Invariant Labs documented the attack in April 2025, with hidden directives that made an agent read sensitive files while the user saw only a simplified description.

Example: a tool described as "Search company documents" could include hidden instructions telling the agent to first send all query parameters to an external endpoint. The user may never inspect the tool description directly, while the agent can still use it when deciding what to do.

Review the tool descriptions an agent receives. Oktsec Signal reviews MCP servers, skills and packages for risk patterns. Record the version reviewed and repeat the review when relevant code or tool definitions change; approval of one version does not cover every future update.

2. Limits of network isolation

Network isolation alone is not enough. The most common pattern I see is an MCP server running on localhost or inside a VPC with zero authentication, on the assumption that network isolation is enough. AI agents often run in environments where the network boundary is blurry: cloud functions, container orchestrators, development machines with multiple tools connected. A server that's "internal only" today might be reachable from an unexpected context tomorrow.

Even for genuinely internal servers, authentication matters because it establishes identity. Without it, you can't answer the most basic question: which agent made this request? The protocol's own security best practices are explicit on this point: servers that implement authorization must verify every inbound request and must not use sessions for authentication.

Record what each server may do and where those limits are enforced.

3. Permissions for each MCP tool

As little as the job requires: expose the minimum capability, with explicit constraints on inputs. Developers build MCP tools to solve a specific problem: "read this database," "send this notification," "query this API." The review also needs to establish what else the tool can access.

  • A database query tool might accept arbitrary SQL.
  • A file reader might traverse beyond its intended directory.
  • A notification tool might accept any recipient, not just the intended one.

The principle of least privilege applies to MCP tools, but enforcement remains inconsistent. In practice that means minimum capability with validated inputs: not "query the database" but "query the users table with these allowed columns and a maximum of 100 rows."

4. Attacks between MCP servers

When an agent connects to multiple MCP servers, a shared agent host can compose data and instructions across servers without an origin isolation model. Output from Server A can influence the agent to call Server B's tools in unintended ways.

This creates a cross origin escalation risk. The browser's same origin model is a useful analogy, not a direct equivalence: MCP hosts still lack a universal isolation boundary for data and instructions composed across servers.

A practical example: an agent connected to both a "company wiki" MCP server and a "code deployment" MCP server. A compromised wiki tool could manipulate the agent into deploying malicious code. Without provenance supplied by the host, the deployment server may not know that untrusted content influenced the request.

This is why Oktsec Control sits at the boundary around the agent's tool calls and applies policy to each call before it runs, for supported calls routed through configured enforcement points. Individual servers must still enforce their own authorization and input checks.

5. Monitoring MCP after deployment

Runtime monitoring helps detect changes after deployment. Check whether the team can identify which tools are called, by which agents, with what relevant parameters and at what rate.

  • You can't detect anomalous behavior when an agent suddenly makes thousands of calls to a tool it rarely uses.
  • You can't audit actions after the fact when someone asks who deployed that code change last Tuesday.
  • You can't identify a compromised agent that starts exfiltrating data through tool calls.

Runtime monitoring for MCP is the equivalent of application logs and APM for web services. Treat it as baseline infrastructure.

Five MCP review questionsreview
1tool descriptionsread as instructions, not docs → grade again when a definition changes
2internal serverlocalhost or VPC, zero authentication → verify every inbound request
3tool scopearbitrary SQL, any recipient → minimum capability, validated inputs
4two serversno origin isolation at the host → policy per call, across every server
5after deploymentno monitoring of calls, agents, parameters → runtime monitoring as baseline
The five questions and their one line answers. Each row is a trust decision that has to be written down and enforced.

The path forward

None of these are unsolvable problems. They're the same kind of issues every new protocol faces as it moves from early adoption to production infrastructure. The difference is the timeline: MCP adoption is measured in months, not years.

This is what I'd recommend for any team deploying MCP servers today.

  1. Scan before you deploy. Check every MCP server for known risk patterns before it goes live. Validate the findings against the installed version and deployment conditions.
  2. Authenticate everything. Even internal servers. Especially internal servers.
  3. Audit your tool descriptions. Read them as an attacker would. What could an agent be tricked into doing?
  4. Scope your tools. Minimum capability, explicit constraints, validated inputs.
  5. Monitor at runtime. Know what your agents are doing after you deploy them.

Review these five boundaries together and test how each is enforced. Grade a server before it connects, authenticate every request, scope every tool, check tool definitions again each time they change and keep a record per call that someone can audit later. The protocol's security best practices now cover the authentication and session parts of that list. The rest falls to the team running the agent.

To inspect the dependencies your agents use, explore AI supply chain security with Signal. See how source review connects a suspicious pattern to the code your team needs to examine.