Because they remove the assumption that the server is reachable only inside a trusted boundary. Once a workload is internet-facing, the access model must rely on authentication, authorization, and revocation rather than location-based trust.
Why public MCP tunnels change the workload trust model
Public tunnels turn an MCP server from an internal service into an exposed endpoint. That shifts the security question from “is this inside the network?” to “can this workload prove it should be here, and what can it do once connected?” The practical effect is that identity, scope, and revocation become the real control points.
In an internal-only setup, location often acts as an informal filter. With a public tunnel, that shortcut disappears, so the workload must be treated like any other reachable service: every connection, token, and delegated action has to stand on its own. The access decision can no longer assume that network placement equals trust.
This is why the same tunnel can be harmless in one design and dangerous in another. If the server keeps broad standing credentials, weak client authentication, or opaque tool permissions, an exposed path increases blast radius immediately. If the tunnel is paired with narrow authorization, short-lived credentials, and clear revocation, exposure is managed rather than assumed away. For MCP-specific controls, see MCP Security Guide.
What changes in authentication, authorization, and revocation
A public MCP tunnel requires the workload to authenticate as an active participant, not as something implicitly trusted because it sits on a private subnet. That usually means stronger client identity, tighter token audience control, and explicit verification of which server or tool namespace is being reached. The access boundary becomes cryptographic and policy-based, not geographic.
Authorization also becomes more granular. Instead of granting a broad path to “the server,” practitioners should think in terms of specific tools, actions, and scopes. That matters because an exposed MCP endpoint can be reachable by more than the intended client, including misconfigured agents, forwarded tokens, or unintended relay paths. In that model, least privilege is not a best practice add-on, it is the containment strategy.
Revocation is the third critical shift. If a tunnel or credential is compromised, you need a way to cut off access quickly without redesigning the topology. Short-lived credentials, audience-bound tokens, and clear trust-policy ownership matter more once the server can be reached from outside the original boundary. For broader workload identity patterns, Cloud Workload Identity Guide and the SPIFFE workload identity specification both reflect the same principle: connectivity is not trust.
Why workloads need a different identity posture once they are internet-facing
Once a workload is externally reachable, its identity posture must be designed for hostile conditions. That means no reliance on long-lived static secrets where a short-lived credential will do, no shared access paths that blur attribution, and no assumption that one authenticated client deserves broad reuse of that trust elsewhere. The tunnel should narrow the trust boundary, not leak it.
For non-human workloads, the non-human dimension matters because these identities often act at machine speed and with automation privileges. A public tunnel can therefore magnify mistakes that were tolerable internally, such as overprivileged service credentials, weak rotation discipline, or token passthrough that expands access beyond the intended hop. The correct design question is not whether the workload is “allowed on the network,” but whether its identity can be limited, observed, and withdrawn with precision. The NHI perspective is covered well in Ultimate Guide to NHIs — What are Non-Human Identities and Ultimate Guide to NHIs — Standards.
In practice, public exposure pushes identity controls closer to Zero Trust thinking. The workload must continuously earn access, not inherit it from where it is hosted. That is especially important when the tunnel bridges environments, tenants, or trust domains, because the blast radius is no longer bounded by a private segment. A useful implementation reference is Guide to SPIFFE and SPIRE, which focuses on workload attestation and strong service identity.
Risk and Threat Considerations
Public MCP tunnels increase exposure because they turn identity failures into remotely reachable failures. If authentication is weak, authorization is coarse, or revocation is slow, an attacker does not need to breach the internal network first, they only need to find a reachable endpoint and abuse the trust it grants.
Failure mechanism: The tunnel removes the network boundary as a meaningful trust control, so any stolen token, overbroad scope, or relayed credential can be used from outside the original environment. Tool misuse, token forwarding, and confused-deputy behavior become more dangerous because they are no longer constrained by location.
Impact: Compromise can lead to unauthorized tool invocation, data exposure, lateral movement across connected services, and faster blast-radius expansion than the internal-only design would allow. If the workload identity is reused elsewhere, the tunnel can also become an entry point into other systems that still trust the same credential or delegation path. For the identity-security failure patterns behind this, see Top 10 NHI Issues and NHI Authentication Guide.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Public MCP tunnels depend on strong workload authentication and token handling. |
| NHI-05 — Overprivileged NHI | Externally reachable workloads need narrow scopes to limit blast radius. | |
| NHI-07 — Long-Lived Secrets | Public exposure makes static credentials harder to defend and revoke quickly. | |
| Recommendation — Use strong workload authentication and remove any implicit trust in tunnel location. Reduce workload privileges to the minimum actions and resources the tunnel needs. Replace long-lived secrets with short-lived credentials and rapid rotation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | A public MCP endpoint is exposed to remote authentication failures. |
| Recommendation — Validate client authentication before allowing any tool or resource access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Public tunnels can let agents or relayed credentials exercise excessive authority. |
| Recommendation — Constrain delegated authority so exposed agents cannot exceed intended privileges. | ||
Practitioner Guidance
What to prioritise: Treat public tunnel exposure as an identity-design problem first and a networking problem second. The first question is whether the workload can authenticate, authorize, and revoke access without relying on the tunnel’s location.
What to verify: Confirm that the workload has unique credentials, narrow scopes, and a clear revocation path. If a single secret or token can unlock multiple tools or environments, the tunnel is carrying too much trust.
Common mistake: Teams often secure the transport and then leave the old trust model in place. That creates a public endpoint that still behaves like an internal one, which is exactly the mismatch an attacker looks for.
Practitioner takeaway: A public MCP tunnel is acceptable only when the identity layer has been upgraded to match the exposure level; if the workload still depends on implicit trust, the tunnel has converted convenience into reachable risk.