MCP tunnels shift AI access control behind the firewall

At a glance

What this is: This how-to explains how Anthropic MCP Tunnels and Stacklok change enterprise AI connectivity by moving access behind the firewall while keeping policy and tool governance on the customer side.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern AI tool access through identity policy and lifecycle controls, not just network perimeter rules.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope.

👉 Read Stacklok's blog post on Anthropic MCP Tunnels and enterprise tool access

Context

MCP tunnels solve a familiar enterprise problem: how to connect AI systems to internal tools without exposing those tools directly to the internet. The primary governance issue is not transport alone, but how identity, authorization, and tool scoping are enforced once the connection exists.

For NHI and IAM programmes, this is a shift from perimeter-first thinking to identity-first control for AI-enabled access. If Claude or another AI surface can reach internal systems through an approved tunnel, the enterprise still needs clear ownership for the credentials, group memberships, policies, and audit trails that govern every MCP server.

The article is therefore about productionizing access, not merely enabling it. That makes it relevant to teams responsible for service accounts, delegated access, privileged tooling, and emerging AI agent workflows that depend on non-human identities behind the firewall.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why do MCP tunnels still require IAM and NHI controls?

A: MCP tunnels solve the connectivity problem, but they do not decide who can reach which tools or how long that access should remain valid. IAM and NHI controls are still needed to manage authorization, ownership, revocation, and auditability. Without them, a secure transport can still carry over-privileged AI access into sensitive systems.

Q: What breaks when AI platform access is managed like ordinary user access?

A: What breaks is the assumption that access is stable, human-owned, and easy to review in a later cycle. AI usage can be distributed, contextual, and agent-driven, so ordinary user access controls often miss the real scope of activity. That leaves privilege, usage, and accountability misaligned.

Q: Who should own lifecycle reviews for MCP-connected AI tools?

A: The business or platform owner responsible for the underlying tool should own lifecycle reviews, with identity and security teams enforcing the process. That review should confirm the connector still serves a valid purpose, still needs the same scope, and still maps to a current group membership. If not, access should be removed or reduced.

Technical breakdown

How MCP tunnels invert enterprise network exposure

Model Context Protocol lets an AI system call tools and data sources, but the traditional model creates pressure to open inbound paths to internal systems. MCP tunnels change that by reversing the connection direction so the internal environment initiates the session outward. That reduces firewall exceptions, but it does not eliminate the need to govern which tools are reachable, how authentication is established, or which identities can invoke them. The practical difference is that network exposure becomes less of the control plane, while identity and authorization become more of it.

Practical implication: treat the tunnel as an access path that still requires explicit identity scoping and authorization review.

Why mTLS and OAuth solve different parts of the problem

Mutual TLS protects the transport layer by verifying both ends of the tunnel and encrypting the session. OAuth sits above that layer to authenticate access at the MCP level and determine who or what can use a given tool. These are complementary controls, not substitutes. Transport security protects the channel, while OAuth and identity policy govern the actions that occur over it. If either layer is treated as sufficient on its own, the enterprise can end up with a secure pipe carrying over-privileged access.

Practical implication: validate both channel security and per-tool authorization before allowing any AI surface into production.

Why orchestration becomes the control point for MCP server sprawl

Once multiple MCP servers are exposed to an AI system, the risk shifts from simple connectivity to sprawl, inconsistent policy, and weak observability. A management layer that aggregates servers into segmented access groups helps avoid every client and every team creating its own isolated tool path. That matters because AI access often expands by use case, not by formal governance design. The operational question becomes which tools exist, who can reach them, and whether the access pattern is still aligned with role and purpose.

Practical implication: centralize MCP server governance so tool exposure, group membership, and audit logging are controlled together.

Threat narrative

Attacker objective: The objective is to reach internal tools and data through an approved AI access path without having to expose those systems directly to the internet.

1. Entry begins when an internal system opens an outbound tunnel to an AI service, creating a controlled but real path between external AI tooling and private enterprise systems.
2. Escalation occurs if tool scope is broad, access groups are weakly segmented, or MCP servers are added without consistent authorization and audit controls.
3. Impact is unauthorized AI-driven access to internal data or operational systems through a path that appears private but can still be over-permissioned.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity boundary control is now the real MCP governance problem. The tunnel changes where the connection starts, but it does not change the enterprise obligation to decide which identities can invoke which tools and under what purpose. That means MCP governance sits squarely inside IAM, PAM, and NHI lifecycle discipline, not just network engineering. Practitioners should treat every MCP endpoint as an identity-controlled interface, not a convenience layer.

Tool segmentation is the named control concept enterprises should adopt for MCP. Once multiple teams use the same AI surface, the risk is not merely access, but uncontrolled reuse of tools across functions. Segmenting MCP servers by group, role, and purpose is the only way to keep AI access from turning into implicit shared privilege. Practitioners should make tool segmentation part of entitlement governance and access review, not an afterthought.

Cross-surface AI access collapses the old assumption that a client equals a device. In this architecture, the same AI service can reach enterprise tools across Claude Code, Claude Enterprise, and other surfaces without per-device configuration. That breaks the old mental model of device-bound trust and makes identity the primary boundary. Practitioners need governance that follows the actor, the group, and the action, not the endpoint alone.

Production MCP requires lifecycle governance for non-human access, not just deployment engineering. A tunnel can make a lab setup operational, but it does not decide when a connector should be removed, rotated, recertified, or restricted. That responsibility sits with the enterprise and must align with NHI lifecycle management. Practitioners should assume that every standing MCP connector will become a governance issue unless it is continuously reviewed.

The market is moving toward identity-mediated AI infrastructure rather than open AI integration. Enterprises do not want to expose internal systems directly to AI services, and they also do not want one-off local setups that cannot be governed at scale. The direction of travel is clear: secure AI access will depend on identity policy, segmented orchestration, and lifecycle control around machine-facing tools. Practitioners should plan for governance-heavy AI adoption, not frictionless integration.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which means tool governance is still the exception rather than the norm.
• Ultimate Guide to NHIs covers the lifecycle controls that should frame MCP connector ownership, review, and offboarding.

What this signals

Tool segmentation is becoming the difference between usable AI access and unmanaged privilege. As more enterprises connect AI surfaces to internal systems, the control question shifts from whether access is technically possible to whether each tool path has a named owner, a scoped purpose, and a reviewable entitlement. That is a classic identity governance problem, not a network problem, and it will surface in every AI programme that scales beyond pilots.

The operational signal is that governance teams need to treat AI connectors like other non-human access paths, especially where service accounts, group membership, and delegated tooling all converge. The practical next step is to align AI access with existing lifecycle controls, then verify whether access reviews can actually see the full tool chain from request to revocation.

For practitioners

• Define MCP server ownership and approval boundaries Assign every MCP server to a named system owner, then require approval for any new tool exposure, group membership change, or external AI surface connection. Make that ownership visible in access review records and operational runbooks.
• Segment tool access by role and purpose Use group-based segmentation to ensure engineering, marketing, and shared AI users see only the MCP tools required for their function. Reconcile those groups with existing identity policy rather than creating parallel entitlements.
• Review tunnel access as a privileged pathway Treat the tunnel endpoint as a privileged access route and apply the same scrutiny you would use for service accounts, delegated admin paths, and other NHI entry points. Validate logging, revocation, and audit coverage before production use.
• Map AI surfaces to the same governance model Check whether Claude Code, Claude Enterprise, and other AI surfaces inherit the same authorization and monitoring rules or drift into separate control planes. Collapse duplicates where possible so policy and observability stay consistent across the stack.
• Build recertification into connector lifecycle Set a review cadence for every MCP connector, including ownership confirmation, tool scope validation, and access revocation for stale group memberships. Connect that cadence to the broader non-human identity lifecycle process.

Key takeaways

• MCP tunnels reduce firewall exposure, but they do not remove the identity governance burden around AI tool access.
• The sharpest control gap is access scoping, because AI integrations become risky as soon as tool permissions are shared too broadly.
• Enterprises should manage MCP connectors through ownership, segmentation, and lifecycle review, not as ad hoc integration plumbing.

Key terms

• Model Context Protocol: A standard that lets AI systems connect to tools and data sources through structured requests. In practice, it creates a governed interface between an AI actor and enterprise systems, which means the identity and authorization model matters as much as the transport layer.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.
• Tool segmentation: The practice of limiting which tools an AI surface can reach based on role, group, or purpose. For AI-connected environments, segmentation is the difference between controlled access and a broad entitlement set that behaves like standing privilege.

What's in the full article

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

• Exact deployment flow for the tunnel endpoint, including Docker Compose and Helm-based setup
• How Stacklok's virtual MCP server model segments tools by group and maps to identity policy
• Details on how Anthropic's Toolbox client handles MCP calls across Claude surfaces
• Production considerations for moving from local experiments to monitored Kubernetes deployments

👉 The full Stacklok post covers tunnel setup, MCP server orchestration, and the production model behind its deployment approach.

Deepen your knowledge

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