The MCP security problem
Agents moved from answering questions to executing actions. The Model Context Protocol made that cheap — and left a security gap in the middle.
From chat to execution
A chat model only reads text and writes text. A tool-calling agent, however, can read your CRM, query your database, and call your billing API. The Model Context Protocol (MCP) standardizes how agents discover and call those tools — which is exactly what makes it dangerous to leave unmanaged.
The two options teams are stuck with
- Expose the system. Open a port or a public endpoint, and now a production system is reachable from the internet.
- Hand over a credential. Give the agent a long-lived key or password. It works until it leaks, or until the agent does something no one approved — with no record of what happened.
Shadow MCP: the gap nobody owns
Developers wire tools to agents without telling security or compliance. The result is shadow MCP: tool access that is real, privileged, and completely invisible to the people who will be asked to explain it after an incident.
What a control point must provide
Turning that chaos into a formal channel takes five things, not just a tunnel:
- Identity per agent. Which agent is calling, not just which machine.
- Authorization per tool. Deny by default; allow specific tools, for specific agents.
- Human approval. Sensitive actions should block until a person says yes.
- An audit trail. Who called what, when, with which arguments, and what came back — tamper-evident.
- Containment. A kill switch and fail-closed behavior when the control point is unreachable.
A tunnel moves bytes. A gateway makes a decision — and then proves it. That distinction is the whole product.