Cloudflare OS getest: de sandbox zonder fetch is het beste idee in het project

Wat het is, en wat het niet is

Cloudflare OS is geen besturingssysteem en geen chatbot. Het is een werkomgeving waarin een agent applicaties voor je bouwt en aanstuurt, draaiend op de Workers-runtime. Cloudflare heeft het intern gebouwd en daarna vrijgegeven onder Apache-2.0. Je hebt geen Cloudflare-account nodig om het te proberen: workerd, de runtime eronder, is zelf open source en draait gewoon op je laptop.

pnpm run-local
# webinterface op http://localhost:8787, data in .wrangler/

Die laatste twee regels bepalen hoe je dit project moet lezen. Vijfduizend sterren en vijftien watchers: dit is geen community-project maar een intern Cloudflare-werktuig dat over de schutting is gegooid. Dat is niet erg — het is goed gereedschap — maar verwacht geen ecosysteem en reken er niet op dat jouw pull request landt.

Gadgets: applicaties die de agent ter plekke schrijft

Een gadget is een applicatie die de agent voor je maakt terwijl je erover praat. Geen template uit een bibliotheek, maar code die op dat moment wordt geschreven en meteen draait. Je kunt de code openen, aanpassen, en de instantie delen zoals je een document deelt.

Het interessante zit in wat een gadget niet mag. De sandbox waarin hij draait heeft geen internet. Letterlijk: fetch() werkt niet. De documentatie in de broncode is er onomwonden over — een gadget bereikt de buitenwereld uitsluitend via zijn bindings, de env-API van Workers.

Dat klinkt als een beperking en is in de praktijk de belangrijkste veiligheidsmaatregel van het hele project. Een agent die op internet mag, is een agent die een kwaadaardige instructie van een webpagina kan uitvoeren en het resultaat ergens heen kan sturen. Hier kan dat niet: de code kan alleen praten met wat jij expliciet hebt aangesloten. Wie wil weten hoe je meet of een opstelling daadwerkelijk bestand is tegen instructies die via inhoud binnenkomen, vindt de methode in indirecte prompt injection: weerbaarheid meten — het is precies de aanval waar deze architectuur een antwoord op is.

Gatekeepers: waar het echt om draait

Als gadgets niet naar buiten mogen, moet er iets zijn dat dat wél mag. Dat zijn de gatekeepers. Een gatekeeper is een tussenlaag met één externe dienst erachter — GitHub, Slack, Notion, Google, Linear, Supabase, Home Assistant, Spotify, e-mail, MCP-servers. In de repo zitten er zestien. Ze doen twee dingen tegelijk: ze geven de agent toegang, en ze houden bij wat hij ermee deed.

Het slimme zit in het goedkeuringsmodel. De meeste agent-tools doen dit synchroon: de agent stopt, jij krijgt een pop-up, jij klikt ja, de agent gaat door. Dat werkt niet zodra een taak twintig stappen heeft, want dan zit je twintig keer te klikken en klik je op stap zeven gedachteloos akkoord. Cloudflare OS draait het om: de agent voert uit, elke actie wordt vastgelegd met een type, en jij beoordeelt achteraf in bulk. Wat achteraf niet deugt, kun je terugdraaien.

Per actietype kun je bovendien automatische goedkeuring aanzetten. In mijn eigen opstelling heb ik dat gedaan voor precies één type: het starten van de dagelijkse nieuwsbrief. Alles anders vraagt nog steeds om een mens.

Ik heb een eigen gatekeeper geschreven om dat werkend te krijgen. Dat viel mee: een klasse met een paar methodes, een actietype met een label, en een implementatie van applyAction en rejectAction. De geplande taak die hem elke ochtend om zeven uur aanroept, draait sindsdien zonder tussenkomst. Wie zoiets liever met een kant-en-klare workflow-engine doet in plaats van met code, kan hetzelfde bereiken via lokale agentic workflows met n8n en Ollama; het verschil is dat je daar aan een grafische editor vastzit en hier aan TypeScript.

Waar het misging

De agent leverde een gadget die deed alsof

Mijn eerste poging om de nieuwsbrief-gadget te laten bouwen, leverde iets op dat er compleet uitzag: nette code, een keurige interface, een statusmelding dat de taak was ingepland. Alleen deed hij niets. De aanroep naar mijn gatekeeper was gesimuleerd — er stond een functie die een geloofwaardig antwoord teruggaf zonder ooit iets aan te roepen.

Dat is niet uniek voor Cloudflare OS — het is wat zwakkere modellen doen als een taak net te moeilijk is — maar het legt wel de zwakke plek van dit ontwerp bloot. De hele belofte is dat de agent applicaties voor je schrijft. De kwaliteit van die belofte is dus precies de kwaliteit van het model dat je eronder hangt, en niets in de interface waarschuwt je als dat model boven zijn macht grijpt. De tweede poging gooide alleen maar fouten; pas met een sterker model en exact voorgeschreven code kwam er iets bruikbaars uit.

Zes dubbele haken

Bij het inplannen van de dagelijkse taak bleken er zes vrijwel identieke hooks te zijn aangemaakt, allemaal actief. Eén ervan had een fatsoenlijke omschrijving, de rest was ruis van eerdere pogingen. Er is geen zichtbare bescherming tegen dubbel inplannen, dus het is aan jou om te controleren wat er daadwerkelijk staat te vuren. Bij een taak die elke ochtend een publicatieketen aftrapt, is zes keer vuren geen detail.

De kritische noot

Early access is hier geen bescheiden formulering. De repo zegt zelf dat er veel scherpe randen zijn en dat versie 2 een volledige herschrijving is. Reken op breuken.

Het is Cloudflare-vormig. Durable Objects, Dynamic Workers, Facets — de architectuur leunt zwaar op eigenschappen van het Workers-platform. Lokaal draaien werkt prima dankzij workerd, maar wie dit serieus in productie wil, komt vanzelf bij Cloudflare uit. Dat is een strategische keuze van de uitgever, geen toeval.

Geen bijdragen betekent geen ecosysteem. Zestien gatekeepers klinkt als veel, maar wat er niet bij zit, schrijf je zelf — en je krijgt het er niet in. Ik heb mijn eigen gatekeeper als lokale commit bovenop de repo staan, en dat blijft zo. Bij elke upstream-update mag ik zelf herstellen wat botst.

Wat ik niet heb getest. Uitrollen op Cloudflare zelf, meerdere gebruikers in één workspace, en de MCP-portal. Over kosten in de cloud doe ik dus geen uitspraak.

Voor wie is dit

Wel: je wilt agents dingen laten doen in echte systemen en je vindt de vraag “wie heeft hier ja gezegd” belangrijker dan de vraag hoe snel het gaat. Het goedkeurings- en terugdraaimodel is het beste dat ik in deze categorie heb gezien, en de sandbox zonder fetch() is een principiële keuze in plaats van een instelling.

Niet: je zoekt een kant-en-klare assistent, of je wilt bijdragen aan een open-source project. Het eerste is dit niet, het tweede mag niet.

Oordeel

Cloudflare OS lost een probleem op dat de meeste agent-tools omzeilen: hoe geef je een agent echte bevoegdheden zonder dat je hem blind moet vertrouwen. Het antwoord — een sandbox die niets mag, gatekeepers die alles loggen, en goedkeuring achteraf in bulk — is beter doordacht dan wat ik elders zie.

Daar staat tegenover dat het bouwen zelf onbetrouwbaar is zolang het model eronder niet sterk genoeg is, dat er geen bescherming zit tegen dubbel inplannen, en dat je aan een project vastzit waar je niets aan mag bijdragen. Het is gereedschap van iemand anders, uitgeleend. Uitstekend gereedschap — maar je bent geen mede-eigenaar.

Naast DeepSeek Harness gelegd valt het verschil in filosofie op. DSH maakt alles vervangbaar en laat de veiligheid aan jou; Cloudflare OS maakt de veiligheid onwrikbaar en laat het bouwen aan de agent. Wie een eigen stack neerzet, kan ze prima naast elkaar draaien: de harness om te bouwen, de gatekeepers om te bepalen wat er naar buiten mag.