On May 19, 2026, InfoQ published Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems. MCP Tunnels is an official Anthropic bidirectional tunneling feature that connects external Claude agents to internal databases, core systems, and in-house APIs without public IPs, all without opening firewall ports. It adapts an architecture similar to Cloudflare Tunnel or Tailscale Funnel, optimized specifically for the MCP protocol, with the critical distinction that no inbound ingress ports need to be opened on the sender side.
From our perspective delivering custom AI solutions for mid-sized enterprises, we previously hit the wall of "core systems that cannot be opened to the internet cannot be integrated with AI." The launch of this feature provides the "final missing piece" for the internal MCP strategies discussed in our Practical Guide to Building Internal MCP Server Fleets and MCP Joins the Linux Foundation. In this article, we outline the architectural considerations and implementation steps for turning internal systems into agents via MCP Tunnels from the frontline perspective of custom development.
Why MCP Tunnels clear the bottleneck for AI adoption in mid-sized enterprises
| Challenge | Conventional limitations | Changes brought by MCP Tunnels |
|---|---|---|
| Connection to core databases | Requires VPN provisioning + IP restrictions | Completed purely via outbound connections |
| AI integration with in-house APIs | Building custom reverse proxies + authentication | Connected via standard MCP protocol |
| On-premise business systems | Requires DMZ setup / hardware procurement | Enabled with a single agent process |
| IT team review workload | Months of coordination for each project | Streamlined into a templated review route |
| Audit Logging | Fragmented across separate pathways | Centralized per tunnel |
This marks a transition from "running AI inside the vault" to "having AI reach into the vault from the outside." It serves as a practical solution reconciling the IT team's restrictions against opening inbound ports with the practical benefits of agents.
Three structural shifts driven by MCP Tunnels
Structure 1: From "VPN-based" to "application-layer tunnels"
Previously, connecting external agents into internal networks required configuring site-to-site or client VPNs. Because MCP Tunnels are established using HTTPS outbound connections only, new firewall exceptions are not required. IT team review timelines drop from weeks to days.
Structure 2: From "broad network exposure" to "least privilege per tool"
While VPNs allow users to "reach the entire network," MCP Tunnels can restrict "reach to specific MCP tools." Granular access control, such as "permitting inventory lookups while prohibiting inventory updates," can be expressed directly in the tunnel definitions. This is an extension of the permission architecture described in Design Patterns for Converting Existing APIs into MCP Servers.
Structure 3: From "per-pathway auditing" to "per-tunnel auditing"
Source, destination, invoked MCP tools, arguments, responses, and token consumption can be aggregated into a single log stream per tunnel. This gives auditors clear visibility into "who did what, to which core system, how many times, and when."
Five phases to execute MCP Tunnels and internal system agent enablement
Phase 1: Target system inventory (2 weeks)
We take inventory of "which business systems," "which data," and "which operations" inside the client organization should be exposed to AI. Typical targets include sales management, inventory, accounting, HR, and manufacturing processes. Classifying them into "read-only versus write-permitted" is paramount.
Phase 2: Tunnel architecture and zero-trust integration (1–2 weeks)
- Outbound pathway (via proxy / SOCKS or direct)
- Authentication (client IdP / OAuth / mTLS)
- Per-tool permission mapping
- Audit log aggregation destination (client SIEM / our operations)
Document these requirements as a set of network diagrams, permission matrices, and audit logging specifications.
Phase 3: Implementing tunnel support for MCP servers (2–4 weeks)
Implement an MCP wrapper around existing internal APIs and databases, bundling the MCP Tunnels client. Begin with read-only tools, then incrementally introduce write tools backed by approval workflows.
Phase 4: Operational agent integration (2–3 weeks)
Configure integrations for Claude, Claude Code, or internal client agents to call MCP tools over the tunnel. Include prompt design, guardrails, and fallbacks.
Phase 5: Monthly managed operations (ongoing)
- Tunnel health monitoring
- Audit log reviews
- Adding new tools / updating permissions on existing tools
- First-line incident response
These tasks must be run continuously as ongoing operations after rollout. Determine during the implementation phase who will handle them.
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Tunnel | Anthropic MCP Tunnels (official) | Cloudflare Tunnel + custom MCP |
| MCP servers | Python mcp / TypeScript SDK | Custom HTTP API |
| Authentication | mTLS + OAuth (client IdP integration) | API keys (PoC only) |
| Access management | OPA / Rego policies | Custom RBAC |
| Audit Logging | OpenTelemetry → client SIEM | Loki / Elasticsearch |
| Secrets | HashiCorp Vault / GCP Secret Manager | AWS Secrets Manager |
| Health monitoring | Prometheus + Grafana | Datadog |
Which projects need this and which do not
| Projects requiring this | Projects not requiring this |
|---|---|
| Need AI to access core / operational DBs | Fully addressed with public APIs |
| Internal APIs without public IP addresses | Already consolidated into SaaS |
| IT team refuses to open inbound ports | DMZ operations are already mature |
| Audit requirements mandate unified pathways | Internal tools outside audit scope |
| Business systems across multiple locations / overseas subsidiaries | Single location only |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target systems | Names of connected systems and operation types | Out-of-scope systems require separate agreements |
| Permission matrix | Authorization table of tools × roles | Executive approval |
| Audit log retention | 12 / 36 / 60 months | Compliance |
| Incident response SLA | First-response triage time / recovery target | Business impact level |
| Behavior on tunnel disconnection | Auto-reconnect / service suspension criteria | Business continuity |
| Offboarding handover | MCP definitions + IaC + audit logs | Internal operational continuity |
Five common pitfalls
Pitfall 1: Opening all systems at once
The ironclad rule for tunnels is "staged rollout starting from read-only tools" rather than "everything at once." Introducing write tools early turns rollbacks into a nightmare.
Pitfall 2: Operating with unapproved permission matrices
Expanding permissions without three-party approval from executive leadership, the IT team, and business units leaves you unable to explain access rights during an audit. Design an operational flow early where approved pull requests automatically reflect in configuration.
Pitfall 3: Discrepancies in audit log retention periods
If retention periods diverge between business systems (e.g., 7 years) and MCP Tunnel logs (e.g., 12 months), incidents cannot be correlated after an event occurs. An architecture aligned to the longest retention period is necessary.
Pitfall 4: Cascading business halts when tunnels disconnect
If it is unclear whether only AI capabilities stop when a tunnel disconnects or if the entire business UI halts, it will cause widespread frontline confusion. Always design circuit breakers and degraded-mode UI states.
Pitfall 5: Unchecked proliferation of tool definitions
When MCP tool definitions proliferate without controls, agents waste tokens attempting unnecessary tools. Prune them through monthly tool catalog reviews.
90-day action plan
| Week | Action |
|---|---|
| Week 1〜2 | Target system inventory |
| Week 3〜4 | Tunnel design + permission matrix formulation |
| Week 5〜8 | MCP wrapper implementation + read-only rollout |
| Week 9〜11 | Operational agent integration + staged release |
| Week 12〜13 | Audit log integration + monthly operations launch |
Conclusion — "Reaching in from outside the vault" becomes the AI standard
With Anthropic's release of MCP Tunnels, the long-standing limitation that "internal databases and core systems cannot be enabled for AI" has been lifted. For providers delivering custom AI solutions to mid-sized enterprises, being able to design zero trust, tool-level least privilege, and integrated auditing as a cohesive whole will define success.
Because agent enablement for internal systems varies significantly in architecture and effort depending on the number of systems, read/write scope, and audit requirements, we provide customized quotes after reviewing your needs. Please feel free to reach out via our inquiry form if you want AI to access core systems without public internet exposure, have AI initiatives stalled in IT team reviews, or need to unify connection pathways for audit compliance.
Sources
- Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems（InfoQ）
- Practical Guide to Building Internal MCP Server Fleets: 2026 Edition (GH Media)
- MCP Joins the Linux Foundation: An Open Standard for Custom Development (GH Media)
- Design Patterns for Converting Existing APIs into MCP Servers (GH Media)
