We’re constantly building for the different goals of our customers. Some customers want to optimize for discovery, while others want to protect their content with the strictest security policy. Among these differing policies, there are multiple ways to mitigate bot traffic. Some mechanisms simply state your preference, assuming best intent from crawlers, and other approaches actually lock down content by outright blocking with a Bot Management solution.
We recognize that it's cumbersome to maintain multiple layers of protection on your website. For example, there are cases in which your robots.txt states that a crawler is Disallowed from accessing your website, while your enforcement rules actually don’t block that crawler. When your stated preferences and your enforced rules disagree, some crawlers treat it as a basis to disregard your preferences or try to bypass your enforced rules.
A couple of years ago, Cloudflare announced an easier way to disallow AI training on your website by tackling two of these layers: a managed value of robots.txt that told a fixed list of major Training crawlers not to train on your content, along with edge-enforced blocks to Training crawlers. On July 1, 2026, we launched easier options to manage different kinds Continue reading
Since June, developers have created thousands of third-party OAuth apps on Cloudflare, with more than a million authorizations since.
OAuth makes delegated access possible. It lets applications act on a user’s behalf without asking them to handle long-lived credentials or hand over a password. That model works well when an application can describe its access needs with a small set of scopes.
Developers use OAuth for SaaS integrations, internal tools, CLIs, and agents. Our permission model has become more granular over time to support better scoping of these different workflows. That is great for security, but it makes a purely all-or-nothing consent screen hard to justify.
Cloudflare OAuth already allows clients to request a subset of their configured scopes. But once the client made that request, the user could not narrow it any further on the consent screen. For the user on the consent screen, the experience was still an all-or-nothing one. If an application requested more access than a user was comfortable granting, their only options were to approve the full request, or deny outright.
MCP servers are a good example of this. An MCP server might request a broad set of permissions, because in Continue reading
Deploying AI for AI Ops, or even just for general use in your network, is very simple–but we often forget that these kinds of new technologies need to be governed. From privacy through cost, operators need to decide how to govern their AI deployments to control costs, ensure accuracy, measure productivity, and make certain these systems are being used effectively. Colin Cosgrove joins Russ and Tom to look at AI governance.
download
Tony Mattke continues publishing excellent “Git for Networking Engineers” content. In his latest article, he described how to find who made what changes (and why) in a Git repository.
Absolutely worth reading if you’re new to Git, but even oldtimers might find a few useful tidbits (Git is one of those things one never truly masters).
In 2021, we assessed remote Spectre attacks against Cloudflare Workers. Based on the results, we shipped a production defense called Dynamic Process Isolation (DyPrIs), which identifies maliciously looking scripts and isolates them into separate processes. Since then, newer techniques in the area of stabilizing Spectre attacks have been discovered. To understand if these techniques posed a threat to our Workers production environment, we decided to internally reassess the remote Spectre attack. Building an updated proof-of-concept on the production environment allowed us to empirically assess the risk of Spectre attacks under production workloads.
To mount a successful side-channel attack in production, an external attacker has to overcome additional obstacles such as activity on shared hardware resources, interrupts, context switches, and coarse-grained timers. Our research uncovered a limitation in the implementation of DyPrIs and we managed to demonstrate a remote Spectre attack reliably leaking up to 12 bit/s with a 99% accuracy in the production environment of Cloudflare Workers. As a consequence of this research, we improved DyPrIs, integrated the V8 Sandbox and an in-process isolation mechanism to further reduce the risk of memory disclosure attacks.
Today we are publishing a paper describing our findings, co-authored by Albert Pedersen, Haocheng Continue reading
New on the Network Tools page: a VLAN / QinQ Tag Overhead Calculator. It exists because of the same problem that led to the MTU / Encapsulation Overhead Calculator — vendors don’t agree on what a config knob actually means, and it costs you an afternoon before you find that out.
The MTU tool exists because mtu isn’t the same number on every platform. Classic Cisco IOS treats it as the L3 payload size. Junos and IOS-XR fold the 14-byte Ethernet header into it. Same command, same-looking number, two different frames on the wire — and the failure mode is never an error message, it’s just silent fragmentation or a black-holed jumbo-frame flow that only shows up under load.
A lot of AI-coding enthusiasts are making claims along the lines of “AI coding tools are like compilers; you supply intent, they translate it into code, and who ever looked at the machine-code output?” Unfortunately, there is a bit of a gap between hope and reality; traditional compilers were always deterministic, and are (after decades of development and bug-fixing) pretty much bug-free. AI coding tools are neither, and no amount of “agentic loops” will solve that.
Route leaks push traffic down paths it was never meant to take. We have written and spoken publicly in the past about route leaks in Border Gateway Protocol (BGP), depicting these events as impactful incidents that cause misdirection of traffic through unintended network paths. BGP routing is driven by the relationships between Autonomous Systems (ASes), i.e., customer-provider and peer-peer. Customers pay providers for access to the rest of the Internet, while peers exchange traffic with one another typically under a “settlement-free” arrangement where no money changes hands. These relationships help define routing rules that form plausible paths. For example, the rules form a “valley-free” hierarchy of how routes should propagate: a route learned from a provider or a peer should be announced only downward to customers, never back up to another provider or peer. Rules like this express an intent or expectation about Internet routes. A route leak is what happens when that intent is violated.
Historically, each network has had to implement this intent on its own, using complex, error-prone routing policies. RFC 9234 (Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages) simplifies this by expressing intent within the protocol Continue reading