Why Cloudflare OS Is Open Source: Borrow the Design, or Run the Software?

Hello, this is Ryuta Hamamoto from TIMEWELL.

On 5 August 2026, Cloudflare released Cloudflare OS. They took the AI agent platform they had been running internally and open-sourced it as it stood¹.

I will admit I braced myself reading it. We work in adjacent territory with ZEROCK, so I was reading as an interested party. With that said, my conclusion: the design ideas are worth borrowing. But the claim that open source means you are not tied to a vendor deserves a closer look than it usually gets.

In order, then.

What was released

Facts first.

Cloudflare OS is officially described as "an open-source platform that lets everyone in your company build apps, automate work, and safely access internal systems"². The "OS" in the name is not an OS in the Linux or Windows sense. It means the ground an AI agent runs on.

What matters is that this is something actually in use. Cloudflare gave every employee access to a first version in May 2026, and thousands of people across every function, many outside engineering, use it every day — for documents and slides, automating repeatable tasks, and building small apps over company data².

Running it internally before releasing it is the right order, in my view. Not built and shipped, but used and then shipped.

It is currently available as a GitHub repository, with a managed deployment through the Cloudflare dashboard planned. Presidio and Happy Cog are named among implementation partners¹.

Why open source it

Their own words. Co-founder and CEO Matthew Prince:

We built this because nothing else did what we needed. Now any company can start from where it took us years to get.¹

The press release goes a little further.

organizations own what they build on it. A company's processes, context, and internal system connections don't get locked into a vendor's closed product.¹

And on models:

Through Cloudflare AI Gateway, organizations can use any AI model provider, and they're not locked into one vendor.¹

The blog says "Cloudflare OS can be used with any model," with every request passing through AI Gateway. There is also a line that "not every task needs the most expensive model," framing model choice by task as a benefit².

Their argument is clear. AI infrastructure ought to differ by organisation, and putting it inside a closed product bends your business to the vendor's shape. So open it.

They also state the design intent:

Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.²

Organisation-specific capability without rewriting the core. There is also the line "Yours should reflect your organization"².

If you want to place your own organisation on the AI adoption curve first, the AI readiness check will help.

The design is where the value is

Here is the substance. What is most valuable as an idea is not the reason for opening it, but the design. Three things.

One. Agents start with zero access.

In Cloudflare OS, every agent and application begins with no access rights³. Reading anything requires an explicitly permitted route.

This is the same structure as the tenant isolation problem I wrote about earlier. Closed by default, or open by default. Add a new agent, and if nobody configures anything it can do nothing. That single design difference decides where you end up after years of operation. The same failure shape is in why tenant isolation breaks later.

Two. Gatekeepers hold the credentials; agents never touch them.

A Gatekeeper is a service-specific layer placed in front of an external API. Its jobs³:

• Complete OAuth on its own side and hold the credentials
• Apply policy
• Record every read

For GitHub, that means implementing things like scoping to a single repository or requiring pull request approval at that layer³.

I think this design is genuinely good. Hand an agent an authentication token and you cannot stop whatever it does with it. Do not give it the token; judge each action at a layer in front. Considering attacks like GlassWorm, where credentials are stolen from a developer's machine, the value of there being no token at the agent to steal is easy to see. The related case is in code you cannot see.

Three. Record everything read, and use it to constrain writes.

This is the most distinctive part. The blog's own phrasing:

Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work.²

Every resource an agent observes is recorded, and that record stays attached to the agent and to what it produced.

The record then does work later. When someone else opens that output, the platform first checks their access to the underlying data³. Beyond that, it is used to block an agent that has read sensitive data from writing to certain destinations, or from inviting collaborators³.

The idea is stopping privilege from leaking through the artefact.

This is a hole that opens constantly in practice. Someone with access has an AI read a confidential document, produces a summary, and shares it with someone who lacks access. The source is protected and the contents leave through the summary. Access control placed only at the entrance cannot catch that. Recording what was read and constraining the exit is a well-shaped answer.

But open source is not the same as vendor-independent

This part deserves a cool head.

The published components²:

Component	Role
Agent Workspace	A workspace carrying context and skills
Gatekeepers	Service-specific Workers controlling resource access
Dynamic Workers	Execution environment for app server code
Durable Object Facets	Persistent state for apps

The two in bold are Cloudflare-specific infrastructure. Workers and Durable Objects run only on their platform. And model routing goes through Cloudflare AI Gateway.

So you can read the source and change it, but where it runs is effectively Cloudflare.

This is not a criticism. It is a coherent strategy. Open the core to lower the barrier to adoption; earn on the execution layer. Put "start from where it took us years to get" next to "managed deployment coming soon" and the intent reads plainly. I would call it an honest approach.

But the receiving side needs to separate the claims.

"Not locked into a vendor's closed product" is true about model providers. Any model works through AI Gateway. You are not bound to OpenAI, Anthropic or Grok.

The execution layer is another matter. Remove the model dependency and you take on a platform dependency. The dependency has not disappeared; it has moved layers.

The same shape appears elsewhere. Dependence spanning positioning, energy and communications is set out in Michibiki No. 7 and Japan's dependency structure. The common point is that dependence is not the problem; not knowing where you depend is.

For companies in Japan there is one more issue: where the data sits. Where a contract says data must remain in the country, which region the execution layer runs in matters before any feature does. Being open source does not answer that question.

Borrow the ideas, or run the software?

To the heart of it. Both can be right, but the criteria are clear.

Borrow the ideas today. No conditions attached.

Concretely, put these three into your own AI design.

1. Agents start with zero access. Add permissions explicitly
2. Do not give agents credentials. Put a judging layer in front and permit per action
3. Record what was read, and use it to constrain the exit. Do not stop at entrance-level access control

The third is missing in most organisations. Without a record of what you let AI read, you have no way to stop leakage through the artefact. Starting with logging alone is enough of a start.

The software itself is conditional. My own framing:

Worth using when you already run on Cloudflare as a primary platform, or you want to start from internal experiments and small automations. In that case you receive years of design work for nothing — faster than building it, and already proven in operation.

Look carefully when contractual constraints exist on data location, or your existing cloud platform is elsewhere and you have consolidated onto it. Adopting the core means moving your execution layer with it. Even partial adoption requires establishing first how much of it does not depend on Workers and Durable Objects.

And in either case it is worth reading. A production platform published under an open licence is good design documentation in its own right¹. Even if you decide against adoption, reading the granularity of Gatekeepers and the shape of the observation log will improve your own design.

We run ZEROCK on AWS servers in Japan with control over who can reach which knowledge because the problem is the same. What you let an agent read, and who you hand the result to. We want the mechanism that answers that inside the product.

Was it the ideas or the product that got released?

To recap.

On 5 August 2026 Cloudflare released Cloudflare OS, having run it internally since May 2026 with thousands of daily users. The design centres on agents that start with zero access, Gatekeepers that hold credentials and record reads, and an observation log of everything an agent sees, used to constrain writes and sharing.

The stated reasons for opening it are that a company's processes and internal system connections do not get locked into a vendor's closed product, and that any model provider works through AI Gateway.

But the execution layer depends on Cloudflare Workers and Durable Objects. The model dependency comes off; the platform dependency goes on. Rather than "open source, therefore free," the accurate reading is a trade: which layer's freedom you gain, and which layer's dependency you accept.

My answer: borrow all of the thinking, take the software conditionally.

One last thing. The heaviest part of this release is not the code but the fact that they used it before publishing it. Thousands of people daily, a stumble over permission tracking when workspaces were shared, and the observation log as the answer that came out of it³. Design only comes out of operational failure. The value of reading it is proportional to that failure.

If you want to talk through how to hand your internal knowledge to AI, ZEROCK may be a useful reference point, and you can reach us here.

---

Footnotes

1. Cloudflare press release, "Cloudflare OS Is the First AI Workspace Built Around How Companies Actually Work" (5 August 2026). The comments from co-founder and CEO Matthew Prince — "We built this because nothing else did what we needed. Now any company can start from where it took us years to get.", "organizations own what they build on it. A company's processes, context, and internal system connections don't get locked into a vendor's closed product.", and "Through Cloudflare AI Gateway, organizations can use any AI model provider, and they're not locked into one vendor." — together with the current availability as an open source repository, the planned managed deployment through the Cloudflare dashboard, and the naming of Presidio and Happy Cog as implementation partners, are all from that release. The public repository is https://github.com/cloudflare/cloudflare-os . https://www.cloudflare.com/press/press-releases/2026/cloudflare-os-is-the-first-ai-workspace-built-around-how-companies-actually-work/ — reporting describes it as Apache 2.0 licensed. https://siliconangle.com/2026/08/05/cloudflare-launches-cloudflare-os-open-source-ai-agentic-workspace-enterprise/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Cloudflare blog, "Cloudflare OS: an open platform for agents, apps, and work" (5 August 2026). The definition "an open-source platform that lets everyone in your company build apps, automate work, and safely access internal systems"; provision of a first version to every employee in May 2026 with thousands using it daily for documents and slides, automating repeatable tasks and building small apps; the components Agent Workspace, Gatekeepers, Dynamic Workers and Durable Object Facets; "Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work."; "Cloudflare OS can be used with any model." and all requests passing through AI Gateway; "Not every task needs the most expensive model"; "Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product."; and "Yours should reflect your organization." — are all from that post. https://blog.cloudflare.com/cloudflare-os/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. Reporting on Cloudflare OS's governance mechanisms. That every agent and application in Cloudflare OS starts with no access; that a Gatekeeper is a service-specific Worker placed in front of an external API which completes OAuth, holds the credentials, applies policy and records reads; that for GitHub this can implement scoping to a single repository or requiring pull request approval; that the record of resources an agent reads is attached to both the agent and its output, and that when another person opens that output the platform first verifies their access to the underlying data; that the observation log functions to block an agent that has read sensitive data from writing to particular destinations or inviting collaborators; and the internal experience of difficulty tracking permissions when workspaces were shared — are all from that article. https://www.helpnetsecurity.com/2026/08/06/cloudflare-os-open-source/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶