If an AI creates a new app from materials it has read, who gets to see that app?
When connecting an internal AI to a GitHub repository or customer data, it can seem enough to limit permissions at the start. But the situation changes when the agent reads those materials, creates a dashboard, shares it with colleagues, or sends it to an external service. Someone who cannot see the original may still be able to see its contents in a processed result.
What makes Cloudflare OS interesting is that it does not stop at hiding API keys from agents. It records the resources an agent actually observed, then uses that record in policies for viewing and transferring workspaces, apps, and outputs created later. It is a design that attaches permissions not to the initial call, but to the data’s path of movement.
Sandstorm did not fail because ‘users could not code’
The lineage of Cloudflare OS leads back to Sandstorm, created by Kenton Varda. Sandstorm was a self-hosting platform that ran documents and apps as small, independent instances and split access rights per instance.
However, when the business shut down in 2017, the official retrospective did not identify an outdated idea as the direct cause of failure. The product was still rough at an alpha level, enterprise sales proved harder than expected, and there was not enough funding or time to stabilize the product and sales efforts. It also explained that hundreds of enterprise trials and expressions of interest led to very few actual purchases.
In a public post in 2026, Varda described Cloudflare OS as a remake of Sandstorm using Workers and AI. Like Sandstorm’s “Grains,” it finely isolates app instances, but this time users can ask an agent to directly modify the apps they need.
Cloudflare made its first version available to all employees in May 2026. According to the company, thousands of people across roles used it to create documents and slides, automate repetitive work, and build small apps. It did not disclose an exact active-user methodology or productivity changes before and after adoption.
Gatekeeper connects access, observation, and subsequent movement
The public Cloudflare OS v2 consists of agent workspaces for company context, a security and governance layer, and a personalized app platform. For teams considering internal adoption, Gatekeeper in the security layer is the first part to examine.
| Stage | What Gatekeeper controls | Question to check |
|---|---|---|
| Before access | Isolates credentials from agents and generated code, and provides narrow capabilities such as specific repositories, issues, or actions | Can the agent view the raw token or call resources outside its scope? |
| While using data | Records the resources the agent actually observed | Does it track the original resources read, rather than only tool-call logs? |
| After using results | Applies observation records to policies for viewing results, inviting collaborators, external requests, and handoffs to other agents | Can a user without access to the original resource open or export a derived result? |
For example, if an agent reads a sensitive table and creates a dashboard, the system can check access to the original resource again when another user opens that dashboard. This prevents a derived result from becoming public automatically just because the agent already read it.
It would be misleading to reduce this difference to “MCP is risky and Gatekeeper is safe.” An MCP server can store credentials too. What Cloudflare OS pushes further is connecting policy beyond permission for tool calls to the resources observed and where data from those resources moves afterward.
Three questions to ask during an adoption review
- Can agents and generated code read OAuth tokens directly?
- Does the system retain which rows, files, and repositories were observed, not just which tools were called?
- Do the same sharing and external-transfer restrictions continue to apply to apps and outputs derived from the original?
Gadgets keep app code and user data separate
In Cloudflare OS, personalized apps created by agents are called Gadgets. Each Gadget has its own Dynamic Worker runtime and SQLite state, separating the execution environment and state for each app.
If you want to give a colleague the same app, you can share a Blueprint. What gets copied is the code; the original user’s data, conversation history, credentials, and connected resources are not included. In other words, it distinguishes sharing a finished app for joint use from handing over an empty copy.
Gatekeeper can also mediate actions with external side effects. While approval is pending, it can simulate outcomes so the agent can continue with subsequent work, and supports users approving actions individually or in batches later. However, not every write operation always requires human approval. Which actions require approval depends on the connected Gatekeeper and organizational policy.
Build your first Gadget without external data
For a first hands-on exercise to understand the architecture, it is simpler not to start by connecting GitHub or Google OAuth. You need a Cloudflare account, an administrator email address, and an instance name to use in a workers.dev address. Also note in advance that model inference runs the moment you create your first whiteboard.
Check billing and usage limits before running it. The default model on the official deployment page can be used through AI Gateway without a separate API key, but usage may be billed to the deployer’s Cloudflare account. Entering an Anthropic or OpenAI API key is optional and can be done later.
- Log in to Cloudflare on the official deployment page. Open the Cloudflare OS deployment page, sign in with your Cloudflare account, and approve the requested dashboard permissions so you can deploy to your own account.
- Enter an instance name and administrator email, then deploy. The instance name is used in the deployed
workers.devaddress. Enter the email address to use as the administrator as well, then start deployment. This hosting path deploys to your own Cloudflare account without a local build. - Log in with the administrator email. Open the deployed
workers.devaddress, enter the administrator email, then sign in with the one-time PIN sent by Cloudflare Access. After access, also confirm under/adminthat the same email is recognized as an administrator. - Enter your first request in the default workspace. Without connecting external services, request Make a collaborative whiteboard app. This is an example prompt provided by the repository, and model usage may begin with this request.
- The success criterion is running it, not generating it. Confirm that the generated whiteboard Gadget opens and that you can add or move elements yourself. Configure the relevant Gatekeeper and OAuth credentials only in the next step, when internal materials are truly necessary.
It is still too early for full production rollout. The public release as of August 2026 is early access, and production deployment documentation and tools for running it on your own server with workerd are not yet complete. Being Apache-2.0 open source does not mean operating costs are free. During the pilot, review actual Workers, storage, and AI usage together with pinned versions and trust boundaries.
What to take away is the lifetime of permissions, not the label ‘AI operating system’
Cloudflare OS is less a traditional computer operating system than a product that compares an agent workspace and app-isolation layer to an OS. So before its name or scale of internal use, the first thing to check is how long permissions persist and how far they extend.
The currently public materials alone cannot independently prove Gatekeeper’s security. External security-audit results, operating costs by organization size, and actual active users and productivity changes for public v2 have not been verified either. Still, it leaves teams designing internal AI platforms with a clear question: Do not stop at “Who can call this tool?” Include in your permissions model, “Who can see the results created from data this tool read, and where can they send them?”
If you want to dig deeper
Cloudflare OS: an open platform for agents, apps, and work You can review the three components, Gatekeeper observation records, and Gadget sharing policies through official examples. blog.cloudflare.com
cloudflare/cloudflare-os This official repository is useful for checking the license, example prompts, local execution methods, and early-access limitations. github.com
Deploy Cloudflare OS to Cloudflare Before running it, you can check the instance name and administrator email needed for the current hosted deployment, along with billing information for the default model. os.cloudflare.app
Sandstorm is returning to its community roots This is the founder’s retrospective on the product maturity, enterprise sales, and funding issues at the time Sandstorm’s business shut down. sandstorm.io
