Cloudflare představil open-source verzi platformy Cloudflare OS – interního nástroje, který si firma sama vyvinula a nyní jej nabízí komukoliv k nasazení na vlastním účtu. Cílem je dát každému zaměstnanci ve firmě AI agenta a pracovní prostor, který rozumí tomu, jak organizace funguje, jakou má terminologii, procesy a interní systémy – a umí s nimi bezpečně pracovat.

Od interního experimentu k open-source produktu

Cloudflare nasadil první verzi Cloudflare OS interně už v květnu letošního roku. Podle autorů ji dnes denně používají tisíce lidí napříč firmou, a to zdaleka nejen vývojáři – ke tvorbě dokumentů a prezentací, automatizaci opakujících se úkolů i k stavbě jednoduchých aplikací pro vizualizaci dat.

Součástí první verze byla i sdílená knihovna kontextu a „skillů“ – instrukcí popisujících osvědčené postupy pro konkrétní úkoly, kterou průběžně doplňovaly týmy napříč firmou. Když někdo přišel na lepší způsob, jak něco udělat, mohli ho použít i ostatní.

Provoz první verze ale odhalil zásadní problém v oblasti bezpečnosti. Přístup k MCP serveru sice řekl, jaké nástroje agent smí volat, ale už ne, jaká konkrétní data si agent při té příležitosti skutečně prohlédl. Jakmile lidé začali sdílet pracovní prostory, aplikace a výstupy mezi sebou, hrozilo, že se přes sdílení dostanou k datům, ke kterým by jinak přístup neměli. To vedlo Cloudflare k tomu, že platformu prakticky postavili znovu, tentokrát s bezpečností jako integrální součástí návrhu, ne jako něčím, co musí správně ošetřit každý autor aplikace zvlášť.

Tři stavební kameny platformy

Nová, otevřená verze Cloudflare OS stojí na třech pilířích:

• Pracovní prostor agenta – zasazený do kontextu a skillů, které si firma sama definuje, s izolovaným runtime prostředím, kde agent může psát a spouštět kód.
• Bezpečnostní a governance vrstva – pro řízený přístup k interním datům a službám.
• Platforma pro osobní, upravitelné aplikace, které lidé mohou stavět, sdílet a dál rozvíjet.

Z jedné konverzace se tak může postupně stát dokument, aplikace nebo workflow, které dál vykonává práci samo.

Co agent workspace umí

Pracovní prostor kombinuje konverzaci s agentem, perzistentní stav, výstupy a soubory, přístup ke zdrojům a izolovaný runtime pro spouštění kódu. Nabízí se v prohlížeči, takže k práci s ním není potřeba být vývojář ani znát příkazovou řádku.

Mezi typické scénáře patří:

• Research a dotazování – agent píše kód, kterým data filtruje, spojuje a analyzuje, místo aby si celý dataset natahoval přímo do kontextového okna modelu.
• Tvorba dokumentů, prezentací a tabulek, které nemusí zůstat statické – mohou zůstat napojené na živá data a zároveň jít exportovat do běžných formátů nebo služeb jako Google Drive.
• Kolaborativní aplikace s vlastním rozhraním, logikou a stavem, na kterých může pracovat víc lidí zároveň.
• Deterministická workflow – ne každý úkol potřebuje plnohodnotnou agentní session. Řadu úkolů lze převést na v zásadě deterministickou posloupnost kroků, kde model rozhoduje jen tam, kde to má smysl, a workflow se pak spouští na vyžádání, podle plánu, nebo jako reakce na událost v napojeném systému.

Agenti a aplikace přitom mají řízený přístup k systémům přes takzvané Gatekeepery (viz níže) a platforma zároveň podporuje existující servery MCP (Model Context Protocol), které firma už používá, a to přes takzvané MCP Server Portals.

Bezpečnostní model: nulová důvěra jako výchozí stav

Cloudflare v článku otevřeně pojmenovává problém, který podle nich řeší většina firem experimentujících s AI špatně: lidé chtějí agentům rovnou dát API klíče k firemním systémům. To je pochopitelné, bez přístupu k datům je AI v práci k ničemu, ale zároveň je to nebezpečné a neškáluje se to. Klíče totiž bývají široké, dlouhodobě platné a špatně se auditují.

MCP tento problém částečně řeší – server drží přihlašovací údaje a agentovi vystaví jen definovanou sadu nástrojů. Jenže samotné řízení toho, jaké nástroje smí agent volat, neřeší otázku, co všechno agent při té příležitosti reálně viděl a kam se ta informace dál může dostat.

Přístup od nuly a typované bindingy

V Cloudflare OS začíná každý agent i aplikace s nulovým přístupem ke čemukoliv. Agent si musí o přístup ke konkrétnímu zdroji požádat, a teprve po schválení dostane vygenerovaný kód typovaný binding, například:

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});Code language: JavaScript (javascript)

env.PROJECT představuje oprávnění použít konkrétní zdroj podle konkrétní politiky – samotné přihlašovací údaje zůstávají od agenta i vygenerovaného kódu zcela izolované. Serverový kód běží ve „Dynamic Workeru“ bez přístupu k internetu, klientský kód pak v sandboxovaném frame v prohlížeči – ani jeden se ven nedostane jinak než přes explicitně povolené capability.

Gatekeepery jako brána ke každé službě

Ke každé externí službě stojí mezi ní a Cloudflare OS takzvaný Gatekeeper – Worker specifický pro danou službu, který rozumí jejímu API, zdrojům a operacím, jež nad nimi lze provádět. Místo aby agent dostal přístup k celému GitHub účtu, může mu Gatekeeper povolit práci jen s jedním repozitářem, dovolit čtení issues bez přístupu ke zdrojovému kódu, maskovat vybraná pole, aplikovat rate limity nebo vyžadovat schválení před mergem pull requestu.

Agent a aplikace vidí jen malé TypeScript API. Gatekeeper na pozadí řeší OAuth, drží přihlašovací údaje, vynucuje politiku, zaznamenává, co bylo přečteno, a zprostředkovává cokoliv, co má navenek viditelný vedlejší efekt.

Politika, která sleduje, co agent už viděl

Klíčovou vlastností je, že řízení prvotního čtení dat nestačí. Pokud agent přečte citlivou tabulku z datového skladu a použije ji k vytvoření živého dashboardu, sdílení dashboardu nesmí ve výsledku znamenat obcházení přístupových práv k původní tabulce.

Cloudflare OS proto zaznamenává každý zdroj, který agent pozoroval, a tato pozorování zůstávají navázaná na agenta a jeho výstupy. Když se k pracovnímu prostoru nebo výstupu chce dostat další člověk, Gatekeepeři ověří, zda má přístup i k datům, ze kterých výstup vznikl. Stejný záznam pozorování zároveň řídí, kdy agent smí provést nějakou externí akci – čtení citlivých dat tak může agentovi zablokovat zápis jinam, pozvání dalšího spolupracovníka, předání práce jinému agentovi nebo odchozí požadavek.

Každá aplikace je Worker

V Cloudflare OS může být „soubor“ rovnou celou aplikací napsanou agentem pro jednoho člověka, projekt nebo tým – ne prototypem, který je potřeba někam exportovat a nasadit, ale plnohodnotnou full-stack aplikací s klientským i serverovým kódem, API a trvalým stavem. Aplikace jsou ve výchozím stavu soukromé, ale dají se sdílet podobně jako dokumenty.

Když agent na požádání staví aplikaci, vytváří dvě části: klientský kód pro UI v prohlížeči a serverový kód, který ukládá stav a implementuje logiku aplikace. Server se načítá on-demand jako Dynamic Worker a instancuje se jako Durable Object Facet – obě jsou to funkce, které Cloudflare pro tento projekt vyvinul. Facet dává aplikaci vlastní SQLite databázi oddělenou od runtime Cloudflare OS, a protože Dynamic Workery využívají odlehčené V8 izoláty, každá aplikace má vlastní izolovaný runtime bez nutnosti mít pro ni vyhrazený server nebo kontejner.

Komunikace mezi klientem a serverem jde přes Cap’n Web – open-source object-capability RPC systém od Cloudflare. Serverovou metodu lze z klienta zavolat jako běžnou JavaScriptovou funkci:

const issues = await app.listIssues({
  status: "done",
});Code language: JavaScript (javascript)

Podstatné je, že stejnou metodu může zavolat i agent – pokud si tedy uživatel postaví nástroj pro nějakou svou úlohu, agent umí ten samý nástroj použít i tehdy, když u toho uživatel není.

Aplikace lze sdílet dvěma způsoby: buď přímo (více lidí pak spolupracuje nad stejným stavem v reálném čase), nebo jako blueprint, ze kterého si další člověk vytvoří vlastní kopii se stejným kódem, ale bez dat, historie konverzace, přihlašovacích údajů či napojených zdrojů. Týmy tak mohou sdílené nástroje samy upravovat pomocí AI, místo aby zakládaly feature requesty.

Libovolný model a kontrola nákladů

Cloudflare OS není vázán na jediný model – každé volání inference jde přes Cloudflare AI Gateway, takže si organizace na jednom místě určí, jaké modely jsou k dispozici a který se má použít pro jaký úkol. Ne každý úkol totiž potřebuje nejdražší frontier model – ranní shrnutí nepřečtených e-mailů si takovou investici nezaslouží. Každý požadavek je navíc přiřazený konkrétní osobě, týmu nebo pracovnímu prostoru, takže administrátoři vidí, kam mizí výdaje za inference, a mohou nastavit rozpočty i rate limity.

Open source a partnerství

Zdrojové kódy jsou dostupné na GitHubu ve dvou repozitářích: cloudflare-os jako samotné jádro a cloudflare-os-starter jako ukázkové nasazení odpovídající tomu, jak si Cloudflare platformu provozuje interně. Nasazovací repozitář jádro pouze konzumuje, aniž by ho patchoval, a slouží jako místo pro vlastní konfiguraci, UI, interní integrace, analytiku a deployment pipeline.

Cloudflare zdůrazňuje, že samotný zdrojový kód je jen začátek – skutečnou hodnotu pro konkrétní firmu přinese teprve kontext, skilly, workflow a napojení na interní systémy. Proto firma spolupracuje se strategickými partnery Presidio a Happy Cog, kteří mají firmám pomáhat s přizpůsobením platformy, tvorbou vlastního UI, napojením interních systémů přes Gatekeepery a MCP Server Portals a nastavením bezpečnostních, model a nákladových politik.

Co dál

Cloudflare OS je dostupný ihned na GitHubu, nasadit ho lze na vlastní Cloudflare účet během několika minut pomocí startovacího repozitáře. Podle autorů firma dále pracuje na plně spravované verzi přímo v Cloudflare dashboardu, na kontejnerech pro vývojářská workflow a na integraci pracovních prostorů do Slacku a dalších chatovacích nástrojů.

Zdroj: Cloudflare Blog – Cloudflare OS: an open platform for agents, apps, and work