What Is Cloudflare OS Gatekeeper? Connecting AI to Internal Data Safely
In brief: Connecting GitHub, Google Workspace, Notion, a CRM and internal databases all at once, on the assumption that more data always makes AI smarter, can erase the boundary between information AI may read and information it may change. Cloudflare OS places Gatekeeper between AI and internal systems instead of giving the AI an API key directly. Gatekeeper acts as the intermediary.
Gatekeeper is the AI’s reception desk
The official README describes Gatekeeper as something close to an enhanced MCP server. Its job is broader than merely making an API callable. It has five principal responsibilities.
- Connect through the user’s own account: Use OAuth or a similar method to reach an external service with the employee’s permissions.
- Convert the service into an API that AI can use effectively
- Narrow access to the necessary scope: Limit it to specified repositories or documents.
- Record what was read and which operations were performed
- Do not apply externally consequential changes until a person approves them
Gatekeeper is therefore both the place where AI receives tools and the place that limits how far those tools may reach.
Grant access to a resource, not an entire account
A conventional AI integration may configure an MCP server or API key once and then reuse broad permissions throughout later conversations. Cloudflare OS works in the opposite direction. Agents and Gadgets initially have no access to external services. A user introduces the resources required for a task one by one.
Public implementations can, for example, select resources at the following levels.
| Service | Resource scope |
|---|---|
| GitHub | Scope: Repository, issue or pull request |
| Google Docs | Scope: A specific document |
| Google Sheets | Scope: A specific spreadsheet |
| Google Calendar | Scope: A specific calendar |
| BigQuery | Scope: A project, narrowed further to datasets or tables where needed |
| Notion | Scope: An entire workspace or specific pages and databases |
| Supabase | Scope: An entire organisation or a specific project |
Connecting GitHub does not mean an agent can freely touch every repository. The design grants the capability “use only this repository for this task”. Rather than listing users in a conventional permissions table, it hands over the resource required for the work. Cloudflare OS describes this as capability-based access control.
OAuth permissions and the AI’s usable scope are different
This distinction is easy to miss. An external service’s OAuth screen may show permissions that are comparatively broad because the implementation needs them technically. The public GitHub integration, for example, requests the repo permission when connecting. Gatekeeper then narrows actual use to introduced repositories, issues and pull requests.
An OAuth consent screen alone cannot establish safety. Review both layers.
- The permissions the external service grants to the OAuth token
- The resources and operations Gatekeeper actually exposes to an Agent or Gadget
Gatekeeper manages OAuth tokens and does not pass them directly to Agents or Gadgets. Its UserAccount design stores, refreshes and revokes connection information for each user. Production adoption should go beyond “OAuth works” and review Gatekeeper’s resource scope and operation APIs.
Do not treat reads and writes alike
Gatekeeper divides interactions with external systems into two broad categories.
Read: Observation
Reading a document, searching issues or running a SELECT query does not change external state. Public implementations pass a result through authorizeObservation() before returning it and record what was read.
Write: Action
Creating an issue, editing a document, changing a calendar event or writing to a database changes external state. The operation goes to submitAction() and is not applied until a person approves it and applyAction() is called.
“Record reads; approve writes” gives operators a much clearer basis for policy.
Keep AI working while approval waits
Conventional approval flows have a practical weakness. If an AI must stop after every proposed change, a long task stalls at its first operation. If teams respond by enabling automatic approval, safety declines.
Cloudflare OS Gatekeepers can apply an unapproved operation provisionally in local state. If an AI changes an issue title and then drafts a comment based on that title, for example, Gatekeeper returns a view in which the title appears changed. The AI can continue, while the real GitHub issue remains untouched.
When the work is complete, a person can approve or reject operations individually or in a batch. The design does not make the work wait; it makes only the external effect wait.
Three good first connection patterns
A first rollout does not need to connect every internal system. Begin with work whose scope is clear and whose failures are easy to inspect.
1. GitHub: organise issues in one repository
Limit the scope to one repository. Start by reading issues and pull requests, then expand to drafting comments, changing labels and creating issues. If merge operations are allowed, use a separate approval rule.
2. Google Docs / Sheets: read one document
Google OAuth scopes differ by service. Google Docs can read and write a selected document, but the public Google Sheets implementation is read-only. Google Drive metadata permission supports the resource-selection screen. Test the service and operation separately—“edit Docs” or “read Sheets”—rather than treating “connected to Google” as a single capability.
3. Supabase: analyse one project in read-only mode
Begin with query(), limited to SELECT and schema inspection. Add execute() only when writing becomes necessary, then verify human approval and duplicate-operation safeguards. Connecting one project rather than the whole organisation creates a boundary that is easier to explain.
Separate Context from live system connections
Cloudflare OS also provides Gatekeeper Context as a home for organisational knowledge. Agents can search, list and read Markdown, text, JSON, CSV, code, images and PDFs stored in collections. Public collections and private personal collections are separate, and a configuration that synchronises from Git-compatible storage is available.
Context and operational-system connections serve different roles.
- Context: Read company rules, procedures, terminology and prior decisions
- External Gatekeeper: Read, and where appropriate change, the current state of GitHub, Notion, Google, databases and other systems
Reference documents that an AI should always consult may be easier to manage in Context than to retrieve through an API every time. Current opportunities, customer records and other information that must always be checked at source should remain connected to the system of record.
Connection procedure
These steps assume that the deployment guide has already been completed.
1. Choose one workflow
“Enable Google Workspace” is too broad. Narrow it to a sentence such as this.
Example: Before the sales meeting, read a specified spreadsheet and summarise opportunities that have no follow-up
Use this sentence to define the target data, read scope, output and need for human approval.
2. Select the appropriate Gatekeeper
The public repository includes Gatekeeper implementations for GitHub, Google, Notion, Supabase, Slack, Linear, Confluence, the Cloudflare API and other services. If the service you need is absent, build an internal implementation on the Starter’s packages/custom-gatekeeper. Do not assume support from the service name alone; verify the public implementation.
3. Create your organisation’s OAuth application
Create an OAuth application in the administration screen for GitHub, Google or the relevant service. Make the callback URL match the format documented by that Gatekeeper exactly.
https://<your Cloudflare OS URL>/gatekeeper/github/oauth
https://<your Cloudflare OS URL>/gatekeeper/google/oauth
Do not put the Client ID or Client Secret in a Git-managed deployment.jsonc or wrangler.jsonc file. Register them as secrets used by the Gatekeeper Worker.
4. Enable connectors gradually in /admin
The administration screen controls which connectors employees see and how they are provisioned. Enable only the one under evaluation and leave the rest disabled. Test whether one workflow completes safely, not how many services can be connected.
5. Introduce one resource
Paste the resource URL into Cloudflare OS or select it from the connection screen: one GitHub repository, one Google document or one Supabase project.
6. Test reading, writing and sharing separately
- Is the read result correct?
- Is the Observation recorded?
- Does a write remain unapplied externally before approval?
- Do approval and rejection behave as expected?
- Can someone with whom the Gadget is shared see data they should not be able to access?
The last check is especially important. Cloudflare OS Gatekeepers can use a Verifier to confirm that each collaborator can access the same source data. Implementations may also prevent highly personal data such as Gmail content from being exposed to collaborators.
Six decisions to record for every connection
Keep the following six items in a single register for each connection.
- Who will use it?
- Which service will it connect to?
- Which repositories, documents or projects will it use?
- Which reads and writes are allowed?
- Which operations require human approval?
- Who reviews the logs, and when?
You also need a rule that excludes API keys, OAuth secrets, model prompts and the internal documents themselves from logs.
The goal is not to describe “what AI can do” in the abstract, but to explain whose work it performs, which resources it may touch and which operations it may carry out. Good integration does not expose all company data; it grants only the resources and operations a specific task requires.
Sources
We can support permission design, approval workflows and development of an organisation-specific Gatekeeper.
Discuss adoption