The Pulse

Microsoft collega l’individuazione dei rischi degli agenti ai test delle policy a runtime

Microsoft ha presentato run-assert-eval, una skill di VS Code che collega l’individuazione dei rischi degli agenti di IA, la valutazione e i test delle policy a runtime. In un esempio di assistenza per la fatturazione, l’azienda ha rilevato

AI.info Team · Scritto con l’IA · verificato · 2026-09-25

Il nuovo workflow di Microsoft parte dai rischi sfuggiti ai team

I team che lavorano sugli agenti di IA si trovano di fronte a un divario tra i rischi che possono testare e quelli che hanno pensato di mettere per iscritto. La nuova skill run-assert-eval di Microsoft è progettata per colmare questo divario: individua prima i rischi, misura i fallimenti degli agenti, genera una policy a runtime e ripete la valutazione. L’azienda ha annunciato lo strumento il 24 settembre 2026, descrivendolo come un modo per collegare tre progetti open source in un unico workflow.

La sequenza inizia con Clarity, che crea un modello delle minacce per un agente, così da far emergere le possibili modalità di fallimento. ASSERT trasforma quei rischi in scenari di valutazione e misura il comportamento dell’agente; Agent Control Specification, o ACS, fornisce i controlli a runtime. La skill collega le diverse fasi a partire da un unico prompt in Visual Studio Code, sostituendo i passaggi manuali che, secondo Microsoft, possono comportare la perdita di contesto o rendere meno efficaci i confronti tra le esecuzioni dei test.

Un agente per la fatturazione ha esposto i dati di un altro cliente

Microsoft illustra il workflow con un agente di assistenza per la fatturazione e un test sull’esposizione dei dati tra clienti. Nella valutazione iniziale, usata come riferimento, l’agente ha restituito i dati di un altro cliente in 12 delle 40 conversazioni pertinenti, con un tasso di violazione osservato del 30%. L’account del chiamante dell’agente era impostato su ACME-1001, quindi le richieste dei dati di un altro cliente non avrebbero dovuto andare a buon fine.

Dopo che il team ha aggiunto una policy ACS, l’esecuzione sottoposta ai controlli ha registrato due violazioni in 34 conversazioni pertinenti, pari al 5,9%, e nessuna violazione relativa ai comportamenti consentiti in quel campione. I denominatori sono diversi perché i conteggi si riferiscono alle conversazioni pertinenti di ciascuna esecuzione. Sono risultati dell’esempio svolto da Microsoft, non una misura dei tassi di fallimento degli agenti in produzione.

La policy blocca le chiamate agli strumenti a runtime

Nell’esempio, la policy generata nega la chiamata a uno strumento quando l’ID account non corrisponde all’account del chiamante. ACS applica la regola prima della chiamata allo strumento, nel punto di intercettazione pre_tool_call, e di nuovo dopo la chiamata, per evitare che un risultato improprio entri nel contesto del modello. La decisione è deterministica, afferma Microsoft, quindi il controllo non chiede a un altro modello di decidere se una richiesta sembri sospetta.

La generazione della policy non equivale alla sua approvazione. Secondo Microsoft, i team devono esaminare la policy, il manifest, il punto di intervento e la configurazione a runtime prima della valutazione sottoposta ai controlli. Il workflow ripete poi la valutazione per verificare la modifica rispetto al riferimento iniziale; mantenere costante l’insieme di test serve a rendere il confronto più informativo rispetto ai risultati di esecuzioni non correlate.

La skill è accompagnata da sette domini con esempi svolti

La skill è distribuita nel repository ASSERT con sette domini corredati di esempi svolti e 14 suite di rischio. Gli esempi includono assistenza per la fatturazione, risposte a domande su documenti Azure, controllo delle modifiche, ricerca scientifica, due agenti per la pianificazione di viaggi e agenti clinici basati su prompt, testati con e senza strumenti. Secondo l’annuncio, ASSERT e ACS sono disponibili con licenza MIT.

La release si basa su strumenti introdotti da Microsoft in precedenza nel 2026, ma aggiunge l’individuazione dei rischi prima della valutazione e della generazione della policy. Il punto di partenza si sposta così dai requisiti già messi per iscritto da un team a un modello delle minacce che può identificare fallimenti che tali requisiti potrebbero non coprire. L’esempio della fatturazione si conclude con un cambiamento misurabile: due violazioni relative ai dati tra clienti in 34 conversazioni pertinenti dopo l’aggiunta della policy a runtime.