MCP as a supply chain: trust boundaries in agent tooling

MCP (Model Context Protocol) is winning. It's becoming the standard way AI agents connect to tools, data sources, and external services. The Linux Foundation now hosts it through the Agentic AI Foundation, multiple major AI platforms support it, and thousands of servers are already in production.

But most teams treat MCP servers like internal APIs. They're not. 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.

After analyzing thousands of MCP server configurations, these are the five blind spots I see over and over again.

1. Why are MCP tool descriptions an attack surface?

Tool descriptions are an attack surface because agents read them as instructions and act on them, not as passive documentation. This surprises most developers. 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.

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.

Most teams never audit what their MCP servers actually tell agents to do. Dedicated tool-poisoning detection catches this, and it shows up more often than you'd expect.

2. Is network isolation enough for an internal MCP server?

No. 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?

3. How much should a single MCP tool be allowed to do?

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." But they rarely think about 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. How can one MCP server attack another through the agent?

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 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 host-provided provenance, the deployment server may not know that untrusted content influenced the request.

This is why Oktsec operates at the gateway layer. It can enforce policies across server boundaries, something individual servers can't do on their own.

5. Why does MCP need runtime monitoring after deployment?

Runtime monitoring matters because the risk doesn't end at deployment, it starts there. Teams invest time in building and testing MCP servers. But after deployment? Silence. No monitoring of what tools are being called, by which agents, with what parameters, at what frequency.

This means 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. And 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. It's not optional infrastructure. It's the minimum viable security posture.

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.

What I'd recommend for any team deploying MCP servers today:

Scan before you deploy. Check every MCP server for known risk patterns before it goes live. It takes minutes and catches the obvious problems early.

Authenticate everything. Even internal servers. Especially internal servers.

Audit your tool descriptions. Read them as an attacker would. What could an agent be tricked into doing?

Scope your tools. Minimum capability, explicit constraints, validated inputs.

Monitor at runtime. Know what your agents are doing after you deploy them.

The MCP ecosystem is going to be critical infrastructure. Let's build it like it matters.