Cloudflare OS Deep Dive: Security Architecture and Implementation Path of an Open-Source Enterprise Agent Platform

Starting from the Problem: Why Code Agents Succeeded While Others Didn't

Every organization has its own mission. It passes terminology, processes, standards, and ways of working to employees, who carry this context along with their own experience to drive work forward. Over the past two years, agents have achieved tremendous success in the coding domain, for a simple reason: code has a clear feedback loop—it either runs or it doesn't—and agents can use this signal to self-improve.

The fundamental reason code agents can iterate rapidly is that software engineering inherently possesses formal verification capabilities. Compiler errors, unit test pass rates, CI/CD pipeline statuses—these are all clear binary signals. In contrast, whether a marketing strategy document is "good" or "bad" depends on the reader's identity, business context, and even timing, making it impossible to provide deterministic evaluation through automated means. This difference is particularly critical in reinforcement learning frameworks: code agents can use test results as reward signals for RLHF training, while reward functions for knowledge work tasks are extremely difficult to design.

But other organizational functions aren't so fortunate. Documents, presentations, cross-departmental process collaboration—these types of work are highly dependent on company-specific context and require access to the business systems employees use daily. So Cloudflare's assessment is: the real challenge isn't making agents that can write code, but making them understand how a company operates and giving them controlled access to do any kind of work.

This is precisely the problem Cloudflare OS aims to solve: turning "context" and "access" into actual output that moves the organization forward. After running it internally for several months, Cloudflare decided to fully open-source the new version, allowing any organization to deploy it in their own account.

Three Core Problems Exposed During Internal Testing

Before open-sourcing, Cloudflare opened the first version to thousands of employees company-wide (many in non-engineering roles). It was used daily to create documents, automate repetitive tasks, and build small applications. But internal operations also exposed three key problems:

• The first version was centered around private personal workspaces, with collaboration added as an afterthought;
• Applications were static, not living software connected to internal systems;
• Some tasks were inherently deterministic, yet still required running through an agent conversation, wasting model tokens.

But the most fundamental challenge came from a blind spot in the MCP protocol: MCP servers can tell platform agents "which tools can be called," but cannot tell platform agents "which underlying resources were actually observed." MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024, designed to standardize how AI models interact with external tools and data sources. MCP uses a client-server architecture: MCP servers encapsulate the capabilities of specific services and expose them as tool sets, while MCP clients invoke these tools through standardized interfaces. However, the current MCP specification only defines input/output interfaces for tools and does not require servers to declare which underlying data resources they access. This means an MCP server might read sensitive tables from a database while executing a tool call, but the upper-level platform is completely unaware of this and cannot enforce data classification-based access control policies.

Once workspaces, applications, and outputs start being shared, this blind spot can become a data leakage channel. So Cloudflare made a decisive decision: rebuild the platform from scratch—security must be built into the platform, rather than relying on each user to be careful.

The Platform Trifecta: The Complete Pipeline from Conversation to Output

The new Cloudflare OS consists of three parts:

1. Agent Workspaces: Housing the context and skills accumulated by the company, with an isolated runtime where agents can write and execute code;
2. Security & Governance Framework: Addressing how agents securely access internal data and services—the centerpiece of this rebuild;
3. Application Platform: Employees can build personalized, modifiable small applications, share them with each other, and continuously evolve them.

In terms of user experience, everything starts with a conversation in the browser. But unlike ordinary chat tools, this conversation is rooted in the organization's own accumulated knowledge base, with a clear goal directed toward work output—the conversation is just the starting point; it can become a document, an application, or an automatically running workflow. This "conversation to output" evolution path is the key thread for understanding the entire product design.

The Compound Effect of Pre-built Skill Libraries

The workspace design goal is clear: everyone in the organization can use it, no coding required, no terminal knowledge needed. What truly creates compound returns for the workspace is the pre-built skill library—teams distill terminology, processes, and best practices into instructions that agents can directly follow. Once someone figures out a better approach, the entire company can reuse it without having to re-explain the same process to the model.

This means knowledge is no longer locked in individual minds but becomes a public asset on the platform—one of the most fundamental differences between Cloudflare OS and typical AI chat tools. From a knowledge management perspective, this is similar to the process of converting Tacit Knowledge into Explicit Knowledge, but unlike traditional knowledge management systems, this accumulated knowledge exists in the form of executable instructions—they're not documents waiting for humans to read and understand, but operational procedures that agents can execute step by step.

Typical workspace use cases can be categorized into four types:

• Research & Inquiry: Agents write code to search and filter data rather than stuffing entire datasets into the context window, saving tokens while protecting data;
• File Output: Documents, presentations, and spreadsheets that stay connected to real-time data;
• Building Collaborative Applications: Internal tools used collectively by teams;
• Deterministic Workflows: Using code to handle predictable parts, only calling the model where judgment is needed.

Security Model: From Zero Permissions to Permissions Following Observation

This is the core of the rebuild. When employees work with AI, their first request is often for API keys to company systems, but keys typically have broad permissions, long validity periods, are hard to constrain, and difficult to audit. MCP's approach of having servers hold credentials and only exposing defined tool sets is directionally correct, but controlling tool calls is only the first step.

Cloudflare OS's approach is to start everything from zero permissions. Agents and applications begin with nothing—when they need to access a resource, they must explicitly request it, and an administrator grants or denies the request. This Zero Standing Privileges approach borrows from the core principles of Google BeyondCorp and zero-trust network architecture, but advances them from the network layer to the agent workload layer. Traditional enterprise applications are typically assigned a fixed set of Standing Privileges at deployment time, even if most of these permissions go unused most of the time. The zero-permission model requires Just-In-Time Access decisions for every access attempt, with granted permissions having configurable automatic expiration times.

Your credentials are completely isolated from the agent and generated code: server-side code runs in Dynamic Workers with global outbound networking disabled, client-side code runs in browser sandboxes—neither side can reach the internet unless you explicitly grant the capability. In Cloudflare OS, this is achieved by disabling global outbound networking for Dynamic Workers—the runtime cannot initiate any external requests by default and must obtain specific resource access capabilities through the Gatekeeper, architecturally eliminating the risk of over-provisioned permissions. Least privilege goes from being a slogan to being the platform's default behavior.

Gatekeeper: Consolidating Governance Logic into a Single Trusted Component

The granularity after authorization is controlled by the Gatekeeper—a dedicated Worker that sits between Cloudflare OS and external services, understanding a service's API resource model and executable operations.

Giving an entire GitHub account to an agent is too broad. Gatekeeper can be precise down to "only this repository, allow reading issues but not source code, can impose rate limits, must have human approval before merging PRs." From the agent's and application's perspective, all they see is a small TypeScript API; the underlying OAuth flows, credential custody, policy enforcement, and auditing are all handled by the Gatekeeper. Governance logic is consolidated into a single trusted component rather than scattered across each application's code.

This design pattern is known as a "Policy Enforcement Point" in security architecture. Its core value lies in the fact that regardless of how upper-layer applications change or how unpredictable agent behavior becomes, all external access must pass through this single chokepoint, making auditing, rate limiting, and policy changes implementable in just one location.

Permissions Following Observation Logs: Plugging Secondary Leakage

The most insightful design is: permissions must follow what the agent has seen. Imagine an agent reads a sensitive table from a data warehouse and uses it to generate a real-time dashboard—if the dashboard can be freely shared, sharing the dashboard becomes a backdoor for sharing the underlying data.

Cloudflare OS records every resource the agent has observed, and observation records are attached to the agent and its outputs. When someone else opens a workspace or views an output, the Gatekeeper verifies whether that person has access permissions to the observed resources. The same observation log is also used for reverse constraints: a single sensitive data read can automatically prohibit the agent from writing to certain data sources, inviting new collaborators, handing off to other agents, or making outbound requests. Users don't need to worry about this at all—the platform handles it for them.

This mechanism is essentially an implementation of an Information Flow Control strategy. In academic security, this is called "Taint Tracking"—once data is marked as sensitive, that marking propagates to all derivative products of the data. Cloudflare OS takes this theoretical research from programming language-level studies and implements it as engineering practice for an agent platform.

Application Platform: Every File Can Be an Application

Traditional productivity suites give you a fixed set of applications—use them and you're done. Cloudflare OS's vision goes further: every file can be a complete full-stack application, written by an agent tailored for a person, a project, or a team, with client-side code, server-side code, APIs, and persistent state—private by default and shareable like a document.

This lowers the software barrier to the level of writing a document—business users describe their needs, agents deliver usable tools, and those tools continue to be modified as needs evolve.

Each application's runtime foundation is Cloudflare's own infrastructure. The server side loads on demand as a Dynamic Worker, then instantiates as a Durable Object Facet, giving the application an independent SQLite database isolated from the runtime. Cloudflare Workers is a serverless computing platform built on V8 JavaScript engine Isolate technology. Unlike traditional containerized approaches, V8 Isolates don't need to spin up separate OS processes or virtual machines for each tenant—instead, they create lightweight execution environments within the same process through V8's memory isolation mechanisms. A single Isolate can cold-start in as little as 5 milliseconds with memory overhead of just a few MB, offering orders-of-magnitude advantages over containers' hundreds-of-MB startup overhead. Dynamic Workers are a further evolution, supporting on-demand dynamic code loading rather than pre-deployment—particularly suited for Cloudflare OS's need to instantiate independent runtime environments for each application.

Durable Objects are stateful serverless computing primitives provided by Cloudflare. Traditional serverless functions are stateless—each request may be handled by different instances, requiring external databases to maintain state. Durable Objects guarantee a globally unique instance, with all requests routed to the same instance, naturally solving concurrency consistency issues. Each Durable Object comes with a transactional SQLite database, with data automatically persisted and replicated across nodes. The "Facet" concept in Cloudflare OS is a further encapsulation of Durable Objects, providing each application with an independent state container ensuring complete data isolation between applications.

Since Dynamic Workers use lightweight V8 Isolates, each application can have an isolated runtime without requiring persistent servers or containers—a massive difference in cost structure.

Client and server communicate through Cloudflare's open-source, object-capability-model-based RPC system Cap'n Web, and agents can call the same methods, meaning human-written tools and agent-written tools are fully interoperable in terms of capabilities. The Object-Capability Model is a security architecture paradigm whose core idea is: access to resources is not controlled through identity verification + access control lists (ACL), but through holding specific object references (capabilities). Only by holding a reference to an object can you call its methods—the reference itself is the permission credential. This model naturally supports the principle of least privilege because capabilities can be precisely passed and restricted. Cap'n Web draws from the design philosophy of the Cap'n Proto serialization protocol, applying the object-capability model to web communication scenarios so that method calls between clients, servers, and agents follow unified permission propagation rules.

Sharing & Blueprints: The Fork Model for the AI Era

Sharing has two modes:

• Sharing the application itself: Multiple people collaborate in real-time with shared state;
• Sharing a blueprint: Others create a copy based on your code, but blueprints deliberately exclude data, conversation history, credentials, and connected resources—each new application starts with independent state.

The result is fascinating: teams that receive a blueprint can use AI to modify the application themselves, rather than submitting feature requests and waiting for the original author to implement them. Application distribution shifts from "publish and wait" to "copy and customize"—exactly like open-source software forking, except the entity doing the customization is now AI.

This pattern aligns with decades of research vision in "End-User Programming": enabling non-professional developers to customize their own software tools. From HyperCard to spreadsheet macros, the industry has long sought ways to lower programming barriers. Cloudflare OS's blueprint + AI customization model may be the closest this vision has come to large-scale implementation—users don't need to understand code, they just describe desired changes in natural language, and the agent handles implementation.

Model-Agnostic and Cost Attribution Strategy

For model integration, Cloudflare OS adopts a model-agnostic strategy—every inference call passes through Cloudflare AI Gateway, where organizations can decide in one place which models are available and which model handles each task.

Cloudflare AI Gateway is a proxy layer between applications and AI model providers, similar to how an API gateway works for backend services. It provides request caching (identical prompts hitting cache can save over 90% in costs), rate limiting, request retry and fallback (automatically switching to backup models when the primary is unavailable), real-time logging and analytics. In the Cloudflare OS architecture, AI Gateway serves as the model abstraction layer: upper-layer applications don't need to care whether the underlying call goes to OpenAI, Anthropic, or open-source models—Gateway handles routing decisions, cost accounting, and SLA guarantees. This intermediary layer design also enables zero-cost model migration in the future.

The value lies in granular cost control: summarizing unread emails in the morning is fine with a cheap model; expensive Frontier models are reserved only for the hardest tasks.

Simultaneously, every request is attributed to a specific person, team, or workspace. Administrators can see where inference spending goes, set budgets, set rate limits, and decide what happens when limits are reached. Model selection and cost control are consolidated from individual hands to the organizational level—a very practical requirement for enterprise-scale AI adoption.

This cost governance approach is consistent with FinOps practices in the cloud computing domain. FinOps emphasizes visibility, optimization, and operationalization of cloud spending—enterprises need to know where every dollar goes, whether it's justified, and whether it can be optimized. AI inference costs are becoming the next growth frontier in enterprise IT spending after cloud infrastructure, and organizations lacking granular controls may face budget blowouts. Cloudflare OS builds cost attribution into the platform layer, making AI spending as trackable and optimizable as cloud resources.

Open-Source Architecture and Enterprise Implementation Path

Cloudflare OS is fully open-source, released as two repositories:

• Cloudflare OS (core repository): The platform itself;
• Cloudflare OS Starter: A sample deployment based on how Cloudflare operates internally—it "consumes the core without modifying it," housing configuration, custom UI, internal integrations, and deployment pipelines.

This core-deployment separation architecture lets organizations deeply customize without taking on the burden of maintaining a fork. This design follows the "Upstream First" open-source best practice: customization needs are met through configuration and extension points rather than directly modifying core code. When the core repository releases security patches or new features, downstream deployments can upgrade directly without handling merge conflicts. This is critical for long-term enterprise maintenance—many organizations abandon upstream synchronization due to the prohibitive cost of maintaining private forks, creating technology islands.

Cloudflare has also made clear that source code is just the starting point—what truly makes the platform valuable is the context, skills, workflows, internal system connections, and policy configurations. To that end, they've partnered with Presidio and HappyCode as strategic partners to help with customization and company-wide rollout, ultimately delivering a branded version connected to your own systems and running on Cloudflare.

Three things on the roadmap worth watching:

1. Bringing Cloudflare OS into the console as a fully managed offering, ready to use out of the box;
2. Adding container support for development workflows;
3. Bringing workspaces into chat tools like Slack, putting agents where employees already are.

Clearly, Cloudflare doesn't intend to leave this as a self-deployed open-source project—they're building a complete enterprise agent ecosystem.

Summary: An Enterprise Agent Platform with Security Built In

In one sentence: Cloudflare OS builds security into the platform, giving every employee an agent that understands the organization, connects to systems, and can work autonomously—delivered as open source to any organization.

Its core value can be distilled into four points:

• The platform trifecta covers the complete pipeline from conversation to output;
• The security kernel uses default zero permissions, Gatekeeper fine-grained governance, and permissions following observation logs to architecturally prevent secondary leakage;
• A fully open-source, core-deployment separated architectural design;
• Model-agnostic plus cost attribution for unified inference cost management.

For teams currently planning enterprise AI strategy, Cloudflare OS's architectural design and security approach deserve serious study and reference. It represents an emerging product paradigm: not layering AI assistants on top of existing SaaS applications, but reconstructing the entire enterprise work platform around AI agents—security, governance, collaboration, and application development are all redesigned around agent characteristics. This "AI-native" platform architecture may become the mainstream form of enterprise software in the future.