The agentic network: Secure private connectivity for agents

Hi, everyone. How's everyone doing? You've got your second, third, fourth coffee of the day. There is a macho bar I've heard downstairs. You're all awake because I'm not. You'll have to wake me up. So this will be an interactive session, hopefully. I hate to talk for more than five minutes straight. So please indulge me into some sort of conversation. My name is Nikita. I'm product manager for Cloudflare Tunnel, Cloudflare Mesh, Workers VPC, Cloudflare One Appliance, and so, and so, and so. Who here knows what Cloudflare Mesh is? Raise your hands. Okay, we've got a few hands. Who used Cloudflare Mesh? Okay. In production? Okay. The goal of this session is for you to try Cloudflare Mesh today. Once I step off the stage, I want you all to try, install it, and test it in your environments, because it's a cool product. Who here uses Tailscale? Raise your hands. Okay. Why? If you're using Tailscale, chances are Mesh is going to interest you, especially if you have workloads hosted at Cloudflare, right? If you're using developer platform, if you're already using Cloudflare Tunnel, if you are using WAN, for reasons I do not know, but people are using WAN still, Mesh is going to be an interesting product for you. But the one thing that makes Mesh a very timely product, we launched this in April this year, is because agentic connectivity. And I managed to narrowly avoid saying AI, LLM, or agent in my previous session for 45 minutes. That is not going to happen here. We are going to talk agentic stuff. So I do apologize for that. But if you have AI workloads or agentic workloads, right, the previous authentication model and the previous networking firewall strategy does not really work. If you have a person clicking the buttons, you can show them an authentication screen. You can put it behind Cloudflare access. You can use an IDP. You can mint their identity through some sort of IDP, right? Agent, unless you are creating agents as employees in your HR systems, which I've heard some people do, not sure it's the right approach, but the idea is out there. You are probably not having an agentic identity in your systems. So how do you actually verify which agent that is, who is the owner of that agent, and which permissions, which scopes this agent should have in this particular environment? So the problem of agent identity is a really big problem. If you know Unmink or Kenny Johnson, PM for access, and you are interested in this problem space, go talk to them. They have a really cool solution that's coming later this year. I'm more concerned with what is happening on layer 4. So if you have machine to machine traffic, server initiated traffic, you still may have agentic stuff happening in between those two nodes. You may have an open claw. You need that open claw to access Postgres somewhere else. How do you make sure that this open claw doesn't do dodgy stuff in other parts of your private network, right? That is my biggest concern. So when open claw became a thing, people without asking us or without reading any of our documentation just naturally arrived to the answer that the best thing to protect open claw is Cloudflare tunnel. You put Cloudflare tunnel in front of open claw, you close all of the inbound ports, so now nobody can potentially exercise anything malicious against your private open claw instance. But that only protects your open claw from public Internet. It doesn't protect your private networks from open claw itself, right? So Mesh is a potential answer to these things. So you may have had VPN. That's good for users as long as you deploy per app policies. You may have had jump host, bastion host, you need to SSH into a server machine, into metal, into VM, Kubernetes container, whatever you have. And engines don't play well with VPN because it's all or nothing in most cases. You don't want to expose everything that you have to engines. They are not deterministic. They can hallucinate, as Michelle said on the previous session. So they can be trusted. You probably don't want an engine to try to SSH into your production environment and do something. You don't even want that to access your production database. Like they can just run a delete SQL query and you go and figure out where your backup is for that. Some people are then doing what is called pure Zero Trust, which means expose all of your stuff on public Internet, publish it as public endpoints, and then protect this with Zero Trust policy engine. Engines cannot go behind the paywall, behind the logging page screen, unless you give this some sort of browser rendering capability. And tunnel doesn't help either because tunnel only off ramps traffic. So tunnel does not support server initiated traffic. So if you have machine running open claw, that machine will be protected from public Internet, as I said, but it won't be able to access private network just because you are running open claw there. So we need some sort of different pattern in there, which supports bidirectional connectivity, preferably protocol agnostic, at least for layer 7 protocols, and allows you to exercise policy controls against any type of network traffic that exists in your environments. So we're not going to expose anything publicly. We're not going to hand over the keys to our entire private network, if it's a VPN, to an engine. So what are we going to do? We are going to protect the fastest growing, the scariest scenario that exists in your private networks. So AI agents do stuff. People in your companies ship whatever they want in under three hours. Your security teams are probably horrified because now we need to detect where these apps are and where they are hosted and where our corporate data ends up. And you don't want to have that. So what if the policy control was the network itself? MCP servers is another example of that same problem. MCP server essentially stands between something that is very important in your production environment and something that lives on the Internet or at least in your client endpoint that needs some sort of mediated access so you can trust the identity of the user of the server machine that tries to get into your CICD or runbook in a wiki or internal API, right? So we have three products. They are connectivity products. We actually have more, but to simplify, let's talk about these three. So channel is great when you are exposing public applications to the Internet. It supports layer 7 traffic really well. Use it for HTTP applications and APIs that you need to expose on the public Internet or you need to put them behind Cloudflare access. That is the most elegant and simple solution out there. Cloudflare Mesh is what we are talking about right now. It is a bidirectional connectivity for devices and service containers, VMs. It's a layer -free connector, mask, fully post-quantum encrypted end-to-end. If you attended Sharon's session about post-quantum cryptography yesterday, you know that every single thing that ships in Cloudflare 1 is post-quantum encrypted end -to-end. We are using exactly the same client endpoint agent called Cloudflare 1 client, also previously known as Warp, to power Mesh connectivity, but we extended that Warp CLI to become a subnet router. So not only the device that runs Warp CLI gets access to your private network, it's also everything that lives inside the same private network that can access your other private networks through that Mesh node as a gateway. And if you install Mesh node in your VPC gateway, you don't even need to configure return routes. It will just work. And then Cloudflare 1 is for situations when you need one gig plus throughput or, for example, you need to manage LAN and DHCP in a retail branch, so you need some low-level networking capability that is really not natively available in a layer-free or a layer-seven connector. So that is when you start deploying 1. So everything in your network becomes a Mesh participant. Every single device that runs Cloudflare 1 client or a Mesh node gets a private IP. By the end of this year, every single device that runs in your Cloudflare 1 network will also get a private host name, and you don't need to host DNS for this. This is called Mesh DNS. And they can start a conversation using these IPs in TCP, UDP, ICMP, you name it, without you having to configure a single route. Because Warp CLI creates a virtual network interface on your device that runs Warp CLI and alters your routing table to tunnel traffic for all the routes that exist in Cloudflare 1 without you having to lift a finger. So all the traffic that you want to send to Cloudflare, which probably should be the majority of your traffic, the only exception to this should be stuff that literally lives inside the same container, for example, gets sent to Cloudflare Mesh. And that means that it gets sent to Cloudflare Gateway, which means that all of your network, firewall, DNS, HTTP policies get automatically applied to this traffic without you having to configure anything. If you already have Gateway, the moment you create a Mesh node, that Mesh node is also subjected to all of your Gateway policies. We have shipped selector that allows you to create custom tailored policies that target specifically Mesh nodes. And we have also added extensive locks in network session locks. So now you know which Mesh node send or receive the traffic, which Mesh node and which replica of a Mesh node receive the traffic. And if you are using workers VPC to talk to Mesh nodes, you also get which worker script with name and ID originated this traffic for you. So it is based on Cloudflare One Client, but there are two different applications. So I'm Nikita, I'm going to use my laptop, so I'm going to install Cloudflare One Client because my identity should be of Nikita. If I'm doing Cloudflare Mesh node, it's probably some sort of headless environment that is Linux or container-based. It shouldn't have an identity of a person, it should have a machine identity. So currently, as of today, all Mesh nodes, they have separate IDs, but they share the same identity. So the way for you to configure policies is to use IPs. Very soon, you will be able to give each separate Mesh node its own identity. It targets each Mesh node individually by its name or ID using Gateway policies. And as always with Cloudflare, it's all Terraformable, it's API-first, and we have CFCLI, which you can ask your agent to use to configure all of this in literally under three minutes. Like the other day, I've asked CFCLI to spin up a completely new fresh account with Mesh nodes with log push, pushing my network session logs from Mesh into R2 bucket, and it was all working in under three minutes. It's as easy as that. Cool. So the beauty of Cloudflare 1 is that you don't need to choose in this specific moment which ramp you are going to use. If you are already using Tunnel, raise your hands, who is using Tunnels? Very good. So if you are already using Tunnel, you are probably already having some Gateway policies in there. When you plug in Mesh node in there, the same policies apply. So you can pick and choose which connectivity strategy you want to have, and all of the policies that live in Cloudflare will apply to all of this traffic. So Mesh is best for connectivity between containers, connectivity between clouds, connectivity between developer platform, and whatever on-prem environment you have. It creates your own private network without you having to manage address space or DNS for that environment. So you can connect things that physically live in many different locations, and they will form part of the same Mesh network. The cool thing that we really want to do is we will do Mesh DNS, but I will talk about that in a few minutes. So how do you actually spin this up? It's as easy as you go into Cloudflare dashboard, networking Mesh, you create a new node, add a participant. You get a token generated. For people who use Cloudflare tunnel, you are very familiar with this setup. Mesh gets exactly the same token, hash of your account tag plus secret, and you execute on the Mesh node warp CLI connector new and that token. From that moment onwards, Mesh node gets an IP from CGNet range that is configured in your account, and it can immediately talk to any other nodes from the same CGNet range. What is really cool about Mesh is that workers and developer platform can become part of that private Mesh network too. So you can use workers VPC, and you can tell workers VPC using the binding whether you want to give access to the whole Cloudflare 1 network, so all Mesh nodes or clients, all tunnels to your worker and to egress as well. So for example, if you want to apply gateway policies on egress traffic to public Internet, and you are using workers, you can send traffic from worker to the CF1 network binding, which is the Mesh binding, and your gateway policies will be applied, and this traffic will be locked in your logs. So you can filter egress traffic from your workers, durable objects, and containers using this, which is really cool. We want to do the reverse of that, which is going to be the biggest thing we'll launch next year. So your workers, durable objects, containers will get a private IP and private hostname that is part of the same Mesh network. So this compute feels like it's a local compute to your environments that you host in other clouds, in your on-prem, and you don't need to either host DNS or figure out overlapping IP spaces or how to DHCP this. We are taking care of all of this. So you can have two nodes talking to each other with overlapping IP space, and they will be able to talk to each other without you having to do anything except for installing Mesh nodes in two places. So you have either one VM or one container in AWS, another one in GCP. You add a route, and they can talk to each other. That's it. You can set this up in five minutes. This is entirely private traffic. It does not go on public Internet. All of the traffic between two Mesh nodes transits through Cloudflare Backbone. It's all post -quantum encrypted. It does support high availability. You can have up to five replicas per Mesh node. It's active, passive. And you can attach the whole subnets to the nodes, as well as hostname rounds for both public and private traffic. That supports wildcards. So essentially, you can express policies like, this Mesh node needs support this slash 16, and this Mesh node needs to support this slash 24. And it will just work on all of the devices that are connected to Cloudflare 1, regardless of how you connect. It can be endpoint client, can be one, can be pack files. It works with everything. At the same time, you can say this Mesh node should be an exit node for, for example, google.com. Because for some reason, google.com expects your traffic to come from your IP, that is one IP. You add this hostname route to your Mesh node, and now anyone in your Cloudflare 1 network, when they request google.com, they will go to that node, and the traffic will exit with your IP, not with Cloudflare IP. Gateway egress IPs are also supported. So if you have a requirement that all of your traffic should leave a public Internet on a specific IP that you expect, but you don't want to bring it on Cloudflare network, we can lease you that IP. It will be attached to your Cloudflare 1 account, and Mesh nodes, as all other Cloudflare 1 products, will also guarantee that this traffic leaves on the public Internet using these egress IPs. And it works for workers as well. So if you attach CF1 network binding, and you have egress IP configured in your account, all traffic that's fetched, that comes from a fetch in the worker, will leave Cloudflare and go on public Internet using that egress IP. So it works for everything, pretty much. You can put a private MCP server behind it with access to whatever information, application, storage, compute you have, and you can configure gateway policies, who exactly can access and do what with this application. For example, you can configure a policy that this group of users can have read access to this, this group of users can have write access to this, this group of users doesn't even get to resolve this DNS entry, so they don't even know that this internal application exists in your network. All of this can be expressed with gateway. And because it's a cloud native thing, it also works with whatever containerization solution you use. I strongly recommend using Mesh in a Kubernetes sidecar scenario, because you get to keep your pods and containers as they are. You put sidecar in front of them. Mesh in containers handles source netting, so you don't need to configure return routes for Docker containers. And that way, you can scale horizontally without having to manage IP space in your containers whatsoever. You just think about sidecar as some sort of little concentrator that routes traffic to other ports, and it just works out of box. We have open source the image as well for this. It's in GitHub. It's in Docker Hub as well. So installing it takes probably five, seven minutes, and we have really good developer docs for this. So go try it out. The way we do hostname routing is interesting. I did explain it on the previous session, but just so that it's not a surprise for you. When you attach a hostname route to a Mesh node, we don't know which actual IP is servicing this application until this DNS record resolves. So, for example, you get db .internal. That db.internal is hosted somewhere in your private network, and you have a DNS server for this. So we don't know which IP, for example, 10.0.0.50, is servicing this. So we can't return it back to the agent. What we are doing is we are sending back a token IP, a placeholder IP, from a public Cloudflare own slash 20 range that is then proxying traffic for this specific user, for this specific hostname, to the actual destination of the exit point. And it works beautifully with both private applications and public applications. And you don't need to configure any policies for this token IPs. If you have a gateway policy, either for db.internal or for that IP 10.0.0.50, both will apply. So you get the luxury of configuring nobody can access this host by the IP, but specific user groups can access this application by this hostname, even if you block the IP that is actually listening, that the service listens on. SourceNode works in containers. We will ship SourceNode in probably a month or two for all of the nodes. It will be a flip switch. So anybody understands what SourceNode is? Okay. So when you use Cloudflare tunnel, when packet hits Cloudflared that is host machine, we terminate that session, we clone that packet, and we send it into your private network with the source IP of the host machine that runs Cloudflared. That allows you to avoid configuring a return route for an actual device that sits behind Cloudflared. Because if you don't have that, for example, I come from a different private network. That IP doesn't exist in the network where Cloudflare tunnel is. So the actual device behind the mesh node or behind the Cloudflare tunnel doesn't know how to send traffic back there. SourceNode uses the IP that already exists in that network, and then that packet gets sent to the right sender. So SourceNode works out of box and containers, and you will be able to flip the switch on any mesh node in a few months so that you don't have to configure return routes at the expense of losing in your own logs the real IP of the sender, of course. You will see the real IP of the sender and the real identity of the sender in gateway network session logs, but inside that private network that is SourceNetted, you will see the IP of the host machine. So you'll have to correlate your logs with gateway network session logs to understand who sent this. But for the sake of simplicity, this setup usually works for most customers. The policy plane is exactly the same, and every single feature that works for Cloudflare 1 client for Linux works for mesh out of box. You can even do device posture checks. I don't know why anybody would do device posture checks on server machines, but if that's your thing, go and do this. It works out of box. DLP as well. If your agent tries to send credentials or financial information or something sensitive to public Internet, gateway policy will drop that. So start with connectivity. Just make one mesh node talk to another mesh node. You can do this in under five minutes. You will get the IP that you think. Once you have a successful ping, you know that these two nodes can talk to each other. And then you can explore the full capabilities of Cloudflare 1 and SASE platform and configure exactly which policies, which primitives you want to use to segment your traffic and secure your company or your environment, your CICD. You don't need to do this on day one. The beauty of this is connectivity takes five minutes, and then you can add policies on top of it when the time counts. Network session logs will have the identity, the destination time, and everything else. You will see bytes transferred as well. So there won't be a situation where connectivity is a black box and you don't know how traffic is flowing through Cloudflare. You will see exactly where it entered with which identity and where it exited with which identity, and this is available today. And you can use log push to send this to your scene, data lake, whatever you have. So there are a couple of mistakes. Just keep that in mind. If you are trying to use Cloudflare tunnel as a side gateway or as a concentrator, jump force, bastion, don't do this because it's one direction and tunnel was never supposed to do that job. Even if it can send TCP and UDP, don't do this. Don't forget to configure return routes if you don't want to use source NAT, otherwise devices won't know how to return traffic. Don't confuse routes with replicas. This is interesting one. The concept of replica is kind of unique to Cloudflare tunnel and Cloudflare mesh. Other providers allow you, and our one as well, allow you to put a priority weight and a region on a route. So your routing table is not deterministic. It is dynamically evaluated and picks the healthy nodes, right? We do the reverse. Your route is always deterministic. If you attach 10.10.10.10 to one mesh node, it doesn't matter whether that mesh node is online or offline. So how do you make it highly available? You spin up multiple replicas of that mesh node, which serves exactly the same tunnel essentially, and that is how you make it highly available. Don't look for priorities and weights and regions for a mesh. Think about this as replicas. Replicas are ephemeral. They are clones of your tunnel or of your mesh node, and you use routes to configure how traffic flows there. Split tunnel is a feature that allows you to configure which traffic should stay in your network and use your default networking interface, and which traffic should go through Cloudflare. This is very useful if you have other applications that live inside the same container or inside the same network that you don't want to flow through Cloudflare. Our network is 50 milliseconds away max from anything, but in some situations, if the same application lives on the same server, why would you send it all the way back if this is privileged access that you have already granted, right? So you can exercise this. And then CF1 network binding is the easiest way to grant access to your entire private network, to your worker, durable object, and by extension container. Ask yourself a question. Do I trust people who have access to deploy workers in my account to have access to all applications? You can configure gateway policies to say that this worker or default binding cannot reach that segment of your network, but Zero Trust should be by default, right? Deny by default and only allow what you need to allow. So be very careful with the binding that just opens your whole network up. It takes five minutes to build. Go try it out. Documentation is all there, and we give 50 seats and 50 nodes for free to everyone. When the time comes, it's currently in beta. When we go GA, there will be some sort of usage-based billing, but we will give terabytes or more of free traffic to everyone monthly so you can keep using it for free. That's it. Any questions?