Drift-Aware Governance-as-Code for Agentic Cloud Operations: Formalizing State Certifiability and Testing Dynamic Authority Control in an AWS Testbed

Nel moderno mondo digitale, le aziende si affidano a vaste reti di server informatici e strumenti software per gestire le proprie attività. Per mantenere questi sistemi in funzione senza intoppi, le organizzazioni utilizzano programmi automatizzati, spesso alimentati dall'intelligenza artificiale, per prendere decisioni e risolvere problemi senza l'intervento umano. Questi programmi possono scalare i servizi, modificare le impostazioni di sicurezza o riavviare componenti guasti in una frazione di secondo. Tuttavia, questi agenti automatizzati operano sulla base di una mappa del sistema che dovrebbero gestire. Questa mappa è un elenco di regole e configurazioni che descrivono come dovrebbe apparire il sistema. Il problema sorge quando il sistema reale cambia in modi che la mappa non conosce. Questo divario tra ciò che il sistema dovrebbe essere e ciò che è realmente in un dato momento è chiamato "drift" (deriva). Se un agente automatizzato tenta di risolvere un problema utilizzando una mappa obsoleta, potrebbe compiere una modifica che è sicura secondo la mappa, ma pericolosa nella realtà. La sfida principale per gli ingegneri è capire quando la mappa è così inaffidabile da richiedere che l'agente smetta di apportare modifiche e attenda che un essere umano verifichi la situazione.

Un team di ricercatori si è posto l'obiettivo di risolvere questo problema specifico creando un nuovo modo per governare questi agenti automatizzati. Hanno sviluppato un sistema che controlla costantemente quanto il sistema reale sia deviato dal suo design intenzionale. Invece di limitarsi a verificare se una regola è stata seguita, il loro sistema misura la qualità delle informazioni che l'agente sta utilizzando. Chiamano questo concetto "certificabilità dello stato", il che significa semplicemente chiedersi: abbiamo prove sufficientemente attendibili per affermare che la comprensione del sistema da parte dell'agente sia abbastanza accurata da permettergli di agire? Se le prove sono deboli perché il sistema è cambiato troppo o i dati sono troppo vecchi, il sistema riduce automaticamente il potere dell'agente. Non spegne completamente l'agente; invece, gli impedisce di compiere cambiamenti grandi e rischiosi, pur consentendogli di eseguire un piccolo insieme di azioni sicure progettate per risolvere il problema e ripristinare l'ordine.

Per testare questa idea, i ricercatori hanno costruito un ambiente controllato utilizzando Amazon Web Services, una popolare piattaforma di cloud computing. Hanno creato un banco di prova in cui potevano simulare diversi livelli di drift, che andavano da nessuna variazione affatto a disallineamenti gravi e caotici tra il piano e la realtà. Hanno eseguito migliaia di esperimenti in cui agenti automatizzati cercavano di eseguire compiti come la rotazione delle password di sicurezza, l'aumento dei carichi di lavoro informatici o l'isolamento di risorse compromesse. Hanno confrontato tre approcci diversi: lasciare che gli agenti agissero senza alcuna restrizione, utilizzare un insieme standard di regole fisse che non cambiavano in base alle condizioni del sistema, e utilizzare il loro nuovo sistema "drift-aware" (consapevole della deriva) che regolava l'autorità dell'agente in tempo reale. I risultati sono stati sorprendenti. Quando il sistema si trovava in uno stato di grave drift, gli agenti senza restrizioni violavano le regole nel 92,3% dei casi. Gli agenti con regole fisse violavano le regole nel 55,2% dei casi. Ma gli agenti governati dal nuovo sistema drift-aware violavano le regole solo nel 25% dei casi. Ciò ha dimostrato che, rendendo il potere dell'agente dipendente da quanto bene esso comprendesse lo stato attuale del sistema, i ricercatori potevano ridurre drasticamente il rischio di errori pericolosi.

Lo studio ha anche esplorato cosa accade quando il sistema decide di bloccare un agente. Una preoccupazione comune è che il blocco di un agente possa impedire la risoluzione di un problema critico, lasciando il sistema guasto. I ricercatori hanno testato un design specifico in cui, anche quando bloccato, l'agente era autorizzato a eseguire un insieme limitato di azioni di "solo recupero", come isolare un server compromesso o annullare una modifica errata. Hanno scoperto che questo approccio rappresentava una via di mezzo intelligente. Un blocco totale che interrompeva ogni azione riduceva il rischio di mosse insicure di oltre l'80%, ma impediva anche all'agente di risolvere il problema nella maggior parte dei casi. Tuttavia, l'approccio di solo recupero riduceva il rischio di mosse insicure di circa il 55%, pur permettendo all'agente di risolvere con successo il problema in quasi l'84% dei casi. Ciò ha dimostrato che è possibile mantenere sicuro un sistema senza paralizzarlo, a patto che l'agente sia autorizzato a intraprendere solo passi specifici e pre-approvati per ripristinare l'ordine.

Uno dei risultati più importanti della ricerca riguarda la natura del punto di "lockout" (blocco). Il team aveva stabilito una soglia specifica in cui avrebbero interrotto le normali operazioni dell'agente, sperando che questo numero rappresentasse un punto di rottura naturale in cui il sistema diventava troppo pericoloso da gestire. Tuttavia, i loro dati hanno mostrato che il rischio di errori non aumentava improvvisamente in quel numero specifico. Al contrario, il rischio aumentava gradualmente man mano che il sistema si allontanava dal proprio piano. Ciò significa che la decisione di bloccare un agente non è la scoperta di una legge naturale, ma piuttosto una scelta deliberata fatta dall'organizzazione. È una decisione politica che dice: "Siamo disposti ad accettare un certo rischio, ma una volta che l'incertezza supera questo punto, non ci fidiamo più della mappa dell'agente". I ricercatori hanno concluso che non esiste un unico numero magico che funzioni per ogni situazione; al contrario, le organizzazioni devono scegliere con cura i propri limiti in base alle proprie esigenze specifiche e alla tolleranza al rischio.

Lo studio ha anche confermato che il nuovo sistema funziona anche quando i dati su cui si basa sono imperfetti. Hanno testato le prestazioni del sistema quando le misurazioni del drift erano leggermente errate o quando i dati erano un po' obsoleti. Il sistema è rimasto robusto, identificando correttamente le situazioni pericolose e limitando il potere dell'agente in quasi tutti i casi. Inoltre, hanno eseguito una validazione separata utilizzando comandi reali sulla piattaforma cloud per garantire che il sistema funzionasse al di fuori di una simulazione. In questi test nel mondo reale, il nuovo sistema ha ridotto le azioni non autorizzate da quasi il 9% a poco più dell'1%, provando che il concetto funziona non solo in teoria, ma anche nella pratica. La ricerca suggerisce che il futuro delle operazioni cloud automatizzate sicure risiede nel trattare l'autorità dell'agente come una variabile flessibile. Chiedendosi costantemente se la conoscenza dell'agente sia abbastanza affidabile da giustificare una specifica azione, le organizzazioni possono permettere ai loro sistemi automatizzati di lavorare più velocemente e liberamente, mantenendo al contempo un controllo rigoroso sulla sicurezza.