Tag Archives: Cloudflare One

Introducing automatic remediation policies with Cloudflare CASB

Post Syndicated from Michael Leslie original https://blog.cloudflare.com/casb-policies/

Today, we’re making Cloudflare CASB more powerful than ever by introducing automatic remediation policies. This means security teams can now design event-driven logic to revoke risky file shares and dispatch custom webhooks, without manual intervention.

When we launched Cloudflare CASB, a cloud access security broker, we wanted to provide security teams complete visibility into the posture of their SaaS applications before misconfigurations became incidents. With a quick, clientless integration, CASB surfaces risks like overshared files, dormant admin keys and tokens, OAuth apps with excessive permissions — continuously, across users in the organization.

For years, SaaS Security Posture Management (SSPM) tools such as Cloudflare CASB have functioned as a passive alarm system. Most SSPM tools tell you what’s wrong but do not help you fix the issue, placing the burden on administrators to manage an ever-growing to-do list. A single misconfigured file-sharing policy across a Google Workspace tenant can generate thousands of findings in seconds, and even a disciplined team faces a window between detection and remediation measured in hours or days — more than enough time for a sensitive file to be downloaded, forwarded, or indexed. 

With automatic remediation policies, CASB customers can now configure the actions that should be invoked immediately after a new finding is identified.

Shifting from reactive to proactive

When we launched manual remediation actions earlier this year, we gave security teams the ability to resolve misconfigurations directly from the Cloudflare dashboard. This removed the need for customers to log in to multiple SaaS portals to take action on the security and content findings detected by Cloudflare CASB. Still, this required a human to confirm and initiate each individual remediation — even if they’d seen this exact finding type before. 

CASB policies are a native automation engine built directly into Cloudflare One that takes action the moment a finding is detected. Security teams define their response logic once, whether that is revoking access to a file share, dispatching a webhook to your security operations center (SOC), or forwarding the event to a security orchestration, automation and response platform (SOAR). The engine handles matches automatically by executing the customer-configured action.

As an example, many organizations implement controls that prohibit files from being shared publicly. However, they may apply an exception to users and groups in their marketing department who are frequently required to collaborate with external parties. SSPMs allow their customers to be alerted of any files that are shared publicly in violation of their policy. With many solutions, this permitted behavior lands in a queue with hundreds of possible violations, forcing administrators to take action on each individual instance. 

CASB policies are designed for exactly this scenario. Rather than waiting for a human to see and act on a finding, automation fires the moment detection happens. The public share is revoked within minutes, keeping the backlog of findings clean and clear.

How CASB policies work

At their core, CASB policies are automated workflows that tell our scanning service what action to take when a new finding is detected. From there, the configured policy will tell CASB to either trigger a remediation action, send a webhook, or both. This gives organizations the flexibility to rely on native CASB remediation capabilities or their own internal automation services and communication channels — without having to take action in disparate platforms or create their own event processing system.

How we built it

The architecture behind CASB policies is built entirely on the Cloudflare developer platform — the same platform available to every Cloudflare customer.

When a finding is detected, the findings engine enqueues an orchestration message to a Cloudflare Queue. A Worker consumer then checks whether a policy configuration matches the incoming finding. If a match exists, it creates the corresponding job and hands it to the remediations pipeline, which runs on Cloudflare Workflows for durable, fault-tolerant execution. That means jobs survive process restarts and retries are handled automatically.

Cloudflare Workflows also handle third-party API rate limits gracefully. If a vendor returns a rate limit error, the Workflow pauses for the appropriate backoff window and retries without dropping the job. Our target from detection to completed remediation is five minutes or less.

How to create policies

To get started, navigate to the Cloudflare dashboard and create your first policy. Policies can include both a remediation and a webhook action, but at a minimum: 

  • Select the vendor. Select the vendor and integration or tenant this policy should apply to.
  • Select the integration. You can hand-select specific integrations or set it to apply to all integrations for the selected vendor. 
  • Choose a finding type. Select the CASB finding type that should fire the policy. 
  • Choose an action. Once a trigger is selected, the available actions for that finding type are shown. There are two categories:
    • Run remediations. First-party actions Cloudflare performs directly against the SaaS integration API. CASB currently supports remediation actions for Microsoft and Google Workspace file/folder finding types. Note that this may require upgrading permissions on integrations to read/write.
    • Send webhooks. Send finding details to configured webhook destinations such as Slack, Microsoft Teams, Jira, ServiceNow, Tines, or any custom HTTP endpoint your team uses.

Example webhook format

Maintaining visibility and compliance

Each policy action produces two categories of logs, visible under Insights in Cloudflare One. 

Admin Activity logs. These capture changes to a policy definition: who created it, who edited it, who disabled it, and when. If a policy was turned off and a risk slipped through, this audit trail surfaces a timeline of the event.

Cloud & SaaS Security policies logs. This new class of logs captures the runtime outcome of policy invocations. This includes details like which finding triggered the policy, which file was acted on, whether it succeeded or failed, and the specific error if it did not — for example, a 401 Unauthorized or an API rate limit response from the vendor. 

For compliance use cases, the execution log is the proof of fix. It ties a specific finding, like an overshared file (e.g. Q4_Financials.pdf), to a specific automated action and event timestamp. 

Get started

Customers can find CASB Policies in the Cloud & SaaS findings section of the dashboard today. Connect or update your Microsoft 365 or Google Workspace integration to Read-Write permissions, and create your first remediation policy. 

In the coming weeks, we’ll also be adding support for Custom Findings to CASB. Different organizations have unique needs when it comes to detection, and we want to give customers the ability to augment or define finding logic to fit those needs. 

New to Cloudflare One? Sign up for 50 free seats to get started with CASB, or talk to our team about a deployment at scale. For full setup instructions, visit our developer documentation.

How Cloudflare detects MCP traffic and helps secure it

Post Syndicated from AJ Gerstenhaber original https://blog.cloudflare.com/mcp-security-updates/

Most companies designed their resource permissions with a human user in mind. A senior engineer may be able to deploy to production, query a sensitive database, or revoke another user's access. Those privileges come with risk, but that risk has traditionally been bounded by two assumptions: the engineer will use human judgment, and the engineer can only act at human speed.

An engineer who sees an unexpected result will usually stop and reconsider their actions. Any human being can only click, type, and review so much in a single day. The introduction of AI agents changes both thresholds. Their decisions are nondeterministic, and they can take the same action (or invoke the same tool) indefinitely, without getting tired or stopping for lunch. A plausible — but incorrect — decision can become thousands of incorrect actions before a human notices.

Today, we're announcing new Cloudflare One capabilities to identify inspected MCP traffic, show which users and servers are generating it, and control direct connections on managed network paths. Combined with MCP Server Portals, these controls help administrators see whether agents are using an approved path, or somehow bypassing it.

Model Context Protocol (MCP) servers give agents a common way to discover and invoke tools backed by third-party SaaS products, internal applications, and APIs. The underlying permissions are likely familiar; what changes is who makes each decision, and how quickly a bad decision can spread.

Connecting an agent to one of these tools can take a single line of configuration. An employee can point Claude Code, Codex, Cursor, OpenCode, VS Code, or any AI harness at an MCP server without checking whether it is approved. The resulting traffic has no obvious shape. The Model Context Protocol does not use a guaranteed hostname or require /mcp in the path, so a direct connection can look like any other HTTPS API call.

To explain how these controls fit together, we'll start with the anatomy of a tool call and the information it exposes. We'll then compare the three places a security team can act: inside the client, on the network, and at the MCP server. From there, we'll show how Cloudflare Gateway uses protocol signals to find shadow MCP traffic and enforce MCP Portal-only access to trusted MCP servers.

The anatomy of an MCP tool call

The same MCP tool call has three forms as it moves through a system. Inside the client it is a decision to invoke a tool with a set of arguments. On the network it is an HTTP transaction carrying a JSON-RPC message. At the server it becomes a call to a tool handler that may read data, change state, or complete some other action.

Consider an agent that wants to know the weather in Austin. A remote MCP request can look like this:

There are several useful signals packed into this request. The hostname and path identify the destination. The authorization header carries the credential used to authenticate the caller when the server requires one. The header: MCP-Protocol-Version identifies the protocol version, while Mcp-Method and Mcp-Name expose the operation and tool in the new stateless protocol. The JSON-RPC envelope repeats the method, gives the request an id that the client can match with a response, and carries the tool arguments in params.

The arguments are the most sensitive part. They can contain a search query, source code, customer data, or instructions for an action such as creating a ticket or changing infrastructure. The tool name says what the agent intends to call; the arguments say what data it will send and what action it wants the server to perform.

If the call succeeds, the server returns a JSON-RPC response with the same id and the tool result. That response may also contain sensitive data. Request inspection can stop an unsafe action before execution, while response inspection and logging show what the tool returned to the agent.

Three places to control an MCP request

The request gives security teams three places to observe or control the call.

Inside the MCP client

A client hook can run after the model selects a tool but before the client serializes the request. From there, it can see the destination server, tool name, and arguments without decrypting network traffic.

This is the earliest stage in the request chain to exercise control. The client can deny a server that is not on an allowlist, ask the user to confirm a sensitive operation, or remove data from the arguments before it leaves the device. It can also cover local stdio (aka local) MCP servers, which never generate network traffic.

This presents a standardization challenge. In order for a security team to benefit from this, they would need to reproduce their controls across every client that their employees use. Client-side controls work best when the organization manages both the client and the device, but telemetry from one client is never a complete inventory of MCP use.

At the device's network boundary

A secure web gateway can observe the HTTP request after it leaves the client. With TLS decryption, it can associate the request with a user and device, inspect the destination and protocol headers, and apply policy without depending on a particular MCP client.

The network layer has the widest lens to detect remote MCP traffic on managed paths. It can identify direct connections to servers outside an approved Portal and block them before the request reaches the destination. Where data loss prevention scanning is supported, a proxy can also examine the JSON-RPC method and arguments for sensitive data. However, proxies cannot see local stdio calls or off-network traffic.

Before the MCP server invokes the tool

The server has the richest execution context. It has authenticated the caller, parsed the MCP message, resolved get_weather to a handler, and validated the supplied arguments against the tool's input schema. This is the last point where the request can be denied before the tool runs.

An Agents SDK handler or similar server middleware can authorize the caller for the specific tool, apply rate limits, inspect arguments, and record the outcome. A server should perform these checks before invoking the handler, especially for tools that write data or trigger external actions. Logging only after execution can explain what happened, but it cannot prevent it.

Cloudflare's WriteGuard uses this pattern across our internal MCP servers. Each tool has a risk tier and an enabled or disabled state. WriteGuard can pass a read through unchanged, add agent attribution and an audit event to an allowed write, or block a critical action before its handler runs. Because the control lives at the server, an end user cannot bypass it by switching clients or disabling a local hook.

While server-side controls only protect servers that implement them, the client and server have the best request depth. The network sees the widest set of remote connections. Used together, these controls can stop sensitive data before it leaves a device, find unmanaged MCP traffic, and deny an unauthorized operation before a tool executes.

The network control point has the broadest coverage, but it first has to distinguish MCP from ordinary HTTPS traffic, a user must be running a proxy, and the MCP Server (or Portal) must verify that the proxy was used in the connection.

Cloudflare One provides the networking pieces of that chain. The Cloudflare One Client sends traffic from managed devices through Gateway. Gateway can classify MCP requests at the protocol layer, and distinguish whether traffic is initiated from an MCP Portal, or is going outside approved controls. Administrators can then report on, or block connections that do not follow the approved path. That process starts with identifying the request reliably.

A URL does not tell you that a request uses MCP

Our first approach to finding MCP traffic used the GraphQL Analytics API to search Gateway HTTP logs for hostnames containing mcp and common paths like /mcp or /sse. Our MCP traffic detection tutorial includes the query. It also explains how to create data loss prevention patterns for MCP JSON-RPC methods like initialize, tools/call, and resources/read in request bodies.

Those signals are still useful for finding traffic from older clients and providing historical visibility, but they're very basic. They miss an MCP server at an ordinary URL like https://tools.example.com/api, which is not uncommon.

And they can match an unrelated service that happens to use mcp in a hostname or path (unlikely, but we have seen it). For conforming Streamable HTTP clients, the protocol header is a more specific signal. The MCP 2025-11-25 specification says clients MUST include MCP-Protocol-Version on every HTTP request after initialization. The MCP 2026-07-28 specification goes further and requires it on every POST request.

That does not make the header a complete detector. The initial request from a legacy client may not contain it, protocol versions earlier than 2025-06-18 did not define it, and local stdio, custom transport, or nonconforming traffic may never carry it. Its presence is a strong positive indicator of MCP; its absence does not prove that a request is not MCP.

The protocol is becoming easier to identify on the wire

The legacy MCP flow begins with an initialize request that does not contain the MCP-Protocol-Version HTTP header, so a network control may not classify the first request to a previously unknown endpoint from the header alone. The signal appears after the client and server finish initialization.

A later tool call looks like this:

The MCP 2026-07-28 specification changes this model considerably. The core protocol is stateless; it removes the initialize handshake entirely and places the protocol version and operation on each request:

The Mcp-Method and Mcp-Name headers let ordinary HTTP infrastructure identify the operation without parsing the body. Load balancers can route requests, rate limiters can separate tools/list from tools/call, and security products get more information on every request.

These protocol signals give Cloudflare Gateway something concrete to evaluate without relying on a list of MCP-looking URLs.

Shadow MCP and approved-path bypass are separate problems

Once Gateway can identify MCP traffic, you can then evaluate what a given connection means for your security posture.

Shadow MCP is a connection to a server the organization has not approved. An employee finds the server in a repository, a product guide, or a message from a colleague and adds it directly to their MCP client. The security team has no idea which tools it exposes or what data employees send to it.

Portal bypass is different: it starts with an approved server that the organization has placed in an MCP Portal, but an employee connects to its upstream URL directly and skips the Portal's Access policy, curated tool catalog, data loss prevention, and tool-level audit trail.

Gateway is the primary control for shadow MCP on managed network paths; it identifies TLS-inspected MCP traffic, shows the destination and user, and can apply policy. Portal bypass needs that network control plus an origin that can reject direct requests, whether that means an Access policy, a source IP restriction, or an enterprise authorization mechanism initiated by the MCP server itself.

Detecting MCP traffic in Gateway

For customers who have already adopted Cloudflare Gateway with TLS inspection, we are adding a detection heuristic that answers a simple question for every inspected request: Is this MCP traffic?

For session-based Streamable HTTP connections, MCP clients send an MCP-Protocol-Version header after initialization. Gateway inspects that header on every TLS-inspected request and classifies the traffic accordingly, using detection built from patterns we observe across the millions of requests that traverse the Cloudflare network every day. The classification identifies MCP negotiation and proxying to a hostname without relying on knowing the specific host or URL ahead of time.

Starting today, all Cloudflare Zero Trust customers see indications of MCP traffic in their Gateway HTTP logs and can explicitly block or allow that traffic with a new Gateway selector:

experimental.is_mcp == true

The selector is a boolean. If Gateway detects the MCP-Protocol-Version header on a TLS-inspected request, the value is true, and an administrator can use it in an Allow or Block policy without maintaining their own list of MCP-looking domains.

Direct encrypted traffic must pass through TLS decryption before Gateway can inspect these headers, and local stdio servers, off-network connections, Do Not Inspect traffic, and requests that never traverse Gateway remain outside this view.

Visibility into MCP traffic across your network

Today, we're introducing a dedicated MCP traffic dashboard that shows which hosts are serving MCP traffic within your network, which users are generating that traffic, and whether requests are going through your Cloudflare MCP Portals or bypassing them entirely.

The dashboard shows:

  • Total MCP requests, unique users, and unique servers over a configurable time window
  • MCP servers over time with per-server request counts
  • Traffic breakdown by on-ramp, separating MCP Portal traffic from direct device client connections
  • Top MCP servers seen outside your Portals, which is the shadow MCP traffic that matters most
  • Top users by MCP request volume

Administrators can filter by specific servers, users, or on-ramp types, and navigate directly to Gateway HTTP logs filtered by the relevant host or user for deeper investigation.

Bring discovered servers into an MCP Portal

MCP discovery turns unknown traffic into a list an administrator can investigate. When an organization approves one of those servers, it can place the server behind a Cloudflare MCP server portal. The Portal gives employees one managed endpoint and puts Access identity, a curated tool catalog, and logging in front of the upstream server. Administrators can route compatible upstream calls through Gateway for HTTP policy, predictable egress, and data loss prevention, either across the Portal or for an individual server. Tool activity can also be exported through Logpush. The discovery dashboard can then distinguish requests that use the Portal from direct connections to the same server.

This creates a path from discovery to governance: find the server, decide whether to approve it, move approved use behind the Portal, and investigate traffic that continues to go around it. That last step matters because unapproved servers and bypasses of approved servers are different problems.

Enforcing Portal-only access

We are adding Traffic Source selectors to Gateway Network and HTTP policies to give administrators the fidelity to write rules to control MCP traffic based on whether or not originated from your MCP Portals.

When MCP Portal traffic routes through Gateway it carries an mcp_portal Traffic Source, which lets policy distinguish Portal-proxied requests from direct employee connections. A baseline enforcement rule looks like this:

Any detected MCP traffic that did not arrive through a Portal gets blocked; traffic that came through the Portal is unaffected. For organizations that want to observe before enforcing, Traffic Source and MCP detection now exist in HTTP logs for traffic that has been decrypted, so you can monitor behavior for proxied traffic without the need for a policy.

More MCP servers can now use the governed path

An approved path is only useful if it can connect to a critical mass of the servers employees actually need.

Earlier MCP specifications recommended Dynamic Client Registration, where the client registers itself with an authorization server without an OAuth application. Many common OAuth providers use a different model: they require an administrator to register an application with a fixed client ID, client secret, callback URL, and set of scopes. MCP 2026-07-28 also recently deprecated dynamic registration.

To help alleviate this, MCP Portals now support pre-registered OAuth clients. An administrator can configure manual OAuth credentials, register the callback URL shown in the dashboard with the upstream provider, and enter the client credentials. The Portal discovers standard OAuth metadata when available, and the administrator can provide the authorization, token, revocation, and issuer endpoints when discovery is not possible.

Each user still authorizes access to their own upstream data sources, and the stored client secret is used only to fetch updated tool and prompt lists.

Manual OAuth support now helps to cover the many permutations of OAuth implementations. Some providers require custom headers, personal access tokens, or an explicit client allowlist, and those are separate compatibility problems. We will continue to expand the OAuth support of MCP portals in the coming months.

Bringing private MCP servers into the same Portal

Public SaaS tools are only part of an enterprise's MCP catalog. Most secure information that businesses rely on is not available from the public Internet; it exists in public or private cloud infrastructure, or is hosted on-premise, and is only reachable through connectivity to private networks.

Today, an MCP Portal must be able to resolve and reach an upstream server over the public Internet. This means that servers that are only available on private networks —  via private DNS or inside private IP space — can’t be reached by Portals. We are working to let MCP Portals connect to private servers through Cloudflare Gateway routing and the same Cloudflare One network that is already used for other private applications.

The private server keeps its private hostname; the Portal reaches it through Cloudflare's private routing and presents its tools beside the public upstream servers; and Access policy, Portal logging, and tool controls continue to apply at the same front door.

Routing Portal traffic through Gateway also stamps it with the mcp_portal Traffic Source, so Gateway policy can distinguish a Portal request from a direct employee connection. Private connectivity for MCP servers is in active development; keep an eye on the Changelog for more information.

Agents SDK supports the new stateless model

A few weeks ago, the MCP project published the 2026-07-28 specification, a major revision that replaces connection-scoped initialization with a stateless, per-request model. We covered the protocol changes and migration path in The next generation of MCP.

Cloudflare Agents SDK v0.20.0 supports MCP 2026-07-28 as both a client and a server. For each connection the client first probes for the new stateless protocol with server/discover; if the server does not support it, the client continues with the legacy initialize handshake on the same connection. Existing addMcpServer calls do not need separate protocol settings or separate clients.

On the server side, createMcpHandler can serve stateless tools, prompts, resources, and elicitation from a Worker without creating a transport session or Durable Object:

The fallback matters because protocol migrations rarely happen all at once. A new client still needs to reach an existing server, and a new server still needs to handle clients that have not moved yet. The Agents SDK supports both paths while the ecosystem transitions.

Start with visibility, then close the paths that should not exist

A workable MCP security program starts with understanding your users’ traffic profiles, MCP usage, and aligning on an approved set of tools and access methodologies.

First, inspect the MCP traffic that traverses Gateway and compare its destinations with the servers your organization has approved. Move more approved servers behind MCP Portals.

Then, enforce the boundary you can control. Compose Gateway policies which use the MCP detection conditions together with the Traffic Source and Destination conditions to block direct MCP connections from managed devices and sites, and restrict self-hosted upstream servers to Portal traffic where possible.

We will soon be adding more granular functionality for visibility and control of MCP traffic, including control over specific tool use and new reporting on tool usage across all MCP servers within your environment — whether they are known or unknown to your security organization.

Our MCP traffic detection tutorial covers the hostname, path, and JSON-RPC heuristics available for Gateway logs today. We will update the documentation with the protocol selector details as the new signal reaches general availability.

Everything we launched during Agents Week

Post Syndicated from Shelley Jones original https://blog.cloudflare.com/agents-week-review-august-2026/

At the beginning of Agents Week, Rita shared that agents represent the next evolution of computing: not only as a new application of AI but also as a new class of software that’s shaping how people interact with technology, and how software interacts with the Internet. Over the last year or so, we set out to explore what this shift means for developers and customers building AI-native apps and the infrastructure needed to support them. As agents become more capable and autonomous, the challenges extend beyond the models themselves — to identity, communication, orchestration, memory, observability, and security.

Over the past week we’ve shared how we’re bringing those pieces together across the Cloudflare platform to serve an Agentic Internet. Each day we presented new tools, products, and ideas toward building for an Internet where humans and agents cooperate instead of collide.

Monday, August 3

Monday focused on the foundations for building and running intelligent, autonomous apps — the runtime and infrastructure agents rely on.

Tuesday, August 4

Tuesday introduced the Agent Development Lifecycle (ADLC) and the primitives that take agentic software from prototype to production.

Wednesday, August 5

Wednesday extended Zero Trust from users and devices to agents themselves — and we shared how we’re running it internally at Cloudflare. 

Thursday, August 6

Thursday defined the Agentic Internet, and how website owners, publishers, and agents can all contribute to an Internet that works for people and agents alike.

Friday, August 7

Friday put a lens on what’s actually happening: what agents are really doing on the web, where AI is running in your apps, who’s contributing to the ecosystems, and new tools for analyzing Internet data.

Agents Week is done, but we aren’t

Five days on, the answer to Rita’s question of “What does your agent need from an Agent Cloud?” is starting to take shape. It needs an execution layer and primitives to run on, a development lifecycle that increasingly writes itself, secure access for the people and agents doing the work, an Agentic Internet, and the humans and communities keeping all of it grounded. There's plenty still to come, but the shape of what’s next is becoming clearer: an Internet that natively supports the humans it was built for and the agents now acting on their behalf.

Our work doesn’t stop here. Keep an eye on our changelog for the latest updates. And if you’re building any part of this with us, we’d love to hear from you! Come find us on X or Discord.

Cloudflare is the only vendor named a Visionary in 2026 SASE and SSE reports

Post Syndicated from Michael Keane original https://blog.cloudflare.com/cloudflare-sase-sse-gartner-magic-quadrants-2026/

We're honored to announce that Cloudflare is the only vendor that has been recognized as a Visionary in both the 2026 Gartner® Magic Quadrant™ for SASE Platforms and the 2026 Gartner® Magic Quadrant™ for Security Service Edge reports. To us, this validates our architectural choices and, more importantly, reflects the trust our customers place in us to navigate an increasingly complex security landscape.

To every customer who shared feedback with Gartner, discussed your roadmap challenges with our team, and pushed us to build better solutions: thank you. This recognition belongs to you as much as it does to us.

The SASE (Secure Access Service Edge) and SSE (Security Service Edge) markets are at an inflection point. Many organizations started with the SSE as the “security half” of SASE to tackle their remote work challenges during the pandemic. More recently, SASE has grown more prominent given the rise in return-to-office work mandates. Now, as AI agents, post-quantum threats, and the sprawl of shadow apps reshape enterprise security, organizations need platforms that can adapt at the speed of change, not vendors locked into yesterday's architecture. That’s exactly where Cloudflare One, our agile SASE platform, comes in.

The market gap and where SASE is heading next

It’s no secret that most SASE vendors haven't adapted to the architectural realities of modern enterprises. In fact, when customers migrate to Cloudflare, we hear some of the exact same challenges time and time again:

Fragmented architectures: When SASE platforms are stitched together through mergers and acquisitions, deploying use cases across multiple products becomes a massive headache. Cloudflare mitigates these implementation nightmares and security gaps with a connectivity cloud approach: one global network that connects and protects your workforce, AI agents, and infrastructure.

Unmanaged AI agents: The market rushed to secure human GenAI prompts, leaving AI agents largely ungoverned. Cloudflare was the first SASE platform to rein in MCP server sprawl, natively governing AI agents and human users together for total visibility. The interaction between our SASE and AI Gateway also lets admins cap AI inference costs per user, team, or application to prevent runaway bills. This is especially important when employees can rack up thousands of dollars in queries without realizing it. 

Theoretical post-quantum security: While other vendors discuss post-quantum cryptography in theory, we built it into our fabric. We were the first SASE platform to deploy post-quantum encryption across all major on- and off-ramps, and we’re neutralizing "harvest-now, decrypt-later" threats for regulated industries right now.

Nickel-and-dime pricing: Legacy vendors have a bad habit of turning advanced capabilities into expensive add-ons, or double-charging for remote and office work. Cloudflare delivers predictable, value-driven SASE bundles designed for holistic adoption, with no hidden fees.

Technological pressures reshaping SASE

We believe the SASE platforms of tomorrow will need to be much more than bundled security and connectivity. Over the coming year, four major technological shifts will force SASE to evolve into a highly agile governance layer:

Securing the "vibe-coded" app explosion: AI has made it easier than ever for employees to spin up internal tools with zero IT oversight. This shadow IT sprawl requires a secure-by-default posture. SASE platforms must automatically wrap these citizen-developed apps in zero trust access, WAF, API protection, and data loss prevention (DLP), safeguarding sensitive AI prompts without slowing builders down.

Reining in AI agents: Traditional SASE tracks human behavior, but the future is autonomous. As we shift to agentic operations, SASE must issue strict, highly scoped credentials for specific bot tasks rather than inheriting broad human permissions. Adaptive access also has to get smarter, analyzing agent intent and baselining tool-call volumes to catch anomalies instantly.

Delivering post-quantum agility today: Quantum computing is accelerating, meaning organizations must protect against "harvest-now, decrypt-later" attacks right now. The market demands native post-quantum encryption that can adapt as NIST standards finalize. By 2028, Cloudflare targets delivering the first fully quantum-secure SASE platform, including post-quantum authentication, years ahead of the 2030 National Institute of Standards and Technology (NIST) mandate, with no impact on user experience.

Deeper architectural consolidation: Deployment fatigue is real, and CIOs are tired of hollow "platformization" pitches. Genuine consolidation only happens on a single codebase with truly unified control, data, and infrastructure planes. To move at the speed of AI, composability and programmability have to be an architectural reality, not a marketing slogan.

These aren't just predictions for the future. They're the realities our customers are facing today, and the exact roadmap we are building together.

Why Cloudflare stands out

If there is one thing that defines Cloudflare’s edge in the SASE market, it’s our architecture. Many legacy SASE solutions are patchworks of disparate technologies stitched together. Cloudflare took a different route and built a unified platform from the ground up. This clean, composable design gives our customers three massive advantages:

The fast path to safe AI adoption

The rest of the market has largely treated AI security as just another bolted-on feature. But because Cloudflare shares a single architecture across our entire global network, we can rapidly roll out new security tools within our SASE platform without waiting for product integration cycles or vendor roadmaps to align.

Thanks to our composable design, your administrators can easily extend coverage using familiar SASE policies, while also keeping costs under control. Securing human GenAI prompts or governing an AI agent's connections to an MCP server happens in the same policy language they use every day. It’s not an add-on module with its own learning curve; it’s built right in.

Whenever your developers build a new AI assistant, or your finance team starts using an AI-powered forecasting tool, Cloudflare's zero trust policies are already there. You never have to retrofit security. You just apply the framework you already rely on.

SASE that’s actually easy to use

First-generation SASE platforms have a bad habit of routing traffic through multiple disjointed inspection points. The result? Complicated deployments, blown timelines, and delayed success. "Single-vendor SASE" has historically been a great pitch on a slide deck, while in reality, customers are stuck managing stitched-together engines under the hood.

Cloudflare’s composability fixes this by delivering an exceptionally intuitive SASE experience. Our architecture is unified by design; every service runs on every server across our entire network. That means no traffic tromboning between specialized appliances, no more capacity planning across siloed products, and no hidden complexity.

By operating like a modern SaaS platform, we are designed for teams to intuitively deploy new use cases in days and weeks, rather than months and years. Need to extend zero trust access to a new app, add DLP to your Gateway traffic, or bring a new office location online? Cloudflare responds at the speed of configuration.

Truly programmable SASE

Too often, the industry waters down the word "programmable" to mean simple automation, like GUI workflows or basic APIs on top of rigid logic. The result is that most SASE platforms feel like black boxes that force you to work around your vendor's limitations.

We built a truly composable, programmable SASE platform that runs natively with our edge developer platform, empowering you to weave custom code directly into our SASE fabric. Want to enrich access decisions using real-time signals from niche, internal tools? Building a custom workflow to route traffic based on a unique application context?

By integrating Cloudflare Workers into our SASE stack, customers can solve sophisticated, highly specific edge cases, without requiring custom feature development that would add bloat and reduce usability for everyone else. It's a level of flexibility legacy architectures just can't offer, and thanks to AI code generation, it's never been easier to implement.

Looking ahead

This recognition from Gartner is a fantastic milestone for us, but we're already focused on the road ahead. Our promise to you hasn't changed: we will keep listening to your feedback, building the primitives that help you adapt, and delivering a platform that gets easier to use even as your challenges grow more complex. To us, agile SASE means enabling our customers to confidently respond to whatever tomorrow brings.

Whether you're actively evaluating SASE platforms or just trying to navigate the shifts we've discussed, we'd love to connect. Download the full Gartner reports (for SASE or SSE, or both), take a closer look at Cloudflare One, or reach out to our team directly.

Gartner, Magic Quadrant for SASE Platforms, Analyst(s): Jonathan Forest, Andrew Lerner, John Watts, July 28, 2026

Gartner, Magic Quadrant for Security Service Edge, Analyst(s): John Watts, Thomas Lintemuth, Theo de Feligonde, Jonathan Forest, July 29, 2026

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

WriteGuard: fine-grained controls for MCP Servers

Post Syndicated from Scott Roe-Meschke original https://blog.cloudflare.com/mcp-portal-writeguard-private-beta/

Let’s imagine the Case of the Endlessly Closing Tickets. 

The bug tickets start closing at noon. Nobody thinks much of it. Joe moved a few tickets to Done, and Joe is having a productive afternoon. Then the pace picks up. By 4 p.m., thousands of tickets have been closed, all by Joe.

Joe is a good engineer. Joe is not a thousand-tickets-an-hour engineer.

We learn that he has several background agents running across three concurrent sessions. It takes half an hour to find the one at fault: a cleanup task with a prompt that was a little too broad.

Once we’ve stopped the agent, we need to repair the state of the ticketing system. Joe has also been legitimately closing tickets by hand that afternoon. The system records all those changes under Joe regardless of whether it was him or his agent, and the network logs do not distinguish one agent session from another. From the outside, the actions look identical.

The example above is relatively low-stakes, but we can all imagine, or read about, much more destructive cases. An agent with access to contract software could amend an agreement. An agent wreaking havoc in a support queue could send hundreds of replies to customers. An agent with database access could drop entire tables.

At Cloudflare, we knew we could not depend on every employee to configure every agent perfectly or watch every tool call. So before expanding write access across our own internal MCP servers, we built WriteGuard. We are now bringing those controls to Cloudflare MCP server portals through a private beta.

MCP Fundamentals

Before explaining WriteGuard, let’s review what an MCP server is and how it works with AI agents.

MCP stands for Model Context Protocol, a popular standard for connecting AI applications to external tools and data sources. MCP servers provide tools that connected clients can use. Each tool has a name, a description, an input schema, and a handler that performs the work.

When an agent selects a tool, the MCP client sends the tool call to the server, which then interacts with the downstream application. 

MCPs at Cloudflare

MCP is a critical piece of the infrastructure powering Cloudflare's internal agents. Those agents use MCP through local clients such as OpenCode and Cloudflare OS, as well as through long-running agentic services. We run the servers behind Cloudflare Access and connect to them through a single internal MCP server portal.

When we described our internal AI engineering stack in April, our portal connected 13 MCP servers. Today, it connects 27, with teams shipping more servers every month. They all began as read-only servers, allowing teams to search Jira, GitLab, our wiki, and operational systems without changing them.

Read-only was a good starting point. As models improved and teams gained experience with AI, people across engineering, product, design, sales, and customer success began asking for tools that could take action.

To avoid our own case of the endlessly closing tickets, we wanted centralized control over the write actions agents could perform, agent labels to appear in downstream applications, and an audit trail that made agent activity easy to investigate. We could not count on client-side controls such as skills or elicitation prompts. Their behavior varies by harness, and users can disable them.

So we built WriteGuard.

Introducing WriteGuard

WriteGuard is a shared policy, attribution, and auditing layer.

It uses each tool’s configuration and the request context to determine what happens. WriteGuard can pass a call through unchanged, enrich supported writes with agent attribution and produce a scrubbed audit event, or block an action before its handler runs.

The diagram below shows where WriteGuard sits in our current internal MCP architecture.

WriteGuard combines tool policy with human and agent identity, downstream attribution, and centralized auditing. It gives us one place to control agent actions and preserve the context needed to understand them.

Beyond callable tools to governable actions

WriteGuard lets us define policy alongside each tool without changing the underlying MCP server. Every tool gets a risk tier, an enabled or disabled state, and a labeling configuration. Risk tiers determine whether the action is logged and whether the tool call is permitted, and the tiers allow for querying the audit log by risk. We support labeling so that we can insert agent attribution labeling and use the best text format for the downstream application, without any code changes needed in the MCP server itself.

Today, we define this configuration in TypeScript in our internal MCP monorepo. As private beta access rolls out in the coming months, server owners will be able to configure the same policies through Cloudflare MCP server portals. Every MCP server will have a baseline Access policy along with WriteGuard controls for individual tools.

Keep the person, add the agent

Our internal MCP servers use Cloudflare Access and OAuth to identify the user. Agents using those servers therefore operate with that employee’s permissions. If Joe cannot close a particular issue, Joe’s agent cannot close it either.

We kept that model instead of introducing standalone agent accounts. Agent accounts would create a second set of permissions to manage and make the connection to the person responsible for the agent less clear. The tradeoff with that decision, however, is that downstream applications see Joe’s credentials but nothing identifying the agent behind the action.

WriteGuard adds MCP client and session context to the human identity, identifying each write as an agent session acting on behalf of a particular person. Notably, that attribution is extremely useful even when nothing goes wrong. It helps humans and other agents interpret changes and decide how to respond.

Make machine-speed activity queryable

Visible labels explain individual actions and provide helpful context in the downstream application, but they don’t provide a fleet-wide view. Because an agent can repeat an action much faster than a person, we also needed central auditing across every MCP server.

WriteGuard classifies each invocation as successful, failed, or blocked, then asynchronously sends a scrubbed event to an internal audit Worker. The event omits values for keys considered secret or sensitive. It includes the server, tool, risk tier, outcome, user, client, and duration.

This makes agentic activity queryable across all of our MCP-enabled systems.

The dashboard complements the request logs provided by MCP server portals. Portal logs show tool invocations, while WriteGuard adds semantic tool classifications, agent context, and outcomes from the backing servers.

We made audit logging asynchronous, so it adds no latency to the response the agent is waiting for.

WriteGuard in Action: GitLab

Earlier in this post, we mentioned three tools from our GitLab MCP server: get_merge_request, create_mr_note, and merge_mr. Let’s follow each one through WriteGuard.

Reading a merge request

Suppose an engineer asks an agent to summarize a proposed code change and the agent calls the get_merge_request tool. WriteGuard classifies the tool as READ_ONLY and WriteGuard allows the call to pass through unchanged.

Adding a note to a merge request

Now the engineer asks the agent to leave comments on a merge request (MR), and the agent calls the create_mr_note tool.

The tool is classified as CONTAINED_WRITE. WriteGuard adds agent attribution to the configured note field using a format GitLab supports, then invokes the tool handler. It also asynchronously records a scrubbed audit event containing the user, tool, outcome, and agent identity context.

Merging the code

Suppose an engineer asks an agent to help review a merge request. Trying to be helpful, the agent goes beyond the request and calls the merge_mr tool without being asked.

Because merges at Cloudflare typically trigger deployment pipelines, we require a human in the loop. We therefore classify the merge_mr tool as CRITICAL risk tier and configure the tool disabled in WriteGuard.

If called, WriteGuard will block the request before its handler runs and record the attempt.

Beyond the single server example

These tools use the same server, identity flow, and downstream API, but WriteGuard handles each one differently before its code runs.

For GitLab alone, we could have built these controls directly into the server. But we needed the same capabilities for Jira, our internal wiki, Google Workspace, and every new MCP server we added. Reimplementing them in each server would take more work and produce inconsistent behavior.

Instead, we built WriteGuard as a shared layer that needs only per-tool configuration and works across every MCP server connected through the portal.

From internal rollout to private beta

We built WriteGuard for Cloudflare's own MCP servers because we needed to move beyond read-only tools without losing control of the writes that followed. The private beta brings that architecture to MCP server portals, providing a way to classify write tools, block tools before execution, add agent attribution, and inspect write activity across connected servers.

The beta will start small and expand over time, leading up to general availability. We want to validate how the risk model maps to customer tools, which downstream applications need attribution formats, and what audit delivery guarantees customers require before making WriteGuard broadly available.

If your organization is adding write tools to MCP servers and wants to test these controls with us, sign up for the WriteGuard private beta.

Introducing the Cloudflare One stack: agent-powered deployment

Post Syndicated from AJ Gerstenhaber original https://blog.cloudflare.com/cloudflare-one-stack/

Adopting or migrating to a Zero Trust network architecture can be a daunting task. Before a single policy changes, teams have to recall how their network is actually built: which applications exist, their authentication and authorization constructs, how traffic flows between them, and any assumptions the current architecture makes. This hands-on process requires practitioners to decode the intent behind every security and routing policy in place.

Today, we’re releasing the Cloudflare One stack, a set of skills you give to your agent to configure, deploy, and manage your Zero Trust environment for you. This toolkit is designed to help automate the process of learning an entirely new security suite and mapping your existing one into Cloudflare.

Cloudflare has worked with thousands of customers through exactly this process. That repetition built expertise on where migrations stall, what questions come up every time, and what it takes to move forward. The Cloudflare One stack packages that expertise and makes it more accessible than ever. 

The agent gap in network security

Teams are already using agents to write code, triage alerts, and automate workflows. Organizations are increasingly asking for Cloudflare-provided tooling to help agents execute on security workflows. On their own, agents are not trained on the nuances of an organization’s specific network topology or vendor configurations.

By providing prescriptive and authoritative guidance, organizations can layer this context into their existing toolkit to make better use of the security products they are already deploying.

Cloudflare has long been the easiest-to-deploy SASE vendor in the market. The stack extends that philosophy to agents: it gives them the context, tools, and structured reasoning they need to operate on your security infrastructure.

What is the Cloudflare One stack?

The Cloudflare One stack is a collection of skills that can be used with any agent. As with any skill, you can use them standalone, layer in your own context, or build tooling on top. It was purpose-built to help security practitioners across the entire lifecycle of evaluating, deploying, and managing Cloudflare One.

The stack was built by synthesizing hand-curated knowledge from employees with tens of thousands of hours of experience working with customers on Cloudflare One products. It contains tools for planning, managing, and implementing your user and agent security infrastructure on Cloudflare. It also contains handpicked logic for migrating from legacy vendors like Zscaler and Palo Alto Networks.

When used in conjunction with the Cloudflare code mode MCP server, the stack gives agents a typed interface to the Cloudflare API. Agents can query your live account, inspect configurations, and make changes through a curated set of Cloudflare-recommended workflows rather than ad-hoc API calls.

What’s in the stack?

The Cloudflare One stack ships as two lightweight skill files: cloudflare-one and cloudflare-one-migration. Together they cover migrating to, building an implementation for, managing, and troubleshooting your Cloudflare One deployment:

  • Remote access and VPN replacement with Cloudflare Access

  • User, network, device, and data security with Cloudflare Gateway

  • Connectivity with Cloudflare Tunnel, Cloudflare Mesh, and Cloudflare WAN

  • Migration guidance with explicit detail for moving from other SASE vendors

  • Network diagram interpretation and generation, so you can visualize proposed changes to your network in a way that is easy for you and your team to understand

  • Vendor concept translation, which maps concepts between SASE vendors to reduce the barrier to evaluating and switching providers

  • Troubleshooting and operations, with the Digital Experience Monitoring (DEX) toolkit and automated rule recommendations

How it works

The stack is available in the Cloudflare Skills repository. Each skill file contains structured knowledge, decision trees, and tool definitions that agents load automatically when the context matches. Give this to your agent and let it help you set up, configure, and manage your Zero Trust environment:

The cloudflare-one skill covers general product guidance. For example, if you ask an agent for the best way to replace your VPN infrastructure with Cloudflare Tunnel or Cloudflare Mesh, the skill knows how to:

  1. Inventory your existing VPN applications and identify which connectivity model each requires

  2. Map each application to the appropriate Cloudflare primitive — self-hosted Access application, Tunnel-connected service, or Mesh-connected network segment

  3. Generate a recommended deployment sequence that minimizes disruption during cutover

  4. Produce a configuration summary your team can review before making any changes

The cloudflare-one-migration skill covers vendor-to-vendor translation. For example, if you ask an agent to migrate your Zscaler Private Access applications to Cloudflare Access, the skill knows how to:

  1. Map Zscaler application definitions to Cloudflare Access application definitions

  2. Transform Zscaler user groups and policies into Cloudflare Access policies

  3. Use the Cloudflare API to create the equivalent resources in your account

  4. Generate a summary of what was migrated and what requires manual review

The migration logic in the stack is the same logic used in Cloudflare’s Descaler and Deskope programs. Those programs have already moved enterprise customers from Zscaler and Netskope to Cloudflare One in hours rather than months. The stack makes that capability available to any customer or partner, at any time, without waiting for a scheduled engagement.

More ways to use the stack

The Cloudflare One stack can also:

  • Recommend security rules based on traffic seen in your live account

  • Automatically migrate your existing Zscaler Private Access applications into self-hosted Cloudflare Access applications

  • Investigate anomalies in your secure web gateway HTTP logs and build rules to resolve issues users are seeing

  • Report on user stability with the DEX toolkit and take actions to improve user latency in key scenarios

Whether you are loading the skill from an agent or building custom tooling on top, the Cloudflare One stack handles all of these use cases and more.

For partners, too

While this simplifies ongoing management for customers who have already adopted the Cloudflare One product suite, it is also a tool for the Cloudflare partner network. Partners can use it to help their customers deploy faster, manage more effectively, troubleshoot with increased accuracy, and drive issues to resolution.

What’s next

You can start using the Cloudflare One stack today. To get the most out of the stack, pair it with the Cloudflare code mode MCP server. The MCP server gives your agent live access to the Cloudflare API through a single, compressed interface that keeps authentication credentials out of the model context. 

The Cloudflare One stack will continue to expand as Cloudflare One products evolve. New skills for additional migration sources and more advanced troubleshooting workflows are already in development.

As we learn more about how customers and partners utilize these skills files, we plan to build more robust tooling around these skills. If you are a customer or partner and want to share feedback on what the stack should handle next, reach out through your account team or open an issue in the repository.

Route public traffic to private applications with Cloudflare

Post Syndicated from Enrique Somoza original https://blog.cloudflare.com/private-origins-dns-routing/

For most of the Internet’s history, public and private infrastructure operated as separate worlds. Public applications lived behind content delivery networks (CDNs) and web application firewalls (WAFs). Private applications lived behind virtual private networks (VPNs), firewalls, and separate operational stacks. We think that distinction is becoming obsolete.

Many of the applications organizations care about are not public websites. They are internal APIs, AI agent backends, MCP servers, operational tools, and services that were never designed to be exposed to the public Internet. Yet these applications still need modern security, performance, and programmability services. Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit.

Until now, applying those services to private applications often required public IPs, firewall exceptions, connector software, or complex networking. As a result, many private applications missed out on capabilities such as WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, despite needing the same protections and controls as public-facing applications.

Today, we’re launching Application Services for Private Origins in closed beta for eligible Enterprise customers. Customers can now securely route traffic to private origins without exposing those origins to the public Internet. This allows Cloudflare’s security, performance, and programmability services to protect applications running on private networks, just as they do for public Internet applications.

WAF rules, bot management, rate limiting, caching, rewrites, and Workers can now sit in front of private origins without requiring public IP exposure, inbound firewall rules, or cloudflared running on the origin.

Four use cases, one application layer

This routing model builds on connectivity patterns Cloudflare already supports today through Cloudflare Tunnel, Cloudflare One Client, and private network integrations. For years, Cloudflare Tunnel has allowed customers to route public traffic to private applications through cloudflared. This new capability extends the same model to existing Cloudflare WAN or Cloudflare Mesh connectivity without requiring connector software running on the origin.

Much of that connectivity is orchestrated through Cloudflare’s private networking routing layer that determines how traffic reaches private destinations across Cloudflare Tunnels, Virtual Networks, Cloudflare Mesh, and other connectivity models. Customers can define their routing behavior through APIs and the dashboard instead of managing separate networking stacks for each product.

We have extended Cloudflare’s private networking layer directly into the application services stack, allowing security and performance proxy infrastructure to treat private IPs as valid origin targets for public hostnames. As a result, the same private IPs previously reachable only through Cloudflare Tunnel, Cloudflare One, Cloudflare Mesh, or Cloudflare WAN can now sit behind Cloudflare’s security, performance, and programmability services the same way public origins already do.

This also creates a more unified model across Cloudflare products. Workers VPC bindings and Spectrum private origin routing now rely on the same underlying private connectivity layer, giving customers a single source of truth for controlling how private traffic moves through their Cloudflare environment.

Application traffic now falls into four combinations based on where users come from and where applications live:


The combination on the upper right is what Cloudflare has always done: users on the Internet reach applications on the Internet, with Cloudflare in the middle. The bottom right is Cloudflare One: users on private networks reach public services securely. 

The upper left is what we are shipping today. The bottom left, private-to-private, is what we are building toward next.

What is shipping today

Until now, getting public traffic to a private origin often meant making tradeoffs. Customers could use Cloudflare Tunnel, which runs cloudflared, our connector software, on or near the origin, or Cloudflare Load Balancing with private origin pools for health checks and failover. In many cases, organizations also maintained parallel infrastructure such as public-facing load balancers, reverse proxies, mTLS between hops, and TLS termination across multiple layers. As a result, applying Cloudflare’s full Application Services stack to private applications often required additional complexity, operational overhead, or separate products. Application Services for Private Origins removes those tradeoffs.

What was missing was a path for customers who already operate Cloudflare WAN (IPsec tunnels, GRE tunnels, CNI links) or Cloudflare Mesh. They had built private connectivity into Cloudflare for site-to-site networking and Zero Trust, and they wanted to use that same connectivity for public traffic to private origins. That is what Application Services for Private Origins delivers.

When you toggle Use private network routing on a proxied A or AAAA record, Cloudflare’s WAF, rate limiting, caching, bot management, and transform rules all run as normal on Cloudflare’s network. The only difference is the final hop: instead of reaching the origin over the public Internet, Cloudflare routes the connection through your existing private network connectivity.

The toggle is enabled automatically for RFC 1918 private IPv4 ranges (10.x.x.x, 172.16.x.x–172.31.x.x, and 192.168.x.x), RFC 6598 CGNAT ranges (100.64.x.x–100.127.x.x), and RFC 4193 Unique Local IPv6 Addresses (FC00::/7), since these addresses are only reachable within private networks. For public IP addresses that are reachable only through your private network or tunnel, you can enable the toggle manually.


What the API looks like

For customers automating deployments through the API, private routing is simply an additional attribute on a standard DNS record.

POST /zones/{zone_id}/dns_records
{
 "type": "A",
 "name": "app.example.com",
 "content": "10.0.0.50",
 "ttl": 300,
 "proxied": true,
 "use_private_routing": true
}

Behind the scenes, Cloudflare’s proxy platform determines where to send traffic for app.example.com by querying Cloudflare’s Origin API. The response includes metadata indicating that the destination should be reached through a private network path:

{
 "zone_name": "example.com",
 "ipv4_addresses": ["10.0.0.50"],
 "use_private_routing": true
}

The use_private_routing flag is the key signal. When our proxy sees it, instead of attempting to connect directly to the private IP address over the public Internet, it hands the request to our private networking layer, which then routes the connection across the customer’s existing private network connectivity, whether that’s IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh.

Beyond HTTP: Spectrum and Workers VPC

The same routing model now extends beyond HTTP applications. The origin does not have to be a web server. It can be a TCP database, a UDP logging endpoint, or a private API that Workers call directly. The common thread is that Cloudflare sits between your traffic and your private network, applying the same security, performance, and routing layer regardless of protocol or where the request originated.

Spectrum, Cloudflare’s Layer 4 proxy, can now sit in front of TCP and UDP services running on private IPs. Instead of creating a load balancer pool as an intermediary, Spectrum applications can specify a virtual_network_id directly on the origin configuration. When you create a Spectrum application, you can include the virtual network ID alongside your private origin IP:

{
 "protocol": "tcp/22",
 "dns": {
   "type": "CNAME",
   "name": "ssh.example.com"
 },
 "origin_direct": ["tcp://10.0.0.50:22"],
 "virtual_network_id": "fab9ac85-491b-44c8-b7ae-dd44d4f4672e"
}

When you create or update a Spectrum application with a private origin and virtual network, Cloudflare verifies that the IP address matches a route in your Cloudflare Tunnel before the configuration is saved. If no matching route exists, the API rejects the request and the application is not created. Once saved, Spectrum hands the connection to your virtual network, which routes it through the associated tunnel, via the same path that HTTP traffic uses when you enable private network routing on a DNS record. In this initial release, Spectrum private origins are supported through Cloudflare Tunnel. Support for additional private network connectivity options will follow in future releases.

This means you can now put Spectrum in front of any TCP/UDP service running on a private IP. The service stays private. No public IP, connector software, or load balancer required.

Workers VPC closes the loop for code running on Cloudflare. A binding tells the Workers runtime to route through the same private path as DNS records. Browsers, mobile apps, Workers, and AI agents all reach your private origins through Cloudflare: DNS records for Internet traffic, bindings for Workers.

What comes next

Public-to-private routing is in closed beta today, and we are targeting GA (General Availability) in Q4 2026.

Beyond GA, we are building toward private-to-private traffic flows: users, services, and AI agents on private networks securely reaching applications on other private networks, with Cloudflare’s application services sitting in the middle.

We are moving toward a model where the same Cloudflare infrastructure can secure traffic regardless of whether the user or the origin is public.

The end state is a world where an employee on Cloudflare One Client accessing wiki.company.internal gets the same WAF, rate limiting, and bot management protections as a customer accessing a public API. An AI agent consuming a proprietary internal API runs through the same security stack as a browser. Service-to-service traffic across clouds and data centers gets the same controls as Internet traffic, even when neither the user nor the server sits on the public Internet.

Get started today

Routing to private origins is available today in closed beta for eligible Enterprise customers. Reach out to your Cloudflare account team to request access. Once enabled, follow our developer documentation, which walks through the full setup. You will need Cloudflare One connectivity (IPsec, GRE, CNI, or Cloudflare Mesh) and a return route for Cloudflare’s source IP range 100.64.0.0/12 in your private network.

Questions or feedback? Join the conversation in our community forums or reach out to your account team.

Announcing Claude Compliance API support with Cloudflare CASB

Post Syndicated from Abe Carryl original https://blog.cloudflare.com/casb-anthropic-integration/

Today, we are extending Cloudflare’s cloud access security broker (CASB) to support the Claude Compliance API. Security and compliance teams can now monitor Claude usage directly in the Cloudflare dashboard. No endpoint agents required.

Enterprise security teams have long struggled to see how users interact with sanctioned and unsanctioned applications. The rapid adoption of AI applications has made this harder. Employees spend significant time in these new surface areas, and their interactions differ from traditional SaaS: users upload files, share freeform prompts, and providers generate content that may contain sensitive data.

Cloudflare CASB helps solve this problem. One API integration gives you out-of-band visibility and control over the applications your organization uses. This integration builds on our existing support for AI governance, extending coverage over the most common tools security teams now manage. 

The fast path to safe AI adoption

AI adoption has outpaced security governance. While IT and security teams raced to enable AI tools for productivity, the controls lagged behind. Most organizations today operate with partial visibility: they may block unauthorized AI tools at the network layer, but they cannot see what happens inside sanctioned ones.

This matters because AI tools are not like traditional SaaS applications. They are conversational, persistent, and deeply integrated into workflows through APIs and agent frameworks. An employee might paste customer data into a prompt. A developer might accidentally share an API key and leave it unrotated for months. An AI application might generate content which contains company secrets. Each of these actions creates compliance risks that conventional security tools cannot detect.

Organizations are moving fast to adopt AI, but these tools require a different security model. They do not just read data; they generate it, act on it, and connect to multiple systems of record in a single workflow. Security needs to cover the full lifecycle: from how an application calls an API, to what data it handles, to where that data lives at rest. Cloudflare gives organizations the tools to do this at every point of the workflow:

  • Cloudflare AI Gateway sits between your applications and AI providers like Anthropic, giving you observability into requests, token spend, and model performance. This allows administrators to enforce rate limits, cache responses, and make fine-grained routing decisions. 

  • Cloudflare Gateway and Data Loss Prevention inspect AI traffic for sensitive data, blocking prompts that contain customer personally identifiable information or confidential material before they reach the model.

  • Cloudflare Access with MCP server portals centralizes agent connections to corporate tools behind a single protected endpoint. Administrators control which users and agents can reach which systems, and every request is logged for audit.

  • Cloudflare CASB now extends this same unified approach to data at rest inside Claude, scanning for misconfigurations and sensitive data without endpoint agents.

These capabilities run side by side, on the same metal, making each service both composable and programmable. More importantly, that means traffic never hairpins through multiple vendors or clouds to be secured. 

Better insight and control with Cloudflare CASB

Cloudflare CASB helps organizations connect to, scan, and monitor third-party SaaS applications for misconfigurations, improper data sharing, and other security risks through lightweight API integrations. Organizations can regain visibility and control over their growing investments in SaaS apps.

As enterprises deploy Claude at scale, security and compliance teams need the same visibility into Claude usage that they have for every other enterprise application in their stack. Anthropic recognized this gap and built the Claude Compliance API to give enterprises programmatic access to security-relevant data about their Claude organizations, workspaces, and usage. 

Cloudflare CASB now consumes this endpoint to surface actionable security findings without requiring inline traffic inspection or endpoint agents. 

What the Claude Compliance API surfaces

With this integration, Cloudflare One customers can monitor Claude Enterprise activity using the detection and remediation workflows they already rely on. Cloudflare CASB connects to Claude via the Compliance API and scans for security findings. 

Starting today, Cloudflare supports security findings for the following assets: 

  • Projects: Detect projects shared across the organization or a subset of users and groups

  • Project attachments: Files and documents added to projects that violate DLP policies

  • Chat files: User-uploaded and provider-generated files that violate DLP policies

  • Chat messages: User prompts and provider responses that violate DLP policies

  • Artifacts: Provider-generated documents and files that violate DLP policies

These findings appear directly in the Cloudflare dashboard alongside posture and content findings from your other SaaS applications. Findings are grouped by category and ordered by severity level. Security teams can triage, assign, and remediate Claude-specific risks using the same workflows they use for Microsoft 365, Google Workspace, or Salesforce. 

Supporting Claude Enterprise and Claude Platform

For Claude Enterprise, CASB surfaces compliance data such as organizations, projects, chats, and roles. It also retrieves conversation content, including messages and uploaded files through dedicated read-only endpoints to prevent data loss.

For Claude Platform, CASB will continue to surface member and workspace changes, API key creation, and file create or download events. In the near future, we will add support for the Activity Feed.

CASB turns findings into action. A detected security finding in Claude, such as a user uploading files containing sensitive data, can become a Gateway policy in minutes. You can use Gateway to block uploads to Claude for specific users, restrict access to the application entirely, or limit functionality until the issue is resolved. This moves security teams from visibility to action by combining CASB findings with Cloudflare’s existing in-line policy engine.

Getting started

To enable the Claude Compliance API integration:

  1. Ensure you have a Claude Enterprise account.

  2. Request Compliance API access from Claude for your organization.

  3. In the Cloudflare dashboard, go to Zero Trust > Integrations > Cloud & SaaS.

  4. Select Add Integration > Anthropic and enter your Compliance API key.

  5. Configure DLP profiles if you want to scan uploaded files for sensitive data.

The integration begins scanning immediately and surfaces findings in the dashboard within minutes.

For new Cloudflare customers, you can sign up and start with your first two integrations for free. Existing customers can enable the integration directly in the dashboard.

What’s next

We are continuing to expand CASB coverage for AI tools as providers release new enterprise security APIs. We are also deepening integrations within CASB to allow customers to create custom findings and build workflows which automatically remediate security findings. 

The shift to agentic AI is here, and we believe the best way to help organizations safely adopt it is by providing a unified platform to build, deploy, and govern agents. To stay up to date, check our developer documentation or subscribe to get updated automatically.

Managed OAuth for Access: make internal apps agent-ready in one click

Post Syndicated from Eduardo Gomes original https://blog.cloudflare.com/managed-oauth-for-access/

We have thousands of internal apps at Cloudflare. Some are things we’ve built ourselves, others are self-hosted instances of software built by others. They range from business-critical apps nearly every person uses, to side projects and prototypes.

All of these apps are protected by Cloudflare Access. But when we started using and building agents — particularly for uses beyond writing code — we hit a wall. People could access apps behind Access, but their agents couldn’t.

Access sits in front of internal apps. You define a policy, and then Access will send unauthenticated users to a login page to choose how to authenticate. 


Example of a Cloudflare Access login page

This flow worked great for humans. But all agents could see was a redirect to a login page that they couldn’t act on.

Providing agents with access to internal app data is so vital that we immediately implemented a stopgap for our own internal use. We modified OpenCode’s web fetch tool such that for specific domains, it triggered the cloudflared CLI to open an authorization flow to fetch a JWT (JSON Web Token). By appending this token to requests, we enabled secure, immediate access to our internal ecosystem.

While this solution was a temporary answer to our own dilemma, today we’re retiring this workaround and fixing this problem for everyone. Now in open beta, every Access application supports managed OAuth. One click to enable it for an Access app, and agents that speak OAuth 2.0 can easily discover how to authenticate (RFC 9728), send the user through the auth flow, and receive back an authorization token (the same JWT from our initial solution). 

Now, the flow works smoothly for both humans and agents. Cloudflare Access has a generous free tier. And building off our newly-introduced Organizations beta, you’ll soon be able to bridge identity providers across Cloudflare accounts too.

How managed OAuth works

For a given internal app protected by Cloudflare Access, you enable managed OAuth in one click:


Once managed OAuth is enabled, Cloudflare Access acts as the authorization server. It returns the www-authenticate header, telling unauthorized agents where to look up information on how to get an authorization token. They find this at https://<your-app-domain>/.well-known/oauth-authorization-server. Equipped with that direction, agents can just follow OAuth standards: 

  1. The agent dynamically registers itself as a client (a process known as Dynamic Client Registration — RFC 7591), 

  2. The agent sends the human through a PKCE (Proof Key for Code Exchange) authorization flow (RFC 7636)

  3. The human authorizes access, which grants a token to the agent that it can use to make authenticated requests on behalf of the user

Here’s what the authorization flow looks like:


If this authorization flow looks familiar, that’s because it’s what the Model Context Protocol (MCP) uses. We originally built support for this into our MCP server portals product, which proxies and controls access to many MCP servers, to allow the portal to act as the OAuth server. Now, we’re bringing this to all Access apps so agents can access not only MCP servers that require authorization, but also web pages, web apps, and REST APIs.

Mass upgrading your internal apps to be agent-ready

Upgrading the long tail of internal software to work with agents is a daunting task. In principle, in order to be agent-ready, every internal and external app would ideally have discoverable APIs, a CLI, a well-crafted MCP server, and have adopted the many emerging agent standards.

AI adoption is not something that can wait for everything to be retrofitted. Most organizations have a significant backlog of apps built over many years. And many internal “apps” work great when treated by agents as simple websites. For something like an internal wiki, all you really need is to enable Markdown for Agents, turn on managed OAuth, and agents have what they need to read protected content.

To make the basics work across the widest set of internal applications, we use Managed OAuth. By putting Access in front of your legacy internal apps, you make them agent-ready instantly. No code changes, no retrofitting. Instead, just immediate compatibility.

It’s the user’s agent. No service accounts and tokens needed

Agents need to act on behalf of users inside organizations. One of the biggest anti-patterns we’ve seen is people provisioning service accounts for their agents and MCP servers, authenticated using static credentials. These have their place in simple use cases and quick prototypes, and Cloudflare Access supports service tokens for this purpose.

But the service account approach quickly shows its limits when fine-grained access controls and audit logs are required. We believe that every action an agent performs must be easily attributable to the human who initiated it, and that an agent must only be able to perform actions that its human operator is likewise authorized to do. Service accounts and static credentials become points at which attribution is lost. Agents that launder all of their actions through a service account are susceptible to confused deputy problems and result in audit logs that appear to originate from the agent itself.

For security and accountability, agents must use security primitives capable of expressing this user–agent relationship. OAuth is the industry standard protocol for requesting and delegating access to third parties. It gives agents a way to talk to your APIs on behalf of the user, with a token scoped to the user’s identity, so that access controls correctly apply and audit logs correctly attribute actions to the end user.

Standards for the win: how agents can and should adopt RFC 9728 in their web fetch tools

RFC 9728 is the OAuth standard that makes it possible for agents to discover where and how to authenticate. It standardizes where this information lives and how it’s structured. This RFC became official in April 2025 and was quickly adopted by the Model Context Protocol (MCP), which now requires that both MCP servers and clients support it.

But outside of MCP, agents should adopt RFC 9728 for an even more essential use case: making requests to web pages that are protected behind OAuth and making requests to plain old REST APIs.

Most agents have a tool for making basic HTTP requests to web pages. This is commonly called the “web fetch” tool. It’s similar to using the fetch() API in JavaScript, often with some additional post-processing on the response. It’s what lets you paste a URL into your agent and have your agent go look up the content.

Today, most agents’ web fetch tools won’t do anything with the www-authenticate header that a URL returns. The underlying model might choose to introspect the response headers and figure this out on its own, but the tool itself does not follow www-authenticate, look up /.well-known/oauth-authorization-server, and act as the client in the OAuth flow. But it can, and we strongly believe it should! Agents already do this to act as remote MCP clients.

To demonstrate this, we’ve put up a draft pull request that adapts the web fetch tool in Opencode to show this in action. Before making a request, the adapted tool first checks whether it already has credentials ; if it does, it uses them to make the initial request. If the tool gets back a 401 or a 403 with a www-authenticate header, it asks the user for consent to be sent through the server’s OAuth flow.

Here’s how that OAuth flow works. If you give the agent a URL that is protected by OAuth and complies with RFC 9728, the agent prompts the human for consent to open the authorization flow:


…sending the human to the login page:


…and then to a consent dialog that prompts the human to grant access to the agent:


Once the human grants access to the agent, the agent uses the token it has received to make an authenticated request:


Any agent from Codex to Claude Code to Goose and beyond can implement this, and there’s nothing bespoke to Cloudflare. It’s all built using OAuth standards.

We think this flow is powerful, and that supporting RFC 9728 can help agents with more than just making basic web fetch requests. If a REST API supports RFC 9728 (and the agent does too), the agent has everything it needs to start making authenticated requests against that API. If the REST API supports RFC 9727, then the client can discover a catalog of REST API endpoints on its own, and do even more without additional documentation, agent skills, MCP servers or CLIs. 

Each of these play important roles with agents — Cloudflare itself provides an MCP server for the Cloudflare API (built using Code Mode), Wrangler CLI, and Agent Skills, and a Plugin. But supporting RFC 9728 helps ensure that even when none of these are preinstalled, agents have a clear path forward. If the agent has a sandbox to execute untrusted code, it can just write and execute code that calls the API that the human has granted it access to. We’re working on supporting this for Cloudflare’s own APIs, to help your agents understand how to use Cloudflare.

Coming soon: share one identity provider (IdP) across many Cloudflare accounts

At Cloudflare our own internal apps are deployed to dozens of different Cloudflare accounts, which are all part of an Organization — a newly introduced way for administrators to manage users, configurations, and view analytics across many Cloudflare accounts. We have had the same challenge as many of our customers: each Cloudflare account has to separately configure an IdP, so Cloudflare Access uses our identity provider. It’s critical that this is consistent across an organization — you don’t want one Cloudflare account to inadvertently allow people to sign in just with a one-time PIN, rather than requiring that they authenticate via single-sign on (SSO).

To solve this, we’re currently working on making it possible to share an identity provider across Cloudflare accounts, giving organizations a way to designate a single primary IdP for use across every account in their organization.

As new Cloudflare accounts are created within an organization, administrators will be able to configure a bridge to the primary IdP with a single click, so Access applications across accounts can be protected by one identity provider. This removes the need to manually configure IdPs account by account, which is a process that doesn’t scale for organizations with many teams and individuals each operating their own accounts.

What’s next

Across companies, people in every role and business function are now using agents to build internal apps, and expect their agents to be able to access context from internal apps. We are responding to this step function growth in internal software development by making the Workers Platform and Cloudflare One work better together — so that it is easier to build and secure internal apps on Cloudflare. 

Expect more to come soon, including:

  • More direct integration between Cloudflare Access and Cloudflare Workers, without the need to validate JWTs or remember which of many routes a particular Worker is exposed on.

  • wrangler dev –tunnel — an easy way to expose your local development server to others when you’re building something new, and want to share it with others before deploying

  • A CLI interface for Cloudflare Access and the entire Cloudflare API

  • More announcements to come during Agents Week 2026

Enable Managed OAuth for your internal apps behind Cloudflare Access

Managed OAuth is now available, in open beta, to all Cloudflare customers. Head over to the Cloudflare dashboard to enable it for your Access applications. You can use it for any internal app, whether it’s one built on Cloudflare Workers, or hosted elsewhere. And if you haven’t built internal apps on the Workers Platform yet — it’s the fastest way for your team to go from zero to deployed (and protected) in production.

Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP

Post Syndicated from Sharon Goldberg original https://blog.cloudflare.com/enterprise-mcp/

We at Cloudflare have aggressively adopted Model Context Protocol (MCP) as a core part of our AI strategy. This shift has moved well beyond our engineering organization, with employees across product, sales, marketing, and finance teams now using agentic workflows to drive efficiency in their daily tasks. But the adoption of agentic workflow with MCP is not without its security risks. These range from authorization sprawl, prompt injection, and supply chain risks. To secure this broad company-wide adoption, we have integrated a suite of security controls from both our Cloudflare One (SASE) platform and our Cloudflare Developer platform, allowing us to govern AI usage with MCP without slowing down our workforce. 

In this blog we’ll walk through our own best practices for securing MCP workflows, by putting different parts of our platform together to create a unified security architecture for the era of autonomous AI. We’ll also share two new concepts that support enterprise MCP deployments:

We also talk about how our organization approached deploying MCP, and how we built out our MCP security architecture using Cloudflare products including remote MCP servers, Cloudflare Access, MCP server portals and AI Gateway. 

Remote MCP servers provide better visibility and control

MCP is an open standard that enables developers to build a two-way connection between AI applications and the data sources they need to access. In this architecture, the MCP client is the integration point with the LLM or other AI agent, and the MCP server sits between the MCP client and the corporate resources.


The separation between MCP clients and MCP servers allows agents to autonomously pursue goals and take actions while maintaining a clear boundary between the AI (integrated at the MCP client) and the credentials and APIs of the corporate resource (integrated at the MCP server). 

Our workforce at Cloudflare is constantly using MCP servers to access information in various internal resources, including our project management platform, our internal wiki, documentation and code management platforms, and more. 

Very early on, we realized that locally-hosted MCP servers were a security liability. Local MCP server deployments may rely on unvetted software sources and versions, which increases the risk of supply chain attacks or tool injection attacks. They prevent IT and security administrators from administrating these servers, leaving it up to individual employees and developers to choose which MCP servers they want to run and how they want to keep them up to date. This is a losing game.


Instead, we have a centralized team at Cloudflare that manages our MCP server deployment across the enterprise. This team built a shared MCP platform inside our monorepo that provides governed infrastructure out of the box. When an employee wants to expose an internal resource via MCP, they first get approval from our AI governance team, and then they copy a template, write their tool definitions, and deploy, all the while inheriting default-deny write controls with audit logging, auto-generated CI/CD pipelines, and secrets management for free. This means standing up a new governed MCP server is minutes of scaffolding. The governance is baked into the platform itself, which is what allowed adoption to spread so quickly. 

Our CI/CD pipeline deploys them as remote MCP servers on custom domains on Cloudflare’s developer platform. This gives us visibility into which MCPs servers are being used by our employees, while maintaining control over software sources. As an added bonus, every remote MCP server on the Cloudflare developer platform is automatically deployed across our global network of data centers, so MCP servers can be accessed by our employees with low latency, regardless of where they might be in the world.

Cloudflare Access provides authentication

Some of our MCP servers sit in front of public resources, like our Cloudflare documentation MCP server or Cloudflare Radar MCP server, and thus we want them to be accessible to anyone. But many of the MCP servers used by our workforce are sitting in front of our private corporate resources. These MCP servers require user authentication to ensure that they are off limits to everyone but authorized Cloudflare employees. To achieve this, our monorepo template for MCP servers integrates Cloudflare Access as the OAuth provider. Cloudflare Access secures login flows and issues access tokens to resources, while acting as an identity aggregator that verifies end user single-sign on (SSO), multifactor authentication (MFA), and a variety of contextual attributes such as IP addresses, location, or device certificates. 

MCP server portals centralize discovery and governance


MCP server portals unify governance and control for all AI activity.

As the number of our remote MCP servers grew, we hit a new wall: discovery. We wanted to make it easy for every employee (especially those that are new to MCP) to find and work with all the MCP servers that are available to them. Our MCP server portals product provided a convenient solution. The employee simply connects their MCP client to the MCP server portal, and the portal immediately reveals every internal and third-party MCP servers they are authorized to use. 

Beyond this, our MCP server portals provide centralized logging, consistent policy enforcement and data loss prevention (DLP guardrails). Our administrators can see who logged into what MCP portal and create DLP rules that prevent certain data, like personally identifiable data (PII), from being shared with certain MCP servers.

We can also create policies that control who has access to the portal itself, and what tools from each MCP server should be exposed. For example, we could set up one MCP server portal that is only accessible to employees that are part of our finance group that exposes just the read-only tools for the MCP server in front of our internal code repository. Meanwhile, a different MCP server portal, accessible only to employees on their corporate laptops that are in our engineering team, could expose more powerful read/write tools to our code repository MCP server.

An overview of our MCP server portal architecture is shown above. The portal supports both remote MCP servers hosted on Cloudflare, and third-party MCP servers hosted anywhere else. What makes this architecture uniquely performant is that all these security and networking components run on the same physical machine within our global network. When an employee’s request moves through the MCP server portal, a Cloudflare-hosted remote MCP server, and Cloudflare Access, their traffic never needs to leave the same physical machine. 

Code Mode with MCP server portals reduces costs

After months of high-volume MCP deployments, we’ve paid out our fair share of tokens. We’ve also started to think most people are doing MCP wrong.

The standard approach to MCP requires defining a separate tool for every API operation that is exposed via an MCP server. But this static and exhaustive approach quickly exhausts an agent’s context window, especially for large platforms with thousands of endpoints.

We previously wrote about how we used server-side Code Mode to power Cloudflare’s MCP server, allowing us to expose the thousands of end-points in Cloudflare API while reducing token use by 99.9%. The Cloudflare MCP server exposes just two tools: a search tool lets the model write JavaScript to explore what’s available, and an execute tool lets it write JavaScript to call the tools it finds. The model discovers what it needs on demand, rather than receiving everything upfront.

We like this pattern so much, we had to make it available for everyone. So we have now launched the ability to use the “Code Mode” pattern with MCP server portals. Now you can front all of your MCP servers with a centralized portal that performs audit controls and progressive tool disclosure, in order to reduce token costs.

Here is how it works. Instead of exposing every tool definition to a client, all of your underlying MCP servers collapse into just two MCP portal tools: portal_codemode_search and portal_codemode_execute. The search tool gives the model access to a codemode.tools() function that returns all the tool definitions from every connected upstream MCP server. The model then writes JavaScript to filter and explore these definitions, finding exactly the tools it needs without every schema being loaded into context. The execute tool provides a codemode proxy object where each upstream tool is available as a callable function. The model writes JavaScript that calls these tools directly, chaining multiple operations, filtering results, and handling errors in code. All of this runs in a sandboxed environment on the MCP server portal powered by Dynamic Workers. 

Here is an example of an agent that needs to find a Jira ticket and update it with information from Google Drive. It first searches for the right tools:

// portal_codemode_search
async () => {
 const tools = await codemode.tools();
 return tools
  .filter(t => t.name.includes("jira") || t.name.includes("drive"))
  .map(t => ({ name: t.name, params: Object.keys(t.inputSchema.properties || {}) }));
}

The model now knows the exact tool names and parameters it needs, without the full schemas of tools ever entering its context. It then writes a single execute call to chain the operations together:

// portal_codemode_execute
async () => {
 const tickets = await codemode.jira_search_jira_with_jql({
  jql: ‘project = BLOG AND status = “In Progress”’,
  fields: [“summary”, “description”]
 });
 const doc = await codemode.google_workspace_drive_get_content({
  fileId: “1aBcDeFgHiJk”
 });
 await codemode.jira_update_jira_ticket({
  issueKey: tickets[0].key,
  fields: { description: tickets[0].description + “\n\n” + doc.content }
 });
 return { updated: tickets[0].key };
}

This is just two tool calls. The first discovers what’s available, the second does the work. Without Code Mode, this same workflow would have required the model to receive the full schemas of every tool from both MCP servers upfront, and then make three separate tool invocations.

Let’s put the savings in perspective: when our internal MCP server portal is connected to just four of our internal MCP servers, it exposes 52 tools that consume approximately 9,400 tokens of context just for their definitions. With Code Mode enabled, those 52 tools collapse into 2 portal tools consuming roughly 600 tokens, a 94% reduction. And critically, this cost stays fixed. As we connect more MCP servers to the portal, the token cost of Code Mode doesn’t grow.

Code Mode can be activated on an MCP server portal by adding a query parameter to the URL. Instead of connecting to your portal over its usual URL (e.g. https://myportal.example.com/mcp), you attach ?codemode=search_and_execute to the URL (e.g. https://myportal.example.com/mcp?codemode=search_and_execute).

AI Gateway provides extensibility and cost controls

We aren’t done yet. We plug AI Gateway into our architecture by positioning it on the connection between the MCP client and the LLM. This allows us to quickly switch between various LLM providers (to prevent vendor lock-in) and to enforce cost controls (by limiting the number of tokens each employee can burn through). The full architecture is shown below.


Cloudflare Gateway discovers and blocks shadow MCP

Now that we’ve provided governed access to authorized MCP servers, let’s look into dealing with unauthorized MCP servers. We can perform shadow MCP discovery using Cloudflare Gateway. Cloudflare Gateway is our comprehensive secure web gateway that provides enterprise security teams with visibility and control over their employees’ Internet traffic.

We can use the Cloudflare Gateway API to perform a multi-layer scan to find remote MCP servers that are not being accessed via an MCP server portal. This is possible using a variety of existing Gateway and Data Loss Prevention (DLP) selectors, including:

  • Using the Gateway httpHost selector to scan for 

    • known MCP server hostnames using (like mcp.stripe.com)

    • mcp.* subdomains using wildcard hostname patterns 

  • Using the Gateway httpRequestURI selector to scan for MCP-specific URL paths like /mcp and /mcp/sse 

  • Using DLP-based body inspection to find MCP traffic, even if that traffic uses URI that do not contain the telltale mentions of mcp or sse. Specifically, we use the fact that MCP uses JSON-RPC over HTTP, which means every request contains a “method” field with values like “tools/call”, “prompts/get”, or “initialize.” Here are some regex rules that can be used to detect MCP traffic in the HTTP body:

const DLP_REGEX_PATTERNS = [
  {
    name: "MCP Initialize Method",
    regex: '"method"\\s{0,5}:\\s{0,5}"initialize"',
  },
  {
    name: "MCP Tools Call",
    regex: '"method"\\s{0,5}:\\s{0,5}"tools/call"',
  },
  {
    name: "MCP Tools List",
    regex: '"method"\\s{0,5}:\\s{0,5}"tools/list"',
  },
  {
    name: "MCP Resources Read",
    regex: '"method"\\s{0,5}:\\s{0,5}"resources/read"',
  },
  {
    name: "MCP Resources List",
    regex: '"method"\\s{0,5}:\\s{0,5}"resources/list"',
  },
  {
    name: "MCP Prompts List",
    regex: '"method"\\s{0,5}:\\s{0,5}"prompts/(list|get)"',
  },
  {
    name: "MCP Sampling Create Message",
    regex: '"method"\\s{0,5}:\\s{0,5}"sampling/createMessage"',
  },
  {
    name: "MCP Protocol Version",
    regex: '"protocolVersion"\\s{0,5}:\\s{0,5}"202[4-9]',
  },
  {
    name: "MCP Notifications Initialized",
    regex: '"method"\\s{0,5}:\\s{0,5}"notifications/initialized"',
  },
  {
    name: "MCP Roots List",
    regex: '"method"\\s{0,5}:\\s{0,5}"roots/list"',
  },
];

The Gateway API supports additional automation. For example, one can use the custom DLP profile we defined above to block traffic, or redirect it, or just to log and inspect MCP payloads. Put this together, and Gateway can be used to provide comprehensive detection of unauthorized remote MCP servers accessed via an enterprise network. 

For more information on how to build this out, see this tutorial. 

Public-facing MCP Servers are protected with AI Security for Apps

So far, we’ve been focused on protecting our workforce’s access to our internal MCP servers. But, like many other organizations, we also have public-facing MCP servers that our customers can use to agentically administer and operate Cloudflare products. These MCP servers are hosted on Cloudflare’s developer platform. (You can find a list of individual MCPs for specific products here, or refer back to our new approach for providing more efficient access to the entire Cloudflare API using Code Mode.)

We believe that every organization should publish official, first-party MCP servers for their products. The alternative is that your customers source unvetted servers from public repositories where packages may contain dangerous trust assumptions, undisclosed data collection, and any range of unsanctioned behaviors. By publishing your own MCP servers, you control the code, update cadence, and security posture of the tools your customers use.

Since every remote MCP server is an HTTP endpoint, we can put it behind the Cloudflare Web Application Firewall (WAF). Customers can enable the AI Security for Apps feature within the WAF to automatically inspect inbound MCP traffic for prompt injection attempts, sensitive data leakage, and topic classification. Public facing MCPs are protected just as any other web API.  

The future of MCP in the enterprise

We hope our experience, products, and reference architectures will be useful to other organizations as they continue along their own journey towards broad enterprise-wide adoption of MCP.

We’ve secured our own MCP workflows by: 

  • Offering our developers a templated framework for building and deploying remote MCP servers on our developer platform using Cloudflare Access for authentication

  • Ensuring secure, identity-based access to authorized MCP servers by connecting our entire workforce to MCP server portals

  • Controlling costs using AI Gateway to mediate access to the LLMs powering our workforce’s MCP clients, and using Code Mode in MCP server portals to reduce token consumption and context bloat

  • Discovering shadow MCP usage by Cloudflare Gateway 

For organizations advancing on their own enterprise MCP journeys, we recommend starting by putting your existing remote and third-party MCP servers behind  Cloudflare MCP server portals and enabling Code Mode to start benefitting for cheaper, safer and simpler enterprise deployments of MCP.  

Acknowledgements:  This reference architecture and blog represents this work of many people across many different roles and business units at Cloudflare. This is just a partial list of contributors: Ann Ming Samborski,  Kate Reznykova, Mike Nomitch, James Royal, Liam Reese, Yumna Moazzam, Simon Thorpe, Rian van der Merwe, Rajesh Bhatia, Ayush Thakur, Gonzalo Chavarri, Maddy Onyehara, and Haley Campbell.

Watch on Cloudflare TV

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

Post Syndicated from Nikita Cano original https://blog.cloudflare.com/mesh/

AI agents have changed how teams think about private network access. Your coding agent needs to query a staging database. Your production agent needs to call an internal API. Your personal AI assistant needs to reach a service running on your home network. The clients are no longer just humans or services. They’re agents, running autonomously, making requests you didn’t explicitly approve, against infrastructure you need to keep secure.

Each of these workflows has the same underlying problem: agents need to reach private resources, but the tools for doing that were built for humans, not autonomous software. VPNs require interactive login. SSH tunnels require manual setup. Exposing services publicly is a security risk. And none of these approaches give you visibility into what the agent is actually doing once it’s connected.

Today, we’re introducing Cloudflare Mesh to connect your private networks together and provide secure access for your agents. We’re also integrating Mesh with Cloudflare Developer Platform so that Workers, Durable Objects, and agents built with the Agents SDK can reach your private infrastructure directly.

If you’re using Cloudflare One’s SASE and Zero Trust suite, you already have access to Mesh. You don’t need a new technology paradigm to secure agentic workloads. You need a SASE that was built for the agentic era, and that’s Cloudflare One. Cloudflare Mesh is a new experience with a simpler setup that leverages the on-ramps you’re already familiar with: WARP Connector (now called a Cloudflare Mesh node) and WARP Client (now called Cloudflare One Client). Together, these create a private network for human, developer, and agent traffic. Mesh is directly integrated into your existing Cloudflare One deployment. Your existing Gateway policies, Access rules, and device posture checks apply to Mesh traffic automatically.

If you’re a developer who just wants private networking for your agents, services, and team, Mesh is where you start. Set it up in minutes, connect your networks, and secure your traffic. And because Mesh runs on the Cloudflare One platform, you can grow into more advanced capabilities over time: Gateway network, DNS, and HTTP policies for fine-grained traffic control, Access for Infrastructure for SSH and RDP session management, Browser Isolation for safe web access, DLP to prevent sensitive data from leaving your network, and CASB for SaaS security. You won’t have to plan for all of this on day one. You just don’t have to migrate when you need it.

New agentic workflows

Private networking has always been about connecting clients to resources — SSH into a server, query a database, access an internal API. What’s changed is who the clients are. A year ago, the answer was your developers and your services. Today, it’s increasingly your agents.

This isn’t theoretical. Look at the ecosystem: the explosion of MCP (Model Context Protocol) servers providing tool access, coding agents that need to read from private repos and databases, personal assistants running on home hardware. Each of these patterns assumes the agent can reach the resources it needs. When those resources are isolated in private networks, the agent is stuck.


This creates three workflows that are hard to secure today:

  1. Accessing a personal agent from a mobile device. You’re running OpenClaw on a Mac mini at home. You want to reach it from your phone, your laptop at a coffee shop, or your work machine. But exposing it to the public Internet (even behind a password) can leave some gaps exposed. Your agent has shell access, file system access, and network access to your home network. One misconfiguration and anyone can reach it.

  2. Letting a coding agent access your staging environment. You’re using Claude Code, Cursor, or Codex on your laptop. You ask it to check deployment status, query analytics from a staging database, or read from an internal object store. But those services live in a private cloud VPC, so your agent can’t reach them without exposing them to the Internet or tunneling your entire laptop into the VPC.

  3. Connecting deployed agents to private services. You’re building agents into your product using the Agents SDK on Cloudflare Workers. Those agents need to call internal APIs, query databases, and access services that aren’t on the public Internet. They need private access, but with scoped permissions, audit trails, and no credential leakage.

Cloudflare Mesh: one private network for users, nodes, and agents

Cloudflare Mesh is developer-friendly private networking. One lightweight connector, one binary, connects everything: your personal devices, your remote servers, your user endpoints. You don’t need to install separate tools for each pattern. One connector on your network, and every access pattern works.

Once connected, devices in your private network can talk to each other over private IPs, routed through Cloudflare’s global network across 330+ cities giving you better reliability and control over your network.


Now, with Mesh, a single solution can solve all of the agent scenarios we mentioned above:

  • With Cloudflare One Client for iOS on your phone, you can securely connect your mobile devices to your local Mac mini running OpenClaw via a Mesh private network.

  • With Cloudflare One Client for macOS on your laptop, you can connect your laptop to your private network so your coding agents can reach staging databases or APIs and query them.

  • With Mesh nodes on your Linux servers, you can connect VPCs in external clouds together, letting agents access resources and MCPs in external private networks.

Because Mesh is powered by Cloudflare One Client, every connection inherits the security controls of the Cloudflare One platform. Gateway policies apply to Mesh traffic. Device posture checks validate connecting devices. DNS filtering catches suspicious lookups. You get this without additional configuration: the same policies that protect your human traffic protect your agent traffic.

Choosing between Mesh and Tunnel

With the introduction of Mesh, you might ask: when should I use Mesh instead of Tunnel? Both connect external networks privately to Cloudflare, but they serve different purposes. Cloudflare Tunnel is the ideal solution for unidirectional traffic, where Cloudflare proxies the traffic from the edge to specific private services (like a web server or a database). 

Cloudflare Mesh, on the other hand, provides a full bidirectional, many-to-many network. Every device and node on your Mesh can access one another using their private IPs. An application or agent running in your network can discover and access any other resource on the Mesh without each resource needing its own Tunnel. 

Using the power of Cloudflare’s network

Cloudflare Mesh gives you the benefits of a mesh network (resiliency, high scalability, low latency and high performance), but, by routing everything through Cloudflare, it resolves a key challenge of mesh networks: NAT traversal.

Most of the Internet is behind NAT (Network Address Translation). This mechanism allows an entire local network of devices to share a single public IP address by mapping traffic between public headers and private internal addresses. When two devices are behind NAT, direct connections can fail and traffic has to fall back to relay servers. If your relay infrastructure has limited points of presence, a meaningful fraction of your traffic hits those relays, adding latency and reducing reliability. And while it can be possible to self-host your own relay servers to compensate, that means taking on the burden of managing additional infrastructure just to connect your existing network.

Cloudflare Mesh takes a different approach. All Mesh traffic routes through Cloudflare’s global network, the same infrastructure that serves traffic for some of the largest websites of the Internet. For cross-region or multi-cloud traffic, this consistently beats public Internet routing. There’s no degraded fallback path, because the Cloudflare edge is the path.

Routing through Cloudflare also means every packet passes through Cloudflare’s security stack. This is the key advantage of building Mesh on the Cloudflare One platform: security isn’t a separate product you bolt on later. And by leveraging this same global backbone, we can provide these core pillars to every team from day one:

50 nodes and 50 users free. Your whole team and your whole staging environment on one private network, included with every Cloudflare account. 

Global edge routing. 330+ cities, optimized backbone routing. No relay servers with limited points of presence. No degraded fallback paths.

Security controls from day one. Mesh runs on Cloudflare One. Gateway policies, DNS filtering, DLP, traffic inspection, and device posture checks are all available on the same platform. Start with simple private connectivity. Turn on Gateway policies when you need traffic filtering. Enable Access for Infrastructure when you need session-level controls for SSH and RDP. Add DLP when you need to prevent sensitive data from leaving your network. Every capability is one toggle away.

High availability. Create a Mesh node with high availability enabled and spin up multiple connectors using the same token in active-passive mode. They advertise the same IP routes, so if one goes down, traffic fails over automatically.

Integrated with the Developer Platform with Workers VPC

Mesh connects your agents and resources across external clouds, but you also need to be able to connect from your agents built on Workers with Agents SDK as well. To enable this, we’ve extended Workers VPC to make your entire Mesh network accessible to Workers and Durable Objects.

That means that you can connect to your Cloudflare Mesh network from Workers, making the entire network accessible from a single binding’s fetch() call. This complements Workers VPC’s existing support for Cloudflare Tunnel, giving you more choice over how you want to secure your networks. Now, you can specify entire networks that you want to connect to in your wrangler.jsonc file. To bind to your Mesh network, use the cf1:network reserved keyword that binds to the Mesh network of your account:

"vpc_networks": [
  { "binding": "MESH", "network_id": "cf1:network", "remote": true },
  { "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]

Then, you can use it within your Worker or agent code:

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    // Reach any internal host on your Mesh, no pre-registration required
    const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");

    // Internal hostname resolved via tunnel's private DNS resolver
    const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");

    return new Response(await apiResponse.text());
  },
};

By connecting the Developer Platform to your Mesh networks, you can build Workers that have secure access to your private databases, internal APIs and MCPs, allowing you to build cross-cloud agents and MCPs that provide agentic capabilities to your app. But it also opens up a world where agents can autonomously observe your entire stack end-to-end, cross-reference logs and suggest optimizations in real-time.

How it all fits together

Together, Cloudflare Mesh, Workers VPC, and the Agents SDK provide a unified private network for your agents that spans both Cloudflare and your external clouds. We’ve merged connectivity and compute so your agents can securely reach the resources they need, wherever they live, across the globe.


Mesh nodes are your servers, VMs, and containers. They run a headless version of Cloudflare One Client and get a Mesh IP. Services talk to services over private IPs, bidirectionally, routed through Cloudflare’s edge. 

Devices are your laptops and phones. They run the Cloudflare One Client and reach Mesh nodes directly: SSH, database queries, API calls, all over private IPs. Your local coding agents use this connection to access private resources. 

Agents on Workers reach private services through Workers VPC Network bindings. They get scoped access to entire networks, mediated by MCP. The network enforces what the agent can reach. The MCP server enforces what the agent can do. 

What’s next

The current version of Mesh provides the foundation for secure, unified connectivity. But as agentic workflows become more complex, we’re focused on moving beyond simple connectivity toward a network that is more intuitive to manage and more granularly aware of who, or what, is talking to your services. Here is what we are building for the rest of the year.

Hostname routing

We’re extending Cloudflare Tunnel’s hostname routing to Mesh this summer. Your Mesh nodes will be able to attract traffic for private hostnames like wiki.local or api.staging.internal, without you having to manage IP lists or worry about how those hostnames resolve on the Cloudflare edge. Route traffic to services by name, not by IP. If your infrastructure uses dynamic IPs, auto-scaling groups, or ephemeral containers, this removes an entire class of routing headaches.

Mesh DNS

Today, you reach Mesh nodes by their Mesh IPs: ssh 100.64.0.5. That works, but it’s not how you think about your infrastructure. You think in names: postgres-staging, api-prod, nikitas-openclaw.

Later this year we’re building Mesh DNS so that every node and device that joins your Mesh automatically gets a routable internal hostname. No DNS configuration or manual records. Add a node named postgres-staging, and postgres-staging.mesh resolves to the right Mesh IP from any device on your Mesh.

Combined with hostname routing, you’ll be able to ssh postgres-staging.mesh or curl http://api-prod.mesh:3000/health without ever knowing or managing an IP address.

Identity-aware routing

Today, Mesh nodes authenticate to the Cloudflare edge, but they share an identity at the network layer. Devices authenticate with user identity via the Cloudflare One Client, but nodes don’t yet carry distinct, routable identities that Gateway policies can differentiate.

We want to change that. The goal is identity-aware routing for Mesh, where each node, each device, and eventually each agent gets a distinct identity that policies can evaluate. Instead of writing rules based on IP ranges, you write rules based on who or what is connecting.

This matters most for agents. Today, when an agent running on Workers calls a tool through a VPC binding, the target service sees a Worker making a request. It doesn’t know which agent is calling, who authorized it, or what scope was granted. On the Mesh side, when a local coding agent on your laptop reaches a staging service, Gateway sees your device identity but not the agent’s.

We’re working toward a model where agents carry their own identity through the network:

  • Principal / Sponsor: The human who authorized the action (Nikita from the platform team)

  • Agent: The AI system performing it (the deployment assistant, session #abc123)

  • Scope: What the agent is allowed to do (read deployments, trigger rollbacks, nothing else)

This would let you write policies like: reads from Nikita’s agents are allowed, but writes require Nikita directly. Agent traffic can be filtered independently from human traffic. An agent’s network access can be revoked without touching Nikita’s.

The infrastructure for this is in place. Mesh nodes provision with per-node tokens, devices authenticate with per-user identity, and Workers VPC bindings scope per-service access. The missing piece is making these identities visible to the policy layer so Gateway can make routing and access decisions based on them. That’s what we’re building.

Mesh in containers

Today, Mesh nodes run on VMs and bare-metal Linux servers. But modern infrastructure increasingly runs in containers: Kubernetes pods, Docker Compose stacks, ephemeral CI/CD runners. We’re building a Mesh Docker image that lets you add a Mesh node to any containerized environment.

This means you’ll be able to include a Mesh sidecar in your Docker Compose stack and give every service in that stack private network access. A microservice running in a container in your staging cluster could reach a database in your production VPC over Mesh, without either service needing a public endpoint.

It is also useful for CI/CD pipelines that can access private infrastructure during builds and tests: your GitHub Actions runner pulls the Mesh container image, joins your network, runs integration tests against your staging environment, and tears down. All without VPN credentials to manage or persistent tunnels to maintain: the node disappears when the container exits.

We expect the Mesh Docker image to be available later this year.

Get started

While we continue to evolve these identity and routing capabilities, the foundation for secure, unified networking is available today. You can start bridging your clouds and securing your agents in just a few minutes.

Get started Cloudflare Mesh: Head to Networking > Mesh in the Cloudflare dashboard. Free for up to 50 nodes and 50 users.

Build agents with Agents SDK and Workers VPC: Install the Agents SDK (`npm i agents`), follow the Workers VPC quickstart, and build a remote MCP server with private backend access.

Already on Cloudflare One? Mesh works with your existing setup. Your Gateway policies, device posture checks, and access rules apply to Mesh traffic automatically. See the Mesh documentation to add your first node.


Watch on Cloudflare TV

From legacy architecture to Cloudflare One

Post Syndicated from Warnessa Weaver original https://blog.cloudflare.com/legacy-to-agile-sase/

For a network engineer, the cutover weekend is often the most stressful 48 hours of their career. Imagine a 30,000-user organization attempting to flip 1,000+ legacy applications from fragmented VPNs to a new architecture in a single window. The stakes are immense: a single misconfigured firewall rule or a timed-out session can halt essential services and lead to operational gridlock.

This “big bang” migration risk is the single greatest barrier to Zero Trust adoption. Organizations often feel trapped between an aging, vulnerable infrastructure and a migration process that feels too risky to attempt.

Cloudflare and Technology Solutions Provider CDW are changing this narrative. We believe that a successful transition to SASE (Secure Access Service Edge) shouldn’t feel like a leap into the dark. By combining Cloudflare’s global Zero Trust platform with CDW’s experience navigating the industry’s most complex deployment failures, we provide the strategic roadmap to de-risk the journey. We don’t just move your “plumbing” — we ensure your legacy debt is transformed into a modern, agile security posture without the downtime.

Leveraging partner expertise to avoid migration traps

Traditional migrations often fail because they treat the network as simple plumbing rather than a complex ecosystem of applications. Without a granular strategy, many organizations fall into the “lift and shift” trap — attempting to move hundreds of applications simultaneously without understanding their back-end dependencies.

To avoid this, CDW uses a risk-aware, tiered methodology. This approach categorizes every application in your environment by its technical complexity. We move simple, modern apps first to build momentum while saving complex, legacy systems for a more controlled, later stage.

A recent large-scale public sector project serves as a cautionary example of what can happen without this structure. In this case, a team attempted to migrate 500 applications at once. Because they lacked a tiered methodology to prioritize their 4,000+ applications, the move led to systemic service disruptions.

CDW’s role is to act as the architect that prevents these failures. CDW strategists, many of whom are former security practitioners, analyze these industry-wide failure points to identify recurring anti-patterns that derail Zero Trust journeys and build a more resilient migration blueprint. By treating migration as an application modernization project rather than a single connectivity swap, CDW ensures that security requirements are built into the foundation of the move rather than bolted on as an afterthought.

Modernizing legacy apps with Cloudflare Access

To move away from the all-or-nothing risks of the past, we start with the foundation of the solution: Cloudflare Access. Before we look at how to migrate complex legacy applications, it’s important to understand the value of the platform itself. Cloudflare Access replaces the broad, vulnerable perimeter of a traditional VPN with a Zero Trust model. Instead of granting a user access to an entire network segment, Access evaluates every single request based on identity, device posture, and other contextual signals. This significantly reduces the attack surface and prevents the lateral movement that leads to the kind of systemic outages we discussed earlier.

Once this security layer is in place, we can begin “wrapping” legacy applications in Cloudflare Access. This allows us to modernize the security posture of an old app without actually rewriting its code.

We do this wrapping in Cloudflare Access using a specific logic:

  • Problem: A legacy application with no built-in Multi-Factor Authentication (MFA) is exposed via a standard VPN, creating a high-risk entry point for attackers.

  • Mitigation: Using Cloudflare Tunnel, we create an outbound-only connection with both Single Sign-On (SSO) and MFA built-in. This effectively hides the application from the public Internet, as it no longer has a public IP address to scan or attack.

  • Policy: We then apply a Cloudflare Access policy at the edge. This requires an endpoint hardware-based MFA check and a device health scan before a single packet ever reaches your server.

By using this wrapping technique, CDW and Cloudflare make it possible for organizations to migrate at their own pace. You get the immediate security benefits of a modern cloud environment, while your legacy apps continue to run safely in the background.

Pre-migration audit

Before launching a pilot, IT leaders must audit the environment for architectural readiness, ensuring legacy systems are technically compatible with modern security protocols. “For large deployments, we focus on application modernization,” says Eric Marchewitz, a security solutions executive at CDW. “Many legacy applications could break if least privilege access was applied without proper preparation.”

1. Architectural & identity assessment

  • Determine identity providers: Confirm which applications rely on a federated Identity Provider (such as Okta) versus those using legacy local directories.

  • Map dependencies: Document backend database and API dependencies for each application to prevent service interruptions. This data identifies the hidden API calls that typically break during a cutover if service token-based Tunnel connectivity is not maintained on the backend.

2. Establish firebreak

Separate the project into a Strategy Group (focused on security standards) and an Implementation Group (focused on efficiency). This ensures that high-level security requirements, like those needed to prevent lateral movement, are not bypassed for the sake of deployment speed.

3. Persistent session stress test

Identify applications using legacy architectures to maintain session persistence and avoid connection drops during cellular tower switching. Cloudflare’s architecture, supported by Dynamic Path MTU Discovery (PMTUD), maintains a persistent session at the edge even as the client IP changes. Identifying these users during the audit allows us to displace expensive, rigid legacy hardware with a modern, single-pass architecture.

4. Categorization & timeline setting

Once complete, the remaining stack is tiered to set realistic implementation timelines:

Application Tier

Description

Estimated Migration Effort

Tier 0 (Modern SaaS Apps)

Native SAML/OIDC support so Cloudflare acts as a clientless identity provider proxy during authentication

1–3 hours per app

Tier 1 (Internal Web Apps)

Standard identity headers and modern web protocols support a clientless reverse proxy deployment with Cloudflare Tunnel 

3–6 hours per app

Tier 2 (Non-Web Client-Server Apps)

Specific port/protocol support or thick-client configurations required so both Cloudflare One Client and Cloudflare Tunnel deployments are used

4–8 hours per app

Tier 3 (Legacy Enterprise Apps)

Complex server-side connectivity (e.g. peer-to-peer, bidirectional) or back-end dependency requirements so Cloudflare Mesh or WAN deployments may complement Cloudflare Tunnel to support.

1–3 days per app; may require code revisions

The roadmap to escape velocity

To achieve “escape velocity” from legacy hardware, CDW follows a phased rollout that prioritizes coexistence over replacement.

  1. Phase 1: Strategy & Infrastructure: Formation of strategy and implementation teams. This phase includes identifying CDW strategists — former CISOs and architects — to act as peer sounding boards.

  2. Phase 2: Pilot Rollout: Deployment of the Cloudflare One Client to a pilot group of employees. During this phase, we address common friction points like the “latency tax,”  ensuring performance doesn’t compromise security.

  3. Phase 3: Production Scaling: Full scaling across the organization. We maintain a dual-client period where users run both legacy VPN and Cloudflare Access in tandem, ensuring a safe rollback path and an easier end-user transition to the new Zero Trust approach.

Performance as a security feature

Cloudflare’s single-pass architecture runs every security check simultaneously. 

“When we talk to customers about the connectivity cloud, the most impactful change isn’t just the modern security posture. It’s the operational velocity,” notes Annika Garbers, Head of Cloudflare One GTM. “Moving to a single control plane allows a security team to stop being a bottleneck.”

By building on a post-quantum encrypted foundation, we ensure this bridge is future-proofed against the next generation of threats.

Build your bridge with Cloudflare One’s agile SASE

Modernization is about building a bridge, not a “big bang.” This methodology is refined through our Partner Technical Advisory Board, where partner feedback informs our product roadmap directly. By focusing on application modernization and a phased rollout, organizations can regain architectural control and eliminate the fragmentation penalty for good.

The combination of Cloudflare’s SASE platform and CDW’s migration expertise provides a safety net for the journey. You get the immediate security benefits of identity-based access and phish-resistant MFA, without the operational gridlock of a massive, unmapped cutover.

The goal isn’t just to move your applications to the cloud. It’s to ensure that when you get there, your environment is more resilient, more visible, and significantly harder to breach.

Ready to de-risk your journey to a zero trust architecture? Use CDW’s Zero Trust Maturity Assessment to identify the hidden dependencies in your environment. Reach out to a Cloudflare One expert to start your transition with a proven blueprint.

Complexity is a choice. SASE migrations shouldn’t take years.

Post Syndicated from Warnessa Weaver original https://blog.cloudflare.com/complexity-is-a-choice-sase-migrations-shouldnt-take-years/

For years, the cybersecurity industry has accepted a grim reality: migrating to a zero trust architecture is a marathon of misery. CIOs have been conditioned to expect multi-year deployment timelines, characterized by turning screws, manual configurations, and the relentless care and feeding of legacy SASE vendors.

But at Cloudflare, we believe that kind of complexity is a choice, not a requirement. Today, we are highlighting how our partners are proving that what used to take years now takes weeks. By leveraging Cloudflare One, our agile SASE platform, partners like TachTech and Adapture are showing that the path to safe AI and Zero Trust adoption is faster, more seamless, and more programmable than ever before.

Slashing timelines from 18 months to 6 weeks

The traditional migration path for legacy SASE products—specifically the deployment of Secure Web Gateway (SWG) and Zero Trust Network Access (ZTNA)—often stretches to 18 months for large organizations. For a CIO, that represents a year and a half of technical debt and persistent security gaps.

By contrast, partners like TachTech and Adapture are proving that this marathon of misery is not a technical necessity. By using a unified connectivity cloud, they have compressed these timelines from 18 months down to just six weeks.

Kyle Jerome Thompson, a solutions architect at TachTech with 30 years of experience, says Cloudflare One fundamentally changes this calculus. By replacing legacy tools with Cloudflare’s robust telemetry and global network, TachTech has slashed deployment times for large organizations down to just four to six weeks.

“Cloudflare has taken the ‘wizardry’ out of zero trust,” says Thompson. “Unlike legacy solutions that require continual care and feeding, Cloudflare Access is lightweight and ‘no-touch’ after deployment. It commoditizes security in the same way you think about plumbing or electricity—it just works, it’s cost-effective, and it lets our customers get back to their real day jobs.”

Why legacy migrations stall

Legacy migrations typically fail when they are treated as a series of hardware replacements rather than a software transformation. Traditional vendors often require complex service chaining where traffic is passed from one inspection cluster to another. This creates a “trombone effect,” adding latency and making troubleshooting nearly impossible.

When you decouple the security policy from the physical network, the migration speed changes. Our partners focus on three pillars to accelerate this transition:

  1. Identity-first on-ramps: Instead of rebuilding network segments, they use existing identity provider (IdP) groups to define access.

  2. Consolidated policy engines: By using a single pass for both SWG and ZTNA, administrators avoid the need to “sync” different products.

  3. Cloud-native connectors: Using lightweight daemons like cloudflared allows for instant connectivity without opening inbound firewall ports.

Scaling at the speed of business

The story is similar at Adapture, where they have a simple mission: improve IT performance and mitigate risk for clients. For one client, what started as a small contractor-focused footprint quickly exploded from 600 seats to a 5,000-seat deployment of Cloudflare Access.

This rapid elasticity proved that Cloudflare’s easy-to-use SASE platform bypasses legacy deployment hurdles—a transition Adapture characterized as “seamless.” 

“Organizations can’t afford an implementation that stretches across months,” says Greg O’Connor, VP of Strategic Alliances at Adapture. “Cloudflare is creating a new standard when it comes to SASE implementation, bringing our clients to the cutting edge of SASE.” 

The power of an extensible edge

In global infrastructure, unique environments and highly specialized workflows are the reality. A hallmark of the Cloudflare One architecture is that it is software-defined and extensible, allowing partners to unblock specific requirements without compromising the organization’s overall security posture.

Cloudflare One is a truly composable and programmable platform, allowing proactive partners to move away from static GUIs and build without bounds.

For example, when Thompson at TachTech encountered a developer team utilizing Arch Linux, they didn’t have to sacrifice visibility or create a security exception. They were able to extend the Cloudflare One Client to support the specific requirements of that environment.

By extracting the binaries from the Ubuntu .deb package and creating a custom PKGBUILD, the team ensured the client could run as a native service on Arch. This ensured the organization maintained consistent device posture checks—verifying disk encryption and firewall status—even on non-standard developer workstations.

Beyond connectivity: the fast path to safe AI

As organizations move toward agentic workflows, O’Connor notes “both threats and security measures are moving faster than ever.” Across the industry, the role of the SWG is evolving. It is no longer just about blocking malicious URLs; it’s about controlling the flow of data into Large Language Models (LLMs). Cloudflare One serves as the fast path to safe AI adoption by integrating security directly into the user’s path to the Internet.

Our goal is to set our partners up for success across a wide variety of customer challenges. Rather than managing disparate security tools, our partners deploy the Cloudflare AI Security Suite to provide a unified defense across the entire AI lifecycle. This native set of controls allows organizations to:

Secure your workforce as they use AI. For employees leveraging public LLMs, Cloudflare One provides a “safe harbor” that balances innovation with strict data governance.

  • Shadow AI visibility: Instantly discover and categorize which unapproved third-party AI tools are being used across your network via the Shadow AI dashboard.

  • AI confidence scores: Move beyond “block-all” policies by grading models on their compliance posture (SOC 2, ISO 42001) and data handling reliability before sanctioning them.

  • DLP AI prompt protection: Secure your intellectual property by using AI-powered Cloudflare Data Loss Prevention (DLP) to block sensitive source code, PII, or financials from being submitted into public training sets.

Secure your AI-powered apps. For the AI-powered applications your team builds and hosts, we provide a dedicated Firewall for AI to protect the integrity of your models.

  • LLM discovery: Automatically discover and label every LLM endpoint exposed to the internet, providing immediate visibility into your AI attack surface.

  • Request validation: Prevent “AI-jacking” by blocking prompt injections and malicious inputs designed to coerce your model into producing wrong or embarrassing outputs.

  • Response scrubbing: Ensure your model doesn’t accidentally “hallucinate” sensitive internal data back to a customer by scrubbing the response for PII or toxic topics before it crosses the wire.

Secure agentic AI. As we move toward autonomous agents, MCP server portals provide a central registry and least-privilege control over how AI interacts with corporate resources like Slack or Confluence. This prevents the autonomous horror stories of data heists and rogue actions by returning visibility and control to IT admins.


The Cloudflare AI Security Suite acts as a secure intermediary between users and AI ecosystems, providing visibility, data protection, and governance for public, private, and agentic AI applications. 

Accelerate your migration

If you are a CIO still tethered to a multi-year migration roadmap, you are operating at a competitive disadvantage. Cloudflare One integrates your network and security into a single fabric that is fast, safe, and infinitely more programmable than the legacy solution in your current stack.

Don’t let the fear of a difficult migration keep you trapped in a legacy mindset. Our partners are proving every day that the move to SASE can be fast, effective, and—dare we say—easy.

Connect with a Cloudflare One expert to start mapping your migration.

From the endpoint to the prompt: a unified data security vision in Cloudflare One

Post Syndicated from Alex Dunbrack original https://blog.cloudflare.com/unified-data-security/

Cloudflare One has grown a lot over the years. What started with securing traffic at the network now spans the endpoint and SaaS applications – because that’s where work happens.

But as the market has evolved, the core mission has become clear: data security is enterprise security.

Here’s why. We don’t enforce controls just to enforce controls. We do it because the downstream outcomes are costly: malware, credential theft, session hijacking, and eventually the thing that matters most: sensitive data leaving the organization. What looks like a simple access policy can be the first link in a chain that ends in incident response, customer impact, and reputational damage.

So when you take a step back, most security programs – even the ones that look different on paper – are trying to answer the same questions:

  • Where is sensitive data?

  • Who can access it?

  • What paths exist for it to move somewhere it shouldn’t?

That’s the backbone of our data security vision in Cloudflare One: a single model that follows data across the places it moves, not a pile of siloed controls. That means:

  • Protection in transit (across Internet + SaaS access)

  • Visibility and control at rest (inside SaaS)

  • Enforcement in use (on endpoints)

  • And now, coverage at the prompt (as AI becomes a new interface to enterprise data)

Think of these as one connected system: visibility tells you what’s happening, controls constrain where data can move, and enforcement closes the last-mile gaps when content leaves an app. That’s the endpoint-to-prompt problem: data moves faster than product boundaries, so policy needs to follow the data, not the tool.

In this post, we’ll walk through a set of updates that push that vision forward – from browser-based Remote Desktop Protocol (RDP) controls, to operation-level logging, to endpoint data loss prevention (DLP), to AI security scanning for Microsoft 365 Copilot. 

Remote access without data sprawl: browser-based RDP clipboard controls

Browser-based RDP is a practical way to provide remote access when you can’t assume a managed endpoint or installed client – common for contractors, partners, and occasional access workflows. Cloudflare One’s browser-based RDP adds visibility and policy controls to that access. But once you’re delivering a full RDP experience in the browser, the question becomes simple: how granular are your controls over where data can move, especially via the clipboard?

Today, we’re adding a setting that directly protects data: clipboard controls for browser-based RDP. With this new feature, security and IT administrators will now be able to decide whether their users can copy or paste information between their local device and the browser-based RDP session.

Clipboard restrictions are a perfect example of the productivity-security tradeoff. If users can’t copy and paste in the workflow they rely on, they’ll route around the control, whether it’s by taking screenshots, retyping data, or shifting work to unmanaged tools. Clipboard controls let you be precise: allow the workflow where it’s safe, and block it where it isn’t.

With clipboard controls in browser-based RDP, administrators can enable the copy/paste workflow users expect while enforcing granular control over directionality and context. For example, if users access a customer support portal that contains sensitive customer information, you might allow copy/paste into the session for productivity, but block copy/paste out of the session to prevent data from landing on unmanaged endpoints.

This functionality is now available in Cloudflare One and can be configured as a new setting within Access Application Policies for browser-based RDP apps.

Visibility without guesswork: operation mapping in logs

While remote access controls reduce risk, to tune them well, you also need to understand the specific actions users are taking inside SaaS apps.

We use a process called operation mapping (detailed in a recent blog post) to give visibility to these actions and simplify the way customers write policies for SaaS services. Our mapping process takes various elements of an HTTP request and interprets them as a single operation, e.g. ‘SendPrompt’, in the example of ChatGPT. We collect multiple operations that perform similar actions into an Application Control, e.g., ‘Share’ or ‘Upload’. The [what?] is viewable in our HTTP policy builder, allowing for simple policy authoring. 

Today, we’ve taken that process a step further to enrich logs and provide greater visibility over how SaaS applications are being used in your organization – by extending that mapping into logging. Without any additional configuration, operations and application controls will now appear in log events for traffic that matches our operation maps.

In log details, you’ll now see both the application control group and the specific operation (e.g., SendPrompt for ChatGPT). This makes investigations and policy tuning faster.


The added context helps you understand usage patterns, accelerate forensic analysis, and spot potentially risky behavior, so you can tune policy with less guesswork and disruption to users.

Visibility is step one. To protect data in use, especially what moves through the clipboard, you also need enforcement on the endpoint.

Better endpoint protection: on-device DLP in the Cloudflare One Client

In a modern enterprise, sensitive information routinely moves from managed applications into unmanaged contexts – often via the clipboard. The risk isn’t only a file leaving the organization; it can be a snippet of proprietary code or a customer record pasted into an unauthorized large language model (LLM) or personal tool.

Cloudflare One already helps protect data in transit with Gateway and DLP, and provides visibility and control at rest through CASB and its API integrations. Now we’re extending coverage to data in use by bringing Endpoint DLP enforcement to the Cloudflare One Client, starting with high-signal workflows like clipboard movement, so data protection doesn’t stop the moment content leaves a browser tab.

That means sensitive data copied from a protected SaaS app doesn’t immediately become “policy-free” content the moment it hits the OS clipboard. With Endpoint DLP, teams can extend data protection to users’ fingertips without deploying a second agent or stitching together complex integrations.

For teams already using Cloudflare One for data protection, Endpoint DLP completes the model by adding a consistent enforcement layer for data in use.

This is the endpoint-to-prompt problem: if sensitive data can be copied locally, it can be pasted into an AI assistant just as easily. Once you protect data in use, the next question becomes unavoidable – what happens when that same data is transformed at the prompt?

AI visibility without blind spots: M365 Copilot scanning with API CASB

Last year, Cloudflare One and API CASB became the first to offer API integrations with OpenAI ChatGPT, Anthropic Claude, and Google Gemini offerings – and we’re not done yet. 

Starting today, customers using Cloudflare One’s API Cloud Access Security Broker (CASB) – which scans SaaS apps via API for common, yet risky security issues – can now analyze Microsoft 365 Copilot activity for data security issues, including chats and uploads that match DLP detection profiles.

Copilot findings surface with rich context (file references, profile matches, and interaction metadata) so teams can triage quickly instead of starting from raw audit logs.


A CASB Finding showing detection of a file used in M365 Copilot that matches an enabled DLP Profile

Customers can now see when Copilot activity includes sensitive data. For example, user prompts, Copilot responses, and uploaded files that match DLP detection profiles.

Microsoft 365 Copilot findings are available by default as part of the Microsoft 365 integration. If you already use this integration, go to Integrations in the Cloudflare One dashboard, update your Microsoft 365 connection, and start receiving Copilot findings. If you’re new to the integration, connect your Microsoft 365 tenant to gain visibility into Copilot usage and associated data security findings.

As AI product sprawl continues, we’ll be massively expanding coverage across additional AI assistants and core SaaS platforms throughout 2026 – stay tuned!

What’s next: unified data security in Cloudflare One

Over the last few years, enterprise security has expanded across more surfaces: SaaS, unmanaged endpoints, remote access patterns, and now AI assistants. But the objective – protecting sensitive data – hasn’t changed. The updates in this post reflect a single direction: consistent visibility and enforcement across data in transit, at rest, in use, and at the prompt. So policy follows data, not product boundaries.

Looking forward, our vision is broader than “data security features in data security products.” Over time, every Cloudflare One product will become more data-security-aware, with more data-oriented configurability, visibility, controls, and guardrails, built directly into the workflows teams already use across Access, Gateway, endpoint enforcement, and SaaS integrations. The goal is simple: wherever your users work and wherever data moves, Cloudflare One should be able to explain what’s happening and help you control it.

As the modern perimeter spreads across applications, browsers, endpoints, and AI prompts, patching together point solutions becomes harder to operate and easier to bypass. By building data security directly into Cloudflare One – from access controls to endpoint enforcement to AI visibility – and continuing to unify these layers, we’re helping teams build a clearer, more complete picture of their data risk and their data security posture from the endpoint to the prompt.

To get started, explore Cloudflare One or contact our team to learn more about the platform and these new features.

Ending the “silent drop”: how Dynamic Path MTU Discovery makes the Cloudflare One Client more resilient

Post Syndicated from Koko Uko original https://blog.cloudflare.com/client-dynamic-path-mtu-discovery/

You’ve likely seen this support ticket countless times: a user’s Internet connection that worked just fine a moment ago for Slack and DNS lookups is suddenly hung the moment they attempt a large file upload, join a video call, or initiate an SSH session. The culprit isn’t usually a bandwidth shortage or service outage issue, it is the “PMTUD Black Hole” — a frustration that occurs when packets are too large for a specific network path, but the network fails to communicate that limit back to the sender. This situation often happens when you’re locked into using networks you do not manage or vendors with maximum transmission unit (MTU) restrictions, and you have no means to address the problem.

Today, we are moving past these legacy networking constraints. By implementing Path MTU Discovery (PMTUD), the Cloudflare One Client has shifted from a passive observer to an active participant in path discovery.

Dynamic Path MTU Discovery allows the client to intelligently and dynamically adjust to the optimal packet size for most network paths using MTUs above 1281 bytes. This ensures that a user’s connection remains stable, whether they are on a high-speed corporate backbone or a restrictive cellular network.

The “modern security meets legacy infrastructure” challenge 

To understand the solution, we have to look at how modern security protocols interact with the diversity of global Internet infrastructure. The MTU represents the largest data packet size a device can send over a network without fragmentation: typically 1500 bytes for standard Ethernet.

As the Cloudflare One client has evolved to support modern enterprise-grade requirements (such as FIPS 140-2 compliance), the amount of metadata and encryption overhead within each packet has naturally increased. This is a deliberate choice to ensure our users have the highest level of protection available today.

However, much of the world’s Internet infrastructure was built decades ago with a rigid expectation of 1500-byte packets. On specialized networks like LTE/5G, satellite links, or public safety networks like FirstNet, the actual available space for data is often lower than the standard. When a secure, encrypted packet hits an older router with a lower limit (e.g., 1300 bytes), that router should ideally send an Internet Control Message Protocol (ICMP) message stating “Destination Unreachable” back to the sender to request a smaller size.

But that doesn’t always happen. The “Black Hole” occurs when firewalls or middleboxes silently drop those ICMP feedback messages. Without this feedback, the sender keeps trying to send large packets that never arrive, and the application simply waits in a “zombie” state until the connection eventually times out.


Cloudflare’s solution: active probing with PMTUD

Cloudflare’s implementation of RFC 8899 Datagram Packetization Layer Path MTU Discovery (PMTUD) removes the reliance on these fragile, legacy feedback loops. Because our modern client utilizes the MASQUE protocol — built on top of Cloudflare’s open source QUIC library — the client can perform active, end-to-end interrogation of the network path.

Instead of waiting for an error message that might never come, the client proactively sends encrypted packets of varying sizes to the Cloudflare edge. This probe tests MTUs from the upper bound of the supported MTU range to the midpoint, until the client narrows down to the exact MTU to match. This is a sophisticated, non-disruptive handshake happening in the background. If the Cloudflare edge receives a specific-sized probe, it acknowledges it; if a probe is lost, the client instantly knows the precise capacity of that specific network segment.

The client then dynamically resizes its virtual interface MTU on the fly, by periodically validating the capacity of the path that we established at connection onset. This ensures that if, for example, a user moves from a 1500-MTU Wi-Fi network at a station to a 1300-MTU cellular backhaul in the field, the transition is seamless. The application session remains uninterrupted because the client has already negotiated the best possible path for those secure packets.


Real-world impact, from first responders to hybrid workers

This technical shift has profound implications for mission-critical connectivity. Consider the reliability needs of a first responder using a vehicle-mounted router. These systems often navigate complex NAT-traversal and priority-routing layers that aggressively shrink the available MTU. Without PMTUD, critical software like Computer Aided Dispatch (CAD) systems may experience frequent disconnects during tower handoffs or signal fluctuations. By using active discovery, the Cloudflare One Client maintains a sticky connection that shields the application from the underlying network volatility.

This same logic applies to the global hybrid workforce. A road warrior working from a hotel in a different country often encounters legacy middleboxes and complex double-NAT environments. Instead of choppy video calls and stalled file transfers, the client identifies the bottleneck in seconds and optimizes the packet flow — before the user even notices a change.

Get PMTUD for your devices

Anyone using the Cloudflare One Client with the MASQUE protocol can try Path MTU Discovery now for free. Use our detailed documentation to get started routing traffic through the Cloudflare edge with the speed and stability of PMTUD on your Windows, macOS, and Linux devices.

If you are new to Cloudflare One, you too can start protecting your first 50 users for free. Simply create an account, download the Cloudflare One Client, and follow our onboarding guide to experience a faster, more stable connection for your entire team.

How Automatic Return Routing solves IP overlap

Post Syndicated from Steve Welham original https://blog.cloudflare.com/automatic-return-routing-ip-overlap/

The public Internet relies on a fundamental principle of predictable routing: a single IP address points to a logically unique destination. Even in an Anycast architecture like Cloudflare’s, where one IP is announced from hundreds of locations, every instance of that IP represents the same service. The routing table always knows exactly where a packet is intended to go.

This principle holds up because global addressing authorities assign IP space to organizations to prevent duplication or conflict. When everyone adheres to a single, authoritative registry, a routing table functions as a source of absolute truth.

On the public Internet, an IP address is like a unique, globally registered national identity card. In private networks, an IP is just a name like “John Smith”, which is perfectly fine until you have three of them in the same room trying to talk to the same person.

As we expand Cloudflare One to become the connectivity cloud for enterprise backbones, we’ve entered the messy reality of private IP address space. There are good reasons why duplication arises, and enterprises need solutions to handle these conflicts.

Today, we are introducing Automatic Return Routing (ARR) in Closed Beta. ARR is an optional tool for Cloudflare One customers that gives you the flexibility to route traffic back to where it originated, without requiring an IP route in a routing table. This capability allows overlapping networks to coexist without a single line of Network Address Translation (NAT) or complex Virtual Routing and Forwarding (VRF) configuration.

The ambiguity problem

In enterprise networking, IP overlap is a fact of life. We see it in three common scenarios that traditionally cause toil for admins:

  • Mergers & acquisitions: Two companies merge, and both use 10.0.1.0/24 for their core services.

  • Extranets: Partners, vendors or customers securely connect to your network using their own internal IP schemes, leading to unavoidable conflicts.

  • Cookie-cutter architectures: SaaS providers or retail brands use identical IP space for every branch to simplify deployment and operation.

The problem arises when these sites try to talk to the Internet or a data center through Cloudflare. If two different sites send traffic from the same source IP, the return packet hits an architectural wall. The administrator has to make a decision on how to route the traffic based on the ambiguous destination. If the administrator puts both routes into the routing table, it will be non-deterministic as to which path is taken: the correct path or the incorrect path. From the perspective of a standard routing table, there is no way to distinguish between two identical paths.


This diagram shows two branches (Site A and Site B) both using 10.0.1.0/24. They send packets to Cloudflare. The return packet from the Internet reaches the Cloudflare edge, and this return traffic is sometimes sent to the wrong site because the routing table has two identical egress options.

Why traditional fixes fail

There are numerous ways to resolve this ambiguity, and we are committed to solving them in the easiest way for our customers to manage. The traditional “industry standard” fixes are functional, but they introduce significant administrative overhead and complexity that we are committed to eliminating:

  1. Virtual Routing and Forwarding (VRF): This involves creating “virtual” routing tables to keep traffic isolated. While effective for separation, it adds administrative overhead. Managing cross-VRF communication (route leaking) is brittle and complex at scale. 

  2. Network Address Translation (NAT): You can NAT each overlapping subnet from an unmanaged IP space to a managed IP range that is unique in your network. This approach works well, but the mapping is administrative toil for each new site or partner.

Typically, the use case we hear from customers is an overlapping network needing to access the Internet or a private data center. How do we solve this without administrative overhead?

Introducing Automatic Return Routing (ARR)

We developed ARR as a “zero-touch” solution to this problem. ARR moves the intelligence from the routing table to stateful tracking.

So what is stateful tracking?

In traditional networking, a router is “forgetful” (aka “stateless”). It treats every single packet like a total stranger. Even if it just saw a packet from the exact same source going to the exact same destination a millisecond ago, it has to look at its routing table all over again to decide where to send the next one.

With stateful tracking, the system has a memory. It recognizes when a series of packets are all part of the same “flow” (that is, a network conversation between two endpoints), and remembers key information about that flow until it finishes. With ARR, we remember one extra piece of information when initializing the flow: the specific tunnel that initiated it. This allows us to send return traffic back to that same tunnel, without ever consulting a routing table!

Instead of asking the network, “Where does this IP live?” ARR asks, “Where did this specific conversation originate?”

The Logic:

  1. Ingress: A packet arrives at the Cloudflare edge from a site via a specific connection, i.e. an IPsec tunnel, GRE tunnel, or Network Interconnect.

  2. Flow Matching: The Cloudflare Virtual Network first checks (by header inspection) whether that packet matches an existing flow.

    1. Proxying: If the packet matches, that’s great! All of the decisions about this traffic have already been made and stored in our memory. All we need to do is pass that packet along already-established paths.

    2. Flow Setup: If it doesn’t match an existing flow, we decide which parts of the Cloudflare One stack to pass it through (e.g. Gateway, DLP, Firewall), as well as its ultimate destination. We store all of this state in memory. With ARR, this is when we record which tunnel initiated the flow.

  3. Symmetric Return: When return traffic arrives from the destination, the Cloudflare Virtual Network uses its existing in-memory state to proxy the traffic. Crucially, it does this without needing to examine the traffic’s destination IP, which could very well be reused across different sites. This completely bypasses the need to consult a routing table. We see the originating tunnel in the flow state and deliver the packet directly back to it.


Example of overlapping source IPs tracked by in-memory flow state, tagged with source onramp to inform return routing decision.

By remembering the originating tunnel for every flow, ARR facilitates zero-touch routing. If your site traffic is only client-to-Internet, there is no need to configure return routes at all, reducing toil when deploying new branch sites or “Coffee Shop Networking.”

Built on Unified Routing

To make ARR a reality at Cloudflare scale, we plugged into another initiative we have been working on: Unified Routing.

Historically, Cloudflare Zero Trust (users/proxies) and Cloudflare WAN (network-layer/sites) lived at different levels of the system. Cloudflare WAN relied on kernel primitives (Linux network namespaces, routes, eBPF, etc). Zero Trust lived in userspace, where proxies could perform deep inspection and application-level security. This “split-brain” approach often required complex logic to move traffic between component services, and some of this complexity became product limitations that customers might notice.



With our new Unified Routing mode, we have moved the initial routing decision from our network-layer data plane into our existing Zero Trust userspace routing logic, the same hardened software used by Cloudflare One Clients and Cloudflare Tunnel in our Zero Trust solution. This change has many benefits to how we enable our customers to use their private networks with products across the Cloudflare platform, as it fixes long-standing interoperability problems between Cloudflare WAN and Zero Trust. Unified Routing means you can use Cloudflare Mesh, Cloudflare Tunnel, and IPsec/GRE on-ramps together in the same account without a single conflict.


In September 2025, we deployed Unified Routing mode internally for all Cloudflare employees and sites. We saw immediate 3-5x performance improvements for Cloudflare One Clients, as you can see in the graph above.

When designing ARR, we knew that we needed to move away from kernel-based routing and build on our new Unified Routing framework.

When Unified Routing is enabled, all Cloudflare WAN traffic flows through Apollo, our Zero Trust hub. Unlike the Linux kernel’s standard routing table, our userspace data plane is fully programmable. We can attach metadata, like the originating Tunnel ID, directly to a flow entry in Apollo. 

Each packet is tracked by flow from the moment it hits our edge, and we no longer need to make independent, per-packet routing decisions. Instead, we can make consistent, session-aware decisions for the lifetime of the flow.

ARR is straightforward to enable on a per tunnel or interconnect basis:


Once enabled for a tunnel or interconnect, any traffic that matches an existing flow is routed back to the connection where it originated, without consulting the routing table.

Putting ARR to work

For the enterprise architect, ARR is a tool to bypass the persistent friction of IP address conflicts. Whether integrating an acquisition or onboarding a partner, the goal is to make the network invisible, so you can focus on the applications, not the plumbing.

Today, ARR is in closed beta and supports overlapping IP addresses accessing the Internet via our Secure Web Gateway. We are already extending this to support private data center access, adding mid-flow failover (pinning the flow to a primary onramp, and seamlessly detecting when that flow fails over to a backup onramp), and further investing in the architectural capabilities needed to make IP overlap a non-issue for even the most complex global deployments.

Not using Cloudflare One yet? Start now with our Free and Pay-as-you-go plans to protect and connect your users and networks, and contact us for comprehensive private WAN connectivity via IPsec and private interconnect.

A QUICker SASE client: re-building Proxy Mode

Post Syndicated from Koko Uko original https://blog.cloudflare.com/faster-sase-proxy-mode-quic/

When you need to use a proxy to keep your zero trust environment secure, it often comes with a cost: poor performance for your users. Soon after deploying a client proxy, security teams are generally slammed with support tickets from users frustrated with sluggish browser speed, slow file transfers, and video calls glitching at just the wrong moment. After a while, you start to chalk it up to the proxy — potentially blinding yourself to other issues affecting performance. 

We knew it didn’t have to be this way. We knew users could go faster, without sacrificing security, if we completely re-built our approach to proxy mode. So we did.

In the early days of developing the device client for our SASE platform, Cloudflare One, we prioritized universal compatibility. When an admin enabled proxy mode, the Client acted as a local SOCKS5 or HTTP proxy. However, because our underlying tunnel architecture was built on WireGuard, a Layer 3 (L3) protocol, we faced a technical hurdle: how to get application-layer (L4) TCP traffic into an L3 tunnel. Moving from L4 to L3 was especially difficult because our desktop Client works across multiple platforms (Windows, macOS, Linux) so we couldn’t use the kernel to achieve this.

To get over this hurdle, we used smoltcp, a Rust-based user-space TCP implementation. When a packet hit the local proxy, the Client had to perform a conversion, using smoltcp to convert the L4 stream into L3 packets for the WireGuard tunnel.

While this worked, it wasn’t efficient. Smoltcp is optimized for embedded systems, and does not support modern TCP features. In addition, in the Cloudflare edge, we had to convert the L3 packets back into an L4 stream. For users, this manifested as a performance ceiling. On media-heavy sites where a browser might open dozens of concurrent connections for images and video, and the lack of a high performing TCP stack led to high latency and sluggish load times when even on high-speed fiber connections, proxy mode felt significantly slower than all the other device client modes.

Introducing direct L4 proxying with QUIC

To solve this, we’ve re-built the Cloudflare One Client’s proxy mode from the ground up and deprecated the use of WireGuard for proxy mode, so we can capitalize on the capabilities of QUIC. We were already leveraging MASQUE (part of QUIC) for proxying IP packets, and added the usage of QUIC streams for direct L4 proxying.

By leveraging HTTP/3 (RFC 9114) with the CONNECT method, we can now keep traffic at Layer 4, where it belongs. When your browser sends a SOCKS5 or HTTP request to the Client, it is no longer broken down into L3 packets.


Instead, it is encapsulated directly into a QUIC stream.

This architectural shift provides three immediate technical advantages:

  • Bypassing smoltcp: By removing the L3 translation layer, we eliminate IP packet handling and the limitations of smoltcp’s TCP implementation.

  • Native QUIC Benefits: We benefit from modern congestion control and flow control, which are handled natively by the transport layer.

  • Tuneability: The Client and Cloudflare’s edge can tune QUIC’s parameters to optimize performance.

In our internal testing, the results were clear: download and upload speeds doubled, and latency decreased significantly.

Who benefits the most

While faster is always better, this update specifically unblocks three key common use cases.

First, in coexistence with third-party VPNs where a legacy VPN is still required for specific on-prem resources or where having a dual SASE setup is required for redundancy/compliance, the local proxy mode is the go-to solution for adding zero trust security to web traffic. This update ensures that “layering” security doesn’t mean sacrificing the user experience.

Second, for high-bandwidth application partitioning, proxy mode is often used to steer specific browser traffic through Cloudflare Gateway while leaving the rest of the OS on the local network. Users can now stream high-definition content or handle large datasets without sacrificing performance.

Finally, developers and power users who rely on the SOCKS5 secondary listener for CLI tools or scripts will see immediate improvements. Remote API calls and data transfers through the proxy now benefit from the same low-latency connection as the rest of the Cloudflare global network.

How to get started

The proxy mode improvements are available with minimum client version 2025.8.779.0 for Windows, macOS, and Linux devices. To take advantage of these performance gains, ensure you are running the latest version of the Cloudflare One Client.

  1. Log in to the Cloudflare One dashboard.

  2. Navigate to Teams & Resources > Devices > Device profiles > General profiles.

  3. Select a profile to edit or create a new one and ensure the Service mode is set to Local proxy mode and the Device tunnel protocol is set to MASQUE.

You can verify your active protocol on a client machine by running the following command in your terminal: 

warp-cli settings | grep protocol

Visit our documentation for detailed guidance on enabling proxy mode for your devices.

If you haven’t started your SASE journey yet, you can sign up for a free Cloudflare One account for up to 50 users today. Simply create an account, download the Cloudflare One Client, and follow our onboarding guide to experience a faster, more stable connection for your entire team.

Mind the gap: new tools for continuous enforcement from boot to login

Post Syndicated from Alex Holland original https://blog.cloudflare.com/mandatory-authentication-mfa/

One of our favorite ask-me-anything questions for company meetings or panels at security conferences is the classic: “What keeps you up at night?”

For a CISO, that question is maybe a bit of a nightmare in itself. It does not have one single answer; it has dozens. It’s the constant tension between enabling a globally distributed workforce to do their best work, and ensuring that “best work” does not inadvertently open the door to a catastrophic breach.

We often talk about the “zero trust journey,” but the reality is that the journey is almost certainly paved with friction. If security is too cumbersome, users find creative (and dangerous) ways around it. If it’s seamless at the cost of effectiveness, it might not be secure enough to stop a determined adversary.

Today, we are excited to announce two new tools in Cloudflare’s SASE toolbox designed to modernize remote access by eliminating the “dark corners” of your network security without adding friction to the user experience: mandatory authentication and Cloudflare’s own multi-factor authentication (MFA). 

Addressing the gap between installation and enforcement

When you deploy the Cloudflare One Client, you gain incredible visibility and control. You can apply policies for permitted destinations, define the Internet traffic that routes through Cloudflare, and set up traffic inspection at both the application and network layer. But there has always been a visibility challenge from when there is no user actually authenticated.

This gap occurs in two primary scenarios:

  1. A new device: Cloudflare One Client is installed via mobile device management (MDM), but the user has not authenticated yet.

  2. Re-authentication grey zone: The session expires, and the user, either out of forgetfulness or a desire to bypass restrictions, does not log back in.

In either case, the device is now unknown. This is dangerous. You lose visibility, and your security posture reverts to whatever the local machine allows.

Introducing mandatory authentication

To close this loop, we are introducing mandatory authentication. When enabled via your MDM configuration, the Cloudflare One Client becomes the gatekeeper of Internet access from the moment the machine boots up.

If a user is not actively authenticated, the Cloudflare One client will:

  • Block all Internet traffic by default using the system firewall.

  • Allow traffic from the device client’s authentication flow using a process-specific exception.

  • Prompt users to authenticate, guiding them through the process, so they don’t have to hunt for the right buttons.

By making authentication a prerequisite for connectivity, you ensure that every managed device is accounted for, all the time.

Note: mandatory authentication will become available in our Cloudflare One client on Windows initially, with support for other platforms to follow. 

When one source of trust is not enough

Most organizations have moved toward single sign-on (SSO) as their primary security anchor. If you use Okta, Entra ID, or Google, you likely require MFA at the initial login. That’s a great start, but in a modern threat landscape, it is no longer the finish line.

The hard truth is that identity providers (IdPs) are high-value targets. If an attacker successfully compromises a user’s SSO session, perhaps through a sophisticated session hijacking or social engineering, they effectively hold the keys to every application behind that SSO.

Cloudflare’s independent MFA: a secondary root of trust

This is where Cloudflare’s MFA can help. Think of this as a “step-up MFA” that lives at the network edge, independent of your IdP.

By remaining separate from your IdP, this introduces another authority that has to “sign off” on any user trying to access a protected resource. That means even if your primary IdP credentials are compromised or spoofed, an attacker will hit a wall when trying to access something like your production database—because they do not have access to the second factor.

Cloudflare Access will offer a few different means of providing MFA:

  • Biometrics (i.e., Windows Hello, Apple Touch ID, and Apple Face ID)

  • Security key (WebAuthn and FIDO2 as well as PIV for SSH with Access for Infrastructure)

  • Time-based one-time password (TOTP) through authenticator apps

Administrators will have the flexibility to define how users must authenticate and how often. This can be configured not only at a global level (i.e., establish mandatory MFA for all Access applications), but also with more granular controls for specific applications or policies. For example, your organization may decide to allow lower assurance MFA methods for chat apps, but require a security key for access to source code.

Or, you could enforce strong MFA to sensitive resources for third-parties like contractors, who otherwise may use a personal email or social identity like LinkedIn. You can also easily add modern MFA methods to legacy apps that don’t otherwise support it natively, without touching a line of code.

End users will be able to enroll an MFA device easily through their App Launcher.


Example of what customizing MFA settings for an Access policy may look like. Note: This is a mockup and may change.

Cloudflare’s independent MFA is in closed beta with new customers being onboarded each week. You can request access here to try out this new feature!

Helping CISOs sleep at night

Security is often a game of “closing the loop.” By ensuring that devices are registered and authenticated before they can touch the open Internet and by requiring an independent second layer of verification for your most precious assets, we are making the “blast radius” of a potential attack significantly smaller.

These features don’t just add security; they add certainty. Certainty that your policies are being enforced and certainty that a single compromised password won’t lead to a total breach.

We are moving beyond simple access control and into a world of continuous, automated posture enforcement. And we’re just getting started.

Ready to lock down your fleet? You can get started today with Cloudflare One for free for up to 50 users. 

We’re excited to see how you use these tools to harden your perimeter and simplify your users’ day-to-day workflows. As always, we’d love to hear your feedback! Join us in the Cloudflare Community or reach out to your account team to share your thoughts.

Defeating the deepfake: stopping laptop farms and insider threats

Post Syndicated from Ann Ming Samborski original https://blog.cloudflare.com/deepfakes-insider-threats-identity-verification/

Trust is the most expensive vulnerability in modern security architecture. In recent years, the security industry has pivoted toward a zero trust model for networks — assuming breach and verifying every request. Yet when it comes to the people behind those requests, we often default back to implicit trust. We trust that the person on the Zoom call is who they say they are. We trust that the documents uploaded to an HR portal are genuine.

That trust is now being weaponized at an unprecedented scale.

In our 2026 Cloudflare Threat Report, we highlight a rapidly accelerating threat vector: the rise of “remote IT worker” fraud. Often linked to nation-states, including North Korea, these are not just individual bad actors. They are organized operations running laptop farms: warehouses of devices remotely accessed by workers using stolen identities to infiltrate companies, steal intellectual property (IP), and funnel revenue illicitly.

These attackers have evolved and continue to do so with advancements in artificial intelligence (AI). They use generative AI to pass interviews and deepfake tools to fabricate flawless government IDs. Traditional background checks and standard identity providers (IdPs) are no longer enough. Bad actors are exploiting an identity assurance gap, which exists because most zero trust onboarding models verify devices and credentials, not people.

To close this gap, Cloudflare is partnering with Nametag, a pioneer in workforce identity verification, to bring identity-verified onboarding and continuous identity assurance to our SASE platform, Cloudflare One.

Your biggest insider threat was scheming from the start

The challenge with insider risk is that companies naturally want to trust their employees. By the time malicious actors are detected by traditional data loss prevention (DLP) or user entity behavior analytics (UEBA) tools, they are already inside the perimeter. They have valid credentials, a corporate laptop, and access to sensitive repositories.

The “remote IT worker” scheme exploits the gap between hiring and onboarding. Attackers use stolen or fabricated identities to get hired. Once the laptop is shipped to a “mule” address (typically a domestic laptop farm located in the country of the remote worker’s alleged employment), it is racked and connected to a keyboard, video, and mouse (KVM) switch. The remote actor then logs in via VPN (or perhaps remote desktop), appearing to be a legitimate employee.

Because the credentials are valid and the device is corporate-issued, standard zero trust network access (ZTNA) policies often see this traffic as “safe” — when in fact it’s an enormous risk to your business.

Enter identity-verified zero trust

Cloudflare Access already serves as the aggregation layer for your security policies — checking attributes such as device posture, location, and user group membership before granting access to applications, infrastructure, or MCP servers. Through our partnership with Nametag, we are adding a critical new layer: workforce identity verification.

Previously, IT departments had no choice but to assume trust throughout the new user onboarding process. They could either ship a laptop to an address provided by the new hire and then send their initial credentials to their personal email, or require them to come in person –– costly and impractical in a world of distributed workforces and contractors. 

Nametag replaces assumed trust with verified identity, ensuring that the person receiving, configuring, and connecting a device to protected resources is a real person, a legitimate person, and the right person throughout the entire process. This integration allows organizations to uncover and stop bad actors, including North Korean IT workers, before they gain access to any internal resources or data.

How it works

Nametag is integrated using OpenID Connect (OIDC). You can configure it as an IdP within Cloudflare Access or chain it as an external evaluation factor alongside your primary identity provider (like Okta or Microsoft Entra ID).


Example of the Cloudflare Access login page prompting for a user to authenticate using Nametag.

Here is an example workflow for a high-security onboarding scenario:

  1. Trigger: A new user attempts to access their initial onboarding portal (protected by Cloudflare Access).

  2. Challenge: Instead of just asking for a username and password, Cloudflare directs the user to Nametag for authentication via OIDC.

  3. Verification: The user enters their new work email address, then snaps a quick selfie and scans their government-issued photo ID using their phone.

  4. Attestation: Nametag’s Deepfake Defense™ identity verification engine leverages advanced cryptography, biometrics, AI and other features to ensure that the user is both a real person and the right person. Nametag’s technology uniquely prevents bad actors from using deepfake IDs and selfies in sophisticated injection attacks or presentation attacks (e.g., holding up a printed photo).

  5. Enforcement: If that check is successful, Nametag returns an ID token to Cloudflare to complete the OIDC flow. Cloudflare then grants or denies access to the application based on the user’s identity and the Access policies.

All of this happens before the user can access email, code repositories, or other internal resources.


Verifying your identity with Nametag takes under 30 seconds to complete. No biometrics are stored after this interaction.

A layered defense

This partnership complements Cloudflare’s existing suite of insider threat protections. Today, you can:

Nametag provides the missing link: identity assurance. It moves us from knowing what account is logging in, to knowing exactly who is behind the keyboard.

In an era where AI can fake a face and a voice, cryptographic proof of identity is the only way to safely trust your workforce.

Beyond onboarding: continuous verification

While stopping bad actors at the door is critical, the threat landscape is dynamic. Legitimate credentials can be sold, and legitimate employees can be compromised.

To protect against that present and ever-evolving risk, Cloudflare Access now incorporates user risk scores so security teams can build context-aware policies. If a user’s risk score suddenly increases from low to high, access can be revoked to any (or all) applications.

In the future, you’ll be able to enforce step-up verification based on signals such as user risk score, in the middle of an active session. Rather than hitting the “big red button” and potentially disrupting a user who does have a legitimate reason for accessing the production billing system from an usual location, you will instead be able to challenge the user to verify with Nametag or by using Cloudflare’s independent MFA with strong authentication methods. If the user is a session hijacker or a bot, they will be unable to pass these checks. 

This capability will also extend to self-service IT workflows. Password resets and MFA device registration are prime targets for social engineering (e.g., the MGM Resorts help desk attacks). By placing Nametag behind Cloudflare Access for these specific portals, you eliminate the possibility of a support agent being socially engineered into resetting a password for an attacker.

Defend against the future, now

Security cannot rely on assumptions. As AI tools lower the barrier to entry for sophisticated fraud, your defenses must evolve to verify the human element with cryptographic certainty. The “remote IT worker” threat is not a hypothetical scenario—it is an active campaign targeting organizations globally.

You don’t need to overhaul your entire infrastructure to stop it. You can layer these protections on top of your existing IdP and applications immediately.

Cloudflare One is free for up to 50 users, allowing you to pilot identity-verified onboarding flows or protect high-risk internal portals right now.

  • Get started: Sign up for Cloudflare One to begin building your policy engine.

  • Deploy the integration: Follow the step-by-step guide to connect Nametag to Cloudflare Access in minutes.

  • Understand the risk: Read the full Cloudflare Threat Report to see the data behind the rise in insider threats and AI impersonation.

Don’t wait for a breach to verify your workforce. Start implementing a SASE architecture that trusts nothing — not even the face on the screen — without verification.

Stop reacting to breaches and start preventing them with User Risk Scoring

Post Syndicated from Nevins Bartolomeo original https://blog.cloudflare.com/adaptive-access-user-risk-scoring/

Most security teams spend their days playing a high-stakes game of Whac-A-Mole. A user’s credentials get phished, or they accidentally download a malicious file, and suddenly you’re in incident response mode. 

We built our SASE platform, Cloudflare One, to stop that cycle. By placing Access and Gateway in front of your applications and Internet traffic, we gave you the tools to decide who gets in and where they can go.

Today, we’re making those decisions smarter. You can now incorporate User Risk Scores directly into your zero trust network access (ZTNA) policies. Instead of just checking “Who is this user?” and “Is their device healthy?”, you can now ask, “How has this user been behaving lately?” and adjust their access in real time.

Step 1: From “what” to “how”

For years, traditional corporate access was binary. You either had the right login and the right certificate, or you didn’t. But identity is fluid. A legitimate user can become a risk if their account is compromised or if they start exhibiting “insider threat” behaviors — like impossible travel, multiple failed login attempts, or triggering data loss prevention rules by moving sensitive data.

Cloudflare One now continuously calculates a risk score for every user in your organization based on these behaviors.


Example list of users and their risk scores

Once you’ve onboarded your team to Cloudflare One, you can navigate to the Team & Resources > Users > Risk Score section of the dashboard. Here, you can define which behaviors matter to you. For example, you might decide that impossible travel has a “high” risk level, while using a device in need of an update is “medium.”

Cloudflare’s risk engine continuously evaluates telemetry from across the SASE platform. For internal signals, the engine monitors logs from Cloudflare Access (e.g., successful/failed logins, geographic context) and Cloudflare Gateway (e.g., malware hits, risky browsing categories, or sensitive data triggers in DLP).

For third-party signals, we’ve built service-to-service integrations with partners like CrowdStrike and SentinelOne. These integrations allow Cloudflare to ingest external telemetry, such as CrowdStrike’s device posture attributes, and map it to a user’s profile.

The calculation logic is designed to be deterministic:

  1. Selection: Administrators choose which specific “risk behaviors” (impossible travel, DLP violations, and more) to enable for their organization.

  2. Aggregation: The engine identifies all risk events associated with a user.

  3. Scoring: A user’s risk score is determined by the highest risk level (low, medium, or high) of any enabled behavior triggered during that period.

  4. Reset: If an admin investigates and clears an incident, they can manually reset the user’s score, which preserves the history but resets their access based on risk data gathered going forward.

Step 2: Easily apply adaptive access

Knowing a user is risky is step one. Doing something about it — automatically — is step two.

In the past, if a security analyst saw a suspicious user, they’d have to manually revoke sessions or move the user into a “restricted” group in their Identity Provider (IdP). That takes time — time an attacker uses to move laterally.

Now, you can build Adaptive Access policies. When you create or edit an Access policy, you’ll find a new selector: User Risk Score.


Example of the new User Risk Score selector in an Access policy. 

This allows you to create global or application-specific rules such as: “If a user’s risk score is high, they cannot access the Finance Portal,” or “If a user’s risk score is medium, they must use a physical security key to log in.” Such rules ensure corporate operations are not interrupted while additional layers of security are applied.

Step 3: Closing the loop

The best part of this system is that it’s dynamic. If a user’s risk score drops after being reviewed and cleared by an investigator, their access is automatically restored based on your policy. Today, risk-based access can revoke access in the middle of an active session when risk score increases. In the future, we will explore expanding this to enforce step-up MFA in the middle of an active session when the risk score changes as well. 

We’ve also made sure this works with the tools you already use. If you use Okta, Cloudflare can share these risk signals back to Okta, ensuring that a user flagged on the network is also restricted at the front door of your SSO. This integration uses the Shared Signals Framework, which enables the sharing of risk signals across platforms.

Move faster, stay secure

We built Cloudflare One so that security teams could stop being the “department of no” and start being the department of “yes, and safely.” Incorporating user risk scores into your Access policies is the next step in that journey. It moves your security from a static snapshot at login to a continuous, living conversation with your network architecture.

If you’re already a Cloudflare customer, you can start exploring these risk signals in your dashboard today. If you’re still wrestling with legacy VPNs or manual security reviews, we’d love to help you flip the switch.

You can get started for free for up to 50 users — no sales call required. For larger organizations looking to integrate third-party signals like CrowdStrike or SentinelOne into their global policies, our team is ready to walk you through a ZTNA pilot.

Reach out to our team here to see how adaptive access can fit into your SASE roadmap.