Hands-on: Cloudflare OS een maand later — wat er van de Gatekeepers overbleef

Door Ivo Donker — samengesteld met AI-ondersteuning · Laatst bijgewerkt: 8 augustus 2026

Dit artikel is de tweede aflevering van het reviewgenre op radar, pijler 2 van de canon: eigen infrastructuur, homelab en edge. De hands-on review van Cloudflare OS verscheen op 6 augustus, één dag nadat Cloudflare zijn interne AI-werkomgeving open source had gemaakt. Dat stuk eindigde met drie open punten: de afwijzings-cascades van de Gatekeepers verschillen per implementatie zonder uniform contract, de architectuur van onafhankelijk deploybare Gatekeepers was nog niet uitgewerkt, en het strenge observer-mechanisme moest zich in de praktijk bewijzen. Deze tweede aflevering kijkt wat er sindsdien is gebeurd. De tussenstand is kort: op 7 augustus kwamen vier commits binnen in de repository, en die raken twee van de drie punten — maar niet het scherpste.

De stand van de code

De review beschreef commit 5ea3bcd van 5 augustus. De hoofd-tak staat inmiddels op 1cb5e3d9 (7 augustus, 21:07 UTC). Tussen die twee staan vier nieuwe commits, allemaal van 7 augustus:

Dat zijn geen cosmetische wijzigingen, maar ook geen herschrijving van de beveiligingslaag. De codeverwijzingen uit de review kloppen nog — dat is hieronder per punt uitgewerkt. Wie de juli-editie over Cloudflare Workers voor AI-bouwers heeft gelezen, herkent de context: dit platform is een van de snelst bewegende onderdelen van de Workers-stack, en de eerste week na open-sourcing is daar geen uitzondering op.

Het gat dat er nog staat: het cascade-contract

De scherpste bevinding uit de review was dat er geen uniform, afdwingbaar contract bestaat voor wat er gebeurt als je een gesimuleerde actie afkeurt. De GitHub-Gatekeeper cascadeert actief: het afwijzen van een voorlopige actie verwijdert de afhankelijke wachtende acties en geeft restart: true terug, zodat de agent opnieuw begint in plaats van door te modderen op een fictie. De Supabase-Gatekeeper cascadeert niet: een afgewezen actie verdwijnt simpelweg uit de wachtrij, omdat er geen simulatiestatus is om terug te draaien. Beide keuzes zijn verdedigbaar voor hun eigen domein, maar het ontbreken van een gedeeld raamwerk betekent dat wie zelf een Gatekeeper schrijft zijn eigen afhankelijkheidsredenering moet bouwen — of vergeet.

Dat beeld is onveranderd. In de huidige hoofd-tak staat #rejectReplyDependencyChain() nog steeds in packages/gatekeeper-github/src/github.ts (regel 1979; in de review was dat regel 1984 — regelnummers zijn verschoven, de code niet), en de restart: true die een herstart afdwingt staat er nog (regel 3489). Ook het plafond van vijftig wachtende acties staat er nog: MAX_PENDING_ACTIONS = 50 in packages/mcp-shared/src/action-store.ts (regel 11), met de weigermelding wanneer het vol zit. Geen van de vier nieuwe commits raakt dit contract.

Wie zelf met agent-runtimes werkt, weet waarom dit ertoe doet: de cascade is de plek waar een beveiligingslaag zijn voorspelbaarheid bewijst. De beveiliging van agent-runtimes behandelt precies deze vraag — wat mag een agent, wie controleert achteraf, en wat gebeurt er bij afwijzing — en Cloudflare OS is daar een concrete implementatie van. De conclusie blijft: dit is een ontwerpgat, geen bugfix, en een week is geen termijn waarin ontwerpgaten dichtgaan.

Nieuw: een preinstall-route voor ambient Gatekeepers

Wel nieuw is dat de release-kant van de Gatekeeper-architectuur concreet wordt. De review noteerde dat Cloudflare schrijft dat Gatekeepers onafhankelijk deployen voor zich ziet, "but the details have yet to be worked out". Commit 8a198d0a zet daar de eerste stap in, in scripts/release/manifest-lib.mjs.

De deploy-service krijgt een lijst met "ambient Gatekeepers" die hij bij elke verse kern-deploy server-side installeert, zonder gebruikersinteractie: gatekeeper-context en gatekeeper-scheduler. De eisen zijn hard en worden in de code afgedwongen: leden van die lijst mogen geen enkele input vragen, en ze mogen hooguit één keer per instantie geïnstalleerd worden — een tweede installatie zou elke gebruiker een dubbele ambient-capsule geven. Het manifest maakt ook zichtbaar welke Gatekeepers zonder externe OAuth-app kunnen (context, homeassistant, scheduler, mcp en mcp-portal), welke niet installeerbaar zijn (gatekeeper-email) en welke binding uit klant-manifests wordt geknipt omdat die nog in closed beta zit (gatekeeper-context en zijn Artifacts-binding; de Gatekeeper degradeert dan netjes in plaats van te falen).

Voor de bouwer met een eigen stack is vooral relevant dat gatekeeper-homeassistant in de groep zonder derde-partij-OAuth zit: wie zijn eigen Home Assistant-URL en -token invult, heeft geen Cloudflare-app nodig. Dat sluit aan bij het signaal uit de juli-editie over homelab en self-hosted AI — Cloudflare richt zich met dit onderdeel nadrukkelijk op mensen die eigen diensten koppelen in plaats van een kant-en-klare SaaS-stack te integreren.

De eerste reparatie aan het observer-mechanisme

Het tweede open punt uit de review was het observer-mechanisme, en dit is het punt waar de eerste echte reparatie is gekomen. In docs/observers.md staat het principe: als Bob een gedeelde gadget opent van Alice, moet Bob voor elke Gatekeeper een eigen verbonden account opgeven, en elke Gatekeeper controleert of dat account voldoende rechten heeft om alles te lezen wat de gadget via die Gatekeeper ooit heeft gelezen. Doet de gadget daarna een nieuwe leesactie waar minstens één geregistreerde kijker geen rechten voor heeft, dan wordt die actie geblokkeerd; bij elke opening wordt de toegang opnieuw gecontroleerd. De onderliggende invariant is dat delen nooit informatie kan lekken die de ontvanger niet al mocht zien.

Commit c6d8999f (7 augustus) repareert een situatie die dit strenge principe in de praktijk oplevert: iemand ontvangt een gedeelde gadget waarvan de verificatie OAuth-scopes nodig heeft die zijn verbonden account nog niet heeft. De fix breidt de scopes uit wanneer dat nodig is, in plaats van de toegang botweg te weigeren. De wijziging zit in packages/workshop-frontend/src/ObserverConfigModal.tsx en heeft een bijbehorende testuitbreiding (+114/−10 regels in de testfile).

Dat is een geruststellende richting: het mechanisme wordt niet afgezwakt maar werkbaar gemaakt. Het blijft strenger dan wat de meeste bedrijfssoftware doet, en de reparatie gaat over de ergonomie van het delen, niet over de beveiligingsgrens zelf.

De GitHub-Gatekeeper is in beweging, maar niet op de cascade

Commit 16a626df raakt het bestand waar de review de actieve cascade vond: packages/gatekeeper-github/src/github.ts (+26/−17). De wijziging gaat echter over iets anders: de repository-scope van GitHub-issue-zoekopdrachten. Er komt een nieuw bestand github-search.ts bij en een testbestand (github-api.test.ts, +103 regels) dat de zoekopdracht-afhandeling dekt. Ook het storage-schema wordt met één regel bijgewerkt.

Dat is goed nieuws voor de kwaliteit van de code — de GitHub-Gatekeeper is de enige met een serieuze testopzet — maar het bevestigt ook het tegenovergestelde van wat je zou hopen: de cascade-logica zelf is niet aangeraakt. Wie wil zien dat het afwijzingscontract veralgemeniseerd wordt, moet nog even wachten.

Observability rond Durable Object-resets

De vierde commit, 1cb5e3d9, gaat over de ruggengraat van het systeem. Cloudflare OS draait op Workers en Durable Objects, en deze commit is een voorbeeld van hoezeer dat platform in beweging is. De wijziging herstelt de zichtbaarheid van API-sessie-aborts: sinds een eerdere commit werd ctx.abort() vervangen door een WebSocket-close, waardoor aborts niet meer als zodanig werden gelogd. Daarnaast komt er een tracing-module bij en wordt de overseer — de component die over wachtende acties waakt — robuuster gemaakt bij resets (+36/−15 in overseer.ts), met bijbehorende wijzigingen in de serverconfiguratie.

Voor de vraag uit de review — wat gebeurt er met een keten van tien acties als je stap drie afkeurt? — is dit geen antwoord, maar wel relevant: het systeem houdt beter bij wat er bij een reset verloren gaat en waarom. Dat is de ondergrond waarop een toekomstig cascade-contract zou moeten rusten. Wie ooit een agentic loop heeft moeten debuggen weet dat dit soort zichtbaarheid het verschil maakt tussen een reproduceerbaar probleem en een mysterie.

Wat dit betekent voor de zelf-hoster

De praktische route is niet veranderd. De README zegt nog steeds dat pnpm run-local "not meant for production use" is, en de sectie "Deploy to your own server using workerd" staat nog steeds op COMING SOON — geverifieerd op de hoofd-tak van 8 augustus (HEAD 1cb5e3d9). Wie het vandaag serieus wil draaien, deployt naar een eigen Cloudflare-account. Dat was het antwoord in de review en dat blijft het antwoord.

De repository bevat nog steeds 16 Gatekeepers, waarvan mcp, mcp-portal, context, scheduler en email geen directe externe koppeling zijn; het aantal échte externe diensten ligt rond de tien. Het facturatiemodel is onveranderd eerlijk: standaard geen limiet en geen rekening voor zelfgehoste installaties, en bij ingeschakelde facturatie gaat het verkeer over het eigen Cloudflare AI Gateway-tegoed. Voor wie een LLM-gateway zelf host is dat nog steeds relevant: de zelfhost-route wordt niet kunstmatig onaantrekkelijk gemaakt, en dat is in deze markt een opvallende keuze die standhoudt.

Het oordeel, een week later

De balans is verrassend stabiel. De belofte uit de review — "ik werk dit bij zodra ik meer weet" — is met deze tweede aflevering ingelost. Het scherpste punt, het ontbrekende cascade-contract, staat er nog precies zo bij. Dat is de eerlijke conclusie: dit is een ontwerpgat, en de eerste week na een open-sourcing is geen termijn waarin ontwerpgaten dichtgaan.

Wat wel veranderde is de ondergrond. De preinstall-infrastructuur maakt de Gatekeeper-architectuur concreet, het observer-mechanisme kreeg zijn eerste praktische reparatie zonder verzwakking, en de GitHub-Gatekeeper kreeg een echte testopzet. Wie een MCP-gebaseerde tooling-laag bouwt of agent-runtimes in eigen beheer draait, herkent het patroon: de waarde van dit systeem zit niet in één commit maar in de richting die de commits samen aangeven.

Wat ik graag als volgende zou zien, is concreet: een cascade-contract dat het GitHub-gedrag (actief afwijzen, herstart afdwingen) veralgemeniseert, een test die afwijkingsketens over meerdere Gatekeepers dekt, en documentatie voor wie zelf een Gatekeeper schrijft. Tot die drie er zijn, blijft de conclusie van de review overeind: dit is een serieuze poging tot een derde weg tussen "constant onderbroken worden" en "alles toestaan", maar de zorgvuldigheid hangt nog af van degene die de Gatekeeper schrijft.