Cloudflare OS: How to Run a Zero-Trust Internal AI Workspace

Cloudflare OS is less a new chat UI and more an open-source platform for running an internal agent workspace on your own Cloudflare account, with zero-trust controls for internal systems.

📑Table of Contents

1. What Cloudflare OS actually ships
2. Gatekeepers and the zero-trust permission model
3. Gadgets vs Blueprints: ownership and share risk
4. Deploy path and prerequisites
5. Comparison: Gatekeeper platform vs key-sharing copilots vs ambient MCP
6. Adoption checklist and next actions
7. Author Perspective
8. FAQ
9. Closing

Release context

Cloudflare rolled an earlier version to employees in May 2026 and open-sourced a rebuilt release around 5 August 2026 under Apache-2.0.

What this guide covers

This guide covers the following, using the official post plus independent reporting:

• three-part architecture
• Gatekeeper permissions
• Gadget/Blueprint sharing boundaries
• deploy prerequisites
• differences from ambient MCP or API-key copilots
• a practical PoC checklist

---

What Cloudflare OS actually ships

Three-part platform definition

The useful definition is platform-shaped:

1. agent workspace
2. Gatekeeper governance
3. personal full-stack apps (Gadgets)

Cloudflare’s announcement frames the release as the internal agent environment employees already use, now deployable by other organizations into their own accounts (Cloudflare Blog).

Why it was rebuilt

The open-source cut is a rebuild, not a cosmetic export.

Independent JA reporting summarizes first-version pain (GIGAZINE):

• apps that were too static
• deterministic jobs that re-ran agent skills and burned tokens
• collaboration paths that could leak observed data

Treat internal adoption numbers cited in secondary analysis—such as sales-hour savings or thousands of apps in 30 days—as CIO-reported signals, not public benchmarks.

Source: Developers Digest.

Repositories and license

Artifacts to inspect first:

• cloudflare/cloudflare-os (core)
• cloudflare-os-starter (org config without patching core)
• demo at os.cloudflare.app

License is Apache-2.0; formal GitHub Releases were still thin at retrieval, which matches an early-access posture.

---

Gatekeepers and the zero-trust permission model

Zero-default entry

Entry is gated by Cloudflare Access.

Agents and apps start with no ambient rights.

Allowed resources arrive as typed bindings (for example env.PROJECT), and credentials stay out of agent/generated code (Cloudflare Blog).

What a Gatekeeper does

A Gatekeeper is a service-specific Worker. It:

• holds OAuth
• exposes a narrow API surface
• logs reads
• mediates side effects/approvals

The recurring example is GitHub scoped so issues on one repo are readable while source is not, with human approval before merge.

Sources: PC Watch, Cyber Press.

Runtime isolation and observation-following

Runtime isolation matches that story.

• Dynamic Workers disable global outbound networking
• browser code runs sandboxed

Observation-following policy does two things:

• attaches resources an agent observed to the artifact
• re-checks the viewer’s ACL on those sources at share time

So a dashboard cannot smuggle warehouse-table access.

Independent analysis also highlights simulated-commit flows that queue side effects for bulk approval later, reducing approval fatigue (Developers Digest).

MCP support without ambient defaults

MCP is supported through MCP Server Portals, but ambient MCP is not the security default.

That is the design intent for teams that already invested in MCP and still need harder capability boundaries.

Source

---

Gadgets vs Blueprints: ownership and share risk

Gadget vs Blueprint

Gadgets are private per-user full-stack instances (client + server + API + SQLite on Dynamic Worker Facets).

• Default is private
• Live share enables co-editing the same state
• Blueprint share copies code only—not SQLite data, chat history, credentials, or connected resources

Source: Cloudflare Blog.

Cap’n Web object-capability RPC is part of the runtime story so clients and agents call the same surface.

Operational implication

Operational implication: template distribution and production-data sharing must be separate policy decisions.

If you only train users on “share the app,” you will recreate the collaboration leakage class the rebuild tried to fix.

---

Deploy path and prerequisites

Deploy steps

Cloudflare’s path assumes deployment into a customer Cloudflare account.

Marketing says “a few minutes”; treat that as best-case, environment-dependent.

Install and account setup

1. Review core + starter; put org config in starter rather than patching core
2. Deploy into a sandbox or production Cloudflare account you control
3. Provide a Cloudflare API token at install (required); embedded model usage bills to that account
4. Anthropic/OpenAI keys are optional at install or later model settings

Access, Gateway, and Gatekeeper wiring

5. Wire Access policies, AI Gateway model allowlists/budgets/rate limits, and Gatekeeper OAuth
6. Start from bundled connectors reported in the field (GitHub, Google, Notion, Confluence, Slack, Email Workers, Cloudflare API, Supabase, and others) (PC Watch)
7. Expect to write custom Gatekeepers for internal systems of record (Developers Digest)

Early-access limits

Limits matter as much as the happy path:

• early-access roughness
• unpublished managed-dashboard timing/pricing
• incomplete production self-host tooling outside Cloudflare (workerd is mentioned technically, not as a finished ops path)

Sources: Impress Watch, PC Watch.

Running in your account helps keep artifacts organization-owned, but it does not remove Workers/Cloudflare runtime dependency.

---

Comparison: Gatekeeper platform vs key-sharing copilots vs ambient MCP

Comparison table

Score options on access control first, then on artifacts and operating cost—not on discovery popularity.

Access, credentials, and share-time ACL

Dimension	Cloudflare OS (Gatekeeper)	Generic chat + distributed API keys	Ambient-leaning MCP wiring
Initial privilege	Zero; grant incrementally	Often broad via key scope	Depends on exposed tools
Credential placement	Inside Gatekeepers; isolated from agents	Easy to land with users/agents	Usually on the MCP server
Share-time source ACL	Observation-following re-check	Easy to leak via shared artifacts	Only if you implement tracking

Artifacts, governance, cost, and maturity

Dimension	Cloudflare OS (Gatekeeper)	Generic chat + distributed API keys	Ambient-leaning MCP wiring
Artifacts	Gadgets with private DB / Blueprints	Docs and scripts	Tool-call results
Model/cost control	Centralized via AI Gateway	Fragmented per tool	Often fragmented
Adoption cost	CF account + Gatekeeper design	Low start, weak audit	Medium
Maturity	Early-access OSS	Product-dependent	Product/in-house dependent

Comparison sources (as of August 2026)

• Cloudflare Blog
• SD Times
• Cyber Press
• Developers Digest

How to score the options

If your org already has copilots, do not score only on “time to first demo.”

Score on:

• auditability
• share boundaries
• who owns side-effect approval

Cloudflare OS makes Gatekeeper design the main work.

---

Adoption checklist and next actions

Decision checklist

Turn the article into a decision, not a bookmark.

• ✓ Does the target workflow read/write internal systems of record? (If yes, Gatekeeper design is the core task.)
• ✓ Do you already operate Cloudflare Access, Workers, and AI Gateway?
• ✓ Can you define a one-Gatekeeper PoC (example: GitHub issues read-only)?
• ✓ Can security/IT agree live-share vs Blueprint rules before pilot users arrive?
• ✓ Is early access acceptable? Require production SLA, deep audit exports, or non-CF self-host → hold
• ✓ Wait for managed dashboard, or cut a sandbox account with starter now?

Suggested three-step path

Suggested path:

1. One low-risk read-only Gatekeeper in a sandbox account
2. One business flow that exercises observation logs and share-time ACL
3. Lock AI Gateway budgets/model tiers before non-engineer rollout

SD Times’ framing matches that sequence:

• browser workspace without developer expertise for end users
• Zero Trust defaults and Gatekeepers underneath
• managed dashboard later

Source: SD Times.

---

Author Perspective

What to judge

From an infrastructure operator lens, Cloudflare OS should be judged on whether the platform can enforce what agents may see, change, and share—not on model leaderboards.

Org readiness

• Teams already deep in Access/Workers have a shorter path to a meaningful PoC.
• Teams without that foundation should budget Gatekeeper authoring and policy work as the product, not a side quest.

Reasons to refuse big-bang cutover

The following are enough reason to refuse a big-bang production cutover:

• early access
• unpublished managed pricing/timing
• incomplete non-Cloudflare self-host tooling

Write the one-system read-only Gatekeeper design first.

---

FAQ

Q1. Can we run Cloudflare OS in production today?

You can deploy the OSS into your Cloudflare account now, but keep these limits in view:

• official and independent coverage still call it early access
• managed timing/pricing is unpublished
• production self-host tooling outside Cloudflare is incomplete

Start with PoC.

Q2. Does it still matter if we already use MCP?

Yes. MCP Server Portals are supported.

The default security story is capability/Gatekeeper rather than ambient tool exposure. Use it to add boundaries around existing MCP assets.

Q3. Can non-engineers use it?

Day-to-day UI is browser conversation and does not require developer skills (official/SD Times).

Initial Access, Gatekeeper, and AI Gateway wiring still belongs to platform/IT.

Q4. Are we locked into a vendor silo?

Design intent is org-owned deployment on your Cloudflare account (Impress Watch).

Evaluate those separately:

• reduced process/context lock-in into a third-party SaaS workspace
• remaining Workers/Cloudflare runtime dependency

Q5. Which system should we connect first?

Prefer a bundled read-mostly Gatekeeper (for example GitHub issues).

Expand write side effects only after approval flow and observation logging are proven.

---

Closing

Cloudflare OS is an open agent platform with zero-default permissions and personal app runtimes—not merely an internal chatbot release.

The differential value sits in:

• Gatekeepers
• observation-following ACLs
• Blueprint boundaries
• AI Gateway governance

Your next action is binary and operational:

1. design a one-Gatekeeper PoC
2. or hold for managed/requirements fit

Decide from Access maturity and SoR scope, not discovery popularity.