Cloudflare just made Gateway and DLP programmable with Workers — here's what full-stack network security means
Cloudflare merged Gateway and Data Loss Prevention with Workers. You can now write JS functions that intercept, rewrite, or block traffic at the edge before it hits your origin.
Cloudflare announced yesterday that Gateway and Data Loss Prevention now run on Workers. You can write JS functions that intercept HTTP requests, inspect payloads, rewrite headers, block traffic, or trigger alerts — all at the edge, before anything hits your origin.
This is a bigger shift than it sounds. Most enterprise security tools are black boxes. You configure policies in a UI, hope the vendor's logic matches your threat model, and file support tickets when it doesn't. Cloudflare just turned that into code you control.
What's actually new
Gateway was already a secure web gateway — it sat between your users and the internet, enforcing firewall rules, DNS filtering, and identity checks. DLP added pattern matching for sensitive data (credit cards, SSNs, API keys) leaving your network.
The Workers integration means you can now:
- Write custom inspection logic in JS that runs on every request
- Call external APIs mid-flight (check a blocklist, log to your SIEM, query a database)
- Rewrite requests or responses based on arbitrary conditions
- Build multi-step workflows (block, alert, log, redirect) without stitching tools together
Cloudflare gives the example of a company that wants to block file uploads over 10MB to non-approved domains. Before: configure a DLP rule in the UI, hope it covers edge cases, find out weeks later it didn't. Now: write a Worker that checks request.headers.get('content-length'), inspects the destination, and returns a 403 if it doesn't match your policy. Add logging, add exemptions, add conditional logic. It's code.
Why this matters for agentic deployments
We deploy voice agents that call external APIs — logistics carriers, CRMs, payment processors. Every API call is a potential leak vector. A poorly-scoped agent could exfiltrate customer data, overshare PII, or hit rate limits that cascade into downtime.
Most DLP tools operate at the payload level — they scan for patterns in transit. That works for credit cards but not for "the agent just sent 400 customer records to a new Airtable base it created without telling anyone." You need semantic inspection: is this API call expected? Is the volume normal? Is the destination approved?
Programmable Gateway means you can write that logic. We can inject a Worker that checks agent-generated requests against a whitelist of approved endpoints, logs every non-standard call, and blocks anything that looks like bulk export. We can rate-limit per-agent instead of per-IP. We can add circuit breakers that pause an agent if it's making unusual API patterns.
This is the first network security product we've seen that treats agents as a distinct threat model instead of just another HTTP client.
The integration path
Cloudflare's docs show Workers DLP as a function you define in the dashboard. It receives a Request object, runs your logic, and returns a modified Request or a Response that short-circuits the chain.
The syntax is familiar if you've written Cloudflare Workers before. You import the Gateway SDK, call gateway.inspectRequest(request), and get back metadata like matched DLP rules, identity claims, and destination classification. You can then decide what happens next.
The performance overhead is minimal — Workers run in V8 isolates with sub-millisecond cold starts. Cloudflare claims p99 latency under 5ms for most DLP checks. That's fast enough to sit inline on every request without users noticing.
What we'd deploy this for
We have three immediate use cases:
Agent API whitelisting. Every agent we deploy calls 3–8 external APIs. We can now enforce at the network layer that Jordan (our NEMT dispatcher) can only call Google Maps, Bergsify's internal CRM, and Twilio. If it tries to call anything else, block and alert.
PII redaction on egress. We handle SSNs and DOBs for NEMT eligibility checks. Those fields should never leave our infrastructure unencrypted. A DLP Worker can scan outbound payloads, redact matches, and log violations.
Rate-limit per agent, not per IP. Cloudflare Workers can key rate limits by custom identifiers. We can tag requests with
agent_id, apply per-agent quotas, and prevent one misconfigured loop from burning through our API budget.
The third one is the killer feature. Most rate-limiting is IP-based, which doesn't map to agents. An agent that spins up 20 parallel threads on the same IP looks like one user. A Worker-based rate limiter can count by agent_id and enforce quotas that actually match how agents behave.
What's missing
Cloudflare's announcement doesn't mention agent-specific primitives. There's no built-in "agent identity" concept, no pre-built rate-limit-by-agent-id module, no agent observability dashboard. You have to build that yourself.
The DLP pattern library also skews toward traditional threats — credit cards, SSNs, secrets. There's no "detect agent bulk export" or "flag unusual API call volume" preset. You write that logic from scratch.
Still, the fact that you can write it is the unlock. Every other enterprise security tool we've evaluated has a fixed taxonomy of threats and a UI for configuring policies within that taxonomy. Cloudflare just gave you the primitives and said "build what you need."
That's the right API for teams running production agents. The threat model is still evolving; the tooling shouldn't be locked down.