Exposing MCP servers externally raises new identity governance risks

At a glance

What this is: This is a practical guide to exposing MCP servers externally through ToolHive and ngrok, with the key finding that public access can be created quickly without abandoning access control, auditability, or isolation.

Why it matters: It matters because MCP endpoints are identity-bearing tool surfaces, so IAM, PAM, and NHI teams need to treat tunnelled access, tokens, and RBAC as governed production controls rather than temporary convenience.

👉 Read Stacklok's blog post on exposing MCP servers with ToolHive and ngrok

Context

Model Context Protocol servers become an identity governance problem the moment they are exposed beyond an internal network boundary. The core issue is not exposure by itself, but the trust model behind the endpoint, because external reachability changes who can call the tool, how those calls are authenticated, and what audit trail exists when something goes wrong.

For IAM and NHI teams, the practical question is how to extend access control, observability, and blast-radius limits to an MCP server that was previously localhost-only. Tool tunnels can be useful, but they also create a new control plane for secrets, tenant-aware authorization, and partner-facing integrations that must be governed explicitly.

The article’s example is a normal pattern for early MCP adoption: internal server first, external access second. That is typical, which is exactly why it needs governance before it becomes routine in production.

Key questions

Q: What do security teams need to verify before exposing an MCP server to users?

A: Teams need to verify who can register as a client, what scopes they can request, how tokens are validated, and how consent maps to real tool permissions. If any of those links are vague, the MCP server can expand access beyond the user’s intent or the organisation’s policy. Auditability should be built in before go-live.

Q: Why do MCP deployments create governance risk when access is only controlled at the server level?

A: Because server-level controls answer only whether a caller can reach the server, not what actions they can perform inside it. That creates unnecessary privilege at the tool layer. Production governance needs the ability to separate read, write, delete, and export actions within the same server.

Q: What breaks when MCP access is left on long-lived tokens?

A: Long-lived tokens assume access is stable enough to review later, but MCP workflows often involve temporary, multi-step delegation. That creates standing trust where task-bound trust is needed, increases blast radius if a token is reused, and makes offboarding or revocation harder to prove.

Q: How do organisations govern partner-facing MCP integrations?

A: Assign a named owner, document the approved use case, and set offboarding rules that remove access when the relationship ends. Partner integrations need the same governance discipline as internal service accounts, including scoped permissions, logging, and periodic access review.

Technical breakdown

How external MCP exposure changes the trust boundary

An MCP server exposed through a tunnel moves from implicit local trust to explicit remote trust. That means the server is no longer protected by network placement alone. Identity now has to be expressed at the gateway, through authentication, authorization, and audit controls that map each request to a tenant, user, or workload. In practice, the key issue is not the tunnel itself, but whether the tunnel preserves the original security model or silently weakens it by widening who can reach the tool.

Practical implication: treat every externally reachable MCP endpoint as an authenticated API surface, not as a convenience link.

Why token handling and RBAC matter for MCP tool access

The article’s workflow relies on a tunnel token and account-level configuration to bring the endpoint online. That is a classic NHI pattern: a secret establishes the trust relationship, and RBAC determines what the exposed service can do once reached. If those credentials are long-lived or shared across teams, the exposure model becomes fragile because access is tied to standing secrets rather than task-scoped identity. For MCP, that creates a direct link between secret governance and tool governance.

Practical implication: align tunnel credentials with NHI lifecycle controls, including rotation, revocation, and scoped ownership.

Blast radius is the real control objective in tool-as-a-service setups

Tool-as-a-service changes the security problem from server placement to impact containment. A public MCP endpoint can be legitimate for customers or partner testing, but the control objective becomes limiting what the exposed tool can reach, which data it can return, and which actions it can trigger. That is where tenant-aware policy, rate limiting, and observability become part of identity governance rather than adjunct operational features. Without them, a single exposed tool can become a broad access path into internal systems.

Practical implication: design exposed MCP services around least privilege at the tool, data, and session level.

NHI Mgmt Group analysis

External MCP exposure is really an identity boundary decision. The article is about a tunnel, but the governance problem is who gets to invoke tools that were previously internal-only. Once an MCP server becomes internet-reachable, authentication, tenant separation, and auditability are no longer optional wrappers. Practitioners should treat this as a shift from infrastructure exposure to identity exposure.

Tool-level blast radius becomes the primary control variable. Exposing MCP servers safely is less about the tunnel and more about what the exposed tool can access once a request is authenticated. Rate limits, scoped permissions, and clear ownership determine whether the service behaves like a controlled integration point or an open-ended execution path. That is the same blast-radius logic used in NHI governance, now applied to MCP.

Secrets govern the tunnel, but lifecycle governs the risk. Tunnel auth tokens and related credentials are non-human identities in practice, and they need the same ownership, rotation, and revocation discipline as any other service secret. A static token used for temporary integration quickly becomes a standing access path if it is reused across environments or partners. The practitioner conclusion is simple: lifecycle control is the difference between temporary exposure and permanent drift.

Identity governance for MCP must extend to partners and external testers. The moment an MCP server is shared outside the organisation, access no longer fits a purely internal IAM model. Partner-facing use cases need explicit identity boundaries, logging, and offboarding rules so the exposed tool does not outlive the relationship or the test window. That makes external MCP access a governance process, not a one-time deployment choice.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• From our research: Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
• For a broader threat lens: Review 52 NHI Breaches Analysis for recurring patterns in exposed credentials, overprivilege, and third-party access drift.

What this signals

External exposure is becoming the default operating mode for emerging identity surfaces. With 98% of companies planning to deploy more AI agents within 12 months, the governance lesson extends beyond MCP itself: access paths that start as temporary tend to become persistent unless lifecycle controls are built in from day one. Teams should align external tool exposure with the Ultimate Guide to NHIs , Key Challenges and Risks and keep the boundary explicit.

Identity governance for exposed tools now sits at the intersection of NHI and agentic AI. Even when the tool is not autonomous, the access path often behaves like a machine identity with secrets, audit requirements, and scoped permissions. That is why practitioner teams should map MCP exposure to the OWASP Non-Human Identity Top 10 and the OWASP Top 10 for Agentic Applications 2026 where AI-driven tool use is involved.

For practitioners

• Define an identity policy for every exposed MCP endpoint Classify each externally reachable server by audience, data sensitivity, and approved actions before publishing a tunnel URL. Require a named owner, explicit authentication method, and documented revocation path for the endpoint.
• Rotate tunnel credentials on a fixed lifecycle Treat ngrok auth tokens and any related secrets as governed NHI credentials, with rotation, revocation, and environment-specific scoping. Avoid shared tokens across teams or long-running test environments.
• Limit MCP tool permissions to the smallest usable set Apply tenant-aware RBAC and service-level allowlists so the exposed server can only perform the functions required for the test or integration. Revisit the permitted actions whenever the use case changes.
• Instrument access and audit trails before sharing externally Verify that every request to the exposed endpoint is logged with identity context, request time, and destination action. Retain these logs long enough to support partner investigations and access reviews.

Key takeaways

• Exposing MCP servers externally turns a network decision into an identity governance decision.
• Short-lived tunnels still require NHI lifecycle control, scoped permissions, and auditability.
• External integrations are safest when blast radius, ownership, and offboarding are defined before the endpoint is shared.

Key terms

• MCP Exposure Surface: The set of endpoints, tools, and sessions that can be reached through an MCP integration. It is broader than the network path alone because it includes identity context, tool permissions, and the lifetime of the access path.
• Tool Boundary: The tool boundary is the point where an agent's model output becomes an enforced action. In agentic systems, this boundary acts like a permission layer because tool names, schemas, and implementations determine what the agent can actually do, not just what it appears able to request.
• Tunnel Credential: A secret or token that establishes trust for an externally exposed connection or gateway session. It is a non-human credential and should be managed with ownership, rotation, revocation, and environment scoping so temporary access does not become standing access.
• Tenant-Scoped RBAC: A role model where permissions are evaluated inside a specific tenant, such as an organisation or workspace, rather than globally across all users. This prevents authority from leaking between customers and makes access decisions easier to audit, review, and explain in multi-tenant SaaS environments.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step ToolHive proxy tunnel command examples for exposing an MCP server through ngrok
• The exact configuration pattern for auth tokens and public URLs used in the integration
• Operational examples showing how a localhost-only OSV MCP server becomes externally reachable
• Practical notes on using a static or custom domain for repeatable partner testing

👉 Stacklok's full post shows the tunnel workflow, endpoint configuration, and testing pattern in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.