cloudflare·Apr 14, 2026·3 min readCurated summary

Secure private networking for everyone: users, nodes, agents, Workers — introducing Cloudflare Mesh

Cloudflare introduces Mesh as a private networking layer designed for humans, services, and autonomous AI agents. It connects devices, servers, cloud VPCs, Workers, Durable Objects, and Agents SDK applications without exposing private services publicly or relying on manual VPN and SSH workflows. Mesh builds on Cloudflare One, so existing Gateway policies, Access rules, device posture checks, and other Zero Trust controls apply automatically. ## Why Agent Workloads Need Private Networking - AI agents increasingly need access to private databases, APIs, repositories, MCP servers, object stores, and home infrastructure. - Traditional solutions are poorly suited to autonomous software: - VPNs often require interactive login. - SSH tunnels require manual setup. - Public exposure increases the risk of unauthorized access. - Basic connectivity does not provide sufficient visibility into agent activity. - Agents may have powerful permissions, including shell, filesystem, and network access, making misconfiguration especially dangerous. ## New Agentic Workflows - **Accessing personal agents remotely** - A user can run an agent such as OpenClaw on a home Mac mini. - Phones, laptops, and work devices can connect securely without exposing the agent directly to the public Internet. - **Letting coding agents access staging systems** - Agents such as Claude Code, Cursor, or Codex can reach private staging databases, analytics systems, APIs, and object stores. - Developers avoid exposing those systems or tunneling an entire laptop into a cloud VPC. - **Connecting deployed agents to private services** - Agents running on Cloudflare Workers can call internal APIs and databases. - Mesh is intended to provide scoped access, auditability, and reduced credential exposure. ## How Cloudflare Mesh Works - Mesh uses a lightweight connector and a single binary to connect: - Personal devices - Remote servers - User endpoints - Private cloud networks - Connected devices communicate over private IPs through Cloudflare’s global network, which spans more than 330 cities. - Cloudflare’s existing terminology is simplified: - WARP Connector becomes a **Cloudflare Mesh node**. - WARP Client becomes the **Cloudflare One Client**. - Example deployments include: - Connecting an iPhone to a home Mac mini running an agent. - Connecting a developer laptop to staging databases and internal APIs. - Connecting Linux servers and external cloud VPCs so agents can reach private resources and MCP servers. ## Security and Cloudflare One Integration - Mesh traffic automatically inherits Cloudflare One protections, including: - Gateway network, DNS, and HTTP policies - Device posture checks - DNS filtering - Access rules - Existing Cloudflare One customers can use Mesh without adopting a separate security platform. - Organizations can later expand into: - Access for Infrastructure for SSH and RDP management - Browser Isolation - Data Loss Prevention - Cloud Access Security Broker capabilities - The goal is to protect agent traffic with the same controls already used for human users and services. Cloudflare Mesh is positioned as a practical starting point for securely connecting agents to private infrastructure. Teams can begin with simple private networking and later add more advanced Zero Trust controls without migrating to a different platform.

Read original(opens in new tab)

PostgreSQLSaseAgents SdkSsh+4

cloudflare·Apr 13, 2026·3 min readCurated summary

Building a CLI for all of Cloudflare

Cloudflare is rebuilding Wrangler into a unified CLI for its entire platform, motivated by the growing role of coding agents in configuring and deploying Cloudflare applications. The technical preview, available as `npx cf` or the globally installed `cf` package, currently covers only a subset of products but is intended to support the full API surface. The effort depends on a new TypeScript-based schema system that can generate consistent commands, configuration, bindings, documentation, and agent-oriented interfaces. ## A CLI for all of Cloudflare - Cloudflare offers more than 100 products and nearly 3,000 HTTP API operations. - Agents increasingly use Cloudflare APIs to: - Build and deploy applications - Configure accounts - Query analytics and logs - Create agents and platforms - Cloudflare aims to expose its products consistently through: - CLI commands - Workers Bindings - SDKs - Configuration files - Terraform - Documentation and OpenAPI schemas - MCP servers and Agent Skills - The new Wrangler technical preview can be tried with: - `npx cf` - `npm install -g cf` - A broader internal version already supports the full Cloudflare API, with ongoing work to make command output useful for both humans and agents. ## A new schema and code-generation pipeline - Existing OpenAPI schemas already generate: - Cloudflare SDKs - The Terraform provider - The Code Mode MCP server - Other interfaces, including Wrangler commands, Workers Bindings, configuration, documentation, and Agent Skills, were previously maintained manually. - Manual synchronization was error-prone and could not scale to Cloudflare’s full product range. - OpenAPI alone is insufficient because it primarily describes REST APIs, while Cloudflare also needs to represent: - Interactive CLI workflows - Multiple local and remote actions - RPC-style Workers Bindings - Agent Skills and related documentation - Cloudflare therefore created a TypeScript schema format containing: - API definitions - CLI commands and arguments - Context required to generate different interfaces - Conventions, linting, and guardrails enforce consistency while allowing the schema to generate OpenAPI and future interfaces. ## Consistency for agents and humans - Agents depend on predictable command names and flags. Inconsistent syntax can cause them to call commands that do not exist. - Cloudflare is enforcing conventions at the schema layer, including: - `get`, never `info` - `--force`, never `--skip-confirmations` - `--json`, never `--format` - Applying these rules across interfaces avoids discrepancies between the CLI, REST APIs, and SDKs. - Wrangler must also clearly distinguish local and remote resources. - This is especially important for D1, R2, and KV, where local simulation and remote bindings can coexist. - Clear defaults and output indicating whether an operation targets local or remote resources help agents avoid modifying the wrong environment. ## Local Explorer for simulated resources - Local Explorer is available in open beta through Wrangler and the Cloudflare Vite plugin. - It lets developers inspect locally simulated: - KV - R2 - D1 - Durable Objects - Workflows - Local resources use the same underlying API structure as Cloudflare’s remote APIs and Dashboard. - Cloudflare’s local development environment runs Workers APIs locally, including D1 backed by SQLite through Miniflare. - Previously, developers had to inspect `.wrangler/state` or use third-party tools to understand local data. - Local Explorer provides an interface showing: - Which bindings are attached to a Worker - What data those bindings contain - It can be opened with the `e` keyboard shortcut and helps developers or agents verify schemas, seed test data, and reset local databases. Cloudflare’s direction is to make Wrangler a consistent, machine-readable interface to the entire platform. The technical preview is early, but the new schema-driven system and Local Explorer establish the foundation for a CLI that is easier for both developers and coding agents to use safely.

Read original(opens in new tab)

Database DesignCloudflareTypeScriptTerraform+4

cloudflare·Apr 13, 2026·3 min readCurated summary

Durable Objects in Dynamic Workers: Give each AI-generated app its own database

Dynamic Workers make it possible to run AI-generated code securely in lightweight isolates, but disposable execution is not enough for persistent applications. Cloudflare’s Durable Object Facets address this by letting a supervised Durable Object dynamically load an AI-generated Durable Object class with its own SQLite-backed storage. This combines sandboxed, persistent application state with centralized control over provisioning, access, logging, metrics, and billing. ## From Disposable Code to Persistent Apps - Dynamic Workers load code on demand in secure isolates rather than containers. - Isolates start quickly and use little memory, making them suitable for short-lived AI-generated tasks. - Persistent AI-built applications need: - Custom user interfaces - Long-lived state - Secure execution - A remote SQL database could provide storage, but it introduces network latency and additional infrastructure. ## Why Durable Objects Fit - Each Durable Object has: - A globally unique name - One active instance per name - An attached SQLite database stored locally - Local SQLite storage provides extremely low-latency access. - AI-generated applications can therefore use normal Durable Object storage APIs, including key-value and SQL storage. ## Limitations of the Traditional Model - Standard Durable Objects require: - A class extending `DurableObject` - Exporting the class from the Worker - Wrangler configuration to provision storage - A namespace binding for access - This model does not naturally support code loaded dynamically at runtime. - Giving an agent direct control of Durable Object namespaces could also allow uncontrolled object creation and storage use. - A platform needs an intermediary to enforce limits and provide observability, billing, and other operational controls. ## Durable Object Facets - Facets allow a normal, statically configured Durable Object to dynamically instantiate another Durable Object class. - The outer object acts as a supervisor: - Loads the agent’s code as a Dynamic Worker - Selects the exported Durable Object class - Forwards requests or RPC calls - Controls and monitors the application - The dynamically loaded class can directly extend `DurableObject`. - Each facet receives its own SQLite database, separate from the supervisor’s database. - Multiple facets can exist within one Durable Object, each identified by a name and subject to storage limits. ## Example Architecture - An `AppRunner` Durable Object receives incoming requests. - It obtains a facet named `"app"` through `this.ctx.facets.get(...)`. - When the facet starts, the runner: - Loads the Dynamic Worker - Retrieves its exported application class - Instantiates it as the facet - Requests are then forwarded to the dynamically loaded application. - The sample application maintains a request counter using Durable Object storage. Durable Object Facets provide a practical foundation for AI-generated applications that need persistent state without sacrificing isolation or platform governance. They are especially suited to personal or small “vibe-coded” apps, where each application can receive its own storage while the host platform retains control over resource usage and operational policies.

Read original(opens in new tab)

Database DesignCloudflarePostgreSQLDurable Objects+3

cloudflare·Apr 13, 2026·3 min readCurated summary

Agents have their own computers with Sandboxes GA

Cloudflare has made Sandboxes and Cloudflare Containers generally available for running AI agents in persistent, isolated computer environments. The platform addresses the operational challenges of agent workloads—including bursty demand, fast state restoration, secure authentication, lifecycle control, and developer-friendly tooling. Recent additions make Sandboxes more capable for coding agents while reducing the cost of running them at scale. ## Why Agents Need Full Computers - Coding agents often need to clone repositories, build software, run development servers, and work across multiple languages. - Existing VM and container approaches must handle: - Rapidly creating many session-specific environments without paying for idle capacity. - Quickly restoring previous session state. - Giving agents access to services without exposing credentials. - Programmatic control over commands, files, and sandbox lifecycles. - Simple interfaces for both human developers and agents. - Figma is using Cloudflare Containers to run untrusted agent- and user-authored code for Figma Make. ## Sandboxes 101 - A Sandbox is a persistent, isolated environment powered by Cloudflare Containers. - Sandboxes are addressed by name: - Running sandboxes are reused. - Inactive sandboxes sleep automatically. - Requests wake sleeping sandboxes on demand. - The same sandbox can be accessed from anywhere using its ID. - The API supports operations such as: - `exec` for running commands. - `gitCheckout` or `gitClone` for retrieving repositories. - `writeFile` for managing files. - Command output can be streamed in real time, such as when running `npm test`. ## Secure Credential Injection - Agents may need to call private services but should not receive raw credentials. - Sandboxes inject credentials at the network layer through a programmable egress proxy. - Custom outbound rules can add authentication headers to requests based on the destination host. - This allows authenticated access while keeping secrets outside the agent’s environment. - Authentication logic can be customized for identity-aware access, dynamic rules, and Workers bindings. ## Real Terminal Access with PTY - Early agent interfaces treated shell commands as isolated request-response operations. - PTY support provides a more realistic terminal experience: - Output streams continuously. - Processes can be interrupted. - Sessions can be reconnected later. - Sandbox terminal sessions are proxied over WebSockets and are compatible with `xterm.js`. - Applications can expose the backend through `sandbox.terminal`. ## Features for Agent Development - **Persistent code interpreters:** Stateful Python, JavaScript, and TypeScript execution is available out of the box. - **Background processes:** Development servers and other long-running commands can continue running independently. - **Live preview URLs:** Agents and users can inspect development servers and verify changes while they are in progress. - **Filesystem watching:** Faster feedback as agents modify files. - **Snapshots:** Coding sessions can be quickly recovered from saved state. - **Higher limits and Active CPU Pricing:** Fleets of agents can scale without paying for unused CPU cycles. Cloudflare’s GA release positions Sandboxes as a managed environment for agent-driven software development: persistent when state matters, isolated when code is untrusted, and cost-efficient when workloads are intermittent.

Read original(opens in new tab)

Docker & ContainersAuthenticationCloudflare SandboxesAgent Systems+4

cloudflare·Apr 13, 2026·4 min readCurated summary

Dynamic, identity-aware, and secure Sandbox auth

Sandboxes for AI agents need more than isolation: they also require fast startup, platform control, and safe access to external services. The post introduces outbound Workers, programmable egress proxies that intercept sandbox traffic and can authenticate, restrict, modify, log, or cancel requests. This approach combines zero-trust security with identity-aware, flexible, observable, and dynamic authorization without exposing secrets to untrusted agents. ## Sandbox Requirements Sandboxes provide three core benefits: - **Security:** Untrusted users or agents can run code without compromising the host or neighboring sandboxes, often through microVM isolation. - **Speed:** Users can quickly start new sandboxes and restore existing state. - **Control:** The trusted platform can mount files, execute commands, and control network access inside the sandbox. Outbound Workers add network-level control to this model by acting as programmatic egress proxies for Sandboxes and Containers. ## How Outbound Workers Work - A sandbox can define handlers for all outbound requests or for requests to specific hosts. - For example, requests to `github.com` can be intercepted through `static outboundByHost`. - The handler can: - Add authentication headers. - Log requests. - Modify request data. - Reject or cancel requests. - Secrets remain outside the sandbox and can be accessed by the Worker through its environment. - Workers run near the sandbox, can access distributed state, and can be updated using ordinary JavaScript. A sample handler copies the request headers and injects `x-auth-token` from `env.SECRET` before forwarding the request. ## Challenges with Existing Agent Authentication Agent workloads cannot be fully trusted, even when the underlying language model is not intentionally malicious. Credentials must therefore limit accidental misuse and prevent data exfiltration. ### Standard API Tokens - Tokens are commonly passed through environment variables or mounted secret files. - They are simple to implement but expose credentials to the sandboxed workload. - A compromised or misbehaving agent could leak the token. - Expiration and rotation are required, creating operational overhead. ### Workload Identity Tokens - Systems such as OIDC provide an identity assertion rather than a general-purpose service token. - The agent can exchange the identity token for a short-lived access token. - Tokens can be invalidated when a workflow ends, simplifying expiration. - The drawback is limited upstream support: many services do not natively accept OIDC, forcing platforms to build custom token-exchange services. ### Custom Proxies - Proxies provide maximum control and can enforce granular permissions even when an upstream service has weak RBAC. - They can be combined with workload identity tokens. - However, intercepting all sandbox traffic and building an efficient, dynamic, programmable proxy is difficult. ## Characteristics of an Ideal Agent Auth System The post argues that agent authentication should be: - **Zero trust:** Never expose a reusable token to an untrusted workload. - **Simple:** Avoid complicated token minting, rotation, and decryption systems. - **Flexible:** Enforce permissions independently of the upstream service. - **Identity-aware:** Apply rules based on which sandbox is making the request. - **Observable:** Record and inspect outbound calls. - **Performant:** Avoid slow, centralized authorization round trips. - **Transparent:** Require no changes to the sandboxed application. - **Dynamic:** Allow authorization rules to change while systems are running. Outbound Workers are presented as a way to satisfy all of these requirements. ## Restriction and Observability A basic outbound handler can enforce network policy with only a few lines of JavaScript: - Inspect each outgoing HTTP request. - Log requests using disallowed methods. - Return a `405 Method Not Allowed` response for anything other than `GET`. - Forward permitted requests with `fetch(req)`. This demonstrates that outbound Workers can enforce restrictions and provide observability without modifying the application running inside the sandbox. ## Practical Recommendation Use outbound Workers as a trusted egress layer for agent sandboxes. Keep sensitive credentials outside the workload, inject or exchange them only at the proxy, and use the Worker to enforce identity-specific policies, logging, and request restrictions dynamically.

Read original(opens in new tab)

JavaScriptZero TrustAuthenticationHttp Requests+4

cloudflare·Apr 12, 2026·3 min readCurated summary

Welcome to Agents Week

Cloudflare argues that AI agents require a fundamental shift in Internet and cloud infrastructure. Unlike traditional one-to-many applications, agents create unique, ephemeral execution environments for individual users and tasks, making current container-based economics and scaling inadequate. The company positions lightweight V8 isolates, alongside containers and browser support, as the foundation for making agents practical at global scale. ## The Internet Was Built for Applications, Not Agents - Cloud infrastructure evolved during the smartphone era to serve many users through a finite number of application instances. - Microservices, containers, Kubernetes, load balancing, and replication all support this one-to-many model. - Agents differ because an LLM dynamically determines code paths, tool usage, and task duration. ## One User, One Agent, One Task - Each agent may need its own execution environment, filesystem, tools, and state. - Coding agents currently use containers with access to Git, Bash, filesystems, and arbitrary binaries. - As agents spread to assistants, analysts, customer service, and planning tasks, the number of simultaneous environments could grow dramatically. ## The Scale Challenge - If 100 million US knowledge workers used agents at 15% concurrency, infrastructure would need about 24 million simultaneous sessions. - At 25–50 users per CPU, that implies roughly 500,000 to 1 million server CPUs in the US alone. - Multiple agents per person and global adoption would increase demand by orders of magnitude. ## Isolates as Agent Infrastructure - Cloudflare’s Workers platform uses V8 isolates instead of containers. - Isolates start in milliseconds, use only a few megabytes of memory, and provide secure sandboxing. - They can be up to 100 times faster to start and up to 100 times more memory-efficient than containers. - Dynamic Workers can create execution environments on demand, run code, and discard them at a scale of millions per second. - This efficiency could make one-agent-per-user economics viable beyond expensive coding assistants. ## The “Horseless Carriage” Phase - Early agent infrastructure often adapts existing systems instead of using designs built specifically for agents. - Agents use headless browsers to navigate human-oriented websites, though structured protocols such as MCP could provide direct service access. - Many MCP servers simply wrap REST APIs, despite LLMs often being better at writing and executing code than making long sequences of tool calls. - CAPTCHAs and behavioral fingerprinting ask whether a requester is human, while agent systems need identity, authorization, and permission controls. - Full containers are frequently used for tasks that require only a few API calls and a response. ## Supporting Both Old and New Models - Infrastructure transitions rarely happen all at once; technologies such as IPv4/IPv6, HTTP/2/HTTP/3, and TLS 1.2/1.3 coexist. - Cloudflare plans to support existing agent workloads while developing more efficient primitives. - Containers remain important for coding agents that need filesystems, Git, Bash, and arbitrary binaries. - Cloudflare is also expanding container-based sandbox environments and browser-rendering capabilities for services that do not yet support agent-native protocols. Cloudflare’s broader recommendation is to build infrastructure that can serve today’s container-based agents while moving toward lightweight, ephemeral isolates designed for billions of specialized agent sessions.

Read original(opens in new tab)

Database DesignLarge Language ModelsKubernetesCloudflare Workers+4

cloudflare·Apr 10, 2026·4 min readCurated summary

500 Tbps of capacity: 16 years of scaling our global network

Cloudflare’s network has grown from a single transit provider in 2010 to more than 500 Tbps of provisioned external capacity across 330+ cities. The company argues that this scale is not merely about bandwidth: it enables security decisions, application execution, and routing validation to happen locally on every server. Its distributed architecture can absorb massive attacks automatically while supporting edge computing and emerging Internet protocols. ## From Transit Provider to Global Network - Cloudflare began with nLayer Communications as its first transit provider. - Expansion required city-by-city work: colocation contracts, fiber installation, hardware deployment, and Internet exchange peering. - In 2018, Cloudflare opened 31 cities in 24 days, despite logistical challenges such as customs delays and missing equipment. - The network now spans more than 330 cities and protects over 20% of the web. - The 500 Tbps figure represents provisioned interconnection capacity across transit, private peering, Internet exchanges, and Cloudflare Network Interconnect ports—not peak traffic. ## Turning the Network into a Security Layer - Cloudflare expanded from caching websites to securing employees and enterprise networks. - Its systems establish secure tunnels to private subnets and advertise customer IP space through BGP. - In 2025, Cloudflare mitigated a 31.4 Tbps DDoS attack lasting 35 seconds. - The attack was part of more than 5,000 attacks blocked that day, without paging an engineer. - Distributed automation allows attacks that once required nation-state resources to be handled in seconds. ## Packet-Level DDoS Mitigation - Incoming packets enter an XDP program chain in driver mode immediately after reaching the network interface card. - The `l4drop` eBPF program applies mitigation rules generated by `dosd`, Cloudflare’s denial-of-service daemon. - Each server identifies heavy traffic sources and shares the information across its colocation facility. - Mitigation rules spread globally through Quicksilver, Cloudflare’s distributed key-value store. - Only legitimate traffic reaches Unimog, the Layer 4 load balancer; Magic Transit traffic receives additional stateful inspection through `flowtrackd`. - The 31.4 Tbps attack was stopped at line rate without centralized scrubbing or human intervention. - Sufficient physical port capacity remains essential: software defenses cannot work if the network cannot first absorb the traffic. ## A Developer Platform at the Edge - Because Cloudflare already runs software on every server for packet filtering, it extended the same infrastructure to customer code through Workers. - Workers, KV, and Durable Objects run across Cloudflare’s global footprint rather than in a small number of cloud regions. - Workers Containers, introduced in 2025, support heavier workloads at the edge. - V8 isolates and custom filesystem layers reduce cold-start times. - Applications run on the same servers that discard malicious traffic before it reaches the network stack. ## Securing Routing with RPKI and ASPA - Cloudflare uses IPv6 and RPKI to reduce the risk of BGP hijacks. - It signs Route Origin Authorizations and rejects routes that fail Route Origin Validation, even when misconfigured networks become temporarily unreachable. - ASPA will extend protection by validating the network path, not just the organization authorized to originate a prefix. - The post compares RPKI to checking a destination passport and ASPA to verifying the entire flight manifest. - Cloudflare says 867,000 prefixes now have valid RPKI certificates, compared with nearly none a decade ago. - The company promotes early adoption of routing security standards because delays leave the Internet exposed to hijacks and route leaks. ## AI Agents and Internet Traffic - AI crawlers, training systems, and autonomous agents now generate more than 4% of HTML requests on Cloudflare’s network. - Human-initiated “user action” crawling increased more than 15-fold in 2025. - Unlike browsers, crawlers may retrieve every linked resource at maximum speed, making legitimate activity difficult to distinguish from attacks. - Cloudflare uses verified bot IP ranges, TLS fingerprints, behavioral analysis, and robots.txt signals to classify AI crawlers. - These signals help site owners decide which automated agents to permit. Cloudflare’s central lesson is that a global network must combine abundant capacity with intelligence distributed across every server. Its continued investment in automated mitigation, edge execution, routing security, and traffic classification is intended to make the Internet faster, safer, and more resilient as traffic patterns evolve.

Read original(opens in new tab)

CloudflareDistributed SystemsNetwork SecurityEbpf+4

cloudflare·Apr 8, 2026·3 min readCurated summary

From bytecode to bytes- automated magic packet generation

Classic BPF filters can hide Linux malware until a precisely crafted “magic” packet arrives, but manually reverse-engineering large filters is slow and error-prone. The post presents a symbolic-execution approach using the Z3 theorem prover to model BPF instructions as packet constraints and automatically generate triggering packets. This reduces analysis from hours of manual work to seconds, even for filters exceeding 100 instructions. ## Why BPF Filters Are Difficult to Analyze - Classic BPF is a small, efficient virtual machine used to filter network traffic inside the Linux kernel. - Unlike eBPF, classic BPF has a simple two-register design but can still contain many conditional jumps and packet-offset calculations. - Malware authors exploit BPF because kernel-level filtering can hide traffic from ordinary user-space monitoring tools. - Short programs are manageable manually, but complexity grows rapidly as filters reach 100 or more instructions. - The core problem is determining which packet bytes satisfy the conditions along an accepting execution path. ## BPFDoor as a Practical Example - BPFDoor is a stealthy Linux backdoor associated with cyberespionage campaigns and groups including Red Menshen/Earth Bluecrow. - It uses BPF to inspect incoming traffic without listening on a dedicated open port. - The example filter checks: - IPv6 or IPv4 EtherType. - UDP protocol. - DNS destination port 53. - Fragmentation status for IPv4 packets. - The IPv4 header length when locating the UDP destination port. - The filter contains two paths leading to acceptance: - An IPv6 UDP packet destined for port 53. - A non-fragmented IPv4 UDP packet destined for port 53. - These paths expose the byte offsets and values that a generated packet must satisfy. ## Finding the Shortest Accepting Path - The tool explores the BPF control-flow graph using a queue. - Each queued item records: - The next instruction pointer. - The sequence of instructions already traversed. - Conditional jumps are explored in both directions. - Paths ending in a drop result are discarded, while paths reaching a nonzero return value are recorded as accepting paths. - Breadth-first traversal prioritizes paths with fewer conditions, helping identify the shortest route to acceptance. - Unconditional jumps are followed directly, while conditional branches enqueue true and false destinations in order of path length. ## Turning Paths into Packets - Once accepting paths are identified, each branch condition becomes a constraint on packet contents. - The required byte offsets, widths, and values can be collected from the executed instructions. - Symbolic execution represents these checks as constraints instead of requiring analysts to reason through every instruction manually. - Z3 can then solve the resulting constraint set and produce packet bytes that satisfy the selected accepting path. - This approach is especially useful for large or heavily branched BPF programs where manual packet construction becomes impractical. The recommended workflow is to combine control-flow exploration with symbolic constraint solving: first identify viable accepting paths, then use Z3 to generate packets satisfying their byte-level requirements. This automates a formerly labor-intensive part of malware analysis and makes complex BPF-based backdoors much faster to investigate.

Read original(opens in new tab)

Network SecurityEbpfBerkeley Packet FilterBpf+4

cloudflare·Apr 7, 2026·3 min readCurated summary

Cloudflare targets 2029 for full post-quantum security

Cloudflare is accelerating its post-quantum security timeline and now aims to complete the transition by 2029, including post-quantum authentication. The company argues that recent advances in quantum algorithms, neutral-atom hardware, and error correction could bring “Q-Day”—when quantum computers can break today’s cryptography—as early as 2029–2030. While Cloudflare has largely addressed harvest-now/decrypt-later risks through post-quantum encryption, it now considers authentication the more urgent priority. ## Cloudflare’s Post-Quantum Roadmap - Cloudflare began preparing for post-quantum migration in 2019. - It enabled post-quantum encryption for all websites and APIs in 2022. - More than 65% of human traffic to Cloudflare is now post-quantum encrypted. - The remaining challenge is upgrading authentication, including certificates, signatures, and access credentials. - Cloudflare now targets 2029 for full post-quantum security. ## New Evidence That Q-Day May Arrive Earlier - Google announced a major improvement to an undisclosed quantum algorithm for breaking elliptic-curve cryptography. - Google provided a zero-knowledge proof of the algorithm rather than revealing its details. - Oratomic published estimates for breaking RSA-2048 and P-256 using neutral-atom quantum computers. - Its estimate for P-256 requires only about 10,000 qubits. - Important implementation details were intentionally omitted. - These developments led Google to move its own migration target to 2029. - Google has emphasized quantum-secure authentication, suggesting concern that Q-Day could arrive around 2030. - IBM Quantum Safe’s CTO has said that “moonshot attacks” against valuable targets might be possible as early as 2029. - Public progress estimates may become less reliable because researchers could stop disclosing details that would help adversaries. ## Progress Across Three Quantum-Computing Fronts ### Hardware - Competing approaches include: - Neutral atoms - Superconducting qubits - Ion traps - Photonics - Topological qubits - Most approaches have made substantial progress, although none has yet demonstrated the scalability needed to break deployed cryptography. - Neutral-atom systems appear particularly promising, and it would be risky to assume every competing approach will fail to scale. ### Error Correction - Quantum computers are inherently noisy and require error-correcting codes. - Conventional superconducting systems may need roughly 1,000 physical qubits per logical qubit because of noise and limited connectivity. - Neutral-atom systems offer highly connected, reconfigurable qubits that can use more efficient error-correcting codes. - Oratomic estimates that only about 3–4 physical neutral atoms may be needed per logical qubit. ### Quantum Software - Improvements to quantum algorithms can substantially reduce the resources required to break cryptography. - Google’s work reportedly accelerated attacks against P-256. - Oratomic added architecture-specific optimizations for reconfigurable neutral-atom systems. ## Why Authentication Requires Immediate Attention - Post-quantum encryption primarily protects against harvest-now/decrypt-later attacks: - Attackers collect encrypted traffic today. - They decrypt it later after obtaining a capable quantum computer. - This has been Cloudflare’s main focus since 2022. - Authentication presents a different threat: - Quantum computers could forge signatures, impersonate servers, or create unauthorized credentials. - If Q-Day were decades away, deploying post-quantum authentication would provide little immediate benefit. - If Q-Day could occur within a few years, authentication systems must be migrated before attackers can exploit them. Cloudflare’s recommendation is to treat post-quantum migration as an urgent, multi-year project rather than waiting for quantum computers to become publicly available. Organizations should continue protecting stored data with post-quantum encryption while prioritizing the migration of authentication, certificates, and digital signatures before 2029.

Read original(opens in new tab)

Quantum ComputingPost Quantum CryptographyElliptic Curve CryptographyQuantum Algorithms+3

cloudflare·Apr 6, 2026·3 min readCurated summary

How we built Organizations to help enterprises manage Cloudflare at scale

Cloudflare’s new Organizations feature helps enterprises centrally manage users, policies, accounts, and analytics across multiple Cloudflare Accounts. It preserves least-privilege access by allowing teams to remain separated while giving designated organization administrators broader oversight. Initially available in public beta for enterprise customers, Organizations is designed to reduce administrative complexity without granting unauthorized access. ## Why Enterprises Use Multiple Accounts - Separate accounts help teams manage their own resources and limit permissions. - Fine-grained RBAC can still be cumbersome when administrators must enumerate individual resources. - Central administrators currently need access to every account for reporting and policy management. - This setup is fragile because account-level administrators can remove those central administrators. ## Organization Structure and Account Management - Organizations add a management layer above individual Cloudflare Accounts. - The core feature is a flat list of accounts onboarded into the organization. - An account can be added only by someone who is a Super Administrator for that account. - Organizations are built on Cloudflare’s existing Tenant system, originally developed for partners. ## Organization Super Administrators - Org Super Administrators have Super Administrator permissions across every account in the organization. - They do not need memberships in child accounts and do not appear in account-level user interfaces. - The new role is the first of several planned organization-level roles. - Cloudflare consolidated legacy authorization paths into domain-scoped roles. - The permissions overhaul added approximately 133,000 lines of code and removed 32,000. - Permission checks for enumeration endpoints such as `/accounts` and `/zones` became 27% faster, especially for users with access to thousands of accounts. ## Organization-Wide Analytics - Org Super Administrators can view aggregated HTTP traffic analytics. - The dashboard combines data across all accounts and zones in the organization. - Cloudflare plans to add analytics for additional products over time. ## Shared Configurations - Organizations allow centrally managed policy sets to be shared across accounts. - Initial examples include WAF and Gateway policies. - Authorized users in the source account can update shared policies for the broader enterprise. - Security analysts can therefore manage enterprise-wide WAF rules without becoming organization or account administrators everywhere. ## Roadmap and Availability - The beta initially targets enterprise customers. - Cloudflare plans to expand access to pay-as-you-go and other customers, followed by the partner ecosystem. - Planned capabilities include: - Organization-level audit logs - Billing reports - More analytics dashboards - Additional organization user roles - Self-service account creation ## Security-First Rollout - Cloudflare will not automatically create organizations through account backfilling. - A self-service invitation process ensures that no user gains access without approval from a relevant Super Administrator. - The first eligible Super Administrator to claim the company’s organization can add other accounts where they also hold Super Administrator access. - If another employee has already claimed the organization, administrators must coordinate invitations or account-level approval. - Cloudflare Support will not configure organizations on customers’ behalf. Enterprise customers can claim an organization from the Cloudflare Dashboard’s Organizations tab at no additional cost. Companies should coordinate internally with their Super Administrators to ensure all relevant accounts are added securely.

Read original(opens in new tab)

Database DesignCloudflareWeb Application FirewallAnalytics+4

cloudflare·Apr 2, 2026·3 min readCurated summary

Why we-re rethinking cache for the AI era

AI traffic is fundamentally changing how CDNs should think about caching. Unlike human visitors, AI crawlers make broad, high-volume, often sequential requests for long-tail content, creating low reuse and substantial cache churn. Cloudflare argues that traditional LRU-based caching and techniques such as prefetching are increasingly poorly suited to this traffic, forcing operators to rethink cache design if they want to support AI access without harming human performance. ## Why AI Traffic Is Different - Automated traffic accounts for 32% of Cloudflare’s network traffic, including crawlers, scrapers, and AI assistants. - AI agents often: - Send many requests in parallel. - Scan large portions of a website sequentially. - Request rarely visited or loosely related pages. - Fetch documentation, images, and articles from many sources. - AI crawlers represent approximately 80% of self-identified AI bot traffic. - Most single-purpose AI bot traffic is associated with model training, with search-related crawling a distant second. ## The Three Defining Characteristics of AI Crawlers - **High unique URL ratio:** More than 90% of pages observed in large-scale Common Crawl datasets are unique by content. - **Content diversity:** Different crawlers target different materials, including source code, technical documentation, media, and blog posts. - **Crawling inefficiency:** Many requests lead to 404 errors or redirects because of poor URL handling. - AI crawlers generally lack browser-side caching and shared session behavior, so independent crawler instances may repeatedly appear as new visitors. - They can also repeatedly revisit content while iteratively refining search results, but each iteration still tends to fetch mostly new pages. ## How AI Crawling Disrupts Traditional Caches - Conventional CDN caching keeps frequently requested content available near users and evicts less recently used objects when storage fills. - Cloudflare uses an LRU (least recently used) policy, but broad AI scans introduce large numbers of low-reuse objects. - These objects can evict content that human visitors are more likely to request. - AI-driven long-tail access increases cache misses and sends more requests back to origin servers. - Cache speculation and prefetching become less effective because crawler access patterns are difficult to predict. - Higher miss rates can cause: - Slower responses. - Increased origin-server load. - Greater egress costs. - Reduced cache hit rates for human traffic. ## Implications for Website Operators - Operators face a tradeoff between optimizing infrastructure for human visitors and accommodating AI crawlers. - Some organizations may want to encourage AI access: - Developers may want documentation represented in AI models. - E-commerce companies may want product information included in LLM search results. - Publishers may seek compensation through systems such as pay-per-crawl. - The challenge is supporting useful AI traffic without allowing it to degrade the cache performance experienced by human users. Cloudflare’s analysis, conducted with ETH Zurich researchers, suggests that CDN caching strategies need to evolve beyond traditional assumptions about popularity and reuse. Cache systems designed specifically for AI-era traffic may need to isolate crawler workloads or otherwise prevent broad, low-reuse scans from displacing content valuable to human users.

Read original(opens in new tab)

RAGCdnAi CrawlersData Fetching+4

cloudflare·Apr 1, 2026·2 min readCurated summary

Our ongoing commitment to privacy for the 1.1.1.1 public DNS resolver

Cloudflare reports that an independent Big Four accounting firm has confirmed its 1.1.1.1 public DNS resolver continues to meet its privacy commitments. The review was conducted because Cloudflare’s DNS infrastructure has expanded and become more complex since the previous examination in 2020. Cloudflare says it aims to make privacy the default and encourages other public DNS providers to undergo similar independent reviews. ## Renewed Independent Privacy Examination - Cloudflare launched 1.1.1.1 in 2018 as a fast, privacy-focused DNS resolver. - A first independent review took place in 2020. - After major changes to its technology stack and DNS platform, Cloudflare commissioned the same accounting firm to conduct another examination. - The latest review examined evidence collected after the 2024 calendar year and took several months to complete. - The resulting report is available through Cloudflare’s compliance resources. ## Confirmed Privacy Commitments The examination confirmed that: - Cloudflare does not sell or share public resolver users’ personal data with third parties. - Resolver data is not used to target users with advertisements. - Cloudflare retains or uses the requested DNS information, rather than information identifying the person making the request. - Source IP addresses are anonymized and deleted within 25 hours. - DNS query information is not combined with other Cloudflare or third-party data in a way that could identify individual users. ## Limited Network Troubleshooting Data - Cloudflare may use randomly sampled network packets for troubleshooting and attack mitigation. - These samples represent no more than 0.05% of total traffic. - The samples can include the querying IP address, but are used solely for operational security and network reliability purposes. ## Scope of the Latest Review - Unlike the broader 2020 examination, the latest review focused exclusively on privacy commitments. - The earlier review also covered how Cloudflare handled anonymized transaction and debug logs, known as “Public Resolver Logs.” - Cloudflare says the use of those logs has evolved, including supporting services such as Cloudflare Radar. - The company maintains that these changes do not affect personal information or user privacy. Cloudflare’s practical position is that 1.1.1.1 users should not have to trust privacy promises alone: independent examinations should verify them. It recommends reviewing the published accountant’s report and continues to present 1.1.1.1 as a privacy-first DNS option.

Read original(opens in new tab)

CloudflareNetwork SecurityDnsData Protection+1

cloudflare·Apr 1, 2026·3 min readCurated summary

Introducing EmDash — the spiritual successor to WordPress that solves plugin security

EmDash is presented as a modern, TypeScript-based successor to WordPress, designed for today’s serverless hosting environment. Its central innovation is isolating plugins in sandboxed Dynamic Workers and granting them only explicitly declared capabilities. The project aims to preserve WordPress’s open-source publishing model while addressing plugin security, marketplace dependence, and licensing concerns. ## Modernizing WordPress for Today’s Web - WordPress powers more than 40% of the Internet but was designed when hosting commonly meant managing virtual private servers. - EmDash is: - Written entirely in TypeScript - Built on Astro - Serverless, while still deployable on personal hardware or Node.js servers - Fully open source and MIT licensed - Intended to remain compatible with WordPress-style functionality without using WordPress code - Version 0.1.0 is available as an early developer beta for Cloudflare or Node.js deployment, along with an online playground. ## Building on WordPress’s Publishing Legacy - WordPress democratized publishing and created a large ecosystem of core contributors, plugin developers, and theme developers. - The authors argue that WordPress will continue to have a role, but newer developers increasingly use Astro and TypeScript frameworks. - EmDash seeks to provide a similarly accessible, inexpensive, and open publishing platform suited to modern development practices. ## Sandboxed Plugins and Explicit Permissions - WordPress plugins are PHP scripts with direct access to the site’s database and filesystem. - This lack of isolation is identified as the source of most WordPress security problems: - 96% of WordPress site security issues reportedly originate in plugins. - High-severity vulnerabilities increased substantially in 2025. - EmDash runs each plugin inside an isolated Dynamic Worker. - Plugins access platform functionality through capability-based bindings rather than direct access to underlying resources. - A plugin must declare its required permissions in its manifest, allowing administrators to evaluate permissions before installation. - The example notification plugin: - Reacts to content-save events - Checks whether a post has been published - Sends an email to editors - Logs the notification - Plugins have no general external network access. If network access is necessary, the plugin can request permission for specific hostnames. - Administrators or platforms could enforce installation policies based on requested permissions instead of relying solely on approved-plugin allowlists. ## Security, Marketplaces, and Licensing - WordPress.org manually reviews plugins because the platform cannot otherwise guarantee their safety. - The review queue reportedly exceeds 800 plugins and can take at least two weeks. - Marketplace reputation, ratings, and reviews therefore become essential substitutes for technical trust. - Because WordPress plugins run inside WordPress and are tightly coupled to its code, developers may also face GPL licensing constraints. - The article argues that plugin security creates marketplace lock-in: - Customers rely on marketplaces to assess plugin trustworthiness. - Developers may need to distribute code under restrictive licensing terms to participate. - Hosting platforms inherit the risk of running third-party plugins. - EmDash’s sandboxing and permission model is positioned as a way to reduce reliance on centralized marketplace approval, though the provided article excerpt ends before explaining the promised “two important properties” in full. EmDash’s practical recommendation is to use capability-limited, isolated plugins as the foundation for a more secure and flexible WordPress-like ecosystem. Its early beta is intended for developers who want to evaluate that model on Cloudflare or Node.js.

Read original(opens in new tab)

Database DesignOpen SourceTypeScriptNode.Js+4

cloudflare·Mar 31, 2026·3 min readCurated summary

Introducing Programmable Flow Protection: custom DDoS mitigation logic for Magic Transit customers

Programmable Flow Protection lets Magic Transit Enterprise customers define custom DDoS mitigation logic for proprietary UDP protocols. Customers write eBPF programs that identify valid and malicious packets, then deploy them across Cloudflare’s global network to pass, drop, or challenge traffic. Currently in beta for an additional cost, the system addresses the limitations of generic blocking and rate limiting. ## Custom Protection for Proprietary UDP - Existing Cloudflare protections understand established protocols such as TCP, DNS, NTP, RDP, and SIP. - Proprietary UDP protocols are harder to protect because Cloudflare cannot interpret their application-level payloads. - Customers can now define what constitutes “good” and “bad” traffic using their own protocol knowledge. - Programs can drop or challenge invalid packets before they reach the customer’s origin. ## Why Generic UDP Mitigation Falls Short - UDP is connectionless and optimized for speed, making it useful for gaming, VoIP, and streaming. - When traffic does not match a known protocol, mitigation typically falls back to: - Blocking a destination IP and port - Applying a generic rate limit - These approaches cannot distinguish legitimate packets from attack traffic, potentially causing lag or connection loss for real users. - Fixed rate limits may also be inappropriate: - A network expecting 1 Gbps may need stricter limits. - A network expecting 25 Gbps may require more permissive thresholds. ## How Programmable Flow Protection Works - Customers upload custom eBPF programs that run on every packet destined for their network. - Programs execute in userspace rather than kernel space, providing isolation and flexibility across different customers and use cases. - Execution occurs after Cloudflare’s existing DDoS protections, preserving baseline security coverage. - Like kernel-based XDP eBPF programs, these programs: - Compile to BPF bytecode - Pass safety and termination verification - Run inside a lightweight, isolated virtual machine - Cloudflare provides specialized helpers for: - Maintaining client state between packet executions - Performing cryptographic validation - Sending challenge packets to clients ## Example: Protecting a Proprietary Game Protocol - A gaming provider running on UDP port 207 could inspect its proprietary application header. - If the header contains a protocol-specific token, the customer’s eBPF program can: - Parse the packet - Extract part of the token, such as its final byte - Pass packets with the expected value - Drop packets that fail validation - This allows legitimate players’ traffic through even when attacks use randomized source addresses, ports, and payloads. Programmable Flow Protection is best suited to Magic Transit customers whose custom UDP protocols cannot be protected effectively by standard protocol-aware controls. By combining customer-specific packet logic with Cloudflare’s global network and stateful challenge mechanisms, it enables more precise mitigation than blanket blocking or generic rate limiting.

Read original(opens in new tab)

CloudflareNetwork SecurityEbpfTcp+4

cloudflare·Mar 30, 2026·3 min readCurated summary

Cloudflare Client-Side Security: smarter detection, now open to everyone

Cloudflare is making its Client-Side Security Advanced product self-serve and offering domain-based threat intelligence free to users of its basic bundle. The service detects malicious browser-side JavaScript through browser reporting, AST-based behavioral analysis, and a new LLM review layer. Its goal is to catch sophisticated skimming attacks while reducing false positives and avoiding performance impacts on customer applications. ## Growing Threat of Client-Side Attacks - Browser skimmers can steal credentials, payment data, and personal information without disrupting page loads or checkout flows. - Recent examples include: - A browser keylogger placed on a major U.S. bank’s employee merchandise store. - Malicious npm package releases capable of enabling browser-based crypto theft when bundled into front-end applications. - These attacks often exploit trusted first-party or third-party scripts rather than obvious server vulnerabilities. ## Broader Access to Client-Side Security - Client-Side Security Advanced, formerly the Page Shield add-on, is now available to self-serve customers. - Domain-based threat intelligence is complimentary for customers using the free Client-Side Security bundle. - Advanced capabilities include: - Machine-learning and LLM-assisted malicious script detection. - Continuous code-change monitoring for compliance requirements such as PCI DSS v4.0 requirement 11.6.1. - Proactive positive security rules maintained through ongoing monitoring. ## Browser-Based Monitoring Without Application Changes - Cloudflare evaluates approximately 3.5 billion scripts per day, with enterprise zones averaging about 2,200 scripts. - The system gathers signals through browser reporting mechanisms such as Content Security Policy. - Customers do not need scanners or application instrumentation. - Traffic must be proxied through Cloudflare. - The approach adds no latency to web applications. ## Detecting Script Intent - Enterprise sites may contain thousands of scripts, and roughly one-third change within a 30-day period. - Manually approving every DOM interaction or outbound connection would create excessive operational overhead. - Cloudflare instead analyzes what scripts are attempting to do. - JavaScript is represented as an Abstract Syntax Tree (AST), allowing the system to identify behavioral patterns even when code is minified, renamed, or obfuscated. ## Reducing False Positives - Client-side compromises are relatively rare but potentially severe, unlike the high-volume attacks typically handled by a WAF. - Because genuine incidents are uncommon, even accurate detection systems can produce more false alarms than real alerts. - False positives contribute to security-team fatigue and can obscure actual compromises. - Legitimate but heavily obfuscated code—such as bot challenges, tracking pixels, advertising bundles, and minified frameworks—can resemble malicious code structurally. ## GNN and LLM Detection Pipeline - Cloudflare’s primary detector is a Graph Neural Network (GNN) operating on JavaScript ASTs. - The GNN learns structural representations of code and can recognize similar behavior despite syntactic changes. - It is optimized for high recall to detect novel and zero-day threats. - Although fewer than 0.3% of analyzed traffic is incorrectly flagged, Cloudflare’s scale makes that percentage a significant number of alerts. - An LLM provides semantic context, recognizing common JavaScript frameworks, domain-specific coding patterns, and benign forms of suspicious-looking obfuscation. - The LLM complements rather than replaces the GNN: - Scripts classified as benign stop after the fast GNN evaluation. - Scripts exceeding the GNN’s risk threshold are sent to an open-source LLM hosted on Cloudflare Workers AI for a second opinion. Cloudflare’s approach combines low-overhead browser telemetry, structural machine learning, and semantic LLM review. For organizations handling payments or sensitive user data, enabling these controls can improve visibility into third-party scripts, detect unexpected code changes, and reduce the chance that false alarms overwhelm security teams.

Read original(opens in new tab)

Large Language ModelsMachine LearningJavaScriptAbstract Syntax Tree+4