Cloudflare and AI: choose your path

Most conversations about AI and Cloudflare start with a product name. It helps to start with the shape of the setup. Then you can see which parts your case needs and which Cloudflare product covers each one.

The shape of every AI setup

Someone acts, and Access checks who it is. The AI runs in an isolated session or in your own app. From there it reaches models, tools and private systems, and each exit gets one gate. Every model call, tool call and connection is logged with the user and the policy.

Three things sit at the edge of this picture: prompts that arrive from the internet, staff who use AI apps you did not build, and AI crawlers that read your sites. The four cases below differ in which of these parts you have to deal with.

A1. Step 1: what kind of AI question is this?

Two questions sort your situation into four cases: do you build AI yourself or use AI that someone else built, and who is affected, your customers or your employees. Each case lists the Cloudflare products to put in place, in order.

A2. The control map: which product guards which traffic

The picture above shows where each control sits. Calls to models go through AI Gateway and calls to tools through MCP server portals. AI Security for Apps checks prompts from the internet, Gateway, CASB and DLP cover staff who use AI apps, and AI Crawl Control covers AI crawlers. Access checks who is acting, and DLP and logs apply to all of them.

Sandboxes and Code Mode keep agent-written code away from your credentials.

A3. Where does inference run?

Where the model runs decides where your data goes, what it costs and who operates it. AI Gateway and Access work with all three options.

The idea of a local inference mesh

Your company may own idle computers: developer Macs, GPU workstations, spare servers. A mesh can join them into one pool of private model capacity. Agents call one controlled entry point, and a router picks where each request runs. Sensitive work runs on the private nodes, so sensitive prompts never leave the company network. Idle hardware takes over part of the work that would otherwise go to hosted models. Hosted providers stay as the default or fallback, so a busy mesh does not stop work.

Three Cloudflare pieces make it governable:

• AI Gateway is the front door. It applies identity, budgets, guardrails, DLP and logs to every route, private or hosted.
• Cloudflare Mesh gives each enrolled server or laptop a private Mesh IP and lets nodes advertise routes. Zero Trust policy decides who can reach which node.
• AI Gateway custom providers connect models that have an HTTPS API endpoint, including self-hosted models, so the same logs, limits and guardrails apply.

I do not cover how the gateway reaches the private machines (Mesh, Tunnel or Workers VPC, which is in beta). Check the network path for your setup.

A4. Internal IT and engineering: the governed agent workspace

This is the shape from the start of this part, built out for case B. Engineers and operations staff work with AI agents that change code and infrastructure, under rules your company sets. It combines the controls from A2 around one session, with one gate in front and one on every exit.

Your engineers may already use agents. Without a sanctioned path they use personal keys and tools, and central IT has no log, budget or policy. A governed workspace sets identity, model access, tool access and network reach once, not per laptop and per tool. An agent that patches servers or changes a firewall needs a limited route and an approved plan. Changes go through your own git, CI and branch protection, and a person approves the merge or the change.

The harness is a Part B decision. Think suits a stateful chat or operations agent. AIChatAgent or your own loop suit cases where you must control the model call. Patch rollouts and reviews are long tasks that must survive restarts, so a Workflow fits the approved, repeatable part: rollout in batches, rescan, close the ticket.

Each gate protects only what passes through it. To control model egress, also block the direct provider endpoints. Start read-only for infrastructure agents and give write access per task, behind an approval step. Keep the human merge and the human approval of infrastructure plans.

A5. Where does agent-written code run? The execution ladder

When an agent writes and runs code, use the lightest environment that does the job.

A6. A ready-made start: Cloudflare OS

Cloudflare OS is an open-source agent workspace for everyone in a company, including people who do not code. You deploy it into your own Cloudflare account and adapt it. It is case B as a finished starting point, with four parts.

• Agent workspace. Each person works in the browser with an agent that knows your company context and shared skills. The agent writes and runs code in an isolated runtime.
• Gadgets. The agent can build small apps for one person or one team. Each app runs in its own Dynamic Worker with its own database and can be shared like a document.
• Gatekeepers. A Gatekeeper sits between the workspace and one external service. It limits access to the resource you chose, logs every action and asks a person to approve actions with side effects.
• Workflows. Repeatable jobs run on demand, on a schedule or when an event happens in a connected system.

It fits a workspace for all staff, including people who do not code, with shared skills and company context for every agent and small internal apps that people build and change themselves.

It is early access, and the README says it still has "many rough edges". Running it on your own servers with workerd is listed as "coming soon". A managed version in the Cloudflare dashboard, containers for development workflows and Slack support are planned. For customer-facing AI or shell-heavy engineering agents, see Part B and A4.

See also the GitHub repository and os.cloudflare.app.

A7. Another ready-made start: VibeSDK

VibeSDK is an open-source (MIT) platform where people build and deploy full-stack apps by describing them to an AI coding agent. The README calls it "an open-source vibe coding platform that helps you build your own vibe-coding platform". It is a starting point for case A (your customers build apps inside your product) or case B (internal teams such as marketing, product and support build their own tools, as the launch post describes it).

According to the README, a session works like this:

1. The user describes the app. The agent asks structured questions when the request leaves something open.
2. The agent plans, edits files, deploys a preview, reads the browser console, repairs errors and repeats, while the user follows along.
3. Each project has its own workspace and version history with restore points. The finished project can be exported to continue elsewhere.

It fits a platform where people who do not write code build small apps, a SaaS product that lets customers build their own customisations, or a base that you fork and change. It builds and hosts apps. To govern the coding agents your engineers already use, see A4. Cloudflare OS gives each person an agent workspace, while VibeSDK turns descriptions into deployed apps.

The reference architecture calls it a starter template, and I found no support or maturity statement for VibeSDK itself in the README. It builds on features that are still maturing: Think is experimental, Dynamic Workers entered open beta in March 2026, and Artifacts is in open beta (changelog, 1 October 2026). For production, the README lists a Workers Paid plan, Workers for Platforms access for production previews, a custom domain with wildcard DNS (and Advanced Certificate Manager where the layout needs it), and credentials for at least one model provider. The September 2025 launch post describes an earlier design with Sandboxes and Workers for Platforms. The README describes the current design.

See also the setup guide and the demo.