Cloudflare OS: agenter starter med null tilgang – og policy følger det de har sett

De fleste enterprise-AI-prosjekter starter baklengs: noen ber om API-nøkler, kobler en agent til tre systemer, og håper at «vi tar sikkerheten senere». Cloudflare snur rekkefølgen. I Cloudflare OS starter hver agent og app med tilgang til ingenting.

• august 2026 åpnet Cloudflare kildekoden til plattformen selskapet har brukt internt siden mai – en agent-workspace for hele organisasjonen, ikke bare utviklere. For norske CIO, CISO og styrer er dette mindre en produktlansering enn en arkitekturmal: hvordan gi agenter nok kraft til å gjøre jobb uten å gi dem nøkkelknippen til huset.

Hva Cloudflare OS faktisk er

Cloudflare beskriver Cloudflare OS som en åpen plattform for agenter, apper og arbeid – ikke et tradisjonelt operativsystem. Kjernen er tre deler:

• Agent workspace i nettleseren, med selskapets kuraterte kontekst og skills, pluss isolert runtime der agenten kan skrive og kjøre kode.
• Sikkerhets- og styringsramme for trygg tilgang til interne data og tjenester.
• Plattform for personlige, endringsbare apper som folk kan bygge, dele og fortsette å endre – full stack, ikke statiske prototyper.

Arbeidsflaten starter som en samtale, men kan bli dokument, regneark, presentasjon, live app eller workflow. Workflows kan kjøre on-demand, på schedule eller når noe skjer i et tilkoblet system. Målet er at ikke bare kode «fungerer eller ikke», men at resten av organisasjonen får samme type feedback-loop.

Lærdommen fra intern v1

Cloudflare ga hele selskapet tilgang i mai 2026. Tusenvis av ansatte – mange utenfor engineering – brukte det til dokumenter, slides, automatisering og små apper. Første versjon eksponerte et samarbeidsproblem de fleste AI-innkjøp fortsatt undervurderer:

MCP forteller hvilke verktøy en agent kan kalle. Det forteller ikke hvilke underliggende ressurser agenten har observert. Når folk deler workspace, apper og outputs, kan samarbeid bli en bakvei til data noen ikke skulle sett.

Derfor ble Cloudflare OS bygget om: sikkerhet må være plattformegenskap, ikke noe hver appbygger må implementere riktig.

Zero-trust for agenter: Gatekeepers og capability-bindinger

Cloudflare Access styrer hvem som kommer inn. Inne i plattformen starter agenter og apper blankt. En agent kan be om tilgang til en konkret ressurs; mennesket kan godta eller nekte. Generert kode mottar ressursen som en typet binding – for eksempel env.PROJECT.listIssues(...). Credentialen forblir isolert fra agenten og generert kode.

Serverkode kjører i Dynamic Worker med global outbound networking avskrudd. Klientkode kjører i sandboxed frame. Verken agent eller app når internett uten capabilities organisasjonen eksplisitt gir.

En Gatekeeper er en tjenestespesifikk Worker mellom Cloudflare OS og eksterne systemer. Den forstår API, ressurser og operasjoner. I stedet for «gi agenten hele GitHub-kontoen» kan en Gatekeeper gi tilgang til ett repo, lese issues men ikke kildekode, maskere felt, rate-limite, og kreve godkjenning før merge. Gatekeeperen håndterer OAuth, holder credentialen, håndhever policy, logger hva som ble lest, og medierer side effects som er synlige utad.

Policy følger det agenten har sett

Det kritiske grepet er observasjonsloggen. Når en agent har lest en sensitiv tabell og bygget et dashboard, må deling av dashboardet ikke bli deling av tabellen. Cloudflare OS knytter observasjoner til agenten og arbeidet. Når noen andre åpner workspace, snakker med agenten eller ser output, sjekker Gatekeepers om personen har tilgang til de observerte ressursene.

Samme logg kan også stramme inn videre handlinger: lesing av sensitiv data kan hindre skriv til visse kilder, nye samarbeidspartnere, handoff til annen agent, eller utgående kall. Det er arkitekturen som gjør «AI for alle» til mer enn en demo – og samtidig til et revisjonsspor styret kan forstå.

Apper er Workers, ikke slides med ekstra glitter

Når workspace bygger en app, skriver agenten klientkode og serverkode. Serveren lastes on-demand som Dynamic Worker og Durable Object Facet med egen SQLite. Browser snakker med server via Cap’n Web (Cloudflares åpne object-capability RPC). Agenten kan kalle de samme metodene som UI-et – så verktøy du bygger for deg selv, kan agenter kjøre når du ikke er der.

Deling skjer på to måter: del den levende appen (samme state), eller del en blueprint (kode uten data, historikk, credentials og tilkoblinger). Hver ny instans starter med uavhengig state. Det er den enterprise-vennlige versjonen av «fork the workflow».

Modellvalg og kostkontroll i samme gateway

Cloudflare OS kan bruke hvilken som helst modell. All inference går via Cloudflare AI Gateway: én plass for tillatte modeller, routing, budsjetter, rate limits og attribusjon til person, team eller workspace. Poenget er kjent for alle som har sett LLM-regningen: ikke alle oppgaver fortjener frontier-pris.

Open source, to repoer, partnere for utrulling

Kildekoden ligger på GitHub: cloudflare/cloudflare-os og starter/deployment cloudflare/cloudflare-os-starter. Deployment-repoet skal konsumere core uten å patche den – plass for config, custom UI, interne Gatekeepers, analytics og pipelines.

Cloudflare peker på Presidio og Happy Cog som strategiske partnere for tilpasning og utrulling. Selskapet jobber også mot managed produkt i Cloudflare-dashboardet, containers for utviklerflyt, og workspace i Slack og andre chatverktøy.

Hvorfor dette treffer norske ledere nå

• Agenttilgang er det nye IAM-problemet. Nøkler i chat og brede MCP-tilganger skalerer dårlig og auditeres dårlig.
• Deling er dataeksponering. Når AI-output deles, må policy følge observerte kilder – ikke bare opprinnelig tool-call.
• Zero-access default er en styringsstandard. Det er enklere å forsvare overfor styret enn «vi stoler på at agenten er snill».
• Kost og modellvalg hører hjemme i kontrollplanet. AI Gateway-mønsteret er relevant også utenfor Cloudflare.
• EU/compliance-vinkelen er åpenbar. Observasjon, tilgang og side effects er råmateriale for internkontroll, leverandørstyring og hendelsesetterforskning.

Cloudflare OS er ikke «enda en chatbot for ansatte». Det er et forsøk på å gjøre agentplattformen til noe organisasjonen eier: kontekst, skills, capabilities og sporbarhet. For ledere som skal skalere AI utenom pilotene, er spørsmålet ikke om dere bruker Cloudflare – det er om deres agentarkitektur har like harde svar på nulltilgang, credential-isolasjon og policy-som-følger-data.

Kilder og medier

• Primærkilde: Cloudflare OS: an open platform for agents, apps, and work — Cloudflare Blog, 5. august 2026
• source_url: https://blog.cloudflare.com/cloudflare-os/
• GitHub: https://github.com/cloudflare/cloudflare-os
• Starter: https://github.com/cloudflare/cloudflare-os-starter
• Thumbnail: OpenAI Image 2 / hogby.ai