Inside Cloudflare OS: What to Decide Before Giving Every Employee an AI Agent¶

Decisions to make before a rollout

Organizational requirement	Current decision
Connect agents safely to company context and systems	Run a limited pilot
Govern sharing based on data the agent observed	Evaluate Gatekeepers
Deploy a mature managed product company-wide now	Wait for managed availability
Preserve easy portability away from Cloudflare	Prove portability first

Once employees begin using AI agents, an organization must control API credentials, shared company context, and data leakage through generated outputs as one system. Cloudflare OS is open-source software that combines agent workspaces, an access-control framework called Gatekeepers, and personal applications called Gadgets. The rollout decision turns on whether the organization can operate policy that follows observed data while accepting early-access roughness and substantial dependence on Cloudflare's platform.

How Cloudflare OS connects workspaces, Gatekeepers, and Gadgets

Cloudflare OS is an AI work environment for employees¶

Cloudflare open-sourced a new version of its internal AI productivity environment, Cloudflare OS, on August 5, 2026.¹ Despite its name, it is not an alternative to Windows or Linux. It is a browser-based execution environment that uses company-curated terminology, procedures, skills, and system connections to produce documents, analysis, applications, and deterministic workflows.

Internal use drove the integration of conversation, access, and apps¶

Cloudflare says it gave the first version to every employee in May and that thousands of people, including many outside engineering, used it daily.¹ Internal use exposed two problems: mostly deterministic jobs could still consume model tokens through repeated agent runs, and shared outputs could reveal information to people who lacked access to the underlying resources. The public release rebuilds the system on a new foundation, and its repository labels the current state as early access.²

The platform combines three elements.

Agent workspaces combine conversations, persistent state, outputs, resource permissions, and an isolated code runtime
Gatekeepers mediate authentication, resource-level access, read observations, and approval of side effects
Gadgets run small, modifiable full-stack applications with code and state dedicated to each user or team

Gatekeepers isolate credentials and track what an agent observed¶

A conventional MCP server can restrict which tools an agent calls and keep credentials on the server. Cloudflare's first version exposed a different problem: tool permission alone does not express which underlying resources an agent actually observed.¹ If an agent reads a sensitive warehouse table and creates a dashboard, sharing the dashboard can indirectly share the table with someone who could not access it directly.

Every agent and application in Cloudflare OS starts with no access. When a user grants access to a specific repository or dataset, generated code receives a typed capability rather than a credential.

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

env.PROJECT represents permission to use one resource under a particular policy. OAuth and credentials remain inside the Gatekeeper, isolated from the agent and generated code.¹

Each Gatekeeper is a service-specific Worker that understands the external API, its resources, and permitted operations. For GitHub, a policy could grant one repository, allow issue access without source-code access, and require human approval before a pull request is merged. When an operation requires approval, the Gatekeeper simulates the result locally so the agent can continue instead of blocking. After the task, the user can approve or reject the queued operations in bulk or one by one.² A pilot must also test how rejection reconciles later operations that relied on the simulated result.

Server code runs in a Dynamic Worker with globalOutbound: null, which disables outbound networking. Client code runs in a sandboxed iframe where CSP and iframe sandbox settings block outbound access to the maximum extent browsers allow.²

Cloudflare OS also records every resource an agent observes and keeps those observations attached to the workspace and its outputs. When another person opens an output, Gatekeepers verify that person's access to the original resources. The same observation history can inform whether the agent may write externally, add a collaborator, hand work to another agent, or make an outbound request.¹

This design narrows unauthorized paths, but it does not automatically prevent business-logic errors or prompt injection that misuses permissions already granted. An adopter still needs service-specific write approvals, action logs, and reversal procedures.

Gadgets give every file an isolated runtime and state¶

In the Gadget model, each file can be its own application. An application has client code for the browser interface and server code for state and behavior. The server loads on demand as a Dynamic Worker and is instantiated as a Durable Object Facet, giving every application an isolated SQLite database and lightweight V8 runtime.¹

Cloudflare reports that Dynamic Workers start about 100 times faster than typical containers.⁴ That figure describes Dynamic Workers generally; it is not an end-to-end performance benchmark for Cloudflare OS.

The client and server communicate through Cap'n Web, Cloudflare's open-source RPC system. A server method can be called through the same interface by the user's client or by an agent, so a tool built for direct human use also becomes an agent operation surface.¹

Users can share the live application and its state for collaboration, or share a Blueprint that copies only the code. An application created from a Blueprint does not inherit the original SQLite data, conversation history, credentials, or connected resources.¹ Kenton Varda described this personal-application model as a remake of Sandstorm.io, his earlier startup.⁵

Operating cost moves beyond software licensing¶

The core is available under Apache 2.0, and Cloudflare publishes a separate deployment repository based on its internal configuration.²³ The deployment repository pins an upstream release without patching the core and gives the organization a place to manage branding, authentication, integrations, routes, and upgrades.

No software license fee does not mean no operating cost. The currently documented production path uses the organization's own Cloudflare account, so the adopter pays for Workers, Durable Objects, AI Gateway, model inference, integrations, permission policy, and audits. Every inference request flows through AI Gateway, where administrators can attribute spend by person, team, or workspace and configure models, budgets, rate limits, and limit behavior.¹

The public sources do not establish retention periods, training use, or processing locations for data sent to a selected external model provider. An adopter should therefore verify each model provider's contract and data-processing terms separately from its AI Gateway configuration.

This is not a simple price comparison with a fixed-fee SaaS product. Total cost depends on how much company context and integration work remains internal, who maintains the growing set of Gadgets, and who owns Gatekeeper approval rules.

Cloudflare dependency and early-access limits remain¶

Portability must include the runtime¶

Readable source code and easy portability are different properties. Cloudflare OS is built around Dynamic Workers, Durable Object Facets, Workers Bindings, AI Gateway, and Cloudflare Access.

The core repository says the system can run on the open-source workerd runtime, but its production self-hosting instructions remain marked "COMING SOON."² An organization that requires cloud independence should prove that it can reproduce authentication, state, isolated execution, and Gatekeepers outside Cloudflare before treating the license as evidence of portability.

The pilot should stay within one workflow¶

The public version remains under heavy development. Cloudflare lists a managed dashboard product, containers for development workflows, and workspace integration with Slack and other chat tools as future work.¹ This is not yet a stage for immediate deployment to every employee.

The first pilot should choose one read-heavy workflow with limited data sensitivity. Evaluation should cover capability scope, denial of sharing based on observed resources, outbound network isolation, approval of side effects, cost attribution, and Gadget retirement, not answer quality alone. Only after those boundaries reproduce reliably should the organization add one connected service and one user group at a time.

Four conditions determine whether to expand the rollout¶

The IT team limits the pilot to one workflow and one connected resource, then tests grants and revocation from a zero-access state.
The security team verifies that outputs containing observed data cannot be shared or sent externally against policy.
The AI platform team estimates model spend, Workers costs, Gadget maintenance, and Gatekeeper development together.
The rollout owner pauses company-wide deployment if early-access change or Cloudflare dependency exceeds the organization's tolerance.

Sources¶

Cloudflare, Cloudflare OS: an open platform for agents, apps, and work, August 5, 2026. Used for internal adoption, the three-part architecture, Gatekeepers, Gadgets, AI Gateway, and stated future work. ↩↩↩↩↩↩↩↩↩↩
Cloudflare, cloudflare-os, accessed August 10, 2026. Used for early-access status, the Apache 2.0 license, supported runtimes, self-hosting documentation, deferred Gatekeeper approval, and runtime network boundaries. ↩↩↩↩↩
Cloudflare, cloudflare-os-starter, accessed August 10, 2026. Used for the pinned-core deployment model and organization-owned configuration. ↩
Cloudflare, Sandboxing AI agents, 100x faster, March 24, 2026. Used for V8 isolate startup and the container comparison. ↩
Kenton Varda, post describing Cloudflare OS as a remake of Sandstorm.io, August 5, 2026. Used only for design provenance, not as evidence for product capabilities. ↩