Article / Public
Cloudflare extends Gateway and DLP decisions with Workers code
Gateway Forward entered public beta on October 15, alongside the availability of DLP custom validation functions. Gateway Custom Functions are planned before year-end.
In an announcement dated October 15, 2026, Cloudflare introduced capabilities connecting its Gateway secure web gateway and DLP data loss prevention service to the Workers computing platform. Gateway’s Forward action entered public beta, while DLP custom validation functions became available. A separate feature, Gateway Custom Functions, is planned before year-end. These schedules show that similarly named capabilities are not all at the same stage at the same time.
Forward: Putting code in the request path
According to Cloudflare, Forward operates on traffic allowed by HTTP policies. The first matching Forward rule sends the request to its associated Worker. Acting as a proxy, the Worker can receive the request headers and body, modify them, send the request to its destination, and also adjust the returning response. The extension point therefore goes beyond reporting a security decision and sits within the HTTP exchange itself.
In the company’s description, Gateway remains responsible for TCP connections, TLS termination and re-encryption, certificate management, and HTTP version negotiation. The Worker handles transformation logic. Not every Worker needs to modify traffic: the company also gives examples such as sending notifications, writing to an external logging pipeline, or calling a webhook using the matched request’s context. These are producer-provided use cases, not independently verified deployment results.
Conceptual HTTP flow with Forward
- Allowed request
The first matching Forward rule applies to traffic allowed by HTTP policies.
- Worker processing
The Worker can process request headers and body, then forward the request to its destination.
- Returning response
The Worker can also modify the destination’s response before returning it to the user.
Custom Functions: Returning a value rather than transforming traffic
Gateway Custom Functions serve a different purpose. According to Cloudflare, these functions will call a Worker during policy evaluation and return a string, number, or boolean. The returned value can be used in rule conditions like a built-in selector in the policy builder. The key distinction is that Forward processes the HTTP request, while Custom Functions supply data for a decision condition.
Depending on the policy phase, the context supplied to the Worker can include the source IP address, destination, user identity, device posture, and HTTP headers. The company says this approach can also be used in network rules. The planned scope therefore extends beyond HTTP. However, this capability should not be confused with Forward’s existing beta: Gateway Custom Functions remain a feature expected before year-end in the announcement.
DLP: Custom validation after a pattern match
DLP custom validation functions, by contrast, are available as of the announcement date. Cloudflare says customers can use their own validation logic and source of truth inside a Worker. The aim is to obtain more context than whether data merely fits a particular pattern: to assess whether the detected instance is actually relevant to the organization.
In the company’s example, a Worker can perform validation after a DLP detection entry matches and before policy enforcement. Checking the relevant endpoint to determine whether a value resembling a GitHub secret is active is one such scenario. This example does not demonstrate that every detection automatically becomes correct; validation quality still depends on the logic and reference source used. The announcement provides no measured reduction in false positives.
Conceptual connections in DLP custom validation
- DLP match
A detection entry match can initiate validation before the policy decision.
- Validation Worker
Customer-defined logic assesses whether the detected data is relevant.
- Customer’s source of truth
Validation can consult the customer’s reference source; checking whether a key is active is one example.
Performance, failure behavior, and billing
Cloudflare says dispatching to a Worker does not introduce an additional network hop because Gateway and Workers run on the same machines. This is the producer’s architectural explanation, not an independent latency test. In the company’s account, Worker code execution time affects performance. It also emphasizes that Forward functions transforming live requests require careful design to avoid adversely affecting the user experience.
For Custom Functions, behavior following an error, timeout, or unexpected value can be configured per function; the contract requires default values. For billing, traffic dispatched to Workers will count as standard Worker requests. The company also advises accounting for Workers Free execution-time and daily request limits as traffic scales. Enabling a Gateway rule therefore does not separate computing consumption from the cost assessment.
Urazo interpretation
The distinctive element of this announcement is its separation of traffic transformation, value generation for decisions, and DLP validation into different extension points. Identifying where an organization wants to execute code may help clarify both availability schedules and operational responsibility. The promise of flexibility does not remove the need to assess custom code correctness, failure behavior, and usage costs. Urazo has not tested the product; this report relies on Cloudflare’s announcement and contains no independent performance or accuracy measurements.
Source: Cloudflare, “A fully programmable secure web gateway,” October 15, 2026. The cover is an AI-generated illustration conceptually depicting the described traffic and validation flow, not a product screenshot.
Sources
Image: AI-generated illustration. Explanatory animations are conceptual diagrams, not measurements or product demos.