The agent platform Cloudflare ran internally from May 2026, open-sourced on 5 August under Apache-2.0. The idea worth the visit: authorization that follows the data. Every resource an agent observes is recorded, the record stays attached to the agent's work, and anyone else who opens that work is verified against what the agent saw — before they see anything.
Cloudflare OS is an open-source platform for building apps, automating work, and letting AI agents safely touch internal systems — built entirely on Cloudflare Workers. The name borrows operating-system metaphors (isolated runtimes, apps, permissions); it is not a Linux competitor. Cloudflare gave the first version to every employee in May 2026 and says thousands of people across every function — many outside engineering — use it daily. Three months of that internal run is what got open-sourced on 5 August 2026 (announcement by Phillip Jones and Dan Carter).
It ships as two repos, both Apache-2.0 (verified at source): cloudflare/cloudflare-os, the core, and cloudflare/cloudflare-os-starter, a deployment modelled on Cloudflare's internal setup that consumes the core without patching it. You deploy it into your own Cloudflare account, with your own Access policies, AI Gateway configuration, data, and integrations — there is no hosted version yet.
The consistent move throughout: nothing gets ambient authority. Agents, generated code, and apps each receive exactly the capabilities they were granted, and credentials never travel with them.
An agent begins with access to no resources. When it needs one, it requests it and a Gatekeeper — a service-specific Worker — mediates the access. The credential stays inside the Gatekeeper; it never reaches the agent or anything the agent wrote. Compare this with the common pattern of handing an agent an API key and hoping the system prompt holds.
Code the agent generates receives typed bindings — env.PROJECT represents permission to use one specific resource under one specific policy. Cloudflare's phrasing: the credential "remains completely isolated from the agent and any generated code." Capability, not credential, is what crosses the boundary.
Server code runs in a Dynamic Worker with global outbound networking disabled — generated code cannot phone home. Each app is instantiated as a Durable Object Facet with its own SQLite database, separate from the runtime. The browser client talks to it over Cap'n Web, Cloudflare's open-source object-capability RPC system — so even the client↔server channel carries capabilities rather than ambient session authority.
This is the part that is genuinely new — the reason this leaf exists rather than being a paragraph on the Workers leaf.
Cloudflare OS records every resource an agent observes, and the observations stay attached to the agent and its work. When a second person opens that work, Gatekeepers verify that person's access to the observed resources before showing anything. If an agent read a document you aren't cleared for, the summary built from it doesn't leak to you through the agent's output. Most agent-security stacks audit after the fact; this authorizes at read time, in both directions.
Observations also drive policy forward, taint-tracking style. From the announcement: "A read of sensitive data can prevent the agent from writing data to certain sources, inviting new collaborators, handing work to another agent, or making an outbound request." What the agent has seen changes what it is subsequently allowed to do.
The contrast with MCP is Cloudflare's own framing, not editorial: MCP governs which tools an agent may call, but "MCP alone does not tell us which underlying resources an agent has observed." Tool-level permission is where MCP stops; resource-level observation is the layer above it — and this is the first open-source implementation of that layer in wide release.
The fully managed version, containers for development workflows, and Slack/chat workspaces are all still ahead (as of August 2026). What exists today is the self-deploy path. If you want a hosted agent workspace with an SLA, this isn't it yet.
It deploys into your own Cloudflare account and assumes Access, AI Gateway, and Workers as the substrate. Rollout support runs through named partners (Presidio, Happy Cog). Evaluate it the way you'd evaluate adopting a platform, because that's what it is.
Three months of daily use by thousands of Cloudflare staff is real hardening — inside one very Workers-native company. As open source it is days old: expect API churn, thin docs, and sharp edges where your org differs from theirs.
It borrows OS concepts — isolated runtime, apps, permission model — but it's an agent/app platform on Workers. Budget the explanation time when someone in procurement asks why you're replacing Windows.
The observation log is a data-flow audit trail by construction. The hard POPIA question with agents isn't "was the model hosted in-country" — it's "what personal information did the agent process, and who saw the output built from it." In most stacks that answer is reconstructed from logs after the fact, if at all. Here the record exists as a side effect of the authorization model: every resource read is captured, attached to the work, and enforced against every subsequent viewer. When an information officer — or the Information Regulator — asks, the answer is a query, not an archaeology project.
We run this substrate already. Vinci, the agent on this site's front page, is Workers AI, Vectorize, and Pages Functions — the same primitives Cloudflare OS is built from. So the claim that Cloudflare's edge carries real agent workloads isn't something we're relaying from a vendor blog; it's how this page you're reading gets its own agent. The cost shape matters here too: Apache-2.0 self-deploy on usage-priced Workers is a very different rand exposure from per-seat agent SaaS billed in dollars.