# Cloudflare OS: Secure Agent Workspace Guide

> Understand Cloudflare OS workspaces, Gadgets, Gatekeepers, deployment choices, and the security checks needed before an early-access rollout.

- **Published**: 2026-08-07
- **Category**: AI Infrastructure
- **URL**: https://agentpedia.codes/blog/cloudflare-os-agent-workspace-security-guide

---

**Cloudflare OS** is an open-source agent productivity environment built for company context, generated applications, and governed access to internal systems. It is not a desktop operating system, and it is more than a chat interface with MCP connectors.

The project combines browser workspaces, isolated code execution, user-generated full-stack apps called **Gadgets**, reusable **Blueprints**, and resource-specific security services called **Gatekeepers**. Cloudflare open-sourced version 2 after using an earlier version internally across engineering, sales, and other functions.

> **Warning callout**

The Cloudflare OS repository labels the August 2026 v2 release early access, says it has rough edges, and advises teams to pin releases and review the trust boundary before production upgrades. Treat the deploy button as an evaluation shortcut, not a production-readiness certificate.

**What to evaluate:**

- Whether Gatekeepers can express your real resource policies.
- Whether observation tracking survives sharing and derived outputs.
- Whether your team can operate Workers, Access, storage, OAuth, and AI Gateway.
- Whether deterministic workflows reduce model use without bypassing approvals.
- Whether early-access churn fits your change-management process.

## What Cloudflare OS is

A workspace starts as a browser conversation grounded in context and skills curated by an organization. The agent can research, generate documents and presentations, write and run code, build an app, or turn repeatable work into a scheduled or event-triggered workflow.

Cloudflare describes three main layers:

1. an agent workspace with persistent state, files, outputs, context, skills, and an isolated runtime;
2. a governance framework for access to internal data and services;
3. a platform for personal, modifiable applications that can be shared or copied.

Cloudflare's internal account is vendor-reported evidence, not an independent case study. The company says thousands of employees use the system and reported more than 4,000 apps or tools created and more than 10,000 sales-team hours saved in one 30-day period. Those numbers are useful adoption signals, but the methodology and counterfactual are not independently documented.

![Cloudflare OS workspace showing an agent conversation beside an AI-generated planning slide deck](/content-assets/cloudflare-os-agent-workspace-security-guide/official-cloudflare-os-workspace.webp)

*Cloudflare OS workspace with a Q3 planning task and generated slide deck. Official project image. [Source](https://github.com/cloudflare/cloudflare-os/blob/main/docs/images/q3-planning-workspace.png).*

## Architecture

Cloudflare OS uses Cloudflare Workers primitives, but the project says the core can run on the open-source `workerd` runtime. The current documented production path is a Cloudflare account; polished production self-hosting outside Cloudflare remains future work.

| Concept | Implementation role |
| --- | --- |
| Workspace | Durable Object holding agent sessions, files, state, and resource observations |
| Gadget | User-specific full-stack app generated or modified with an agent |
| Gadget server | Dynamic Worker Facet with its own SQLite-backed state |
| Gadget client | Sandboxed browser frame |
| Blueprint | Copyable application code without the original data, credentials, or conversation |
| Gatekeeper | Service-specific Worker that mediates a narrow external capability |
| AI Gateway | Central routing, attribution, model policy, limits, and observability for inference |
| MCP Server Portal | Adapter path for existing MCP servers |

Gadget clients and servers communicate through **Cap'n Web**, Cloudflare's object-capability RPC project. The same server methods can be called by the UI or by an agent. This makes generated applications agent-addressable without adding a separate MCP server for each app.

Each Gadget gets independent runtime state. Sharing a live Gadget shares that instance. Sharing a Blueprint copies code into a new instance without copying its SQLite data, credentials, connected resources, or original conversation.

That separation is an important claim to test. A production evaluation should verify the behavior for every storage and resource type your organization enables, including exported files and third-party destinations.

## Security model

Cloudflare OS starts agents and apps with no ambient resource access. A user introduces a specific resource, or an agent requests one. Generated code receives a typed binding rather than the underlying credential.

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

Expected output: `issues` contains only records allowed by the policy behind the `PROJECT` capability; generated code never receives the service credential.

A **Gatekeeper** sits between a workspace and a service. It can:

- complete OAuth and hold the credential;
- expose a small typed API;
- scope access to one repository, document, table, or account segment;
- filter fields and apply role or regional restrictions;
- rate-limit operations;
- log resources observed and actions attempted;
- require approval for side effects.

Cloudflare also describes asynchronous approvals: a Gatekeeper may simulate an action and its result so an agent can continue, then queue the real effect for later human approval. This can reduce "agent stopped at step one" fatigue, but simulation creates a new correctness obligation. Test what happens when later steps depend on a simulated result and the human rejects the original action.

### Policy follows observations

Tool-call authorization is only the first boundary. An agent might read a sensitive table, summarize it, and publish a dashboard. Cloudflare OS records resources the agent observed and attaches those observations to the workspace and its outputs. When another person opens or shares the work, Gatekeepers can check whether that person may access the original resources.

This is the project's most consequential security design. Verify at least these flows:

1. read a restricted resource and create a Gadget;
2. share the Gadget with an unauthorized account;
3. copy a Blueprint from the Gadget;
4. export content to Drive or another system;
5. ask the agent to send a derived summary externally;
6. revoke the original user's resource access;
7. inspect audit events and error reporting for every denial.

The server side of generated apps runs in Dynamic Workers with global outbound networking disabled, according to Cloudflare. The browser client uses a sandboxed frame and CSP. External access should occur only through bindings and Gatekeepers. Those controls still require configuration review, browser testing, and validation of each custom Gatekeeper.

## Deployment paths

### Fast evaluation

The core repository supports local evaluation:

```bash
git clone https://github.com/cloudflare/cloudflare-os.git
cd cloudflare-os
pnpm run-local
```

Expected output: the local stack starts on localhost port `8787` using Wrangler and `workerd`, with data stored under `.wrangler`. The repository says this path is not intended for production.

### Cloudflare account deployment

Cloudflare publishes a hosted deployment flow and a separate `cloudflare-os-starter` repository. The starter wraps a pinned upstream release and lets an organization own identity, routes, storage, branding, integrations, observability, and upgrade timing.

Its documented baseline requires Node.js 24, pnpm 11, Wrangler authentication, Workers, KV, R2, Browser Rendering, and Dynamic Worker Loaders. AI products are optional until models are enabled.

```bash
git clone --recurse-submodules https://github.com/cloudflare/cloudflare-os-starter.git
cd cloudflare-os-starter
pnpm install
pnpm --dir cloudflare-os install
pnpm exec wrangler login
# Configure deployment.jsonc and Cloudflare Access first
pnpm check
pnpm deploy
```

Expected output: the starter validates configuration, builds the frontend, deploys private supporting Workers and Gatekeepers, then deploys the main Workshop. Run this only in a dedicated test account or reviewed production account with explicit change approval.

Pin the upstream submodule or release. Do not track `main` in production. Keep OAuth secrets out of tracked configuration, define Worker rollback procedures, and document the storage resources the deployment creates.

### Outside Cloudflare

The core is built on `workerd`, and the project says it can run on your own servers. However, its README marks production guidance and tooling for that path as **coming soon**. Local execution proves portability of the runtime, not operational parity with the managed deployment.

## Evaluation plan

A useful pilot is narrower than "let everyone build anything."

1. **Choose one bounded workflow.** Prefer read-heavy work with clear acceptance criteria.
2. **Create a dedicated environment.** Separate account, Access policy, storage, hostname, OAuth apps, and model budgets.
3. **Pin source.** Record the Cloudflare OS and starter revisions, licenses, and dependency lockfiles.
4. **Enable one Gatekeeper.** Start with one repository or document set, not an entire corporate account.
5. **Test deny paths.** Unauthorized user, revoked access, field masking, rate limit, blocked egress, and rejected side effect.
6. **Test derived-data sharing.** Confirm observation policy follows documents, Gadgets, copies, exports, and invitations.
7. **Measure model use.** Compare agent sessions with deterministic generated workflows for cost and correctness.
8. **Exercise rollback.** Revert Workers, restore configuration, and verify data remains consistent.
9. **Review logs.** Ensure audit events are useful without leaking prompts, secrets, or sensitive records.
10. **Expand by capability.** Add resources only after policy and ownership are explicit.

Ownership matters as much as isolation. Every generated workflow needs a human owner, a review date, a budget, and a shutdown path when that person changes roles or leaves.

## Limits and unknowns

- The release is early access and under heavy development.
- Outside-Cloudflare production tooling is not complete.
- Custom integrations require service-specific Gatekeepers and OAuth setup.
- Gatekeeper quality determines the real security of each external boundary.
- Observation-aware policy is ambitious; test derived data and every export path.
- AI-generated applications still require functional, security, accessibility, and data-retention review.
- Vendor adoption and time-saved figures are not independently audited.
- "Use any model" still depends on your configured provider, data terms, regional requirements, and AI Gateway policy.
- The project's current contribution policy discourages large external pull requests, which may affect teams expecting community-led feature development.

## Verdict

Cloudflare OS is notable because it treats agent access and generated apps as a capability-security problem rather than handing a general agent a bundle of API keys. Gatekeepers, observation tracking, network-disabled generated code, and per-app isolation form a coherent design.

The caveat is maturity. This is an early-access platform that combines identity, policy, code generation, application hosting, data lineage, model routing, and organization change. Evaluate it with one resource and one workflow, prove the deny paths, and pin every deployed revision before expanding.

## FAQ

## FAQ

### Is Cloudflare OS a desktop operating system?

No. It is a browser-based, open-source agent productivity environment built around workspaces, generated applications, organization context, and governed access to external resources.

### Can Cloudflare OS run outside Cloudflare?

The core uses the open-source workerd runtime and can run locally, but the repository says production self-hosting guidance and tooling are still coming. The supported starter path deploys to a Cloudflare account.

### What is a Cloudflare OS Gatekeeper?

A Gatekeeper is a service-specific Worker that holds credentials, exposes a narrow typed capability, enforces policy, logs observations and actions, and can require approval for side effects.

### Does Cloudflare OS support MCP servers?

Yes. It can connect existing MCP servers through MCP Server Portals, while Gatekeepers provide Cloudflare OS's more resource-aware capability and policy layer.

### Is Cloudflare OS production-ready?

Cloudflare calls the August 2026 v2 release early access and warns that it has rough edges. Teams should pin a release, verify identity and resource boundaries, stage integrations, and define rollback before production use.


## Sources and links

- [Cloudflare OS launch article](https://blog.cloudflare.com/cloudflare-os/)
- [Cloudflare's internal adoption lessons](https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os/)
- [Cloudflare OS core repository](https://github.com/cloudflare/cloudflare-os)
- [Cloudflare OS deployment starter](https://github.com/cloudflare/cloudflare-os-starter)
- [Official workspace image](https://github.com/cloudflare/cloudflare-os/blob/main/docs/images/q3-planning-workspace.png)


---

- [All articles](https://agentpedia.codes/blog)