MCP servers are your new supply chain

The Model Context Protocol is now how agents get tools. Claude, ChatGPT, Cursor and most agent frameworks speak it, and thousands of servers expose everything from GitHub to email. Installing one is as easy as installing a package, and carries the same kind of risk, with one difference: the consumer is a language model that treats much of what it reads as guidance.

The problem: three ways in

• Tool poisoning. A server's tool descriptions are read by the model as trusted context. Invariant Labs showed in 2025 that a description can carry hidden instructions, for example to read the user's private SSH key and pass it along in a tool argument, which the user never sees and the model may follow.
• Injection through tool output. A legitimate server returns content written by someone else: an issue, an email, a web page. That content can instruct the agent, the indirect injection we describe in prompt injection is an architecture problem.
• Ordinary supply-chain compromise. Servers are packages. Security researchers have catalogued malicious and vulnerable MCP packages, and the official MCP security guidance lists confused-deputy problems, token passthrough and session hijacking among the risks implementers must handle.

Why it is worse than an ordinary dependency

An ordinary dependency runs code with your process's permissions. An MCP server can additionally talk your agent into using its other tools on the attacker's behalf. A harmless weather server with a poisoned description can induce an agent to use the email server beside it. Trust is not contained per server.

The proposal: an MCP gateway

Rather than letting each agent connect to whatever servers someone configured, route every connection through a gateway you control:

1. 01Pin and review manifests. The gateway records each server's tool names, descriptions and schemas when approved, and blocks the server if they change until someone reviews the change. This defeats a server that turns malicious after approval.
2. 02Scope every token. Users authorise each server with OAuth, and each tool call runs with that user's scoped token, never a shared admin credential and never a token passed through to another service.
3. 03Sandbox local servers. Servers that run on a developer's machine run in a container with no network except what they need, and no access to the home directory.
4. 04Sanitise output. Tool output is marked as untrusted data, stripped of hidden text and links that would render, and size-limited before it reaches the model.
5. 05Allowlist egress. Agents and servers can reach only approved destinations, which closes the path most exfiltration needs.
6. 06Log everything. Every tool call with its arguments, caller and result, kept for investigation.

For teams publishing MCP servers

If you are exposing your own product to agents, the same principles apply from the other side: a small set of task-shaped tools, OAuth with per-user scopes, input validation, rate limits and descriptions that contain nothing but an honest description.

What to measure

• Inventory. The number of MCP servers in use, and the share approved and routed through the gateway.
• Manifest drift. How often an approved server's tool descriptions change, and how fast changes are reviewed.
• Token scope. The share of tool calls made with per-user scoped tokens rather than shared credentials.
• Blocked egress. Outbound requests the gateway refused; each is either a misconfiguration or an attempt worth investigating.

How we would start

Inventory the MCP servers your teams have installed; there are usually more than anyone expected. Then decide which to keep, and put them behind a gateway. We build both sides: secure MCP servers for products, and gateways and evaluations as part of LLMOps and guardrails. Agents that pay for tools add a financial layer to this; see agent payments that settle on proof.