Cloudflare OS open-sources a self-hostable agent platform with a real security model
Cloudflare published Cloudflare OS, its internal AI agent platform, on 5 August 2026 under Apache-2.0, self-hostable on workerd with local LLMs via Ollama. The security model — zero-initial-access agents and per-resource Gatekeepers — is the real novelty, but the runtime requires a paid Workers plan.
5 August 2026. Cloudflare open-sourced the agent platform it first built for itself. May 2026. That is when every employee in the company received the first version of the tool. Thousands. That is how many people were using it daily by August, and not only engineers. The result is published under Apache-2.0 as Cloudflare OS, a platform any organisation can self-host.
What makes the release worth a second look is not the chat interface — everyone has one of those. It is the security architecture wrapped around it, and the fact that its designer, Kenton Varda, already attempted this bet a decade ago with Sandstorm.io. He calls Cloudflare OS “Sandstorm, with AI.”
The three building blocks
Cloudflare OS assembles three pieces rather than bolting together three products.
An agent workspace. A browser interface, no code required, preloaded with a shared library of company context and skills. When one colleague documents a better way of doing something, that procedure becomes an instruction every agent in the organisation can follow. Agents can write code to search and filter internal data instead of loading whole datasets into context, produce documents and slides tied to live data, or run largely deterministic workflows.
Gatekeepers. The governance layer that mediates each agent’s access to internal and external systems. This is the part to understand in detail, because it is what separates the platform from ordinary agent frameworks.
Gadgets. The app platform: every application an agent or a human builds runs as an isolated instance with its own SQLite database, rather than in a shared multi-tenant server.
The security model: zero access by default
The core of the project fits in one sentence: every agent and every app starts with access to nothing. Cloudflare Access controls who can enter Cloudflare OS at all. Once inside, to use a resource — a GitHub repository, a data-warehouse table, a Slack channel — the agent has to request access, and a human grants or denies it.
Once granted, access becomes a typed binding injected into generated code, in the form:
const issues = await env.PROJECT.listIssues({
teamId: "ENG",
state: "open",
});env.PROJECT is a capability: permission to use a specific resource under a specific policy. The underlying credential never touches the agent or the code it writes. Server code runs in a Dynamic Worker with all outbound networking disabled by default; client code runs in a sandboxed browser frame. Neither reaches the open internet except through capabilities explicitly handed to them.
The Gatekeeper is a dedicated Worker sitting between Cloudflare OS and one specific service. It understands that service’s API finely enough to scope access far more narrowly than a global token: read-only on one repository, field masking, rate limits, human approval before any write. It holds the OAuth credential, logs every read and mediates every action with a real-world side effect.
Taint tracking closes the loop. The platform logs every resource an agent has observed, and that history stays attached to the agent and to everything it produces. If a second person opens the workspace or views an output, Gatekeepers re-check that person’s own rights against every resource touched along the way. A shared dashboard does not become a backdoor path to a table the recipient cannot query directly.
Self-hosting: what is true and what it costs
On paper, Cloudflare OS is genuinely self-hostable. The repository is Apache-2.0, built on workerd, Cloudflare’s open-source Workers runtime, and it supports local LLMs via Ollama. Varda himself notes that running locally is, in his words, “honestly… faster.”
The catch lives in the runtime. Gadgets and server code execute in Dynamic Workers, a recent Workers runtime primitive. Community reports indicate that Dynamic Workers require the Workers Paid plan — the free tier reportedly cannot run them. In practice, self-hosting does not mean zero cost: it means carrying a Workers plan and accepting a lock-in to Cloudflare primitives (workerd, Durable Objects) rather than your usual containers.
The deliberate comparison with Sandstorm sharpens the point. In 2015, Sandstorm pushed the same per-instance granularity — one isolated “Grain” per document. The project failed, by Varda’s own account, because too few people had the time or patience to modify their own software. His bet today is that AI agents remove that bottleneck: anyone can ask their agent to add the missing feature to their own copy of an app.
Verdict
If you want to host agents with real least privilege, Cloudflare OS deserves a pilot. The “zero access by default + per-resource Gatekeeper + taint tracking” model answers a real problem — agent-driven exfiltration and prompt injection — that ordinary agent frameworks barely address. It is the platform’s strong suit, and it has no simple equivalent elsewhere.
If you want zero cost or Cloudflare independence, temper that: self-hosting assumes a Workers Paid plan and a commitment to workerd and Durable Objects. Confirm the pricing point before building a prototype, and weigh whether your agent workload justifies depending on a runtime vendor.
The simple rule stands: pilot for the security model, not the interface. If per-resource least privilege is your problem, Cloudflare OS is one of the few serious open-source answers. If it is not your problem, you do not need the complexity yet.