Beyond policies: putting code inside the security path

Security teams are used to making choices from a short menu: allow, block, isolate, or quarantine. Cloudflare’s argument is that this model is too rigid. A SASE platform should let you run your own logic — not just pick a preset action — when traffic hits a policy.

That is what Cloudflare means by programmability, and it’s the direction the company is taking Cloudflare One, its SASE platform. The software-defined network is built so that customers can insert custom code into their security policy enforcement paths.

The distinction between APIs and programmability

Most vendors claim to be programmable because they offer APIs, Terraform providers, and webhooks. Cloudflare does too, but the company argues those capabilities alone are table stakes. Configuration automation is useful; it does not let a policy make a decision.

True programmability, as Cloudflare frames it in this context, is the ability to intercept a security event in real time, enrich it with data from an external system, and act before the request completes. Consider a user trying to open an application that contains sensitive financial data. The policy reaches out to a learning management system to check whether their compliance training is current. If the certification has lapsed, access is denied and the user is shunted to the training portal. The policy did not generate an alert after the fact; it made the call upfront.

One network, shared building blocks

Cloudflare’s global network spans more than 330 cities and sits roughly within 50 milliseconds of 95% of the internet-connected population. The company’s key architectural point is that every service runs on every server in every data center. The SASE platform and the Developer Platform (Workers) are co-located on the same metal.

BLOG-3149 Hero Image

That co-location is deliberate. Customers protecting external web properties, securing internal users and private networks, or building full-stack apps are all using the same primitives. The integration is not a post-hoc set of connectors—the services share the same network and runtime, so policies can call Workers inline without adding a round trip to a separate cloud.

BLOG-3149 Image 1

Managed and custom actions

Cloudflare plans to extend its SASE services with so-called actions. There will be two tiers:

  • Managed actions: templates for common scenarios like IT service management integrations, redirects, and compliance automation.
  • Custom actions: user-defined logic executed as a Cloudflare Worker.

Under this model, when a Gateway HTTP policy matches, the administrator can trigger a Worker instead of only choosing allow, block, or isolate. The code runs at the edge with the full request context available.

What's available today

Several capabilities described in the roadmap—internal functions like Gateway redirects, custom device posture checks, and external evaluation rules—are already available. Workers’ full feature set is as well. What is new is the push to make those extensions a first-class part of Cloudflare One rather than a manual assembly job.

A real implementation: automated device session revocation

One Cloudflare customer wanted to force client re-authentication periodically, the way traditional VPNs do. Cloudflare’s built-in session controls are scoped around per-application policies, not global time-based expiry. So a technical specialist built a solution out of two existing parts of the platform: a scheduled Worker and the Devices API.

The Worker queries for devices inactive beyond a threshold, revokes their registrations, and forces users through their identity provider again. Configuring it takes three environment secrets (API_TOKEN, ACCOUNT_ID, REVOKE_INTERVAL_MINUTES) and a cron trigger (e.g. 0 */4 * * * for every four hours).

Notably, the customer had this policy running in production after an afternoon’s work. A roadmap feature request could easily take months to materialize.

export default {
  async scheduled(event, env, ctx) {
    const API_TOKEN = env.API_TOKEN;
    const ACCOUNT_ID = env.ACCOUNT_ID;
    const REVOKE_INTERVAL_MINUTES = parseInt(env.REVOKE_INTERVAL_MINUTES); // Reuse for inactivity threshold
    const DRY_RUN = env.DRY_RUN === 'true';

    const headers = {
      'Authorization': `Bearer ${API_TOKEN}`,
      'Content-Type': 'application/json'
    };

    let cursor = '';
    let allDevices = [];

    // Fetch all registrations with cursor-based pagination
    while (true) {
      let url = `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/devices/registrations?per_page=100`;
      if (cursor) {
        url += `&cursor=${cursor}`;
      }

      const devicesResponse = await fetch(url, { headers });
      const devicesData = await devicesResponse.json();
      if (!devicesData.success) {
        console.error('Failed to fetch registrations:', devicesData.errors);
        return;
      }

      allDevices = allDevices.concat(devicesData.result);

      // Extract next cursor (adjust if your response uses a different field, e.g., devicesData.result_info.cursor)
      cursor = devicesData.cursor || '';
      if (!cursor) break;
    }

    const now = new Date();

    for (const device of allDevices) {
      const lastSeen = new Date(device.last_seen_at);
      const minutesInactive = (now - lastSeen) / (1000 * 60);

      if (minutesInactive > REVOKE_INTERVAL_MINUTES) {
        console.log(`Registration ${device.id} inactive for ${minutesInactive} minutes.`);

        if (DRY_RUN) {
          console.log(`Dry run: Would delete registration ${device.id}`);
        } else {
          const deleteResponse = await fetch(
            `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/devices/registrations/${device.id}`,
            { method: 'DELETE', headers }
          );
          const deleteData = await deleteResponse.json();
          if (deleteData.success) {
            console.log(`Deleted registration ${device.id}`);
          } else {
            console.error(`Failed to delete ${device.id}:`, deleteData.errors);
          }
        }
      }
    }
  }
};

Other customers have used redirect policies and Workers for coaching pages and purpose-justification screens. Some have written custom logic to evaluate browser attributes ahead of routing decisions.

What the roadmap says

Throughout 2026, Cloudflare plans to deepen the integration between Cloudflare One and the Developer Platform. The first move will be custom actions in Cloudflare Gateway supporting dynamic policy enforcement. Per the company, these actions will draw auxiliary data from customers’ existing databases—a point Cloudflare emphasizes as a way to avoid migrating sensitive data onto its platform. The actions are also intended to carry Cloudflare attributes into downstream systems for better logging and access posture in those internal systems.

The bottom line

Cloudflare’s direction is to make security policy code logic. For security teams this could shift the conversation away from feature requests and roadmap timelines. For MSSPs, it lets them build their own solutions rather than pay for professional services work. And it removes the dynamic-policy function from the vendor’s backlog, placing it with the team that actually knows the requirement: the customer.