Simulate Success: The System Tells the AI It's Done Before You Approve

This approach is described in the interface documentation for gatekeeper developers:

It is suggested that the gatekeeper "simulate" actions that have not been approved yet, meaning the Session interface should behave as if all actions have been applied.

It is suggested that the gatekeeper "simulate" actions that have not been approved yet, that is, the Session interface should reflect the state of the resource as if all actions had been applied.

cloudflare/cloudflare-os · gatekeeper.ts

One important detail: simulation is recommended, not mandatory. It's up to each gatekeeper's developer. The real red lines are the other three: every action must go through the approval queue, reads must be authorized, and actions with side effects must never be truly executed before approval. "Simulating success" is just an optional optimization to keep the agent moving.

Sandbox isolation: Every document lives in its own room, so bad code can't spread

Kenton Varda, the lead behind Cloudflare OS and creator of Cloudflare Workers, said on launch day: the sandbox is so safe you can tinker freely, and AI cannot introduce major security vulnerabilities. A company's security team can let non-technical colleagues vibe code and still sleep at night.

This "isolate every document" idea comes from Kenton's decade-old startup, Sandstorm, which didn't take off. Two reasons are often cited. First, it was too expensive: containers were the only option, and spinning one up was costly. Second, per Kenton: the world wasn't ready—there wasn't enough skill or patience to adapt software. Both reasons together make sense: it finally became cheap and the skills finally exist.

How much cheaper? Here are the official figures:

An isolate is a lightweight execution environment from the V8 engine (the one that runs Chrome). The analysis article claims containers take "several seconds" to cold-start, which is an order of magnitude off from the official numbers. We've used the official figures.

Withhold keys: The agent never gets secrets, only a few methods

This "methods, not keys" approach has a formal name: the object-capability model, a concept studied in security circles for decades.

Track Data Lineage: The System Knows What the Agent Read and Checks Permissions Before Sharing

Ultra-safe fallback (lockdown mode): For data too sensitive to be described by existing rules, you can simply flag it as "allow no sharing." Once a gadget reads such data, it immediately enters lockdown mode. It can still read, but it can no longer take any action through any gatekeeper, completely sealing off the leak path. The code comments even admit this is a temporary measure, to be replaced by finer-grained rules later.

Also worth noting: prompt injection is still an unsolved problem in this architecture. The source code's TODO list still has two items: detecting whether free-text content in a read could be a hidden injection, and identifying who has written to these content sources.

Distrust Human Contributors Too: External PRs Over a Few Lines Are Automatically Closed

An unreviewed contribution is untrusted input, whether it came from a careless human or a confident model is almost irrelevant. The system's distrust of AI thus extends to a distrust of human contributors.

The Cost of This Design: The Tighter You Control AI, The Less It Can Do For You

The five mechanisms above are clever. But they share a common cost: the tighter you control AI, the less work it can do for you. This breaks down into two things.

First, an agent that never gets keys can never do the jobs that require keys. It can't renew a service or call an API that no one has explicitly opened for it. The system design just doesn't give it that power. It can only operate within the bounds you've defined. Anything outside that, a human still has to do.

Second, write operations always need human approval, meaning a human is always in the loop. This design certainly means you don't have to watch every step, but that batch of pending actions still needs your review and your click. And the whole point of an agent was to stop needing a human to watch over it. The human is still in the loop, just moved from "present at every step" to "always present for the final step."

To summarize the trade-off: The same leash that keeps it from running amok is the one that stops it from pulling a heavy load. You can't have maximum autonomy and maximum safety at the same time. Cloudflare chose safety, and chose it firmly. Their bet is that a leashed agent you can actually deploy inside your company is more valuable than a free agent you're too scared to use.

One more paradox: It distrusts everyone, except itself

The system's logic is "trust no one": not AI, not user code, not outside programmers.

But there's one exception: Cloudflare itself.

The technologies used for isolation, approval, and tracking (Workers, Durable Objects, etc.) are all Cloudflare's own, some built specifically for this project and available nowhere else. So this "trust no one" system is itself built on the premise that you must trust Cloudflare.

The saving grace is that it's fully open-source, running on the open-source workerd runtime. In theory, you can move it to your own servers, which is more than most similar products. But using it comes with accepting that premise first.

Finally: Even its creators haven't figured out how to define an Agent

In the repo, there's a table mapping Cloudflare OS components to those of a traditional OS: what maps to the kernel, drivers, processes. The first rows all match up. The last one is blank, with three question marks.

The question marks mean: in a traditional OS, there's no such thing as an "AI agent."

It's not a regular user: user permissions are pre-defined, but an agent answers to a specific person, and its permissions need to be granted and revoked in real-time. It's also not a regular program: program code is written in advance, but an agent writes its own code as it goes.

Cloudflare's answer is that the best way to manage this new thing is via "you can only do the specific things I allow" (the capability model), rather than the traditional "what groups are you in, what permissions do you have" list.

But they didn't fill in that row either. This is a new species, and even its creators haven't figured out how to define it.

When an agent tries to do something with real consequences—merge code, send an email, write to a production system—it has to go through a service called the Gatekeeper. Before you approve, the gatekeeper lies.

One caveat: simulation is not mandatory. It's up to each gatekeeper's developer. The real red line is the other one: actions with side effects are never truly executed before approval.

The remaining four mechanisms each cover a different angle, but they're four corollaries of the same philosophy. Let's walk through them as xiaohu creates a quarterly report:

The sandbox idea was tried a decade ago by Kenton Varda's startup Sandstorm. Back then, only containers were available for isolation, too expensive. Now it's cheap:

These three figures come from Cloudflare's Dynamic Workers engineering blog and haven't been independently verified. The analysis article describes containers as "cold-starting in seconds," which is an order of magnitude off, so we didn't use it.

With all five locks in place, what does the agent actually have left?