A public MCP server approach publishes an internet reachable endpoint and relies on perimeter controls to absorb hostile traffic. An outbound only zero trust tunnel keeps the server private, opens one authenticated connection from inside the enterprise, and authorises access at the service and tool level. The practical difference is reduced exposure, tighter scope, and cleaner governance.
Why a Public MCP Server and an Outbound Only Zero Trust Tunnel Are Not the Same Design
A public MCP server exposes the endpoint to the internet and asks perimeter, rate limiting, and authentication layers to absorb unsolicited traffic. An outbound only zero trust tunnel keeps the service private and uses a brokered, authenticated connection to publish only the approved path. That shift changes the trust boundary, the blast radius, and the operational burden of exposure.
The difference is not just deployment style. It is a different security posture for the same agent access problem. A public endpoint must assume hostile discovery, scanning, and misuse, while a tunnel-based design reduces who can even reach the service in the first place. That matters because agent access usually combines tools, credentials, and action authority in one control plane.
For a public MCP server, the main control question is whether the server can safely remain internet reachable while still enforcing strong authentication, authorization, and tool scoping. For an outbound tunnel, the question shifts to whether the enterprise can keep the service private, verify the caller, and constrain each tool invocation through policy rather than network reachability alone.
What Changes in Trust Boundary, Exposure, and Governance
A public MCP server expands the observable attack surface because the service itself is discoverable from outside. Even if the protocol is well designed, the exposed endpoint creates more opportunity for probing, token replay attempts, misconfiguration, and accidental overexposure of tools that were meant to stay internal.
An outbound only tunnel changes the governance model by making connectivity originate from inside the enterprise and by hiding the server from unsolicited inbound traffic. That can simplify perimeter policy and make access review more precise, because the organisation can reason about a small number of authenticated sessions rather than a broadly exposed listener. The MCP authorization specification is the right reference point for understanding how MCP expects servers to behave as resource servers rather than token sinks.
The practical consequence is that the tunnel model usually gives better scope control, but it also introduces a dependency on the tunnel broker, connection health, and policy enforcement point. Public exposure pushes more burden onto the MCP server itself and any edge protection in front of it.
Why the Tunnel Model Usually Fits Zero Trust Better
Zero trust is about verifying the principal, the request, and the allowed action every time, not about assuming the network path is safe. An outbound only design aligns with that model because it removes standing inbound reachability and forces each interaction to pass through authenticated, policy-bound access decisions. NIST SP 800-207 Zero Trust Architecture formalises that shift from perimeter trust to continuous verification.
In practice, the tunnel approach is often better when the agent only needs a narrow set of tools or when the service should never be directly reachable from the public internet. It is not automatically safer in every respect, though. If the tunnel becomes a single choke point with broad policy or weak identity binding, the organisation may have traded one exposure for another. The key design question is whether the tunnel enforces least privilege at the service and tool level, not whether it merely hides the IP address.
A public MCP server can still be defensible when the service must be internet accessible, but then the implementation needs much stronger front-door discipline, clearer token handling, and tighter monitoring. If the same workflow can be delivered through outbound only reachability, the tunnel model usually gives cleaner separation between access, transport, and authority.
Risk and Threat Considerations
Public MCP servers concentrate risk in a single exposed endpoint, which makes them attractive to scanning, token theft attempts, and tool abuse. The main failure mode is not simply “internet reachable”, it is that discovery and misuse happen before the service can make a meaningful trust decision.
Failure mechanism: The exposed server accepts unsolicited connections, or it trusts a credential or token too broadly, allowing a hostile caller to reach tools that should have been private or more tightly scoped.
Impact: That can increase the chance of unauthorized tool invocation, confused-deputy behaviour, and governance gaps around which agent or operator actually exercised the action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent and MCP service connections require service-to-service authentication and scoped trust. |
| Recommendation — Use IA-9 to authenticate the MCP service path and bind tool access to the verified service identity. | ||
| NIST Zero Trust (SP 800-207) | 1 — Never trust, always verify | The question contrasts exposed perimeter trust with brokered, continuously verified access. |
| Recommendation — Apply zero trust so each agent request is verified before any tool access is granted. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP endpoints and tunnels both rely on strong caller authentication to prevent unauthorized access. |
| API5 — Broken Function Level Authorization | The key difference is whether each tool call is authorised at the function level. | |
| Recommendation — Harden authentication so the MCP server does not accept unauthenticated or weakly bound requests. Enforce function-level authorisation for every MCP tool invocation. | ||
Practitioner Guidance
What to verify: Check whether the MCP deployment ever needs direct inbound exposure at all. If it does, verify the exact auth boundary for each tool, the token audience rules, and whether the server can reject requests that do not originate from an approved enterprise context.
Decision rule: If the service can be kept private without breaking the workflow, prefer outbound only connectivity and treat the tunnel as the constrained access path. If public reachability is unavoidable, require stronger edge controls, strict tool scoping, and explicit review of what the exposed endpoint can do.
What good looks like: The operator can explain, for any agent action, which identity authenticated, which service accepted the connection, and why that action was allowed. When that trace is unclear, the design is too permissive for agent access.
Practitioner takeaway: The important choice is not public versus private in the abstract, it is whether network reachability, authentication, and tool authority are cleanly separated. Outbound only tunnels usually make that separation easier to enforce.
Related resources from NHI Mgmt Group
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between an outbound zero trust tunnel and a site-to-site VPN for agentic AI access?
- What is the difference between zero trust for users and zero trust for NHIs?
- What is the difference between zero trust access and a traditional perimeter approach in M&A?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
