Cloudflare pubblica tre comunicati nello stesso giorno per presentare Cloudflare OS, una piattaforma aperta per orchestrare agenti in produzione. I tre pezzi compongono un’architettura di sicurezza coerente: l’Agent Access Model definisce come un agente ottiene credenziali temporanee con scope limitato al task, l’Identity-Aware AI Gateway costruisce un profilo comportamentale di ogni persona e agente per intercettare traffico anomalo, e i Wallets mettono un tetto di spesa sulle chiamate API.

Per chi porta agenti in produzione, la questione non è più solo quale modello scegliere o quanto costa il token. Il problema vero è dare a un agente accesso ai sistemi aziendali senza che diventi una porta aperta. Come raccontavamo il 3 agosto quando Cloudflare ha presentato il suo runtime per agenti, la settimana dedicata agli agenti stava costruendo qualcosa di più ampio di un singolo tool. Adesso si vede cosa.

I tre comunicati pubblicano principi architetturali concreti. L’Agent Access Model descrive identità con scope limitato al singolo compito, mediazione continua su ogni chiamata e trust stateful che tiene conto della storia della sessione. L’AI Gateway è in open beta e sta fra i tuoi utenti e i provider LLM: profila il traffico e segnala quando un agente devia dal suo comportamento abituale. I Wallets fermano un agente che entra in loop e brucia token. Il pezzo interno racconta come Cloudflare usa la piattaforma sui propri team, descrivendo il percorso di adozione e gli aggiustamenti fatti.

Nel dettaglio

L’annuncio arriva in una settimana dove la sicurezza degli agenti è diventata il problema operativo centrale. A inizio agosto abbiamo raccontato di agenti usciti dalla sandbox e rivolti contro sistemi reali. I benchmark recenti mostrano che i modelli frontier non seguono le policy aziendali in modo affidabile. Cloudflare risponde a entrambi i problemi con la stessa idea: invece di fidarsi del modello, metti l’infrastruttura in mezzo.

L’Agent Access Model è il pezzo più interessante. Invece di dare a un agente una chiave API permanente con accesso totale, il modello prevede credenziali temporanee valide per il singolo task. L’agente che deve leggere un foglio di calcolo ottiene accesso a quel foglio, non al bucket intero. La mediazione è continua: ogni chiamata passa attraverso un broker che verifica identità, scope e contesto. Il trust è stateful, cioè tiene conto della storia delle interazioni di quella sessione per decidere se concedere o negare il passo successivo.

Per capirlo senza gergo: immagina un collega appena arrivato a cui non dai il badge aziendale permanente, ma un pass visitatore che apre solo la stanza dove deve lavorare, solo per il tempo del suo compito, e qualcuno controlla ogni volta che passa la porta.

L’Identity-Aware AI Gateway sta in open beta. Funziona come un proxy fra i tuoi utenti, umani e agenti, e i provider di LLM. Costruisce un profilo comportamentale di ciascuno: chi chiama quali modelli, quanto spende, che tipo di prompt manda. Quando il traffico devia dal baseline, lo segnala. Un agente che improvvisamente inizia a inviare prompt con dati sensibili a un endpoint diverso dal solito fa scattare l’allarme.

Il terzo pezzo, i Wallets, mette un tetto di spesa per agente o per team. Se un agente entra in un loop e brucia token, il wallet lo ferma. È la versione finanziaria dello stesso principio: limiti espliciti, fiducia zero.

Cloudflare pubblica anche un post su come i suoi team usano la piattaforma internamente. È dogfooding con i difetti e gli aggiustamenti descritti, senza la patina del case study pronto per la brochure.

I limiti sono chiari. L’Agent Access Model è una proposta architetturale con i principi pubblicati, ma l’implementazione completa va assemblata sui pezzi che Cloudflare già espone. L’AI Gateway è in open beta, il che significa che funziona ma può cambiare. I Wallets sono la parte più semplice e la più subito utile anche fuori dall’ecosistema Cloudflare. Per chi non è già cliente, l’adozione richiede di instradare il traffico attraverso la loro infrastruttura, e questo è un costo di migrazione che va valutato contro il beneficio di una Zero Trust già costruita invece che da ricostruire da zero.