Gatekeepers: Turning Access Into a Capability
Cloudflare OS uses Gatekeepers to solve a problem that a sandbox cannot solve by itself: how an agent or Gadget may reach a real service without receiving an account-wide credential and an unlimited network path. This chapter follows the authority path from a connected account to a resource-specific session, then separates reads from side effects and shows how Code Mode stays productive while actions remain reviewable. The result is a concrete distinction between a connection, a capability, an observation, and an unapplied action.
A Gatekeeper is a policy boundary, not a connector
A connector usually suggests plumbing. It takes an application’s request, sends it to a vendor API, and returns the response. A Gatekeeper includes that plumbing, but its job is broader. It is an independent Worker application that wraps a service’s native API in a Cap’n Web interface and sits inside the Workshop’s capability path.
The distinction begins with what the Gatekeeper does not expose. The Workshop may hold a broad account-level adapter representing a user’s connected service account. Gadgets and agents should not receive that adapter directly. Instead, the Workshop selects a particular resource, creates a Gatekeeper Facet for it, and gives the caller a session capability for the interface that resource supports. The code gets an object with methods, not a token that lets it invent arbitrary requests.
A Gatekeeper can therefore combine several responsibilities at one boundary. It can manage OAuth and credentials, describe the selected resource, provide the types needed for an agent to use its interface, narrow the connection to a resource, authorize observations, and submit side effects for review. It can also record what the Gadget or agent attempted. These are not separate conveniences added after the network call; together they define what it means for the call to be allowed.
This is why the project compares Gatekeepers with device drivers and describes them as “supercharged” MCP servers. The comparison is limited but useful. A driver translates between a general program interface and a particular device. A Gatekeeper translates between a Gadget-friendly RPC interface and a particular external resource, while carrying the authorization and audit rules that the remote API alone may not provide in the form the Workshop needs.
The boundary also changes the default. A connected account is not an ambient capability. The repository says agents and Gadgets start with access to nothing, and a user must introduce the particular resource they want the agent or application to use. The agent may ask for an introduction, but the connection request is a user-visible step. This prevents the system from turning “the owner once connected Google” into “every agent can inspect the owner’s entire Google account.”
From account authority to resource authority
The narrowing step is easiest to see as a three-stage distinction. A user first has an account connection with a vendor. That account may be capable of accessing several kinds of resources. The Workshop then matches a specific resource request, such as a repository or document, to a Gatekeeper implementation. Finally, a Gadget or agent receives a binding to that resource-specific Gatekeeper session.
Each stage answers a different question.