Until now, secure web gateways have worked on a simple model: traffic matches a condition, and a terminal action fires, such as Allow, Block, Isolate or Log. Cloudflare argues this model, which it says has underpinned network security for nearly 30 years, handles common cases well but leaves customers with complex environments stuck. The company's examples include teams standing up pools of NGINX proxies just to inject HTTP headers based on identity provider claims, and building Logpush-to-SIEM-to-Slack pipelines with 5 to 15 minute delays simply to get a Slack notification when an employee signs up for a new SaaS service.

The Forward action routes matched HTTP requests to a Cloudflare Worker, which acts as inline middleware receiving the full headers and request body, letting customers transform traffic or bring their own data into policy evaluation. Cloudflare says Gateway and Workers were built on the same infrastructure, so dispatching traffic to a Worker is a local function call with no additional latency from crossing a network boundary. The company positions this as possible only because it runs both customer compute and a full secure web gateway in the same globally distributed network, across more than 330 locations.

Cloudflare also takes a swipe at the industry, arguing that the term programmability has been diluted because most vendors claim it on the strength of public APIs, Terraform providers and webhooks. In its view, true programmability means running arbitrary code you wrote for your specific environment inline in the policy evaluation path. That framing is the vendor's own, but the underlying distinction between configuration APIs and executable logic in the decision path is a fair one for security teams weighing flexibility against maintenance overhead.