Cloudflare OS Gatekeepers Fix Agent Approvals by Lying to the Agent

Cloudflare open-sourced the agent workspace its own staff uses. The interesting part is not deny-by-default access, which everyone ships now. It is a per-service proxy that fakes an action's result so approvals can happen later, and understanding that trick tells you where the new risk sits.

The most widely used safety feature in agentic coding is the flag that turns safety off. Anyone who has run a long agent task knows exactly why. You hand over a job, walk away, come back twenty minutes later, and the agent is sitting on step two waiting for you to click yes. So you pass --dangerously-skip-permissions and get on with your life, and every approval gate you configured evaporates at once.

Cloudflare's engineers wrote that failure into their own README, by name, as the problem they set out to solve. That is a level of candor I do not usually get from a launch post, and it points at something the rest of the industry has been treating as a policy problem when it is really an ergonomics problem.

Cloudflare OS shipped as open source on August 5 under Apache 2.0, a self-hostable agent workspace that a large part of Cloudflare's workforce already uses daily. At scan it showed 1.5k stars, 85 forks, 5 watchers, and 622 commits, with no tagged releases.

The trick

A Gatekeeper is a Worker that sits between an agent and one external service. It wraps that service's native API in a clean Cap'n Web interface, holds the OAuth credential itself, narrows access to the one resource you pointed at, logs every action, and requires human approval for anything with side effects.

Most of that is familiar. Here is the part that is not.

When the agent performs an action needing approval, the Gatekeeper does not block. It simulates the outcome locally, tells the agent the action completed, and lets it continue. If the agent reads back the result, the Gatekeeper hands it simulated results. The agent keeps working, queuing further actions, and finishes the task. Later, whenever you feel like it, you approve or reject the queue in bulk or one at a time.

Read that again, because the design commits to something most safety tooling refuses to do. The Gatekeeper deliberately tells the agent something untrue in order to keep the agent unblocked.

I think this is correct, and I think it is the first genuinely new idea in human-in-the-loop agent design in about a year. Synchronous approval fails not because people are careless but because it converts an autonomous task back into a supervised one, which destroys the reason you delegated it. Asynchronous approval keeps the delegation intact and moves the human to the end, where reviewing twelve queued actions at once is actually a reasonable ask.

The rest of the architecture, briefly

Access starts at nothing. Each agent and each Gadget has no permissions by default, even when the workspace itself holds credentials for a dozen services. You introduce a resource explicitly, by pasting a GitHub repo link or picking it from the UI, and the agent can request an introduction you then grant or deny. The README contrasts this directly with the usual harness pattern where MCP servers get configured up front and every chat inherits ambient access to everything.

A Gadget is one user's private instance of an app. Ask for a slide deck and you get your own copy of slide software running in its own sandbox, not a call out to shared SaaS. The server runs in a Dynamic Worker with internet access disabled, reaching only the bindings you designated. The client runs in a sandboxed iframe that can talk to its server over a Cap'n Web session through postMessage() and nothing else, locked down with Content-Security-Policy. Cloudflare's claim follows from that: a slide app bug cannot leak your slides, because the app never had a route to the outside.

The team means the operating system framing more literally than I expected. Their own mapping puts the kernel at packages/workshop-backend, device drivers at packages/gatekeeper-*, the shell at packages/workshop-frontend, processes as Gadgets, executables as Blueprints, and ACLs as shared permissions. The row they leave blank in the traditional column is agents, and their argument is that a real OS ought to have a concept for a process that acts on a user's behalf with its own narrower rights.

None of this is new thinking. It is ten-year-old thinking. Kenton Varda, who built Cloudflare Workers, described the release as a remake of Sandstorm.io, the startup he ran a decade ago. A Gadget is a Sandstorm grain. Capability-based security lost to ACLs in the 2010s partly because per-instance sandboxing was expensive and nobody would pay that cost to contain software they had already decided to trust. Agents changed the arithmetic. You cannot decide to trust a process whose behavior is written at runtime by a model reading text you did not author.

Put this into practice

The fastest look costs one command. Install pnpm, run pnpm run-local, open http://localhost:8787. That runs the whole stack on wrangler and workerd on your machine, with state in a local .wrangler directory. Ask it to make a slide deck or a whiteboard app and watch what the Gatekeeper does. For something more permanent there is a guided deploy at os.cloudflare.app/deploy into your own Cloudflare account, and a separate starter repo for deployments with custom Gatekeepers.

If you are not going to adopt the platform, read packages/gatekeeper-github/README.md anyway and steal the shape. The pattern generalizes to any stack: the OAuth credential belongs in a per-service proxy that your agent calls, not in the agent's environment. Add action logging at that proxy, since that is the only place you can see what actually happened rather than what the agent claims happened. Then pick your irreversible operations, the merges and sends and deletes, and route only those through an approval queue instead of gating every command.

The optimistic-approval piece is harder to copy and worth attempting on your highest-friction path first. Pick the one action your team most often auto-approves out of impatience and try returning a plausible fake result while queueing the real one.

Where this gets uncomfortable

The simulation is a fabrication, and fabrications compound.

An agent that queues fifteen actions has reasoned about thirteen of them using read-backs the Gatekeeper made up. If the simulated result diverges from what the real service would have returned, every downstream decision inherits that divergence, and you find out at approval time when the queue no longer makes sense. Simulation quality is per-Gatekeeper and undocumented, so how well this holds depends entirely on how carefully whoever wrote that particular Gatekeeper modeled the service.

And bulk approval is its own hazard. A human reviewing fifteen queued actions at 6pm approves them the same way a human approves a synchronous prompt at step two, which is to say fast. The design fixes the reason people disable permissions. It does not fix the reason people rubber-stamp them. Those are related problems and only one of them just got solved.

A few more things the launch coverage underplayed.

Self-hosting is not fully here. The README markets running on workerd, Cloudflare's open-source runtime, on your own servers, and then labels that section COMING SOON with a pointer to low-level workerd config docs and a suggestion to have a go. The supported path today is your own Cloudflare account.

This is version 2, a complete rewrite of an internal version 1, and Cloudflare calls the August 2026 release early access with many rough edges in their own words. That is not a knock, but it is not a thing to put in front of your sales team next week.

Eleven Gatekeepers ship: GitHub, Google, Cloudflare, Supabase, Notion, Confluence, Email Workers, Home Assistant, Slack, Spotify, ZoomInfo. Anything else, you write. The repo includes a .agents/skills/write-gatekeeper skill, which tells you how much of that work Cloudflare expects you to do. Each one also needs its own OAuth client credentials, and the README admits plainly that many providers make this deliberately unpleasant.

Contributions are mostly closed. The project accepts small trivially-verified fixes and will close anything past roughly a dozen lines, with an argument I find hard to dispute: AI made writing code cheap and review expensive, so an unsolicited PR donates the easy half of the job. Treat this as source you can read and fork, not a project you join.

What to actually do with this

Go run it locally tonight. Not because you are going to migrate your company onto it, but because the Gatekeeper approval flow is the clearest working demonstration I have seen of an idea most teams are still solving with a config flag.

Then look at your own agent setup and answer one question honestly. How many of your approval gates are still on, and how many did you disable the first week because they got in the way? Whatever number comes back is your real security posture, and the fix is probably not a stricter policy.

Sources: cloudflare/cloudflare-os on GitHub; Cloudflare OS: an open platform for agents, apps, and work; Kenton Varda on the Sandstorm lineage; cloudflare/cloudflare-os packages.