Cloudflare ha pubblicato il codice di Cloudflare OS, l’ambiente di lavoro con agenti AI sviluppato inizialmente per i propri dipendenti. Nonostante il nome, non è un sistema operativo destinato a sostituire Windows, macOS o Linux: è una piattaforma accessibile dal browser che riunisce conversazioni con gli agenti, conoscenza aziendale, strumenti interni, documenti, workflow e piccole applicazioni.
Cloudflare OS estende al resto dell’organizzazione il modello che gli assistenti di programmazione hanno già applicato allo sviluppo software. Per lavorare in modo utile, però, un agente aziendale non deve soltanto generare contenuti: deve conoscere terminologia, procedure e regole dell’impresa, accedere ai sistemi utilizzati dai dipendenti e rispettarne le autorizzazioni.
Per anni Cloudflare è stata conosciuta soprattutto per la CDN, il DNS e la protezione dei siti dagli attacchi informatici. Con l’introduzione di Workers nel 2017, la società ha però iniziato a trasformare la propria rete globale in una piattaforma programmabile, ampliata progressivamente con servizi di calcolo, archiviazione, database, networking Zero Trust e intelligenza artificiale. Oggi Cloudflare si presenta come una “connectivity cloud” per collegare, proteggere e costruire applicazioni, mentre Cloudflare OS estende questa evoluzione al lavoro quotidiano dei dipendenti e agli agenti AI: non più soltanto infrastruttura che trasporta e difende il traffico, quindi, ma anche un ambiente nel quale software e automazioni vengono creati ed eseguiti.
Nel maggio 2026 Cloudflare ha distribuito una prima versione del sistema a tutto il personale. Da allora, migliaia di dipendenti di funzioni diverse, non soltanto sviluppatori, la utilizzano quotidianamente per preparare documenti e presentazioni, automatizzare attività ripetitive e costruire applicazioni dedicate all’analisi e alla visualizzazione dei dati.
La versione resa pubblica è una riscrittura basata sull’esperienza maturata internamente. Il repository di Cloudflare OS, distribuito con licenza Apache 2.0, è già disponibile, ma Cloudflare lo definisce espressamente un progetto “early access”, ancora in pieno sviluppo e con diverse parti da perfezionare.
Un agente con il contesto dell’organizzazione
L’interfaccia iniziale ricorda quella di altri assistenti AI: l’utente apre una conversazione nel browser e assegna un compito. Ogni workspace comprende però sessioni con gli agenti, file, stato persistente, risorse autorizzate e un ambiente isolato nel quale il modello può scrivere ed eseguire codice.
L’organizzazione può aggiungere al sistema una raccolta condivisa di contesto e “skill”, cioè istruzioni che descrivono terminologia interna, procedure e modalità consolidate per svolgere determinate attività. Un processo messo a punto da una persona può quindi diventare una capacità riutilizzabile dal resto del personale, evitando di spiegare nuovamente al modello le stesse regole a ogni conversazione.
L’agente può cercare e analizzare informazioni, combinare dati provenienti da più fonti e trasformare il risultato in documenti, presentazioni o fogli di calcolo. Questi artefatti possono anche rimanere collegati alle sorgenti originali ed essere aggiornati quando cambiano i dati, pur conservando la possibilità di esportarli in formati più tradizionali o verso servizi come Google Drive.
Le attività composte prevalentemente da passaggi prevedibili possono invece diventare workflow deterministici. Il codice gestisce le operazioni ripetitive, mentre il modello viene coinvolto soltanto nei punti che richiedono valutazione. I workflow possono essere eseguiti manualmente, in base a una pianificazione o in risposta a un evento proveniente da un sistema collegato.
Ogni file può diventare un’applicazione
Uno degli elementi più originali di Cloudflare OS è il concetto di “Gadget”. Quando un documento o un foglio di calcolo non è sufficiente, l’agente può creare una piccola applicazione completa di interfaccia, logica server e stato persistente.
Ogni Gadget viene eseguito separatamente dagli altri. La parte server gira in un Dynamic Worker, mentre un Durable Object Facet assegna all’applicazione un database SQLite indipendente da quello impiegato per amministrare il runtime. Il client viene invece caricato in un frame isolato all’interno del browser.
La comunicazione tra client e server passa attraverso Cap’n Web, il sistema RPC open source di Cloudflare. I metodi esposti dall’applicazione possono essere richiamati sia dall’interfaccia sia dall’agente: uno strumento costruito per un dipendente può quindi continuare a essere utilizzato automaticamente dall’AI.
Le applicazioni sono private per impostazione predefinita, ma possono essere condivise per collaborare sullo stesso stato. In alternativa, l’autore può distribuire un “Blueprint”, una copia del codice dalla quale altri utenti creano una propria istanza. Il Blueprint non trasferisce dati SQLite, cronologia delle conversazioni, credenziali o risorse collegate.
Questo modello avvicina Cloudflare OS più a una suite per la produttività programmabile che a un semplice chatbot aziendale. Ogni artefatto può diventare un’applicazione su misura e gli utenti possono chiedere all’agente di modificarne il funzionamento senza attendere l’intervento del team che l’ha creata.
Gatekeeper, accesso minimo per agenti e applicazioni
Il problema centrale affrontato dalla nuova architettura è la sicurezza. Collegare un agente a un server Model Context Protocol permette di stabilire quali strumenti può chiamare, ma non basta a controllare ciò che accade alle informazioni lette attraverso quegli strumenti. Un agente potrebbe combinare dati provenienti da ambienti diversi o inserirli in un’applicazione condivisa con persone che non sono autorizzate a consultare le fonti.
In Cloudflare OS, quindi, ogni agente e applicazione parte senza accesso ad alcuna risorsa. L’utente può autorizzare un elemento specifico oppure accettare o rifiutare una richiesta presentata dall’agente. Il codice generato riceve una “capability”, vale a dire un collegamento tipizzato che rappresenta il permesso di utilizzare quella risorsa secondo una determinata policy. Le credenziali restano esterne sia al modello sia al codice che questo produce.
A mediare il collegamento sono i Gatekeeper, Worker specializzati per un singolo servizio. Un Gatekeeper può, per esempio, consentire di leggere le issue di un repository GitHub senza mostrare il codice sorgente, nascondere determinati campi, applicare limiti di frequenza o richiedere l’approvazione umana prima di un’operazione con effetti esterni.
La piattaforma registra inoltre le risorse osservate dall’agente. Queste informazioni rimangono associate al workspace e ai risultati generati: quando un’altra persona tenta di aprire una conversazione, usare un’applicazione o consultare un output, il Gatekeeper può verificare che disponga dei permessi necessari anche sulle fonti originarie.
La stessa cronologia può influire sulle azioni successive. Dopo aver letto dati sensibili, per esempio, a un agente potrebbe essere impedito di inviarli verso un sistema meno protetto, aggiungere collaboratori o effettuare una richiesta di rete non consentita.
Il server di un Gadget viene eseguito con le connessioni in uscita disattivate e può raggiungere l’esterno soltanto attraverso le capability autorizzate. Il codice client è invece limitato dalle policy di sicurezza del browser e dalla sandbox del frame. È un’impostazione “deny by default” interessante, anche se le garanzie effettive dipenderanno dalle policy configurate, dalla qualità dei Gatekeeper e dalla maturità di un progetto che Cloudflare considera ancora preliminare.
Modelli intercambiabili e costi centralizzati
Cloudflare OS non impone un singolo modello linguistico. Le richieste passano attraverso AI Gateway, che consente all’organizzazione di scegliere i fornitori disponibili e di assegnare modelli differenti ai diversi compiti.
Ogni inferenza può essere attribuita a una persona, a un team o a uno specifico workspace. Gli amministratori possono così controllare la spesa, impostare budget e applicare limiti di utilizzo, riservando i modelli più costosi alle operazioni che ne richiedono realmente le capacità.
Pur essendo costruita soprattutto sui servizi Cloudflare — fra cui Workers, Access, AI Gateway, Dynamic Workers e Durable Objects — la piattaforma può essere provata localmente tramite workerd, il runtime open source alla base di Workers. Il percorso locale indicato nel repository è destinato alla sperimentazione e non alla produzione; la documentazione per eseguire l’intero sistema sui propri server è ancora in preparazione.
Per un’installazione operativa, Cloudflare propone invece il deployment nel proprio account attraverso uno starter repository dedicato. L’azienda sta inoltre lavorando a una versione completamente gestita nel pannello Cloudflare, al supporto dei container per i flussi di sviluppo e all’integrazione dei workspace con Slack e altri strumenti di messaggistica.
