In this roundtable episode of the Hedge, Eyvonne, Tom, and Russ hang out and talk about data centers–why are we building all these things again? Our second topic is the FCC’s ban on non-US made home routers. Was this the right thing to do? Was it the wrong thing to do? Were there any other policy options?
download
Organisations are re-evaluating their VM infrastructure. The economics have shifted, the tooling has matured, and the case for running two separate platforms, one for containers, one for VMs, is getting harder to justify. Platform teams that spent years managing hypervisor infrastructure are being asked to consolidate, and most are landing on the same answer: Kubernetes.
KubeVirt makes running VMs on Kubernetes possible. But KubeVirt networking – what happens to a VM’s IP address, VLAN, and security posture when it lands in a cluster – is where most migration plans hit a wall. The reasons go beyond cost:
The decision to migrate is being made. The question is how to do it without causing chaos.
KubeVirt extends the Kubernetes API with new custom resource Continue reading
We are at the tail end of our multicast series. So far, we have covered multicast basics, IGMP, PIM Dense Mode, PIM Sparse Mode, and Auto-RP. In this post, we will look at Bootstrap Router, or BSR.
Suresh Vinasiththamby
In the previous post, we looked at Auto-RP, which is Cisco's proprietary method for dynamically distributing RP information to all routers in the network. BSR solves the same problem but is defined in the PIM standards (RFC 5059), making it vendor-neutral and interoperable across different platforms. The core idea is the same. Instead of manually configuring the RP address on every router, BSR allows routers to learn RP information automatically. A router called the Bootstrap Router collects RP information from Candidate RPs and distributes it to all PIM routers in the network.
The key difference is in how this information flows. With Auto-RP, the Mapping Agent sends RP mappings to the specific multicast group 224.0.1.40. This creates the chicken-and-egg problem we discussed in the previous post Continue reading
What does biology have to do with computer networks? Much more than you might think. Communications systems, after all, need to solve the same problems–and they often use the same kinds of tools. In this episode of the Hedge, Emily Reeves and Joe Deweese join Russ and Tom to talk about a recent paper comparing computer communications to biological communications.
download
Why accountability, not capability, is the real bottleneck for enterprise agentic AI, and what security leaders need to do about it before regulators force the issue.
Every enterprise is building AI agents. Marketing has one summarizing campaign performance. Engineering has one triaging incidents. Customer support has one resolving tickets. Finance has one processing invoices. And increasingly, those agents are talking to each other: calling tools, accessing databases, delegating tasks across complex multi-hop chains.
But here’s the question nobody wants to hear at 3 a.m. when something goes wrong: who authorized that action, what policy permitted it, and what’s the full chain of events?
For most enterprises, the honest answer is: nobody knows. That’s not a governance problem — it’s an AI agent accountability crisis.
The data paints a stark picture. McKinsey research found that 80% of organizations have already encountered risky behavior from AI agents. These actions were unintended, unauthorized, or outside acceptable guardrails. Yet only about one-third of organizations report meaningful governance maturity. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls.
This Continue reading
Kubernetes adoption is no longer the challenge it once was. More than 82% of enterprises run containers in production, most of them on multiple Kubernetes clusters. Adoption, however, does not mean operational maturity. These are two very different things. It is one thing to deploy workloads to a cluster or two and quite another to do it securely, efficiently and at scale.
This distinction matters because the gap between adoption and Kubernetes operational maturity is where risk accumulates. Operationally mature organizations ship faster, recover from incidents in minutes instead of hours and consistently pass compliance audits. They spend less time dealing with outages and more time delivering new services to their customers.
So what separates maturity from adoption? It comes down to a handful of foundational capabilities that, when done well, result in measurable business impact. Operational maturity — the ability to run Kubernetes workloads securely, efficiently, and at scale, with consistent policy enforcement, cross-cluster observability, and automated incident recovery — is not a destination; it is a continuous process of strengthening the architectural pillars that keep your Kubernetes environment production-ready.
Operational maturity spans several interconnected areas from Kubernetes security best practices to observability Continue reading
If you are treating Large Language Models (LLMs) like simple question-and-answer machines, you are leaving their most transformative potential on the table. The industry has officially shifted from zero-shot prompting to structured AI agent design patterns and agentic workflows where AI iteratively reasons, uses external tools, and collaborates to solve complex engineering problems. These design patterns are the architectural blueprints that determine how autonomous Agentic AI systems work and interact with your infrastructure.
But as these systems proliferate faster than organizations can govern them, they introduce a critical AI agent security risk: By the end of 2026, 40% of enterprise applications will feature embedded AI agents, and those teams will urgently need purpose-built strategies to govern this new autonomous workforce before it becomes the next major shadow IT crisis.
Before you can secure these autonomous systems, you have to understand how they are built. Here is a technical breakdown of the current AI Agent design patterns you need to know, and the specific security blind spots each design pattern creates.
Building reliable AI systems comes down to how you route the cognitive load. Here are the three baseline structural patterns:
Cloudflare has a vast API surface. We have over 100 products, and nearly 3,000 HTTP API operations.
Increasingly, agents are the primary customer of our APIs. Developers bring their coding agents to build and deploy applications, agents, and platforms to Cloudflare, configure their account, and query our APIs for analytics and logs.
We want to make every Cloudflare product available in all of the ways agents need. For example, we now make Cloudflare’s entire API available in a single Code Mode MCP server that uses less than 1,000 tokens. There’s a lot more surface area to cover, though: CLI commands. Workers Bindings — including APIs for local development and testing. SDKs across multiple languages. Our configuration file. Terraform. Developer docs. API docs and OpenAPI schemas. Agent Skills.
Today, many of our products aren’t available across every one of these interfaces. This is particularly true of our CLI — Wrangler. Many Cloudflare products have no CLI commands in Wrangler. And agents love CLIs.
So we’ve been rebuilding Wrangler CLI, to make it the CLI for all of Cloudflare. It provides commands for all Cloudflare products, and lets you configure them together using infrastructure-as-code.
Today we’re sharing an early version of Continue reading
When we launched Cloudflare Sandboxes last June, the premise was simple: AI agents need to develop and run code, and they need to do it somewhere safe.
If an agent is acting like a developer, this means cloning repositories, building code in many languages, running development servers, etc. To do these things effectively, they will often need a full computer (and if they don’t, they can reach for something lightweight!).
Many developers are stitching together solutions using VMs or existing container solutions, but there are lots of hard problems to solve:
Burstiness - With each session needing its own sandbox, you often need to spin up many sandboxes quickly, but you don’t want to pay for idle compute on standby.
Quick state restoration - Each session should start quickly and re-start quickly, resuming past state.
Security - Agents need to access services securely, but can’t be trusted with credentials.
Control - It needs to be simple to programmatically control sandbox lifecycle, execute commands, handle files, and more.
Ergonomics - You need to give a simple interface for both humans and agents to do common operations.
We’ve spent time solving these issues so you don’t have to. Since our initial Continue reading
A few weeks ago, we announced Dynamic Workers, a new feature of the Workers platform which lets you load Worker code on-the-fly into a secure sandbox. The Dynamic Worker Loader API essentially provides direct access to the basic compute isolation primitive that Workers has been based on all along: isolates, not containers. Isolates are much lighter-weight than containers, and as such, can load 100x faster using 1/10 the memory. They are so efficient, they can be treated as "disposable": start one up to run a few lines of code, then throw it away. Like a secure version of eval().
Dynamic Workers have many uses. In the original announcement, we focused on how to use them to run AI-agent-generated code as an alternative to tool calls. In this use case, an AI agent performs actions at the request of a user by writing a few lines of code and executing them. The code is single-use, intended to perform one task one time, and is thrown away immediately after it executes.
But what if you want an AI to generate more persistent code? What if you want your AI to build a small application with a custom UI the user can Continue reading
As AI Large Language Models and harnesses like OpenCode and Claude Code become increasingly capable, we see more users kicking off sandboxed agents in response to chat messages, Kanban updates, vibe coding UIs, terminal sessions, GitHub comments, and more.
The sandbox is an important step beyond simple containers, because it gives you a few things:
Security: Any untrusted end user (or a rogue LLM) can run in the sandbox and not compromise the host machine or other sandboxes running alongside it. This is traditionally (but not always) accomplished with a microVM.
Speed: An end user should be able to pick up a new sandbox quickly and restore the state from a previously used one quickly.
Control: The trusted platform needs to be able to take actions within the untrusted domain of the sandbox. This might mean mounting files in the sandbox, or controlling which requests access it, or executing specific commands.
Today, we’re excited to add another key component of control to our Sandboxes and all Containers: outbound Workers. These are programmatic egress proxies that allow users running sandboxes to easily connect to different services, add observability, and, importantly for agents, add flexible Continue reading
If you work with Juniper hardware and have never used the Juniper Port Checker, you are missing out on a really useful tool. It is part of the Juniper Pathfinder suite and it gives you a visual representation of the front panel of a device and lets you configure port speeds to validate that your...
The post Juniper Port Checker – Validate Port Speed Mappings Before You Deploy first appeared on Fryguy's Blog.I have been meaning to put together some network tools for a while now, and I finally got around to it. I added a new Network Tools section to the site with eight tools that I find myself needing on a regular basis. They all run in the browser – nothing gets sent to a...
The post New Network Tools Section first appeared on Fryguy's Blog.Cloudflare's mission has always been to help build a better Internet. Sometimes that means building for the Internet as it exists. Sometimes it means building for the Internet as it's about to become.
Today, we're kicking off Agents Week, dedicated to building the Internet for what comes next.
The cloud, as we know it, was a product of the last major technological paradigm shift: smartphones.
When smartphones put the Internet in everyone's pocket, they didn't just add users — they changed the nature of what it meant to be online. Always connected, always expecting an instant response. Applications had to handle an order of magnitude more users, and the infrastructure powering them had to evolve.
The approach the industry converged on was straightforward: more users, more copies of your application. As applications grew in complexity, teams broke them into smaller pieces — microservices — so each team could control its own destiny. But the core principle stayed the same: a finite number of applications, each serving many users. Scale meant more copies.
Kubernetes and containers became the default. They made it easy to spin up instances, Continue reading
Even though UniFi released the UTR (UniFi Travel Router) a while back, I've been researching it and trying to find a use case for myself. Fast forward to today, and even though I still don't have a clear use case for it, I bought it purely based on vibes.
It was out of stock pretty much all the time in the UK store, and even when it came back in stock, it would sell out within minutes. I happened to be checking their site one day and noticed it was available, so I ordered it right away. It costs £90 including delivery.
The UTR is a small (like very tiny), portable router that you can take anywhere with you. It fits in your pocket. It supports both 2.4GHz and 5GHz bands and can connect to an upstream network via Wi-Fi or Ethernet. If you are into the UniFi ecosystem, in a nutshell, it can extend your home network wherever you go.
It is a small device, measuring 95.95 x 65 x 12.5 mm and weighing just 89g, so it genuinely fits in your pocket. It runs WiFi 5 with 2x2 MIMO Continue reading
I’ve previously blogged about RustRadio, my GNU Radio like framework for writing software defined radio applications in Rust. And now there’s more progress of an interesting kind.
Anything that tries to do something similar to GNU Radio needs a few things:
In addition to these, GNU Radio also has the excellent GNU Radio Companion for interactive creation of flowgraphs, but I’m not tackling that yet.
I have a core framework, and some components (blocks). But the UI has been a bit lacking.
I’ve played around with TUI applications, but I always knew I also wanted to support having a UI in the browser. I’m not as interested in adding support for QT or Windows native UI. The browser will do fine.
There are two ways to get the UI in the browser:
While I’ll want (1) eventually, and have some ideas about that, this post is about running everything in the browser, using Wasm.
I know that this is just scratching the surface Continue reading