Agent-era networking needs a new baseline
AI agents have introduced a new category of client to private networks. A coding agent that needs to inspect a staging database, a production agent that must call an internal API, or a home assistant that has to reach a device on your LAN—these are not interactive sessions. They are autonomous processes making unapproved requests against infrastructure that must stay protected.
The old tools don't fit. VPNs demand interactive login. SSH tunnels need manual construction. Public exposure of private services invites attack. None of them tell you what the agent did after it connected.
Cloudflare Mesh is a new offering designed for this reality. It connects private networks to each other and provides secure access for agents. It is also integrated with the Cloudflare Developer Platform, meaning Workers, Durable Objects, and agents built with the Agents SDK can reach private infrastructure directly.
For existing Cloudflare One customers, Mesh is an extension of the platform, not a new paradigm. It uses the same connectivity options you already run—WARP Connector (now called a Mesh node) and WARP Client (now called Cloudflare One Client). Existing Gateway policies, Access rules, and device posture checks apply automatically to Mesh traffic.
For developers without Cloudflare One, Mesh is a standalone starting point. Setup takes minutes, and the platform provides room to grow. When you need more, Gateway brings network, DNS, and HTTP policy control. Access for Infrastructure handles SSH and RDP session management. Browser Isolation secures web access, DLP prevents data exfiltration, and CASB covers SaaS security. These capabilities are available on demand—no migration required later.
The three agent workflows that break today
Private networking has always linked clients to resources. What changed is the client population. A year ago, clients were your developers and services. Now they include agents—MCP servers providing tool access, coding agents reading from private repos, and personal assistants on home hardware. When those resources sit in isolated networks, the agent cannot reach them.
This produces three common scenarios that are difficult to secure:
- Accessing a personal agent from mobile. OpenClaw on a Mac mini at home, reachable from a phone or laptop. Public exposure—even with a password—risks shell, file system, and home network access if misconfigured.
- Giving a coding agent staging access. Claude Code, Cursor, or Codex on a laptop needs deployment status, staging database queries, or internal object store reads. Those services live in a private VPC, so tunneling your entire laptop or exposing services is the only current option.
- Connecting deployed agents to private services. Agents built with the Agents SDK on Workers need internal APIs, databases, and non-public services—with scoped permissions, audit trails, and no credential leakage.
One private network for everything
Cloudflare Mesh is developer-friendly private networking built around a single lightweight connector. One binary connects personal devices, remote servers, and user endpoints. Install one connector on your network and every access pattern works.
Once connected, devices in the private network communicate over private IPs, routed through Cloudflare's global network spanning 330+ cities. This gives improved reliability and centralized control compared to direct peer-to-peer connections.
Mesh handles each of the agent scenarios above with a single solution:
- Cloudflare One Client for iOS—connect a phone to the Mac mini running OpenClaw over a Mesh private network.
- Cloudflare One Client for macOS—connect a laptop to the private network so coding agents can reach staging databases and APIs.
- Mesh nodes on Linux servers—connect VPCs across external clouds, giving agents access to resources and MCPs in other private networks.
Because Mesh runs on Cloudflare One Client, every connection gets the platform's security controls. Gateway policies, device posture checks, and DNS filtering apply to agent traffic just as they do to human traffic—with no extra configuration.
Mesh vs. Tunnel: different directions
Tunnel and Mesh both connect external networks privately to Cloudflare, but they solve different problems. Cloudflare Tunnel is for unidirectional traffic, where Cloudflare proxies from the edge to specific private services like a web server or database.
Mesh provides a full bidirectional, many-to-many network. Every device and node on the Mesh can reach any other using private IPs. An application or agent running in your network can discover and access any resource on the Mesh without each resource needing its own Tunnel.
Routing through the edge solves the NAT problem
Mesh networks offer resiliency, scalability, and low latency, but NAT traversal typically breaks them. Most internet devices sit behind Network Address Translation, where direct device-to-device connections fail and traffic falls back to relay servers. When relay infrastructure is sparse, a meaningful portion of traffic hits relays—adding latency and reducing reliability. Self-hosting relays is possible, but that means managing extra infrastructure just to connect your existing network.
Mesh routes all traffic through Cloudflare's global network, the same infrastructure that serves major internet sites. For cross-region or multi-cloud traffic, this consistently beats public internet routing. There is no degraded fallback path because the Cloudflare edge is the primary path.
Routing through Cloudflare also pushes every packet through the platform's security stack. Building Mesh on Cloudflare One means security is not a bolt-on. The core pillars are available from day one:
50 nodes and 50 users free. Your team and staging environment share one private network on every Cloudflare account.
Global edge routing. 330+ cities with optimized backbone routing, no relay servers with limited presence.
Security controls from day one. Gateway policies, DNS filtering, DLP, traffic inspection, and device posture checks run on the same platform. Start with simple connectivity, enable Gateway for traffic filtering, add Access for Infrastructure for session-level SSH and RDP control, and turn on DLP when needed. Each capability is a toggle away.
High availability. A Mesh node with high availability enabled spins up multiple connectors from the same token in active-passive mode. They advertise identical IP routes, so if one fails, traffic fails over automatically.
Workers reach the Mesh through VPC
Mesh handles connectivity across external clouds. For agents built on Workers with the Agents SDK, Workers VPC has been extended to make the entire Mesh network accessible to Workers and Durable Objects.
A single binding's fetch() call can now reach any resource on the Mesh network. This complements Workers VPC's existing Tunnel support and gives developers a choice in how to secure networks. Specify the network in wrangler.jsonc using the cf1:network reserved keyword to bind to the account's Mesh network:
"vpc_networks": [
{ "binding": "MESH", "network_id": "cf1:network", "remote": true },
{ "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]
Then use it inside your Worker or agent code:
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
// Reach any internal host on your Mesh, no pre-registration required
const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");
// Internal hostname resolved via tunnel's private DNS resolver
const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");
return new Response(await apiResponse.text());
},
};
Connecting the Developer Platform to Mesh networks enables Workers with secure access to private databases, internal APIs, and MCPs. That makes cross-cloud agents and MCPs possible, and it opens the door to agents that observe the entire stack end-to-end, cross-reference logs, and suggest optimizations in real time.
The complete picture
Cloudflare Mesh, Workers VPC, and the Agents SDK together form a unified private network for agents that spans both Cloudflare and external clouds. Connectivity and compute are merged so agents reach resources anywhere on the globe securely.
Mesh nodes are your servers, VMs, and containers. They run a headless version of Cloudflare One Client, get a Mesh IP, and exchange service-to-service traffic over private IPs bidirectionally through the edge.
Devices are your laptops and phones running Cloudflare One Client. They reach Mesh nodes directly via SSH, database queries, and API calls over private IPs—giving local coding agents a path to private resources.
Agents on Workers reach private services through Workers VPC Network bindings. They get scoped access to entire networks, mediated by MCP. The network enforces what the agent can reach; the MCP server enforces what the agent can do.
Routing by name, not number
Mesh nodes are currently addressed by their Mesh IPs — ssh 100.64.0.5 works, but it doesn't reflect how you think about infrastructure. Later this year, Mesh DNS will give every node and device that joins a Mesh an automatically routable internal hostname. No DNS configuration or manual records required: add a node named postgres-staging, and postgres-staging.mesh resolves to the right Mesh IP from any device on the Mesh.
Hostname routing is also being extended from Cloudflare Tunnel to Mesh this summer. Mesh nodes will attract traffic for private hostnames like wiki.local or api.staging.internal without you managing IP lists or worrying about edge resolution. Combined with Mesh DNS, this means you'll be able to ssh postgres-staging.mesh or curl http://api-prod.mesh:3000/health without ever handling an IP address directly. For infrastructure with dynamic IPs, auto-scaling groups, or ephemeral containers, that removes an entire class of routing problems.
Identity for every node — and every agent
Today, Mesh nodes authenticate to the Cloudflare edge, but they share a single identity at the network layer. Devices authenticate with user identity via the Cloudflare One Client; nodes don't yet carry distinct routable identities that Gateway policies can differentiate. The roadmap calls for identity-aware routing, where each node, device, and eventually each agent gets a distinct identity that policies can evaluate — so rules are written based on who or what is connecting, not IP ranges.
This becomes critical for AI agents. When an agent running on Workers calls a tool through a VPC binding, the target service sees a Worker making a request — not which agent is calling, who authorized it, or what scope was granted. Similarly, a local coding agent on your laptop reaching a staging service looks like just another request from your device.
The work ahead targets a model where agents carry their own identity through the network:
- Principal / Sponsor: the human who authorized the action (e.g., Nikita from the platform team)
- Agent: the AI system performing it (e.g., the deployment assistant, session #abc123)
- Scope: what the agent is allowed to do (e.g., read deployments, trigger rollbacks, nothing else)
That would enable policies such as: reads from Nikita's agents are allowed, but writes require Nikita directly; agent traffic is filtered independently from human traffic; an agent's network access can be revoked without touching Nikita's. The underlying infrastructure is already in place — Mesh nodes provision with per-node tokens, devices authenticate with per-user identity, and Workers VPC bindings scope per-service access. The missing piece is exposing these identities to the policy layer so Gateway can base routing and access decisions on them.
Mesh for containers and CI/CD
Mesh nodes currently run on VMs and bare-metal Linux servers, but modern workloads increasingly live in Kubernetes pods, Docker Compose stacks, and ephemeral CI/CD runners. A Mesh Docker image is in development to add a node to any containerized environment. You could include a Mesh sidecar in a Docker Compose stack and give every service in that stack private network access — a microservice in a staging cluster could reach a database in a production VPC over Mesh without either service needing a public endpoint.
It also fits CI/CD pipelines that need private access during builds and tests: a GitHub Actions runner pulls the Mesh container image, joins the network, runs integration tests against staging, and tears down. No VPN credentials to manage, no persistent tunnels to maintain — the node disappears when the container exits. The Mesh Docker image is expected later this year.
Try Mesh today
The identity and routing capabilities above are still evolving, but the foundation for secure, unified networking is available now. Mesh is free for up to 50 nodes and 50 users — head to Networking > Mesh in the Cloudflare dashboard to get started.
- Build agents: install the Agents SDK (
npm i agents), follow the Workers VPC quickstart, and build a remote MCP server with private backend access. - Already on Cloudflare One? Mesh works with your existing Gateway policies, device posture checks, and access rules — they apply to Mesh traffic automatically. Check the Mesh documentation to add your first node.
