Warp Pipes

Connecting AI agents to private tools is two problems. The first is networking: your internal MCP servers and services aren’t reachable from the public internet, by design. The second is governance: a tunnel only moves bytes, so authentication, per-user credentials, access scoping, and audit are a separate problem that the tunnel products leave to you.

The Arcade runtime already solves governance. Warp Pipes is a managed service that solves the networking — Arcade hands you a public MCP URL and forwards traffic to your private runtime, so you don’t run the connection yourself.

How Warp Pipes works

Your Arcade runtime runs as an MCP server inside your private network, on port 9099 by default, and it never faces the internet. You run the Warp Pipes connector alongside it; the connector makes one outbound connection to Arcade. Arcade gives you a public MCP URL and forwards every request down that connection to your runtime.

What Warp Pipes adds, and only this:

• A public MCP URL hosted by Arcade that any AI client connects to.
• Managed forwarding from that URL to your internal runtime.
• An outbound connector in your network that holds the connection open. Nothing inbound is exposed.

Everything behind the connector is the runtime you already have. Warp Pipes does not re-implement authentication, credentials, governance, or audit. It connects clients to the runtime that already does them.

How the runtime works

Two concepts shape every deployment, with or without Warp Pipes:

• Gateways are named paths on the runtime (/mcp/{slug}). Each gateway has its own auth mode, tool allow-list, and access rules, so an AI client connecting to /mcp/finance sees only finance tools. You create gateways in the Arcade dashboard, not in engine.yaml.
• Identity and access — users, organizations, API keys, RBAC, and OAuth — is managed in Arcade. The runtime makes outbound-only calls to it; it never dials the runtime. Multiple runtimes can share one Arcade account.

Gateway auth modes

Each gateway uses one of three auth modes. The mode determines what the AI client sends and which clients can connect.

For Claude, through the Messages API or managed agents, use Arcade Auth or User Source. See MCP Gateways for how to choose a mode and User Sources for connecting your own identity provider.

Connect to internal MCP servers

Your internal MCP servers live at private hostnames or IP addresses. Configure the ssrf_allowlist in engine.yaml to tell the runtime which internal addresses it’s permitted to call, then register each MCP server URI as a worker.

The runtime calls these servers directly over your private network, by their internal addresses. No inbound ports, and no tunnel, are required.

Add the allowlist and workers to the tools.directors section of engine.yaml:

tools:
  directors:
    - id: default
      ssrf_allowlist:
        - "*.corp.internal"       # any subdomain
        - "10.10.0.0/16"          # IP range
      workers:
        - id: bloomberg
          enabled: true
          http:
            uri: "http://bloomberg.corp.internal:8000"
            secret: "${env:BLOOMBERG_SECRET}"
        - id: sap
          enabled: true
          http:
            uri: "http://sap.corp.internal:8080"
            secret: "${env:SAP_SECRET}"
        - id: github-enterprise
          enabled: true
          http:
            uri: "http://github.corp.internal"
            secret: "${env:GITHUB_SECRET}"

For the rest of the tools.directors and worker options, see runtime configuration.

Allowlist entry types

Keep these rules in mind when you write allowlist entries:

• URIs must use http:// or https://. The runtime rejects other schemes at startup.
• A wildcard such as *.corp.internal does not match the bare apex corp.internal. Add the apex separately if the runtime needs to reach it.
• CIDR entries match against the resolved IP. For split-horizon DNS, where a hostname resolves to different IPs inside and outside the network, use exact-host or wildcard entries instead.
• Malformed entries cause the runtime to fail at startup.

Configure the allowlist with Helm

If you deploy the runtime with the Arcade Helm chart, set the allowlist with --set:

helm upgrade arcade monorepo/deploy/charts/arcade/ \
  --set engine.ssrfAllowlist[0]="*.corp.internal" \
  --set engine.ssrfAllowlist[1]="10.10.0.0/16"

Verify the connection

Use the worker test endpoint in the Arcade dashboard. A successful test confirms the allowlist entry is correct and that the runtime has a network path to the MCP server.

Deploy across multiple networks

For multiple business units or regions, deploy a separate runtime per network. Each runtime has its own ssrf_allowlist scoped to the servers in that network, and all runtimes share one Arcade account for identity and access.

A typical topology assigns one runtime to each network:

This topology gives you:

• Network isolation — each runtime can only reach the hosts and ranges in its own allowlist. The finance runtime can’t dial 10.20.x.x even if it receives a URI pointing there.
• Data residency — the EU runtime’s tool traffic never leaves eu-west-1, and credentials in its vault stay in-region.
• Credential isolation — each runtime holds its own credential vault. A compromise of one runtime exposes no credentials from the others.
• Shared identity — all runtimes make outbound calls to the same Arcade account for auth and RBAC. The data planes are independent; identity and access are shared.

Connect each runtime out with its own Warp Pipes URL, or front each with your own reverse proxy.

Bring your own reverse proxy

Warp Pipes manages the connection for you. If you’d rather run the networking hop yourself — or you already operate a reverse proxy or API gateway you trust — Arcade has always worked behind one.

Run a reverse proxy inside your network. It makes one outbound connection, so no inbound ports are needed. External clients connect to the proxy’s public hostname, and the proxy forwards traffic to the runtime internally.

All AI clients see the same RFC 9728 OAuth interface regardless of which proxy you use. The runtime, the governance, and the security model are identical whether the connection is managed by Warp Pipes or by your own cloudflared, ngrok, or nginx.

tunnel: <tunnel-id>
credentials-file: /etc/cloudflared/credentials.json
ingress:
  - hostname: arcade.yourdomain.com
    service: http://arcade:9099
  - service: http_status:404

cloudflared tunnel run

ngrok http 9099 --domain arcade.your-org.ngrok.app

server {
    listen 443 ssl;
    server_name arcade.yourdomain.com;
 
    ssl_certificate     /etc/ssl/certs/arcade.crt;
    ssl_certificate_key /etc/ssl/private/arcade.key;
 
    location / {
        proxy_pass http://arcade:9099;
 
        # Required for streaming
        proxy_buffering    off;
        proxy_cache        off;
        proxy_read_timeout 3600s;
        proxy_http_version 1.1;
        proxy_set_header   Connection '';
 
        # Required headers
        proxy_set_header Host                  $host;
        proxy_set_header X-Real-IP             $remote_addr;
        proxy_set_header Authorization         $http_authorization;
        proxy_set_header Mcp-Session-Id        $http_mcp_session_id;
        proxy_set_header MCP-Protocol-Version  $http_mcp_protocol_version;
    }
}

Required proxy headers

Whichever proxy you use, verify these headers pass through unchanged:

The path /mcp/{slug} must also pass through intact. The runtime routes by gateway slug from the path.

Client compatibility

Known limitations

Next steps

• Configure the Arcade runtime for the full engine.yaml reference
• Create an MCP Gateway to scope tools and auth for each client
• Set up a User Source to authenticate end users with your own identity provider
• Connect your MCP client to a gateway URL