AI agents are only as useful as the tools they can reach. An organization’s most valuable tools are the ones it’s deliberately kept off the public internet: internal APIs, SAP on-premises, GitHub Enterprise, LDAP directories, proprietary databases. Connect an AI agent to any of these and you hit infrastructure that was never designed for external access.

This post explains what that problem actually is, surveys how every major AI platform has responded so far, and introduces Arcade Warp Pipes, a managed service that connects AI clients to your private tools on top of the governance Arcade.dev already gives you.

Connecting AI to private tools is two problems

When engineers describe “the private tool problem,” they’re almost always conflating two problems that need different solutions. One is networking. The other is governance. They’re related but independent, and most products only solve the first.

Problem 1, Networking: your tools aren’t reachable. Your AI clients — the Claude API, Cursor, ChatGPT, your own agent code — run on the public internet. Your tools live inside your network. Bloomberg resolves at bloomberg.corp.internal, SAP at sap.corp.internal, and GitHub Enterprise at github.corp.internal. These names only resolve inside your network by design. Internal services simply aren’t reachable from the public internet. Getting a request from an external AI client to an internal MCP server is a routing problem.

Problem 2, Governance: a tunnel is just transport. Suppose you solve the routing. A tunnel moves bytes and nothing more. It has none of the controls your enterprise actually needs on an AI-to-tool call: authenticating the caller, identifying and managing each user and agent’s credentials, scoping which tools an agent can use, recording every call for audit, and enforcing runtime policy. Moving traffic through a firewall is routine. Enforcing who can do what, as whom, is far more complex, and it’s a completely separate problem from routing.

Both have to be solved for AI agents to reach your private tools safely.

Why everyone converged on the same networking mechanism

In May and June of 2026, Anthropic, OpenAI, and Cloudflare all shipped or updated tools for private MCP connectivity. They approached it from different angles but landed on the same core idea for Problem 1 (Networking):

A small process runs inside your private network and makes one outbound connection to the provider’s infrastructure. Requests come in through that connection. No inbound ports needed.

Firewalls almost always allow outbound traffic by default, even when everything inbound is locked down. Every tunnel product exploits this: the connector dials out, holds the connection open, and the provider routes requests back through it.

Where they differ is who sits in the data path, which AI products can use the tunnel, and critically, how much of Problem 2 (Governance) they leave to you.

The current landscape: Anthropic, OpenAI & Cloudflare

Anthropic MCP connector (beta)

Anthropic built this to get Claude into your private network to reach an MCP server. Two processes run inside it. cloudflared — Cloudflare’s open-source connector — makes an outbound connection to Cloudflare’s edge. Alongside it, Anthropic’s routing proxy terminates an inner layer of encryption so Cloudflare carries traffic it can’t read, then forwards requests to your MCP server by hostname.

The security model has three layers: an outer mTLS connection between Anthropic and Cloudflare, an inner TLS layer between Anthropic’s backend and your proxy using a certificate only you hold, and OAuth on the MCP server itself — which Anthropic explicitly leaves to you to implement and maintain.

It’s in beta with no uptime guarantee. It works only with Claude. And it only gets Claude to your MCP server’s front door; everything from authentication to credential management to access governance is still your problem.

OpenAI Secure MCP Tunnel (general availability, May 2026)

OpenAI is the one major vendor that ships a purpose-built tunnel for the networking problem. Its open-source tunnel-client (Apache 2.0, in Go) runs inside your network and connects a private or firewalled MCP server to ChatGPT, Codex, the Responses API, and AgentKit through an OpenAI-hosted tunnel endpoint. It works only with OpenAI’s products, and like Anthropic’s connector it handles connectivity and nothing else. Auth, credentials, and access control are left to you.

Cloudflare MCP Server Portals (open beta)

Cloudflare’s MCP Portals sit in front of multiple MCP servers, handle OAuth for clients through Cloudflare Access, and aggregate tool catalogs behind one endpoint. Useful if you’re already on Cloudflare Zero Trust; meaningful onboarding overhead otherwise. HTTP MCP servers only.

What the tunnels leave unsolved

Every product above is good at one thing: moving traffic through a firewall. That’s Problem 1 (Networking). What they leave to you is the governance of Problem 2, everything that makes an AI-to-tool call safe.

Authentication. Anthropic explicitly makes OAuth on your MCP server your responsibility. OpenAI’s tunnel does the same. You build and maintain the flow that authenticates every AI client: implementing the spec, issuing and validating tokens, handling refresh.

Credential management. When an agent calls a tool that acts on behalf of a specific user — pulling their Salesforce records, sending email from their account, querying their repos — someone has to manage that user’s OAuth tokens: storing them, refreshing them, scoping them. The tunnel products hand the request off and walk away.

Access governance. Who can call which tools? A junior analyst shouldn’t have the same Bloomberg functions as a portfolio manager. A contractor shouldn’t see internal HR tooling. The tunnels have no concept of this — no policy layer, no per-user access control.

Audit trail. For regulated industries, you need a record of every tool call: who called it, what arguments were passed, what came back, and when. The tunnel products produce none of this.

Avoiding lock-in. Anthropic’s connector works with Claude. OpenAI’s tunnel works with OpenAI. Want the same private MCP server reachable from both Claude and ChatGPT? How about Cursor, Cline, or your own agent code? You’re running multiple tunnels and configurations.

Connecting to multiple internal services. Each tunnel exposes one MCP server. Bloomberg, SAP, GitHub Enterprise, and LDAP all serving tools means four tunnels stitched together on the client side.

This is the whole point: a tunnel solves networking. It doesn’t touch governance.

Arcade already solves governance and lets you handle networking

Here’s what’s not new. The Arcade runtime already does everything in the list above. It runs inside your network as an MCP server, and AI clients connect to it the way they’d connect to any MCP server. It implements OAuth natively, so any MCP-capable client authenticates automatically. It stores and refreshes per-user credentials for every tool. It scopes access through gateways, named paths like /mcp/finance and /mcp/engineering, each with its own allowed tools, auth, and access rules. It logs every call with the caller’s identity, the arguments, and the response. And it reaches your internal MCP servers directly over your private network.

You’ve always been able to handle the networking hop (getting external AI clients to that runtime) by putting your own reverse proxy or API gateway in front of it. Whether it’s cloudflared, ngrok, nginx, an F5, your existing edge: any of them makes the one outbound connection, and external clients connect to the public end. The runtime behind it is unchanged.

What’s new is that you no longer have to run that hop yourself.

Introducing Arcade Warp Pipes

Warp Pipes is a managed service that connects external AI clients to your private Arcade runtime so you don’t have to operate the networking yourself. It’s a batteries-included reverse proxy in the cloud, available with one click.

Your runtime stays inside your network. You run the Warp Pipes connector alongside it, and it makes one outbound connection to Arcade. Arcade gives you a public MCP URL and forwards traffic from that URL down the connection to your internal runtime. On your side, the only thing facing out is the Warp Pipes connector, pointing outbound. No inbound ports, no reverse proxy to run yourself, no certificates to rotate.

The surface now includes:

  • A public MCP URL, hosted by Arcade, that any AI client can connect to.
  • Managed forwarding from that URL to your internal runtime.
  • An outbound connector that runs in your network and holds the connection open.

Put simply, Warp Pipes connect clients to the existing Arcade runtime for auth, credentials, governance, or auditing. Problem solved.

Warp Pipes is managed networking. The runtime is the governance.

Because the runtime implements OAuth natively, any MCP client — Claude, ChatGPT, Cursor, Cline, your own agent code — authenticates automatically and gets exactly what its gateway allows. One runtime, one managed connection, every AI client.

Prefer to run it yourself? Bring your own reverse proxy

Warp Pipes is the managed option but not the only option. If you’d rather own the networking hop, or you already run a reverse proxy or API gateway you trust, keep it. Put cloudflared, ngrok, nginx, or your existing edge in front of the Arcade runtime, point it at the runtime’s port, and external clients reach the same gateways the same way. Arcade has always worked this way.

The choice is only about who runs the connection. The runtime, the governance, and the authentication model are identical either way.

Multiple networks, multiple runtimes

For organizations with multiple business units or regions, run a separate Arcade runtime per network, each scoped to what that network contains. A Finance runtime in your NYC datacenter reaches Finance MCP servers on 10.10.x.x. An Engineering runtime in AWS reaches Engineering MCP servers on 10.20.x.x. An EU runtime in Frankfurt reaches EU-region services, and that data never leaves the region.

Each runtime enforces its own network boundary. All of them share one identity and access control plane in Arcade but have independent data planes, the one place for auth and governance. Warp Pipes connects each of them out to its own public MCP URL, or you front each with your own proxy. Either way, the boundaries hold.

The tunnel moves traffic. The runtime governs it.

Every tunnel product covered above is good at the networking problem and stops there, leaving you to build governance yourself.

Arcade approaches the problem from the other end. Our runtime has always handled governance — OAuth, per-user credentials, access control, audit, multi-provider support — and you could always bring your own networking. Warp Pipes now makes the routing even easier by managing that networking for you. The runtime governs every call, Warp Pipes connects every client to it.

To join the Arcade Warp Pipes early access program, contact us.