Notifications
Clear all
Topic starter
20/08/2026 5:39 pm
TL;DR: ToolHive and ngrok can expose MCP servers through a public HTTPS tunnel for testing, demos, and partner integration while preserving access controls, audit trails, and blast-radius management, according to Stacklok. The governance issue is that externally reachable MCP endpoints shift identity and secret handling from an internal assumption to an internet-facing one, which requires tighter lifecycle control.
NHIMG editorial — based on content published by Stacklok: Integrations Safely expose MCP servers externally with ngrok + ToolHive
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Stacklok's blog post on exposing MCP servers with ToolHive and ngrok →
MCP server exposure with ngrok and ToolHive: what changes for IAM?
Explore further
20/08/2026 6:24 pm
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Exposing MCP servers externally raises new identity governance risks
