The Model Context Protocol did for agent tools what REST did for web services: it gave them a common language. An agent can now reach a database, a ticketing system, a code host, or an internal API through one consistent interface. That's a genuine unlock — and it quietly moved a large part of your attack surface from "the prompt" to "the tool call."
A lot of products now advertise "MCP support." Most of what they mean is proxying — passing tool calls through and logging them. That's table stakes, and it's not enough. The interesting question isn't whether traffic flows through MCP; it's whether anyone is governing what happens when it does.
Why a tool call is a security event
To a model, a tool result reads like an instruction. That makes tools a uniquely dangerous surface for three reasons.
Tool calls act on the world. A prompt produces text; a tool call deletes a record, sends an email, or moves money. The blast radius is real, not conversational.
Toxic combinations. Tools that are individually safe can be chained into something that isn't — read a secret here, write it somewhere public there. No single call looks malicious; the sequence is the exploit.
Exfiltration paths. A compromised or over-eager agent can use a legitimate tool as the way data leaves. The tool isn't the vulnerability; unconstrained access to it is.
If your MCP layer only proxies, none of this is addressed. The calls flow; nobody is deciding whether they should.
What "governing" MCP means
Governance is the set of decisions a proxy skips. Four of them matter most.
Authorization per tool. Every connector should carry explicit rules about which agents may call it and how. Least privilege for agents is the same principle as least privilege for service accounts — it just hasn't been applied to agents yet.
An egress allowlist. Constrain where a tool is allowed to reach. If a connector's resolved host isn't on the allowlist, the call doesn't happen. This is what turns "the agent could exfiltrate through this tool" into "it can't."
Inspection of the call itself. The tool call is a surface to be scanned, not just a packet to forward. Watch for abuse and toxic-combination patterns the way you'd watch the prompt for injection — because by 2026, attackers target both.
Full lineage. An audit record of which agent called which tool, with what arguments, when — written into a tamper-evident trail. When something goes wrong, "who did what through which tool" should be answerable in seconds.
Turn your own APIs into governed tools
There's a second half to MCP that gets less attention: you don't only connect existing MCP servers. Any internal REST API can be compiled into MCP tools straight from its OpenAPI spec — no custom wrappers. That's powerful, and it's exactly why governance can't be optional: the moment your internal services become agent-callable tools, they inherit the agent threat model. Authorization, allowlisting, and inspection are what make exposing them safe.
The takeaway
MCP made tools a first-class part of how agents work, which made the tool call a first-class part of your attack surface. Proxying tool traffic is the easy 80%; the 20% that matters is the governance a proxy skips — per-tool authorization, an egress allowlist, inspection of every call, and a complete audit trail.
TrustGate treats the tool surface like every other agent surface: MCP governance that authorizes, constrains, and inspects every call — native MCP servers and any REST API you compile into tools — all self-hosted.
