A Cloudflare OS Gatekeeper Example: GA4 and Search Console Without the Keys
A concrete Cloudflare OS Gatekeeper example that fuses GA4 and Google Search Console into a fresh, read-only growth brief—without giving an agent permission to publish, deploy, or spend.
We did not give an agent access to Google Analytics, Search Console, a CMS, or a deployment command.
We gave it one read-only resource: a fresh growth brief.
That distinction is the useful part of a Cloudflare OS Gatekeeper. An agent can inspect evidence, identify a problem, and write a proposed next step. It cannot turn “this landing page is leaking traffic” into an unreviewed homepage edit, a blog post, or a production deploy.
This week we made that boundary concrete for Stackbilder. The source fuses the GA4 snapshot AEGIS already stores in D1 with a current Google Search Console snapshot. The result is a single authenticated endpoint with source freshness attached to the response.
The first live read returned this:
{
"status": 200,
"freshness": "fresh",
"ga4_snapshot_at": "2026-08-05T08:00:59.685Z",
"gsc_generated_at": "2026-08-06T01:02:26.092Z",
"gsc_window": {
"start": "2026-07-06",
"end": "2026-08-03"
},
"queries": 25
}
That is small by design. A trustworthy agent interface should be smaller than the systems behind it.
A Cloudflare OS Gatekeeper example for GA4 and Search Console
Cloudflare OS introduces Gatekeepers as the capability boundary between an agent and a service. The important question is not whether an agent can call an API. It is which resource it is allowed to observe, which side effects it can propose, and which ones remain impossible.
Our resource is a Stackbilder growth workspace:
interface GrowthWorkspace {
getLatestBrief(): Promise<GrowthBrief>;
getEvidence(): Promise<GrowthEvidence>;
proposeActions(actions: ProposedAction[]): Promise<ActionProposal>;
}
The interface deliberately does not contain publishPost, updatePage, deploy, sendEmail, or spendCredits.
That sounds obvious until you look at a typical “analytics agent” integration. A token with access to the reporting API often sits next to tokens for the rest of the growth stack. The agent gets a broad tool and a prompt saying “be careful.” Prompts are not a capability boundary.
We learned the same lesson when we built the safeguards around autonomous code changes. In How Do You Trust an AI Agent to Modify Production Code?, the answer was not to trust the model more. It was to put hard stops around the model. Our confidence-boundary routing follows the same principle for reasoning: decide where the system is allowed to spend attention before it starts reasoning.
A growth assistant needs the same architecture. Reading is useful. Publishing is consequential. They should not be the same permission.
The fused GA4 and Search Console source
GA4 and Search Console answer different questions.
GA4 tells us what happened after a visit. Search Console tells us what Google showed before a visit. A traffic spike without the query context is incomplete. A ranking report without on-site behavior is also incomplete.
AEGIS already receives a daily GA4 snapshot in Cloudflare D1. The snapshot contains a seven-day window, top pages, source/medium rows, bounce rate, and generated observations. Search Console is collected separately through the Search Analytics API, using local Application Default Credentials with read-only scope.
The local collector does one narrow job:
node web/scripts/seo-positioning-data.mjs --publish
It reads Search Console, validates the result, and sends a redacted snapshot to AEGIS. The Google credential stays on the operator machine. It never becomes a Worker secret. It never becomes a Gatekeeper capability. The Worker stores the snapshot next to the existing analytics data and exposes one protected read route:
GET https://aegis.stackbilt.dev/api/growth/stackbilder
The response carries a freshness value. That field matters more than it looks.
A fusion endpoint that silently combines yesterday’s GA4 data with a month-old Search Console export will sound authoritative while being wrong. Our response is only fresh when both sources are within 48 hours. It becomes partial when GA4 is current but Search Console is absent. It becomes stale when the analytics snapshot is too old.
That is an operational contract, not decorative metadata.
The first current brief showed 82 GA4 sessions versus 29 in the prior seven-day window. It also showed a 91% bounce rate and 16 Google organic sessions. Search Console showed the img-forge quickstart earning 55 impressions at an average position of 28.1. None of those numbers proves a product decision on its own. Together they are enough to frame a specific question: are visitors who arrive through the homepage finding a useful path into img-forge?
This is where a fused source earns its keep. It narrows the conversation from “do more SEO” to “test the path between the page receiving traffic and the product page earning impressions.”
The visual: evidence in, proposal out, execution blocked
The post’s central visual is not a dashboard. It is the permission boundary.
GA4 daily snapshot ─┐
├── AEGIS fused growth brief ──┐
Search Console ─────┘ │
▼
Growth Gatekeeper
│
observes evidence ─────┤───── proposes a weekly plan
│
└───── publish / deploy / spend: blocked
│
▼
human review
A more concrete version looks like this:
┌──────────────── Growth brief · Stackbilder ────────────────┐
│ GA4: fresh Search Console: fresh │
│ 82 sessions · +183% week over week · 91% bounce │
│ img-forge quickstart: 55 impressions · position 28 · 0 CTR │
│ │
│ Proposed action │
│ Audit the homepage → img-forge path and rewrite the │
│ quickstart's title and meta description for the observed │
│ image-generation queries. │
│ │
│ Status: PROPOSED │
│ Content publishing, deployment, spending, and messaging │
│ are unavailable to this capability. │
└──────────────────────────────────────────────────────────────┘
The card demonstrates the value without pretending that a recommendation is an accomplishment. The useful artifact is a reviewable plan tied to cited evidence.
That distinction connects to The Feedback Loop That Fixed Itself. A system improves when it can retain and inspect what happened. It becomes dangerous when its observation loop is also an unbounded execution loop.
What failed before the source became useful
The first time we ran the Search Console publisher, it failed with a 404.
The publisher had valid local credentials. The endpoint did not exist in production yet.
That failure was helpful. It separated four states that are often collapsed into “the integration works”:
1. Google Search Console authentication works locally.
2. The collector can form a validated snapshot.
3. AEGIS has a deployed ingestion route.
4. The fused resource returns current data to an authorized caller.
After the Worker route was deployed, an unauthenticated request returned 401. That was the expected intermediate result. The path existed, but it was not public. The authenticated publisher then returned:
Published Search Console snapshot to AEGIS (stored).
The next read returned fresh.
This is mundane infrastructure work. It is also the work that makes an agent claim believable. “Our agent uses GA4 and Search Console” means very little unless you can point to the collection boundary, freshness rule, authentication behavior, and actual response.
We have written about this kind of discipline from another angle in Cost-aware routing and tiered execution in serverless AI workloads. The recurring pattern is to make the selection rule explicit. Here the selection rule is authorization: the system can read one bounded resource and propose actions from it. It cannot choose to widen its own authority.
Why a read-only growth agent is worth building
A read-only agent is not a watered-down autonomous marketer. It solves a different and more useful problem.
Most growth work fails before execution. The hard part is deciding which signal deserves attention this week. A good brief can combine a ranking change, a click-through gap, a traffic source shift, a high-bounce landing page, and a product page with early organic demand. It can turn that evidence into a short proposal with links back to the source rows.
The human then decides whether the proposal deserves work.
That is also why we are not claiming the approval queue is finished. The current implementation has the read-only source and the proposal contract. A future Cloudflare OS Gatekeeper phase can use its approval mechanisms for a simulated action and a human decision. It should not skip straight to execution.
The boundary gives us a clean story to test:
We let an agent see the growth evidence, but not act on the world. It could finish a proposed weekly plan; a human approved any follow-up separately.
If that loop produces better decisions, we can expand it deliberately. If it produces generic advice, the failure is contained to a draft plan. No landing page changed. No customer received an email. No deployment happened because an agent saw a chart.
That is the standard we want for agent access: useful enough to make a decision, narrow enough to survive a bad one.
AEGIS is Stackbilt’s agent system on Cloudflare Workers. The growth source is built on Cloudflare D1 and Google Search Console’s Search Analytics API. Cloudflare OS is open source at github.com/cloudflare/cloudflare-os.