Every time a Gadget or agent touches the outside world — reading a Google Doc, opening a GitHub issue, posting a Slack message — that request passes through a Gatekeeper. Gatekeepers are the security boundary between your sandboxed applications and every external service they depend on. They enforce narrow, auditable, revocable access on behalf of the user who owns the Gadget, and they give you meaningful control over what AI is actually allowed to do in your name.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/cloudflare/cloudflare-os/llms.txt
Use this file to discover all available pages before exploring further.
What a Gatekeeper does
A Gatekeeper is a separate Cloudflare Worker that wraps one external service integration. For each service it manages, a Gatekeeper:- Exposes a clean Cap’n Web API. Instead of exposing raw REST calls, a Gatekeeper defines a typed, version-stable RPC interface that Gadgets and agents call directly. The underlying vendor API is an implementation detail.
- Handles OAuth authorization. The Gatekeeper owns the full OAuth flow, token storage, and token refresh. Gadgets never see raw credentials.
- Enforces narrow access. A Gatekeeper is introduced to exactly one resource (e.g., a specific GitHub repository or a single Google Doc). It cannot be used to access other resources in the same service that the user has not explicitly introduced.
- Logs every action. Every read observation and every write action is recorded in the workspace action log, visible to the Gadget owner at any time.
- Queues writes for human approval. Any action with side effects (posting a comment, editing a document, sending a message) is queued for the user to approve or reject, rather than being applied immediately and silently.
Asynchronous human-in-the-loop approval
The human-in-the-loop approval mechanism in Cloudflare OS is fundamentally different from every other agent safety system, and it solves the core problem that causes people to reach for--dangerously-skip-permissions.
The traditional approach blocks the agent at each write action, waiting synchronously for your approval before proceeding. You hand the agent a task, walk away to get coffee, and come back to find the agent frozen on step one waiting for a click.
The Cloudflare OS approach uses a simulation pattern:
Agent requests a write action
The Gadget calls the Gatekeeper with a write action — for example, “post this comment to GitHub issue #42.”
Gatekeeper simulates the outcome
Rather than blocking, the Gatekeeper simulates the outcome locally: it tells the agent the action succeeded and, if the agent reads back the results, returns plausible simulated data.
Agent continues unblocked
The agent proceeds with the rest of its task, queuing up additional actions as needed, all while no real writes have been made.
Capability-based resource introductions
By default, no Gadget or agent has access to any external service — even if you have configured that service in your account. Access is granted only through an explicit introduction. You introduce a resource by pasting a link to it (e.g., a GitHub repository URL or a Google Doc URL), or by using the UI to select it from a connected account. The agent can also request an introduction to a resource it believes it needs, which you can approve or deny inline in the chat. Either way, the resulting Gatekeeper is narrowly scoped to that one resource. This differs from conventional agent setups where MCP servers are configured once and become ambiently available to every chat. In Cloudflare OS, each agent session starts with access to nothing, and access is granted only for what is actually needed.Auto-discovery via service bindings
Each Gatekeeper runs as a completely independent Cloudflare Worker. The Workshop backend discovers available Gatekeepers automatically by scanning its ownGATEKEEPER_* service bindings at startup — installing a new Gatekeeper requires only adding a binding, not modifying the kernel code.
Gatekeeper vendor IDs are derived from the binding suffix, lowercased (e.g., GATEKEEPER_GITHUB → "github"). The Gatekeeper’s own VendorDescription declares its display name, logo, supported resource types, and whether it supports OAuth, auto-provisioning, or a management UI.
Observer tracking for shared Gadgets
When you share a Gadget with a collaborator, Gatekeepers verify that the collaborator independently has access to every external resource the Gadget has read. This enforcement is mediated through two Gatekeeper RPC methods:addObserver(observerId, verifier)— called when a collaborator opens the Gadget. The Gatekeeper verifies, via the collaborator’s own connected account, that they can directly read all data the Gadget has accessed through this Gatekeeper. It throws if they cannot, blocking the open.removeObserver(observerId)— called when the collaborator’s access is revoked. Idempotent.
Auto-provisioned Gatekeepers
Some Gatekeepers do not require an OAuth flow — they mint a connected account automatically. These auto-provisioned Gatekeepers are enabled by deployment admins and appear as ambient singleton bindings in every agent chat environment. The two built-in examples are:| Gatekeeper | Purpose |
|---|---|
Context Library (GATEKEEPER_CONTEXT) | Named collections of context documents that the agent reads as observations. Public collections are curated by admins; private collections belong to individual users. |
Scheduler (GATEKEEPER_SCHEDULER) | Lets Gadgets register persistent workspace callbacks on a schedule. |
executeCode environment via getSession() / getAgentCatalog() — no introduction step required.
Available Gatekeepers
GitHub
Repos, issues, pull requests, and code search.
Docs, Sheets, Calendar, Gmail, and BigQuery.
Confluence
Sites, spaces, pages, and blog posts.
Slack
Channels, messages, and file access.
Notion
Pages, databases, and workspace search.
MCP
Connect any MCP-compatible server as a Gatekeeper endpoint.