Cloudflare Gateway can now hand traffic to a customer's Worker on every Zero Trust plan

Cloudflare says true programmability means running your own code "inline in the policy evaluation path, at the moment a security decision is made" ^[5]. The two customer cases it cites show what that replaces.

In the first, a team needed HTTP headers injected from JWT claims. Gateway could not read the JWT and write the header, so the team stood up a pool of NGINX proxies solely for that job. Cloudflare notes the pool must be patched, monitored and secured indefinitely ^[6].

In the second, a team wanted a Slack message when an employee signed up for a new SaaS service. The policy engine could only Allow or Block, so the team built a pipeline from Logpush through a SIEM into Slack; messages lagged 5 to 15 minutes and delivery was not guaranteed ^[7].

Cloudflare says that when Gateway forwards traffic to a Worker, the dispatch is a local function call, with no hairpinning and no added latency from crossing a network boundary ^[9]. That covers the hop between Gateway and the Worker. It does not cover the Worker's own work. A Worker that calls an identity provider or a database adds that round trip to the decision. For the no-added-latency claim to transfer to your workload, the Worker's logic has to run on data it already holds.

Failure is the harder question. A rule that ends in Block behaves the same way every time. A rule that ends in customer code can throw, time out or return something unexpected. The excerpt we reviewed ends mid-sentence, before it covers timeouts, CPU limits, pricing, or whether an error fails open or closed.

In our view, that makes the right first use of Forward a rule where an allow-on-failure costs little, such as header injection for an internal app with its own authentication. Hard blocks belong on the built-in actions until the failure behavior is documented. Revisit once it is.