The Pulse
Microsoft illustra quattro livelli per consentire agli agenti di IA di agire in produzione
Microsoft descrive un’architettura a quattro livelli per gli agenti di IA che gestiscono incidenti nella rete Azure, con limiti relativi all’identità, agli strumenti, alle modifiche in produzione e alle attività ripetute. L’architettura con
AI.info Team · Scritto con l’IA ·
Microsoft vuole che gli agenti di IA diagnostichino guasti di rete in corso e individuino le soluzioni; il limite proposto è che qualsiasi modifica alla produzione debba fermarsi in attesa dell’approvazione di una persona. In un articolo pubblicato il 13 ottobre, Arun Malik, ingegnere software principale di Azure Networking presso Microsoft, descrive un sistema in grado di indagare sugli incidenti e predisporre interventi, limitando però ciò che l’agente può effettivamente modificare. È questa la tensione al centro dell’architettura: un agente può conoscere la soluzione, ma questo non significa che abbia il permesso di applicarla.
Una soluzione BGP mette alla prova la dimostrazione
L’esempio di Malik parte da un collegamento che si attiva e si disattiva ripetutamente all’interno di un datacenter, mentre gli allarmi confluiscono in un unico incidente. Un agente raccoglie lo stato dei dispositivi e i dati di telemetria, mette in relazione le modifiche recenti, classifica il guasto e scrive un riepilogo prima che l’ingegnere reperibile abbia finito di effettuare l’accesso. Può anche individuare una soluzione, come disattivare una sessione BGP che trasporta traffico attivo dei clienti.
Quest’ultimo passaggio cambia il livello di rischio. Un risultato diagnostico può essere esaminato prima che qualcuno intervenga; un’operazione di scrittura in produzione ha conseguenze immediate. «La parte difficile dell’autonomia è l’autorizzazione, non l’intelligenza», scrive Malik.
«La parte difficile dell’autonomia è l’autorizzazione, non l’intelligenza».
Arun Malik, ingegnere software principale, Azure Networking, Microsoft
Quattro limiti definiscono l’autorità dell’agente
L’architettura di Microsoft suddivide i controlli in quattro livelli: identità, accesso agli strumenti, approvazione delle modifiche in produzione e passaggio dal ragionamento guidato dal modello all’automazione ripetibile. L’agente opera con i permessi della persona che lo ha avviato o, se necessario, con un’identità di servizio, ma si applica l’insieme di permessi più restrittivo. L’accesso agli strumenti è di competenza dei team che ne sono responsabili; i permessi vengono modificati tramite modifiche al codice sottoposte a revisione.
L’agente opera inoltre attraverso un’interfaccia agli strumenti tipizzata e dotata di registrazione, anziché ricevere accesso illimitato a una shell. Microsoft non esclude gli strumenti da riga di comando: Malik afferma che un comando può essere reso disponibile come strumento circoscritto e dichiarato, mentre una shell senza restrizioni rende difficile associare permessi specifici, schemi e una traccia di controllo. Indica MCP come adatto alle chiamate che attraversano i confini di fiducia, citando il principio del privilegio minimo, l’isolamento delle credenziali, una registrazione strutturata per i controlli, meccanismi di approvazione e limiti alla frequenza delle richieste.
Il terzo limite è una sospensione obbligatoria prima di una modifica in produzione. Le attività diagnostiche possono procedere senza attendere una persona, ma è il codice nel motore di esecuzione, non un prompt, a trattenere le modifiche in attesa dell’approvazione. Microsoft afferma che qualsiasi eccezione deve essere ottenuta per una procedura e un tipo di azione specifici: la competenza apparente di un modello non basta per saltare questo controllo.
Gli incidenti di routine potrebbero fare a meno del modello
Il quarto livello riguarda ciò che accade quando il sistema incontra ripetutamente lo stesso incidente. Secondo Microsoft, l’agente può prima ragionare su un caso nuovo e poi trasformare un percorso di ragionamento riuscito in una procedura deterministica. A quel punto, i casi di routine che si ripetono possono essere gestiti senza chiamate al modello, riducendo i costi e la variabilità del ragionamento ripetuto, secondo l’articolo.
In un esempio relativo allo stato della rete, il modello analizza l’output non strutturato di un dispositivo e lo converte in campi come interfaccia, stato e VLAN. Il codice tradizionale verifica il risultato rispetto a uno schema e decide se lo stato richiede un intervento di ripristino; un’operazione di scrittura deve comunque attendere una persona. Malik definisce l’approccio «struttura deterministica, compilazione probabilistica»: il modello interpreta, mentre il software tradizionale convalida e controlla l’azione.
La proposta è un’architettura, non un lancio
La tesi di Microsoft è che nessuno dei quattro limiti possa garantire da solo la sicurezza. Senza limiti legati all’identità, un agente potrebbe operare con credenziali più ampie di quelle della persona che lo ha chiamato; senza un’interfaccia agli strumenti controllata, un comando di shell potrebbe aggirare le autorizzazioni granulari; senza un passaggio di approvazione, una configurazione plausibile ma errata potrebbe raggiungere un dispositivo. Sostituire il ragionamento ripetuto del modello con una procedura affronta un problema diverso: evitare che i casi di routine già risolti dipendano ogni volta da una nuova decisione del modello.
L’articolo su Command Line descrive l’approccio ingegneristico di Microsoft, non il lancio di un prodotto. Non indica una data di disponibilità, prezzi, risultati di benchmark né un’implementazione presso un cliente identificato. Il limite operativo più chiaro è anche il più concreto: gli agenti possono indagare autonomamente sugli incidenti di rete, ma le azioni che modificano la produzione si fermano in attesa dell’approvazione di una persona.