Skip to main content

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.

Gatekeepers are the “device drivers” of Cloudflare OS — purpose-built Cloudflare Workers that mediate every interaction between your agents, Gadgets, and the external services you care about. Each gatekeeper handles OAuth authorization, enforces narrow access to only the specific resource a user intended to share, logs every action for later review, and — for operations with side effects — provides a human-in-the-loop approval flow that does not block the agent while it waits.

​
How a Gatekeeper Works

Each gatekeeper runs as a separate Cloudflare Worker, completely isolated from the workshop backend. The router discovers installed gatekeepers automatically by scanning its own GATEKEEPER_* service bindings, so installing one is purely a configuration change — no code modifications required.
wrangler.jsonc (router)
{
  "services": [
    { "binding": "GATEKEEPER_GITHUB",     "service": "gatekeeper-github" },
    { "binding": "GATEKEEPER_GOOGLE",     "service": "gatekeeper-google" },
    { "binding": "GATEKEEPER_CONFLUENCE", "service": "gatekeeper-confluence" }
  ]
}
Once bound, a gatekeeper exposes a capability-based Session API to each Gadget or agent that has been introduced to a resource it manages. The session is scoped to exactly what the user shared — a single repository, a specific Confluence page, a chosen calendar — and nothing more.

​
The Approval Queue: Asynchronous Human-in-the-Loop

Traditional human-in-the-loop setups block the agent until a person approves each action. Cloudflare OS takes a different approach: write actions are queued, not blocked. When an agent performs an operation that has side effects — creating a GitHub issue, editing a Confluence page, sending a message — the gatekeeper does the following:
  1. Simulates the outcome locally. The gatekeeper tells the agent that the action completed and returns simulated results, including provisional IDs for created resources. The agent continues working.
  2. Queues the real action. The actual API call is staged but not sent until a human approves it.
  3. Presents a review UI. The user can approve or reject queued actions in bulk, or one-by-one, whenever it is convenient — not synchronously while the agent is mid-task.
This eliminates the “agent stuck waiting for approval” problem without resorting to --dangerously-skip-permissions. The agent makes progress; the human stays in control.
Every read still calls authorizeObservation() so that sharing a Gadget with a collaborator correctly tracks what data they would be exposed to — even before any write is approved.

​
Capability-Based Introductions

By default, agents and Gadgets have access to nothing — even if a gatekeeper is installed and your account is connected. You must introduce each agent or Gadget to the specific resources you want it to use. You can make an introduction by:
  • Pasting a URL into the chat (e.g., a GitHub repo link or a Confluence page URL)
  • Using the Connections UI — clicking + New Connection inside a Gadget or agent workspace and using the resource picker
  • Requesting an introduction — an agent can ask for access to a resource it thinks it needs, which you can then grant or deny
This capability-based model means every agent is restricted to only the access it actually needs for the task at hand, rather than having ambient access to everything you have ever connected.

​
Observer Tracking

When you share a Gadget with a collaborator, Cloudflare OS needs to ensure that your collaborator has their own legitimate access to any external resources the Gadget uses — not just inherited access through your credentials. When a collaborator opens a shared Gadget that uses a gatekeeper:
  • Read-only resources that the collaborator also has access to (e.g., a public GitHub repo, a shared Confluence page) allow the Gadget to open normally.
  • Private resources (e.g., Gmail) are always blocked for observers — the gatekeeper is marked private-only and sharing is denied.
  • Ambiguous resources (e.g., a Notion page the collaborator may or may not have access to) prompt the collaborator to verify their own access by connecting their own account and completing the OAuth flow for that resource.
This “Strategy B / Strategy C” observer tracking ensures that a collaborator never silently reads your private data through a shared Gadget.

​
Available Gatekeepers

GitHub

Repositories, issues, and pull requests via OAuth App. Supports “Continue with GitHub” sign-in.

Google

Google Docs, Sheets, Calendar, Gmail, and BigQuery. Supports “Continue with Google” sign-in.

Confluence

Atlassian Cloud Confluence pages, spaces, blog posts, comments, and labels. Cloud only.

Slack

Read-only access to Slack channels, DMs, threads, and workspace search via user token.

Notion

Notion pages and databases, with full read/write via public OAuth integration.

MCP

Connect any MCP-compatible server. User-pasted endpoints or admin-configured portal.

Email

Built on Cloudflare Workers Email. No OAuth setup required — provisioned automatically at deploy time.

Home Assistant

Self-hosted Home Assistant instances. Uses a long-lived token; no OAuth flow needed.

Supabase

Project-level OAuth for Supabase databases and edge functions.

ZoomInfo

Enterprise data enrichment. Contact ZoomInfo for credentials before configuring.

Scheduler

Auto-provisioned gatekeeper for persistent workspace callbacks. No setup required.

Cloudflare

Used for “Continue with Cloudflare” sign-in and AI Gateway billing. Not a data connector.

​
Installing a Gatekeeper

Gatekeepers are discovered by the router at startup by scanning its own service bindings. To install one, add the appropriate GATEKEEPER_* service binding to your router’s wrangler.jsonc:
wrangler.jsonc
{
  "services": [
    {
      "binding": "GATEKEEPER_GITHUB",
      "service": "gatekeeper-github"
    }
  ]
}
The binding name determines the gatekeeper’s vendor ID and must match the naming convention exactly. After adding the binding and configuring the gatekeeper’s own credentials (see each gatekeeper’s page), restart or redeploy the router. The new gatekeeper will appear automatically in the Connections UI.

​
Auto-Provisioned Gatekeepers

Two gatekeepers require no user action to set up:
  • Context Library (GATEKEEPER_CONTEXT) — automatically provisions a read session and management UI for every user. Administrators can create public context collections that are visible to everyone in the deployment; users can maintain their own private collections. No OAuth credentials to configure.
  • Scheduler (GATEKEEPER_SCHEDULER) — automatically provisions a singleton binding that agents use to register persistent workspace callbacks (cron-style scheduled tasks). The account is minted per-user with no OAuth flow.
Both gatekeepers declare autoProvisionsAccount: true in their vendor description, which tells the workshop to mint an account for each user automatically. Their mode can be set to enabled (forced on for all users), optional (user opt-in from the Connectors page), or disabled in the deployment admin panel.

Build docs developers (and LLMs) love

Get started for freeTalk to us