MCP SECURITY
Security for Model Context Protocol servers, from the network up.
Tunnex secures MCP in five layers: discover every server and tool in shadow mode, validate OAuth trust, enforce per-tool default-deny policy, prove every call with signed provenance, and bound machine-rate behavior with limits and step-up approval — all on top of a fail-closed WireGuard network boundary you self-host.
THE FIVE LAYERS
Discovery before enforcement. Enforcement before trust claims.
DISCOVER
Shadow-mode MCP inventory
A managed agent runtime observes your MCP estate — servers, tools, resources, schema hashes, versions, first and last seen — without holding credentials or touching session content. You cannot govern what you have not enumerated.
TRUST
OAuth protected-resource validation
Authorization-server discovery, issuer metadata, protected-resource URI, scopes, and audience are validated before a connection is trusted. Access tokens are never stored as ordinary configuration, and token passthrough is rejected explicitly.
ENFORCE
Per-tool policy, default-deny
Versioned allow/deny rules keyed to stable server and tool identities. Newly discovered tools stay denied until someone allows them. Request content is validated against headers before forwarding — and the L3/L4 network boundary underneath remains fail-closed.
PROVE
Signed workflow provenance
An SDK-signed request envelope carries workflow ID, trigger, initiator, claims, and signature. Verification yields an Agent → Run → Tool → Resource chain you can show an auditor. Unsigned context is labeled unverified — never silently attributed.
BOUND
Argument controls, rate limits, step-up approval
Server-owned JSON-schema constraints validate arguments before execution. Per-agent and per-tool usage limits cap machine-rate mistakes. Destructive operations pause for human approval without ever exposing secrets to the approver.
WHY BOTH LAYERS
Per-tool policy never replaces the network boundary.
LAYER 1 · NETWORK (ALWAYS ON)
Fail-closed L3/L4 boundary
Agents connect over WireGuard as owned principals. Default-deny rules scoped to host and port decide reachability at the gateway kernel. If the MCP layer is ever wrong, the network layer still holds: unreachable is unreachable.
LAYER 2 · PROTOCOL (MCP-AWARE)
Per-tool decisions inside the tunnel
For traffic that is allowed through, authoritative request content is validated against headers, matched against versioned tool policy, rate-limited, and — for classified destructive operations — paused for human approval before forwarding.
STATED PLAINLY
Nothing here detects prompt injection.
Under injection, authentication is intact and authorization is intact — only intent is corrupted, and intent is not visible on the wire. What these controls do is make a manipulated agent boring: it can invoke only allowed tools, at bounded rates, within validated arguments, while destructive steps wait for a human. Unsigned requests are labeled unverified rather than attributed to anyone.
QUESTIONS
MCP security questions, answered directly.
What is MCP security?+
MCP security is the practice of governing access between AI agents and Model Context Protocol servers: knowing which servers and tools exist, verifying the identity of both sides, enforcing least-privilege rules per tool rather than per server, and attributing every call. Tunnex adds the missing network layer — default-deny reachability plus MCP-aware L7 controls.
How do I secure MCP servers on my network?+
Three layers work together. Network level: place MCP servers behind a Zero Trust gateway so only named principals can reach specific ports. Protocol level: validate OAuth protected-resource metadata and reject token passthrough. Tool level: enforce per-tool allow/deny policies where newly discovered tools remain denied until explicitly allowed. Tunnex implements all three.
Can a firewall or VPN protect MCP servers?+
Partially. Traditional firewalls and VPNs control which hosts can reach which ports — necessary but blunt: an allowed agent can call every tool on a reachable server. Tunnex keeps that L3/L4 boundary fail-closed and adds per-tool enforcement on top, so a compromised or over-eager agent hits a decision point per tool call.
What happens when a new MCP tool appears?+
It stays denied. Tool policy is keyed to stable server and tool identities, and anything not explicitly allowed is blocked by default. Discovery runs continuously in observation mode, so new or changed tools surface in the inventory — with schema hashes and versions — before you decide whether to allow them.
Does securing MCP require exposing servers to the internet?+
No. That is the failure pattern Tunnex exists to remove. MCP servers stay inside your network; agents connect over WireGuard tunnels as owned principals. No public exposure, no bearer token standing in for identity.
Can Tunnex detect prompt injection?+
No — and be suspicious of any network product that claims to. Under prompt injection, authentication and authorization are intact; only intent is corrupted. What network-level control does is bound the blast radius: per-tool default-deny caps what a manipulated agent can invoke, rate limits cap how fast, and step-up approval puts a human back in the loop for destructive operations.
Know every tool. Allow it once. Prove it forever.
Deploy the control plane, enroll an agent, and watch your MCP estate appear in inventory — before you allow a single tool.