cloudflareAug 10, 2026

Serving the most critical missions- Cloudflare for Government achieves FedRAMP Class D (High) Certified status (opens in new tab)

Cloudflare announced that Cloudflare for Government has achieved FedRAMP High (Class D) certification, enabling it to support highly sensitive federal workloads. The company is also using the systems built for FedRAMP High as the foundation for pursuing DoD Impact Level 4 authorization. Its core argument is that government agencies should receive the same modern capabilities as commercial customers without relying on isolated, outdated platforms. ## What FedRAMP High Represents - FedRAMP provides standardized security assessment, authorization, and continuous monitoring for U.S. government cloud services. - Cloudflare previously achieved FedRAMP Moderate authorization in 2022. - FedRAMP High involves substantially stricter controls and addresses data where a breach could have catastrophic consequences. - High-impact workloads include law enforcement, emergency services, financial systems, and national security information. - The authorization was sponsored by the National Institute of Standards and Technology and verified by the FedRAMP Program Management Office. ## One Platform on a Global Network - Traditional public-sector technology platforms often use separate, isolated environments that fall behind commercial products. - Cloudflare instead runs the same software stack across its global network. - Its FedRAMP High offering uses the same underlying machines and services, with software-defined regional controls rather than a separate government cloud. - This allows federal customers to access current Zero Trust tools, application performance services, and developer features as they are released. ## Data Localization and Compliance - Cloudflare’s Data Localization Suite controls where traffic is processed and stored. - For FedRAMP High services, traffic inspection and processing can be restricted exclusively to U.S. data centers. - These software-defined controls allow Cloudflare to meet strict residency and handling requirements while retaining a unified global architecture. ## Path Toward DoD IL4 - Cloudflare designed its FedRAMP High systems with DoD Impact Level 4 requirements in mind. - DoD IL4 applies to systems handling controlled, unclassified information. - The company expects its existing compliance infrastructure to support the pursuit of IL4 authorization. - Cloudflare argues that this approach could help defense organizations adopt new security capabilities faster than release-isolated government clouds allow. Cloudflare presents FedRAMP High as more than a compliance milestone: it is a way to modernize federal infrastructure with Zero Trust security, DDoS protection, resilient services, and continuously updated technology.

zero-trustcloudflarecloud-securityfedramp+3

cloudflareAug 5, 2026

Cloudflare is the only vendor named a Visionary in 2026 SASE and SSE reports (opens in new tab)

Cloudflare argues that SASE and SSE are entering a major transition driven by AI agents, shadow applications, post-quantum threats, and increasingly distributed workforces. It presents Cloudflare One as a unified, programmable platform designed to address these pressures without the fragmented architectures, complex deployments, and hidden costs associated with legacy vendors. The company cites its recognition as a Visionary in both Gartner’s 2026 SASE and SSE Magic Quadrants as validation of this approach. ## The SASE Market’s Architectural Gap - Many SASE platforms are assembled through mergers and acquisitions, creating disconnected products and difficult deployments. - Cloudflare’s “connectivity cloud” uses one global network to connect and protect employees, AI agents, and infrastructure. - AI security has focused primarily on human interactions with generative AI, leaving autonomous agents and MCP server sprawl insufficiently governed. - Cloudflare claims its SASE platform provides shared visibility and policy controls for both humans and AI agents, including limits on AI inference costs. - Post-quantum protection is presented as an immediate requirement against “harvest-now, decrypt-later” attacks, rather than a future concept. - Cloudflare emphasizes predictable SASE bundles instead of charging separately for advanced capabilities or remote and office use cases. ## Technological Pressures Reshaping SASE - **AI-generated applications:** Employees can rapidly create internal “vibe-coded” tools without IT oversight. SASE platforms will need to automatically apply zero trust access, WAF, API protection, and DLP. - **Autonomous AI agents:** Future systems must issue narrowly scoped credentials for individual tasks, evaluate agent intent, and detect abnormal tool-call activity. - **Post-quantum agility:** Organizations need adaptable post-quantum encryption now, while standards continue to evolve. Cloudflare says it aims to deliver a fully quantum-secure SASE platform by 2028. - **Architectural consolidation:** Genuine platform consolidation requires shared code, control, data, and infrastructure planes—not merely multiple products marketed as a single platform. - These changes are described as current customer requirements rather than distant predictions. ## Cloudflare’s Unified Architecture - Cloudflare says it built its SASE platform from the ground up on a single global network rather than combining unrelated security products. - A composable architecture allows new security capabilities to be introduced without waiting for lengthy integration cycles. - Administrators can use familiar SASE policies to secure human AI prompts, AI-agent connections, and MCP servers. - New AI applications can inherit existing zero trust controls instead of requiring security to be retrofitted later. ## Easier SASE Deployment - Legacy platforms often route traffic through multiple inspection points, producing “tromboning,” capacity-planning challenges, and complicated operations. - Cloudflare claims every service runs across its network, eliminating specialized appliance silos and reducing deployment complexity. - Common tasks—such as extending zero trust to an application, adding DLP to Gateway traffic, or connecting an office—are intended to take days or weeks rather than months or years. - The platform is positioned as operating more like a modern SaaS service than a collection of separately managed security engines. ## Programmable SASE - Cloudflare distinguishes true programmability from basic GUI automation and APIs layered over inflexible products. - Its SASE platform runs alongside the company’s edge developer platform, allowing customers to integrate custom code directly into the security fabric. - This design is intended to let organizations enrich access decisions with real-time signals and adapt policies to their own requirements. Cloudflare’s recommendation is effectively to choose SASE platforms built on unified, composable infrastructure that can govern people, applications, and autonomous agents together. Organizations should prioritize integrated policy enforcement, native post-quantum readiness, predictable pricing, and genuine programmability over loosely bundled legacy products.

zero-trustai-securitysasecloudflare-one+3

cloudflareAug 5, 2026

The Agent Access Model (opens in new tab)

BeyondCorp established that access should depend on identity and device health rather than network location. The post argues that this human-centered model is inadequate for ephemeral, fast-moving, and highly composable software agents. It proposes the Agent Access Model (AAM), which limits an agent’s capability to a specific task, evaluates every action against evolving task state, and enforces controls in the execution harness and network rather than relying on prompts. ## The Shift from Humans to Agents - Traditional Zero Trust assumes a legible human principal: - A person uses a small number of devices. - Activity occurs at human speed. - Access decisions can be evaluated over time using SSO, device posture, and risk scoring. - Agents have a different operating model: - A task-scoped run is ephemeral and ends when its work is complete. - A long-lived service may execute many independent tasks. - Agents can access databases, source control, logs, ticketing systems, documents, and other systems in rapid succession. - Least privilege must therefore become real-time and task-specific rather than a periodic policy review. ## Why Human-Oriented Controls Fail - **Durable credentials outlive ephemeral work** - Service-account keys and broad scopes may remain available after a task ends. - Credentials can persist in memory, logs, or environment variables. - Agent credentials should expire with the task and typically live only for minutes. - **Machine-speed activity bypasses slow detection** - An agent can read sensitive data and transmit it externally before human-tuned anomaly or DLP systems react. - Preventive controls must operate inline at tool-call and network boundaries. - **Prompts cannot enforce security boundaries** - Instructions such as “do not access production” can be overridden by malicious content or unsafe model behavior. - Intent may inform risk decisions, but enforcement must occur in the harness and network layer. - **Authority can disappear across delegation chains** - Agents may call tools that invoke other agents and APIs. - Existing identity and delegation mechanisms struggle to preserve the original human, task, and permissions across multiple hops. ## The Agent Access Model - AAM’s central rule is: **do not trust the task execution graph; authorize every action.** - Each action is evaluated against: - The agent’s identity. - The human or system principal it acts for. - The authorized task. - Resources already accessed by the task execution graph. - Accumulated task state can only reduce remaining capabilities; authorization for one action does not automatically authorize later actions. - AAM complements systems such as Beyond Zero by shrinking the capability set that authorization engines must evaluate and recording the agent, principal, and task behind each decision. ## AAM’s Five Principles - **Short-lived, bound credentials** - Credentials are minted for a specific task, expire with it, and are sender-constrained. - A stolen token cannot be replayed without the harness-held proof key. - **Enforcement outside the prompt** - The harness mediates tool calls. - The network mediates packets. - Prompts communicate intent but are not security boundaries. - **Exceptional human oversight** - Human approval is reserved for genuinely consequential decisions. - Requiring approval for every step causes fatigue and habitual clicking. - **Evidence-based grant review** - Captured activity reveals whether task templates are too broad or too narrow. - Approved policy changes apply only to future tasks and never expand the permissions of an active task. - **One-way capability reduction** - A declared protected event triggers the Trust Ratchet. - Capabilities are removed across the task execution graph according to policy. - Removed authority can return only through a newly authorized task. ## Reference Architecture - AAM describes a reference architecture with: - Four active controls governing the task. - An Agent Activity Log that records evidence. - A Grant Review Loop that uses that evidence to improve future grants. - The architecture is intended to define security guarantees and component responsibilities rather than prescribe a specific wire-level implementation. - At dispatch, the Agent Identity Broker issues a verifiable, short-lived credential scoped to the task. - The credential identifies: - The agent. - The principal on whose behalf it acts. - The authorized task. - It must expire no later than the task itself and be sender-constrained to prevent token-only replay. A practical implementation should treat each agent run as a bounded, independently authorized execution graph. Enforce permissions inline at the harness and network layers, use short-lived task-bound credentials, continuously reduce capability when risk changes, and use audit evidence to refine future grants without widening permissions during an active task.

zero-trustaccess-controlaudit-loggingleast-privilege+2

cloudflareAug 5, 2026

How we’re rethinking work at Cloudflare with Cloudflare OS (opens in new tab)

Cloudflare built Cloudflare OS to let employees use AI agents safely after a sudden increase in demand for production access and automation capabilities. The company’s approach combines AI enablement with strict controls around data access, human accountability, organizational context, and engineering quality. Its experience suggests that successful AI adoption requires meeting both technical and non-technical users where they work. ## Why Cloudflare Built Cloudflare OS - Employees rapidly began using improved AI models and agent-building tools to create internal applications. - One sales employee requested production access to roughly a dozen systems and administrative deployment permissions for an AI-built “SuperApp.” - Cloudflare needed to enable experimentation without exposing internal systems, company data, or customer data. - The resulting platform combines existing products such as Workers and Access with custom services developed for internal AI workflows. ## Principles for AI Adoption - **Start with jobs to be done:** Teams should identify customer-related pain points, bottlenecks, or missed opportunities before selecting an AI tool. - **Give everyone access to AI capabilities:** AI interfaces should not be limited to developers using terminals, code editors, and repositories. - **Keep humans accountable:** Employees remain responsible for defining quality, testing outputs, and owning the workflows and agents they deploy. - **Prioritize organizational context:** Cloudflare-specific knowledge and canonical internal guidance matter more than simply choosing the most powerful model. - **Never expand permissions through AI:** AI tools and agents must inherit users’ existing access restrictions and receive only the permissions required for their tasks. Shared agents must respect each recipient’s permissions rather than the deployer’s. ## Engineering Guardrails with the Cloudflare Engineering Codex - Cloudflare created the Engineering Codex as an authoritative, opinionated guide to engineering practices. - Unlike policies, which define what engineers cannot do, the Codex describes what they should do. - Domain owners are responsible for defining quality standards across the codebase. - AI agents use the Codex throughout the software development lifecycle: - Planning work - Reviewing merge requests - Evaluating technical designs before implementation - Reviewing incident reports - Over four months, these agents identified nearly 250,000 potential issues, blocked 16,000 merges, and caught architectural problems in almost 600 designs. - Cloudflare is now focusing on helping engineers create evaluation loops for assessing the work produced by their agents. ## Rethinking AI Tools for Non-Engineers - Cloudflare initially gave non-engineering employees developer-oriented tools with more approachable interfaces. - This approach worked poorly for knowledge workers who create one-off deliverables and interact with many systems of record. - Code-focused harnesses encouraged excessive “vibe-coded” applications, often without a clear problem to solve. - Cloudflare then began working backward from users’ actual needs and introduced the idea of a “magic AI email bot” to which employees could delegate unwanted work. The supplied excerpt ends before describing how that system worked. Cloudflare’s experience recommends pairing broad AI access with strong identity, permission, context, and accountability systems. Organizations should design tools around real jobs to be done—not simply distribute coding agents—and provide interfaces suited to both engineers and non-engineers.

zero-trustai-agentcloudflare-workerscode-review+2

cloudflareJul 20, 2026

Cloudflare Internal DNS is now generally available (opens in new tab)

Cloudflare Internal DNS is now generally available as a unified platform for public and private DNS. It combines recursive resolution, authoritative private zones, DNS policy enforcement, and Zero Trust controls on Cloudflare’s global network. The goal is to eliminate fragmented DNS systems and simplify split-horizon management without duplicated configurations or synchronization drift. ## Problems with Traditional Internal DNS - Organizations often manage public DNS, internal DNS, and cloud-provider DNS separately. - Separate control planes create inconsistent policies, limited visibility, and operational overhead. - Split-horizon DNS typically requires parallel environments that can drift and cause outages. - Legacy appliances introduce hardware refresh cycles and scaling constraints. ## Unified DNS and Zero Trust - Public and private DNS share one platform, API, audit trail, and policy layer. - Internal DNS is included for Enterprise customers using Cloudflare Gateway. - Gateway policies determine which users and devices can resolve specific DNS views. - Private name resolution becomes part of the broader Zero Trust architecture. ## Internal DNS Architecture Cloudflare Internal DNS has two main components: - **Gateway Resolver** - Performs recursive resolution and evaluates DNS policies. - Can filter queries or redirect them to different upstream sources. - Provides centralized logging, auditing, and policy management. - **Internal Authoritative DNS** - Serves records for private zones using Cloudflare’s authoritative DNS infrastructure. - Stores resources such as internal applications, databases, and service endpoints. The main configuration objects are: - **Internal Zones:** Authoritative records for private resources. - **DNS Views:** Resolution contexts containing one or more zones. - **Resolver Policies:** Gateway rules that route matching queries to a specific view. - **Zone references:** Allow one shared zone to be reused across multiple views without duplicating records. ## Query Resolution and Change Propagation - Queries first reach the Gateway Resolver for policy evaluation. - Matching policies route queries to an internal DNS view. - Blocked queries are dropped. - Unmatched queries use public resolution through 1.1.1.1. - Views can fall back to public DNS when a name is not found internally. - Changes from the dashboard, API, or Terraform use the same DNS Records API. - Records are validated, persisted, replicated globally, and propagated within seconds as caches are invalidated. ## Getting Started - Enterprise customers using Gateway can access Internal DNS from **Networking → Internal DNS**. - Initial setup generally requires: - Creating an internal zone and records. - Creating a DNS view and associating the zone. - Creating a Gateway resolver policy that routes users or devices to the view. - Terraform is supported and follows the same API ingestion and propagation path. ## Connectivity Cloud Integration - Internal DNS works with Cloudflare One Client, DoH, DoT, standard DNS, PAC files, and Cloudflare WAN. - Cloudflare WAN enables devices across branches, data centers, cloud environments, and remote networks to resolve internal names without installing the client on every device. - The service extends Cloudflare’s existing Connectivity Cloud rather than operating as an isolated DNS product. Cloudflare’s recommendation is to consolidate public DNS, private DNS, and DNS security policies on one control plane, particularly for organizations already using Cloudflare Gateway or WAN.

zero-trustdnsterraformcloudflare-gateway+4

cloudflareJul 7, 2026

Cloudflare proudly joins the UK government's Cyber Resilience Pledge (opens in new tab)

Cloudflare has joined the UK government’s voluntary Cyber Resilience Pledge, supporting its focus on security governance, board accountability, and supply-chain protection. The company argues that these principles align with its existing approach: make security broadly accessible, use network-scale intelligence, apply protections internally, and be transparent about failures. It presents collective action and stronger baseline controls as essential to addressing rising cyberattacks and AI-enabled threats. ## The Cyber Resilience Pledge - The pledge encourages organizations to adopt foundational cybersecurity governance and make resilience a leadership responsibility. - It promotes comprehensive security coverage across supply chains. - Its central principles include: - Democratizing access to security - Leadership accountability - Radical transparency - Cloudflare sees the pledge as validation of principles it has followed for more than a decade. - The company highlights the need to address common weaknesses such as: - Unpatched systems - Weak access controls - Poor vendor oversight ## Rising Cybersecurity Risk - Cloudflare blocked an average of 234 billion cyber threats per day during the first quarter of 2026. - It recently mitigated a DDoS attack peaking at 31.4 Tbps. - By the end of 2025, the UK was the sixth-most targeted location globally for DDoS attacks. - Threat actors increasingly targeted application-layer services in financial services, aviation, and regional government. - UK survey data found that 43% of businesses and 28% of charities experienced a cyber incident in the previous year. - Frontier AI models are making attacks easier to automate, including vulnerability scanning and convincing phishing campaigns. ## Why Cyber Resilience Matters - Resilience is a business requirement because customers expect services to remain available, responsive, and trustworthy. - It extends beyond recovering from incidents to proactively: - Monitoring threat signals - Absorbing disruptions - Adapting systems after failures - Cloudflare views security controls as the foundation that makes resilience possible. ## Cloudflare’s Resilience Architecture ### Security by Default - Cloudflare aims to make baseline protections available to organizations of all sizes. - Examples include: - SSL certificates for encrypted traffic - Unmetered DDoS protection on its free plan - CDN and DNSSEC access - Post-quantum cryptography deployment - Impact programs such as Project Galileo and the Athenian Project - This model is intended to help small businesses, startups, local authorities, and public services participate in the UK’s resilience efforts. ### The Network as a Sensor - Cloudflare peers directly with more than 13,000 networks worldwide. - Attack intelligence gathered in one location can become a protection rule for customers elsewhere within seconds. - This global visibility improves threat detection, scoring, and response across its services. ### Cloudflare as “Customer Zero” - Cloudflare uses its own security products and infrastructure to protect internal systems. - Employees access internal applications through Cloudflare Access and Gateway. - Internal requests require hardware-based MFA, device posture checks, and cryptographically verified identity tokens. - Testing security controls internally helps Cloudflare identify improvements before delivering them to customers. ### Transparency and Incident Response - Cloudflare publishes technical postmortems for security incidents and zero-day vulnerabilities. - It shares indicators of compromise, telemetry, and architectural lessons with the wider security community. - After a major outage, its “Code Orange” initiative focused on building systems that “fail small,” safer configuration tooling, and automated best practices. ## Cloudflare’s Pledge Commitments - The post begins describing the pledge’s requirements around: - Board responsibility and governance - Supply-chain security - Technical standards related to UK Cyber Essentials - The provided text ends before detailing Cloudflare’s specific implementation of these commitments. Organizations should treat cyber resilience as an ongoing governance and engineering responsibility, not an optional product feature. Raising baseline protections, sharing lessons from incidents, and securing supply chains can make the wider Internet safer and more dependable.

zero-trustcloudflarepost-quantum-cryptographycybersecurity+3

cloudflareJun 17, 2026

Introducing the Cloudflare One stack- agent-powered deployment (opens in new tab)

Cloudflare’s One stack is a pair of agent skills designed to help organizations evaluate, migrate to, deploy, and operate Cloudflare One Zero Trust environments. It combines expert-curated guidance, migration logic, decision trees, and API tooling so agents can understand existing networks, recommend architectures, and safely implement changes. The goal is to reduce migrations that traditionally take months to a more guided and automated process. ## The Challenge of Zero Trust Migration - Teams must first understand their existing environment, including: - Applications and connectivity requirements - Authentication and authorization policies - Traffic flows - Assumptions embedded in current security and routing rules - Agents can automate many security workflows, but lack organization-specific knowledge about network topology and vendor configurations. - Cloudflare’s stack supplies the structured context and prescriptive guidance needed for agents to work more effectively with security infrastructure. ## What the Cloudflare One Stack Provides - The stack consists of two lightweight skill files: - `cloudflare-one` for general Cloudflare One planning, deployment, management, and troubleshooting - `cloudflare-one-migration` for translating and migrating from legacy SASE vendors - It incorporates knowledge gathered from Cloudflare employees with extensive customer deployment experience. - When combined with Cloudflare’s code mode MCP server, agents receive a typed interface to the Cloudflare API. - Agents can inspect live accounts and make changes through Cloudflare-recommended workflows rather than arbitrary API calls. ## Covered Cloudflare One Capabilities - VPN replacement and remote access through Cloudflare Access - User, device, network, and data security through Cloudflare Gateway - Connectivity using Cloudflare Tunnel, Mesh, and WAN - Migration from vendors such as Zscaler and Palo Alto Networks - Network diagram interpretation and generation - Translation of concepts between competing SASE platforms - Troubleshooting and operations using Digital Experience Monitoring and automated rule recommendations ## Guided Deployment and Migration - For VPN replacement, the agent can: - Inventory existing VPN applications - Determine the required connectivity model - Map applications to Access, Tunnel, or Mesh - Recommend a deployment sequence that reduces cutover disruption - Produce a configuration summary for human review - For Zscaler Private Access migrations, the agent can: - Convert application definitions into Cloudflare Access applications - Translate user groups and policies - Create equivalent resources through the Cloudflare API - Summarize completed work and identify items needing manual review - The migration logic is based on Cloudflare’s Descaler and Deskope programs, which have migrated enterprise customers from Zscaler and Netskope in hours rather than months. ## Operations and Troubleshooting - The stack can recommend security rules based on live account traffic. - It can automatically migrate Zscaler Private Access applications into self-hosted Cloudflare Access applications. - Agents can investigate anomalies in secure web gateway HTTP logs and create rules to address user issues. - The Digital Experience Monitoring toolkit can report on user stability and help improve latency in important scenarios. Cloudflare positions the One stack as a way to make Zero Trust deployment more accessible and repeatable. Organizations can use the skills with their existing agents, add internal context, and combine them with API tooling—but should still review generated plans and configurations before applying changes.

zero-trustmodel-context-protocolsasecloudflare-access+4

cloudflareJun 10, 2026

Route public traffic to private applications with Cloudflare (opens in new tab)

Cloudflare is extending its application security, performance, and programmability services to applications hosted on private networks. Its new Application Services for Private Origins allows public traffic to reach private origins through existing connectivity such as IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh—without public IP exposure, inbound firewall rules, or `cloudflared` on the origin. The feature is entering closed beta for eligible Enterprise customers. ## Unifying Public and Private Application Traffic - Private applications—including internal APIs, AI backends, MCP servers, and operational tools—can now use: - WAF - Bot management - Rate limiting - Caching - Traffic acceleration - Rewrites - Workers - Cloudflare treats private IPs as valid origin targets for public hostnames. - The model supports four traffic combinations: - Public users to public applications - Private users to public applications - Public users to private applications, which is shipping now - Private users to private applications, planned for the future ## Reusing Existing Private Connectivity - The feature builds on Cloudflare’s existing private networking layer. - Supported connectivity models include: - Cloudflare Tunnel - Cloudflare One Client - IPsec and GRE tunnels - CNI links - Cloudflare Mesh - Customers can manage routing through Cloudflare’s dashboard and APIs rather than maintaining separate networking stacks. - Workers VPC bindings and Spectrum private-origin routing also use this shared connectivity layer. ## Application Services for Private Origins - Customers can enable **Use private network routing** on a proxied A or AAAA DNS record. - Cloudflare continues applying WAF, rate limiting, caching, bot management, and transform rules at its edge. - Only the final connection differs: Cloudflare sends traffic through the customer’s private network instead of over the public Internet. - Private routing is automatically enabled for: - RFC 1918 IPv4 ranges such as `10.0.0.0/8` - RFC 6598 CGNAT ranges such as `100.64.0.0/10` - RFC 4193 IPv6 unique-local addresses such as `FC00::/7` - Public IPs reachable only through a private network can be configured manually. ## API Configuration - Private routing is represented as an additional DNS record attribute: ```json { "type": "A", "name": "app.example.com", "content": "10.0.0.50", "ttl": 300, "proxied": true, "use_private_routing": true } ``` - Cloudflare’s Origin API returns the `use_private_routing` flag. - When the proxy sees that flag, it passes the request to Cloudflare’s private networking layer, which selects the appropriate private path. ## Beyond HTTP - The same routing approach supports non-HTTP services. - Potential origins include: - TCP databases - UDP logging endpoints - Private APIs accessed by Workers - Spectrum can extend the model to TCP and UDP services, while Workers VPC enables direct access from serverless code. Cloudflare’s recommendation is effectively to use existing private connectivity as the transport layer while centralizing application security, performance, and routing at Cloudflare’s edge. The feature is currently limited to eligible Enterprise customers in closed beta.

zero-trustcloudflarecloudflare-workersweb-application-firewall+3

googleMay 27, 2026

Private analytics via zero-trust aggregation (opens in new tab)

Google presents a private analytics architecture combining one-shot cryptographic secure aggregation with trusted execution environments (TEEs). The design follows a zero-trust model: cryptography prevents individual data from being reconstructed, while TEE attestation verifies that approved, publicly auditable code is running. It aims to provide useful population-level insights without exposing raw user data, even if hardware protections are compromised. ## Why Private Analytics Matters - On-device AI protects user information, but developers still need to measure performance across millions of devices. - Aggregated analytics can reveal: - Model drift, such as difficulty handling new language or slang. - Hidden biases across regions, environments, or demographic conditions. - Real-world error rates and user reactions to model outputs. - Google already uses federated analytics in products including Pixel Recorder and Gboard. ## Limitations of Existing Protections - **TEEs** isolate sensitive computation from compromised operating systems and hypervisors. - Hardware attestation produces a cryptographic fingerprint proving which firmware and software are running. - However, TEEs remain vulnerable to newly discovered side-channel attacks. - Traditional cryptographic aggregation offers mathematical privacy guarantees, but many protocols require devices to stay online through several interactive rounds. - Extended multiround participation limits practical deployment at large scale. ## Combining Encryption and Isolation - The new system allows devices to submit data in a single message. - This removes the need for devices to remain connected for multiple protocol rounds. - Data is encrypted before leaving the device and is never reconstructed in server memory, including inside a TEE. - Unencrypted information is processed off-device only after it has been aggregated and anonymized. - TEE attestation provides verifiable evidence that the intended secure aggregation implementation is running correctly. - The cryptographic and hardware layers provide defense in depth: failure of one layer does not automatically expose individual data. ## One-Shot Lattice-Based Aggregation - The protocol uses lattice-based cryptography. - Ciphertexts can be combined so that their underlying data—and encryption keys—are aggregated together. - A resulting decryption key can reveal only the aggregate, not individual contributions. - Small client committees hold decryption hints and help unlock the aggregated result. - Differential privacy noise is added to further protect the aggregate. - Decryption authority is distributed across multiple parties, preventing any single party from accessing encrypted data. ## Application to Android SafetyCore - SafetyCore provides privacy-preserving, on-device safety features for Android 9 and later. - Private analytics can help measure which threats are detected and identify areas where detection needs improvement. - Google is working with the Android SafetyCore team to apply this system while preserving the confidentiality of individual users’ data. ## Practical Takeaway The approach pairs the scalability of one-shot cryptographic aggregation with the verifiability of TEEs. It is designed for private, large-scale analytics where neither individual data nor trust in a single hardware or software component is required.

zero-trustdifferential-privacyon-device-aifederated-analytics+3

cloudflareMay 1, 2026

Code Orange: Fail Small is complete. The result is a stronger Cloudflare network (opens in new tab)

Cloudflare’s “Code Orange: Fail Small” initiative rebuilt key parts of its infrastructure to prevent repeats of the November 18 and December 5, 2025 global outages. The work focused on safer configuration rollouts, smaller failure impact, stronger emergency access, and improved incident communication. Cloudflare concludes that the network is now more resilient, though reliability remains an ongoing effort. ## Safer Configuration Changes - Configuration changes affecting customer traffic are now deployed progressively rather than instantly across the network. - Health monitoring can detect problems early and automatically roll back faulty changes. - Cloudflare introduced **Snapstone**, a unified system that: - Packages configuration changes. - Releases them gradually. - Monitors system health in real time. - Automatically rolls back unsafe deployments. - Snapstone supports different configuration types, including data files and global control flags. - New high-risk configuration pipelines have been identified and brought under the health-mediated deployment process. ## Reducing the Impact of Failure - Product teams reviewed failure modes and removed unnecessary runtime dependencies. - Systems now use the last known good configuration where possible, following a **“fail stale”** strategy. - Where stale configuration is unavailable, teams choose between: - **Fail open:** Continue serving traffic with reduced protection or functionality. - **Fail close:** Stop processing when that is safer than continuing. - The Bot Management outage scenario would now be detected during an early rollout stage, affecting only a small amount of traffic before rollback. - Services are increasingly segmented into independent systems serving different customer cohorts. - For example, the Workers runtime deploys first to less-critical segments, such as free customers, before reaching more critical traffic. - This approach limits the blast radius of faulty deployments and adjusts rollout speed based on customer criticality. - Cloudflare plans to extend cohort-based deployment to more systems. ## Revised Break-Glass and Incident Procedures - Cloudflare audited tools needed for visibility, debugging, and emergency production changes. - It created backup authorization paths for **18 key services**, along with emergency scripts and proxies. - These pathways are designed to remain usable if Cloudflare’s own Zero Trust infrastructure is affected by an outage. - More than 200 engineers participated in an organization-wide emergency drill on April 7, 2026. - Repeated exercises are intended to ensure engineers can use emergency access procedures effectively under pressure. - Cloudflare also began improving how technical incident observations are converted into clear customer communications. Cloudflare’s changes make configuration rollouts safer, reduce failure blast radius, and improve emergency response. The practical recommendation is to treat these safeguards as ongoing operational practices rather than a one-time project, continually testing them and extending them to additional systems.

zero-trustcloudflareincident-managementconfiguration-management+4

cloudflareApr 20, 2026

The AI engineering stack we built internally — on the platform we ship (opens in new tab)

Cloudflare built an internal AI engineering stack that now supports AI coding tools for 93% of its R&D organization. The system combines centralized authentication and model routing with internal knowledge, automated review, and sandboxed agent execution. Cloudflare argues that building these capabilities on its own platform improved security, visibility, cost control, and developer velocity, while also serving as a proving ground for products it ships publicly. ## Adoption and Impact - Over the previous 30 days: - 3,683 employees used AI coding tools, representing 60% of the company and 93% of R&D. - AI tools generated 47.95 million requests. - 295 teams used agentic AI tools or coding assistants. - AI Gateway handled 20.18 million requests and routed 241.37 billion tokens. - Workers AI processed 51.83 billion tokens. - The four-week rolling average of merge requests increased from roughly 5,600 per week to more than 8,700. - The week of March 23 reached 10,952 merge requests, nearly twice the Q4 baseline. - Cloudflare’s initial focus was MCP servers, but the effort expanded to standards, code review, onboarding, and propagating changes across thousands of repositories. ## Architecture at a Glance Cloudflare organized the stack into three layers: - **Platform layer:** Authentication, model routing, inference, MCP access, and code execution. - **Knowledge layer:** System context and repository guidance through Backstage and `AGENTS.md`. - **Enforcement layer:** Automated quality controls using AI Code Reviewer and the Engineering Codex. The stack uses Cloudflare products including: - **Cloudflare Access** for zero-trust authentication. - **AI Gateway** for centralized LLM routing, cost tracking, bring-your-own-key support, and zero-data-retention controls. - **Workers AI** for open-weight model inference. - **Workers and Access** for an MCP Server Portal with single OAuth. - **Dynamic Workers** for sandboxed agent-generated code execution. - **Agents SDK and Durable Objects** for stateful, long-running agent sessions. - **Sandbox SDK** for isolated cloning, building, and testing environments. - **Workflows** for durable, multi-step processes. - **Backstage** for a 16,000-plus-entity knowledge graph. ## Centralized Authentication and AI Routing - Cloudflare Access authenticates users and enforces zero-trust policies. - Every LLM request passes through AI Gateway, providing a single control point for: - Provider credentials - Usage and cost attribution - Model selection - Data-retention policies - Provider permissions - In the past month, frontier providers handled 91.16% of requests, while Workers AI handled 8.84%. - Cloudflare routes requests through a proxy Worker rather than connecting clients directly to AI Gateway. - The proxy enables later additions such as per-user attribution, model catalogs, permission enforcement, and support for new coding tools without changing client configurations. ## Workers AI and Open-Weight Models - Workers AI runs open-source models on GPUs distributed across Cloudflare’s global network. - Keeping inference on the same network as Workers, Durable Objects, and storage reduces latency, network failures, and cross-cloud configuration. - Kimi K2.5, with a 256,000-token context window, tool calling, and structured outputs, processes more than 7 billion tokens per day for a Cloudflare security agent. - Cloudflare estimates that running this workload on Workers AI is 77% cheaper than using a mid-tier proprietary model. - Workers AI is also used for: - Documentation review in CI - Generating `AGENTS.md` files - Lightweight inference where latency matters more than maximum model capability - Cloudflare expects open-source models to handle an increasing proportion of its internal workloads. ## One-Command Client Configuration - Engineers begin setup with: ```bash opencode auth login https://opencode.internal.domain ``` - The command uses an OpenCode discovery endpoint at: ```text https://opencode.internal.domain/.well-known/opencode ``` - The Worker-hosted endpoint provides authentication and configuration information. - This mechanism is designed to configure providers, models, MCP servers, agents, commands, and permissions without requiring engineers to edit configuration files manually. ## Overall Recommendation Cloudflare’s experience suggests that organizations adopting AI coding tools should build a centralized control plane early: authenticate users consistently, route model traffic through one managed gateway, maintain shared system knowledge, and enforce quality through automated review and isolated execution. Using the same production platform for internal tooling can also expose product gaps and accelerate improvements to the platform itself.

zero-trustdatabase-designci-cdopen-source+4

cloudflareApr 13, 2026

Dynamic, identity-aware, and secure Sandbox auth (opens in new tab)

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.

zero-trustjavascriptauthenticationhttp-requests+4

cloudflareMar 16, 2026

From legacy architecture to Cloudflare One (opens in new tab)

Moving from fragmented VPNs to Cloudflare One is presented as a gradual modernization effort rather than a risky “big bang” cutover. Cloudflare and CDW recommend a tiered, application-aware migration that combines Zero Trust controls with careful dependency analysis and staged deployment. The central conclusion is that legacy applications can gain modern security protections without immediate code rewrites or major downtime. ## Reducing Big-Bang Migration Risk - Large organizations may need to transition hundreds or thousands of applications and users from legacy VPNs. - A single firewall error, dependency failure, or session timeout can disrupt essential services. - These risks often prevent organizations from adopting Zero Trust despite vulnerable, aging infrastructure. - CDW applies lessons from failed deployments to create a risk-aware migration roadmap. - Applications are categorized by complexity, with simpler systems migrated first and legacy systems handled later under tighter controls. - A public-sector migration of 500 applications caused widespread disruption because more than 4,000 applications had not been prioritized or tiered. ## Treating Migration as Application Modernization - Traditional migrations often treat networks as basic connectivity infrastructure and overlook application ecosystems. - CDW analyzes: - Backend databases and APIs - Identity and authentication dependencies - Hidden service-to-service calls - Legacy session behavior - Security requirements are incorporated into the architecture from the beginning rather than added after connectivity is restored. - The migration becomes an application modernization program instead of a simple VPN replacement. ## Protecting Legacy Applications with Cloudflare Access - Cloudflare Access replaces broad network-level VPN access with request-by-request Zero Trust authorization. - Each request can be evaluated using: - User identity - Device posture - Hardware-based MFA - Other contextual signals - This limits lateral movement and reduces the attack surface. - Legacy applications can be “wrapped” with modern security controls without rewriting their code. - Cloudflare Tunnel provides: - An outbound-only connection - SSO and MFA integration - No public IP exposure for the application - Access policies can require endpoint MFA and a device health check before traffic reaches the server. - This approach allows organizations to modernize security incrementally while legacy applications continue operating. ## Pre-Migration Audit ### Architectural and Identity Assessment - Identify whether applications use a federated identity provider such as Okta or legacy local directories. - Map database, API, and backend dependencies. - Verify that hidden API calls and service-token-based Tunnel connections will continue functioning after migration. - Assess whether applying least-privilege controls could break application behavior. ### Establishing a Strategy and Implementation Firebreak - Create separate groups for: - Security strategy and standards - Deployment and operational implementation - This separation prevents deployment speed from overriding requirements designed to limit lateral movement. ### Testing Persistent Sessions - Identify applications that depend on persistent sessions, particularly for users switching between cellular towers. - Cloudflare’s edge architecture and Dynamic Path MTU Discovery (PMTUD) help maintain sessions even when client IP addresses change. - This assessment can identify opportunities to replace rigid legacy hardware with a modern single-pass architecture. ### Categorizing Applications and Setting Timelines - **Tier 0: Modern SaaS applications** - Native SAML/OIDC support - Cloudflare can act as a clientless identity-provider proxy - Estimated effort: 1–3 hours per application - **Tier 1: Internal web applications** - Support identity headers and modern web protocols - Use a clientless reverse proxy with Cloudflare Tunnel - Estimated effort: 3–6 hours per application - **Tier 2: Non-web client-server applications** - Require specific port/protocol support or thick-client configurations - Use both Cloudflare One Client and Cloudflare Tunnel - Estimated effort: 4–8 hours per application A phased migration built around application dependencies, identity readiness, session behavior, and technical complexity offers a safer path to Cloudflare One. Organizations should begin with an audit and pilot, secure legacy applications using Access and Tunnel, and expand tier by tier rather than attempting a single cutover.

zero-trustdatabase-designcloudflaresase+4

cloudflareMar 10, 2026

Investigating multi-vector attacks in Log Explorer (opens in new tab)

Cloudflare Log Explorer provides a unified view for investigating multi-vector attacks across application, network, identity, and endpoint activity. By correlating 14 new datasets from Cloudflare Application Services and Cloudflare One, analysts can connect reconnaissance, credential abuse, DDoS activity, lateral movement, and data-exposure risks. This broader visibility helps reduce Mean Time to Detect and supports faster, more complete forensic investigations. ## Unified Telemetry Across the Stack - Cloudflare describes logs as a “flight recorder” for digital infrastructure, capturing requests, attacks, configuration changes, and performance issues before traffic reaches origin servers. - Log Explorer centralizes telemetry in one interface, allowing analysts to correlate events across: - Application-layer HTTP traffic - Firewall and DDoS activity - DNS queries - Zero Trust access and network sessions - Endpoint, browser, email, and device events ## Zone-Scoped Logs These datasets focus on public websites, edge security, and application performance. - **HTTP Requests:** Reconstruct sessions, exploit attempts, and bot activity. - **Firewall Events:** Show blocked or challenged requests and the rules, IP reputations, or filters involved. - **DNS Logs:** Help detect cache poisoning, domain hijacking, and reconnaissance. - **NEL Reports:** Separate Layer 7 attacks from legitimate client connectivity problems. - **Spectrum Events:** Reveal Layer 4 anomalies and brute-force attempts against services such as SSH or RDP. - **Page Shield and Zaraz Events:** Track unauthorized JavaScript, outbound connections, third-party tools, and privacy-related behavior. ## Account-Scoped Logs Account-level datasets cover internal security, administration, identity, and network operations. - **Access Requests and Zero Trust Network Sessions:** Show who accessed protected applications and how long sessions lasted. - **Audit Logs:** Identify unauthorized Cloudflare configuration changes. - **CASB Findings:** Detect SaaS misconfigurations and potential data exposure. - **Gateway DNS, HTTP, and Network Logs:** Reveal malware callbacks, shadow IT, malicious downloads, unauthorized ports, and lateral movement. - **Magic IDS and Network Analytics:** Detect known exploit signatures, unusual traffic spikes, and volumetric attacks. - **Browser Isolation and Device Posture Logs:** Track risky user actions and whether connecting devices meet security requirements. - **Email Security Alerts:** Trace phishing and other email-based entry points. - **WARP and IPSec Logs:** Identify tampering with security connectivity and monitor encrypted tunnel health. - **DEX telemetry:** Help distinguish security incidents from ordinary application or device-performance problems. - **Sinkhole HTTP Logs:** Confirm attempts by internal devices to contact known botnet infrastructure. ## Investigating Attacks Across Multiple Stages - Public-facing telemetry can reveal how attackers probe websites, while account and Gateway logs show subsequent internal activity. - Analysts can correlate compromised credentials with the applications, devices, and network resources accessed by an attacker. - Magic IDS and Network Analytics extend investigations beyond HTTP to detect network-layer attacks and east-west movement. - Combining these sources gives investigators a timeline spanning initial reconnaissance, exploitation, internal access, and possible command-and-control activity. ## Detecting Reconnaissance - Query `http_requests` for repeated `401`, `403`, or `404` responses from a single IP address. - Look for requests targeting sensitive paths such as: - `/.env` - `/.git` - `/wp-admin` - Use `magic_ids_detections` to identify network-layer scanning. - Suspicious patterns include: - One source IP triggering multiple unique detections - Probes across many destination ports - Activity occurring within a short time window - Magic IDS signatures can identify techniques such as Nmap scans and SYN stealth scans. Log Explorer is most valuable when teams correlate its datasets rather than examining each log source in isolation. Combining application, identity, DNS, network, and endpoint telemetry provides the context needed to identify sophisticated attacks quickly and reconstruct their full scope.

zero-trustcloudflarenetwork-securityhttp-requests+4

cloudflareMar 9, 2026

Complexity is a choice. SASE migrations shouldn’t take years. (opens in new tab)

Cloudflare argues that SASE and zero trust migrations do not need to take years. Its partners, TachTech and Adapture, reportedly reduced deployments from around 18 months to four–six weeks by using Cloudflare One’s unified, cloud-native architecture. The post concludes that programmable security infrastructure can accelerate zero trust adoption while also enabling safer use of AI. ## Faster Zero Trust Deployments - Traditional Secure Web Gateway (SWG) and Zero Trust Network Access (ZTNA) migrations can take up to 18 months for large organizations. - TachTech reduced comparable Cloudflare One deployments to four–six weeks. - Cloudflare Access is presented as lightweight and largely “no-touch” after deployment, reducing ongoing operational effort. ## Why Legacy Migrations Stall - Legacy architectures often treat migration as hardware replacement rather than software transformation. - Complex service chaining creates a “trombone effect,” increasing latency and making troubleshooting difficult. - Cloudflare’s partners accelerate migrations through: - **Identity-first on-ramps:** Existing identity-provider groups define access policies instead of rebuilding network segments. - **Consolidated policy engines:** SWG and ZTNA policies are handled together, avoiding synchronization between separate products. - **Cloud-native connectors:** Tools such as `cloudflared` provide connectivity without opening inbound firewall ports. ## Scaling Quickly - Adapture expanded one Cloudflare Access deployment from 600 contractors to 5,000 users. - The company describes the expansion as seamless compared with the lengthy implementation cycles associated with legacy SASE platforms. - Cloudflare positions rapid elasticity as important for organizations whose workforce and security needs change quickly. ## A Programmable, Extensible Edge - Cloudflare One is described as software-defined and composable, allowing partners to adapt it to specialized environments. - TachTech supported Arch Linux developer workstations by extracting binaries from an Ubuntu `.deb` package and creating a custom `PKGBUILD`. - This approach preserved device-posture checks, including disk-encryption and firewall-status verification, without creating a security exception. ## Supporting Safe AI Adoption - Cloudflare says the Secure Web Gateway is evolving from simple URL filtering toward controlling data flows to large language models. - Its AI security capabilities include: - **Shadow AI visibility:** Identifying unauthorized AI tools in use across the organization. - **AI confidence scores:** Evaluating models based on standards such as SOC 2 and ISO 42001, as well as data-handling practices. - **DLP prompt protection:** Blocking sensitive source code, personally identifiable information, and financial data from being submitted to public AI services. - **LLM discovery:** Finding and labeling internet-exposed LLM endpoints to reveal the organization’s AI attack surface. - **Request validation:** Intended to defend AI applications against prompt injection and related attacks. Cloudflare’s central recommendation is to replace fragmented, hardware-oriented security deployments with a unified, programmable platform. Doing so can shorten zero trust migrations, simplify operations, preserve consistent security controls across unusual environments, and establish a faster foundation for responsible AI adoption.

zero-trustdatabase-designcloudflarepostgresql+4