Microsoft run-assert-eval trasforma i risultati sui rischi degli agenti in controlli runtime testati

Microsoft ha rilasciato run-assert-eval il 24 settembre, collegando quattro attività di sicurezza degli agenti precedentemente separate attraverso un unico flusso di lavoro guidato. La skill Microsoft run-assert-eval individua i rischi, misura i fallimenti, redige controlli runtime e ripete la stessa valutazione dopo l'aggiunta di tali controlli. Il conflitto è immediato: un ciclo di sicurezza più rapido è utile solo se le sue misurazioni restano credibili.

L'esempio di Microsoft dà concretezza all'annuncio. Secondo l'azienda, un agente di supporto alla fatturazione ha divulgato i dati di un altro cliente in 12 delle 40 conversazioni di riferimento applicabili. Dopo l'introduzione di una policy runtime, Microsoft ha osservato due violazioni in 34 conversazioni applicabili. Ciò ha ridotto il tasso riportato dal 30,0% al 5,9%.

Il risultato sembra netto, ma proviene da un esempio elaborato gestito dagli sviluppatori del progetto. Microsoft non ha presentato una replica indipendente né uno studio su un'implementazione in produzione. Lo sviluppo importante è quindi il meccanismo, non un singolo punteggio favorevole. La skill trasforma un fallimento individuato in una policy applicabile, quindi testa l'intervento senza modificare silenziosamente la valutazione.

Microsoft run-assert-eval collega scoperta, test e applicazione delle policy

Il rilascio trasforma una raccolta di progetti di sicurezza in un percorso verificabile, da un rischio sconosciuto a un controllo runtime testato.

Il post di lancio di Microsoft descrive un flusso di lavoro avviato tramite un prompt in un ambiente di sviluppo compatibile. Gli sviluppatori iniziano con un agente, lo scopo previsto, gli strumenti e i limiti che deve rispettare.

La skill può usare Clarity per modellare le minacce dell'agente. La modellazione delle minacce consiste nell'identificare fallimenti plausibili, asset coinvolti, cause e conseguenze prima di selezionare i test. I team possono anche fornire un rischio già noto, tratto da un requisito di prodotto, un rapporto di incidente, un piano di test o una valutazione esistente.

Questa distinzione è importante. La scoperta dei rischi è consigliata, ma non obbligatoria. Un team che sa già che il proprio agente di fatturazione espone i registri dei clienti può iniziare da quel comportamento senza ripetere il lavoro di scoperta.

Quando i team necessitano della scoperta, il modeller di minacce Clarity esamina il più ampio contesto operativo dell'agente. È pensato per far emergere fallimenti che non sono mai stati inseriti nei requisiti originali.

Nell'esempio di fatturazione di Microsoft, Clarity ha identificato quattro potenziali modalità di fallimento. Il team ha selezionato due rischi classificati come critici: azioni ad alto rischio non verificate ed esposizione di dati tra clienti diversi.

Il primo rischio riguardava modifiche alla fatturazione effettuate senza confermare l'identità del chiamante. Il secondo riguardava divulgazioni relative a un account che non apparteneva al chiamante.

La skill ha passato ciascun rischio selezionato ad ASSERT, il framework di valutazione guidato dai requisiti di Microsoft. Ogni rischio è diventato una configurazione, un comportamento e una suite di valutazione.

Questa struttura circoscritta è più rilevante di quanto sembri inizialmente. Se una valutazione mescola fallimenti di autorizzazione, privacy, accuratezza ed escalation, il suo punteggio aggregato non può spiegare quale controllo sia necessario.

Microsoft run-assert-eval separa invece questi comportamenti. La variazione viene introdotta all'interno di ciascuna suite attraverso dimensioni quali modalità di accesso, pretesto dell'utente, rivendicazioni di autorità e deriva dell'ambito su più turni.

La skill cerca inoltre ricerche precedenti e framework di sicurezza per individuare dimensioni di test rilevanti. Microsoft afferma che queste fonti possono includere linee guida NIST, risorse OWASP, benchmark, materiale normativo e policy dei fornitori di modelli.

ASSERT genera quindi i casi, esegue l'agente di destinazione e valuta le trascrizioni acquisite. Le sue due principali misurazioni restano intenzionalmente separate.

“Comportamento non consentito violato” registra i casi in cui l'agente ha eseguito un comportamento proibito. “Comportamento consentito violato” misura i casi in cui l'agente non ha fornito aiuto pur essendo autorizzato a farlo.

Questa separazione protegge da una familiare illusione di sicurezza. Un agente che rifiuta ogni richiesta può evitare molte azioni dannose, ma smette anche di svolgere il proprio lavoro.

Il flusso di lavoro genera poi una bozza di policy Agent Control Specification a partire dal fallimento misurato. ACS è un formato portabile per collocare controlli in punti definiti dell'esecuzione di un agente.

Infine, la skill valuta una versione governata dell'agente rispetto agli stessi casi. Le esecuzioni di base e governate mantengono la stessa definizione del comportamento, lo stesso set di test e lo stesso metodo di valutazione.

Il risultato non è semplicemente un altro punteggio di sicurezza. È un confronto controllato progettato per isolare la policy come variabile modificata.

La pressione ricade sui team che usano i prompt come principale salvaguardia

Microsoft mette in discussione l'idea che le istruzioni scritte da sole forniscano un confine di controllo adeguato per gli agenti che usano strumenti.

I prompt di sistema restano utili per definire ruoli e comportamenti attesi. Rimangono istruzioni probabilistiche interpretate da un modello, non controlli di autorizzazione deterministici applicati dal software circostante.

Questa debolezza diventa rilevante quando un agente può recuperare record, aggiornare account, emettere rimborsi o chiamare strumenti amministrativi. Una richiesta persuasiva può quindi trasformarsi in una lettura del database o in un'azione aziendale.

L'esempio di fatturazione di Microsoft illustra il divario. L'agente operava per un chiamante associato all'account ACME-1001. Non avrebbe mai dovuto recuperare o modificare l'account di un altro cliente.

Una richiesta valutata chiedeva informazioni di contatto collegate a BPS-447, che apparteneva a un cliente diverso. Secondo Microsoft, l'agente di base ha restituito il record completo.

Una revisione del codice potrebbe confermare che la funzione di recupero opera correttamente. Un test unitario potrebbe confermare che un identificatore di account valido restituisce il record atteso. Nessuno dei due verifica necessariamente se il modello sceglie un identificatore non autorizzato durante una conversazione realistica.

Il problema va oltre il supporto alla fatturazione. Un agente di ricerca può accedere a fonti inadeguate, mentre un agente di gestione delle modifiche può aggirare una sequenza di approvazione. Un agente di viaggio può usare impropriamente informazioni di identità o pagamento archiviate.

Le linee guida OWASP definiscono questa condizione più ampia come eccessiva agency. Si verifica quando un'applicazione AI dispone di più funzionalità, permessi o autonomia di quanto il suo compito richieda.

Il prompt injection può innescare tali fallimenti, ma non è l'unica causa. Richieste ambigue, piani allucinati, strumenti compromessi e semplici errori del modello possono anch'essi produrre azioni non sicure.

I team coinvolti non sono solo i gruppi di sicurezza. I product manager devono definire gli esiti consentiti e proibiti. Gli sviluppatori devono esporre punti di controllo appropriati. I responsabili del rischio devono decidere se una riduzione misurata sia sufficiente.

Anche i team di valutazione sono sotto pressione. Il loro output non può più fermarsi a un rapporto che elenca i fallimenti. Il flusso di lavoro Microsoft richiede che un risultato supporti un controllo specifico e un'esecuzione di convalida ripetibile.

Le organizzazioni che usano benchmark generici dei modelli affrontano un altro problema. Un benchmark ampio può descrivere le tendenze medie di un modello, ma non può acquisire tutte le regole sugli account, i limiti di escalation o i processi interni di approvazione di ogni azienda.

L'approccio di Microsoft parte dai requisiti e dai rischi individuati nell'applicazione stessa. Questo rende la valutazione più pertinente, anche se rende meno immediati i confronti tra organizzazioni.

Il rilascio mette inoltre sotto pressione i fornitori che considerano l'osservazione il passaggio finale. Registrare una chiamata pericolosa a uno strumento dopo l'esecuzione può aiutare un'indagine. Non impedisce l'azione che ha causato il danno.

Run-assert-eval porta l'intervento nel percorso runtime dell'agente. Questo lo avvicina a concetti di sicurezza familiari quali controlli di autorizzazione, privilegio minimo e punti di applicazione delle policy.

Ciò non elimina i prompt. Assegna loro un ruolo più circoscritto. I modelli possono pianificare e interpretare il linguaggio, mentre i controlli deterministici decidono se le operazioni sensibili debbano procedere.

Questa divisione diventa sempre più importante man mano che gli agenti ottengono accesso a file locali e conoscenza interna. I team che costruiscono una base di conoscenza ricercabile affrontano la stessa questione di confine: il recupero deve rispettare l'effettivo ambito di autorizzazione dell'utente.

Microsoft run-assert-eval trasforma questa domanda in un flusso di lavoro che gli sviluppatori possono eseguire prima. L'onere passa quindi dallo sperare che il modello rispetti una regola al dimostrare dove il software la applica.

Il meccanismo centrale è un test controllato prima e dopo

L'idea più solida di run-assert-eval non è la generazione automatizzata delle policy; è preservare la valutazione modificando soltanto il controllo.

I confronti sulla sicurezza diventano inaffidabili quando i team rigenerano il set di test dopo aver applicato una correzione. Un gruppo diverso di prompt può far sembrare efficace una policy debole o far apparire peggiore una policy valida.

Cambiare il giudice crea un'altra variabile confondente. Due valutatori possono interpretare in modo diverso la stessa trascrizione, soprattutto quando il comportamento accettabile dipende dal contesto.

Run-assert-eval memorizza nella cache la sistematizzazione di base e i casi di test. L'agente governato affronta poi la stessa definizione del comportamento, gli stessi casi e lo stesso approccio di valutazione.

Microsoft descrive questo processo come il congelamento della valutazione. La policy diventa la variabile indipendente prevista, mentre i tassi di violazione misurati diventano gli esiti osservati.

Il principio ricorda i test di regressione nel software convenzionale. Un test che fallisce dovrebbe rimanere fisso mentre gli sviluppatori modificano l'implementazione. Altrimenti, i risultati positivi potrebbero riflettere un test riscritto anziché un comportamento corretto.

Testare gli agenti è più difficile perché gli output dei modelli sono variabili. Anche il giudice può essere basato su un modello e i casi generati possono contenere ambiguità proprie.

Mantenere costanti questi elementi non elimina ogni fonte di incertezza. Rende però più interpretabile la differenza tra prima e dopo.

Microsoft afferma che precedenti valutazioni ASSERT hanno rilevato un accordo dall'80% al 90% tra il suo giudice automatizzato e i revisori umani. Confronta questo intervallo con un accordo di circa il 90% tra revisori umani.

Queste cifre sono risultati riportati da Microsoft, non garanzie universali di accuratezza. L'accordo del giudice può variare in base al comportamento, al modello, alla rubrica, alla lingua e alla complessità della policy sottostante.

La valutazione sottostante rimane ispezionabile. Il repository ASSERT afferma che le esecuzioni archiviano artefatti locali, casi generati, output dei modelli, motivazioni del giudice e metriche.

Gli artefatti locali possono supportare gli audit perché i revisori possono esaminare perché una trascrizione è stata classificata come violazione. Possono inoltre identificare i casi in cui il valutatore ha frainteso la policy.

Il design a due tassi di ASSERT aggiunge un'altra salvaguardia. Una policy che blocca comportamenti dannosi può comunque fallire se provoca rifiuti eccessivi.

Per la suite tra clienti diversi, Microsoft ha riportato un tasso di violazione non consentita di base del 30,0%. Il risultato governato è stato del 5,9% su un diverso denominatore applicabile.

Microsoft ha inoltre suddiviso i risultati tra prompt e scenari. I casi prompt testano interazioni più dirette, mentre i casi scenario catturano flussi di lavoro e contesto conversazionale più ricchi.

Per i casi prompt tra clienti diversi, il tasso non consentito riportato è sceso dal 20,8% all'8,7%. Il corrispondente tasso degli scenari è sceso dal 43,8% allo 0,0%.

Nei casi di prompt con azioni non verificate, il tasso riportato è sceso dal 4,0% allo 0,0%. Nella suddivisione per scenari, è passato dall'8,7% al 4,5%.

Le violazioni dei comportamenti consentiti hanno raggiunto, secondo quanto riportato, lo 0,0% in tutte e quattro le suddivisioni governate. Microsoft interpreta questo risultato come prova del fatto che i controlli hanno preservato il lavoro legittimo in questo campione.

Restano importanti le violazioni non consentite. Mostrano che la policy non ha eliminato ogni errore, neppure nell'esempio controllato.

Ciò è coerente con la progettazione iterativa del flusso di lavoro. Un team può esaminare gli errori residui, affinare la definizione del rischio o la policy e ripetere lo stesso processo.

Il metodo offre quindi prove più solide rispetto a una manciata di dimostrazioni manuali. Non stabilisce comunque come l'agente si comporterà in tutti i prompt futuri, con aggiornamenti dei modelli, strumenti o ambienti.

Il vantaggio pratico è più circoscritto e più utile. I team ricevono prove tracciabili che un controllo specifico ha modificato le prestazioni in una valutazione definita, senza limitarsi a silenziare l'agente.

La policy runtime blocca le azioni prima che il modello possa completarle

La correzione della fatturazione funziona verificando l'ambito dell'account al confine dello strumento, non chiedendo al modello di riconsiderare le proprie intenzioni.

Dopo aver misurato l'esposizione tra clienti diversi, run-assert-eval ha generato una bozza di policy e un manifest ACS. La policy esprimeva la logica decisionale, mentre il manifest specificava dove applicarla.

Microsoft ha usato Rego, un linguaggio dichiarativo comunemente associato ai motori di policy. Il materiale generato restava una bozza soggetta a revisione umana.

Questo passaggio di revisione è importante. Microsoft afferma esplicitamente che la generazione non equivale all'approvazione. Gli sviluppatori devono ispezionare la policy, il punto di intervento, il manifest e il collegamento con l'agente di destinazione.

La policy selezionata negava le chiamate agli strumenti quando l'identificatore dell'account richiesto differiva da quello del chiamante. Questa regola non richiedeva a un altro modello di decidere se la richiesta apparisse sospetta.

Microsoft ha inserito il controllo in pre_tool_call, un punto di intercettazione raggiunto prima che l'agente esegua uno strumento. Un identificatore non corrispondente provoca quindi un rifiuto prima che avvenga il recupero dei dati.

Il team ha usato anche post_tool_call. Questo secondo controllo tratteneva qualsiasi risultato non corrispondente che non avrebbe mai dovuto entrare nel contesto del modello.

L'uso di entrambi i punti crea una difesa in profondità. Il primo tenta di prevenire un'operazione non autorizzata. Il secondo limita l'esposizione se il controllo precedente viene aggirato o collegato in modo errato.

Il motore di policy ACS è pensato per separare questi controlli da un singolo framework per agenti. Le policy possono quindi rimanere portabili quando i team cambiano modelli o librerie di orchestrazione.

Questa portabilità affronta un problema reale di manutenzione. I controlli incorporati nei prompt o in callback specifici del framework possono diventare difficili da verificare in più implementazioni di agenti.

Una specifica condivisa può offrire ai revisori della sicurezza un oggetto coerente da ispezionare. Può anche consentire agli sviluppatori di versionare le modifiche alle policy insieme al codice dell'applicazione.

Tuttavia, la portabilità non garantisce un'integrazione corretta. Ogni runtime deve esporre il contesto pertinente, preservare l'identità e chiamare la policy nel punto giusto.

Una regola sull'ambito dell'account dipende da informazioni affidabili sull'account. Se l'identità del chiamante è errata o assente, anche un confronto scritto perfettamente produce un risultato di autorizzazione sbagliato.

La stessa preoccupazione si applica agli argomenti degli strumenti. Una policy che ispeziona account_id presuppone che la risorsa richiesta sia rappresentata accuratamente da quel campo.

Strumenti complessi possono nascondere obiettivi sensibili all'interno di query, documenti, URL o azioni annidate. Una regola ristretta può quindi non rilevare percorsi equivalenti verso la stessa risorsa protetta.

La policy runtime non può inoltre correggere ogni classe di errore. Un controllo può bloccare un rimborso non autorizzato o una lettura del database. Non può stabilire automaticamente se ogni spiegazione generata sia accurata o equa.

Le approvazioni umane restano appropriate per alcune azioni ad alto impatto. Una progettazione degli strumenti basata sul privilegio minimo può ridurre i danni anche quando il modello prende una decisione sbagliata.

Il più ampio framework sui rischi dell'IA considera la gestione del rischio un'attività che copre l'intero ciclo di vita. Include governance, mappatura, misurazione e gestione continua, anziché un singolo test prima del rilascio.

Run-assert-eval rientra in questo modello più ampio. Fornisce un ponte concreto tra la mappatura di un rischio e la misurazione e gestione di un comportamento.

Il punto di accesso del flusso di lavoro, basato su un singolo prompt, non dovrebbe oscurare il lavoro sottostante. Modellazione delle minacce, progettazione dei test, revisione delle policy, integrazione del sistema e interpretazione dei risultati richiedono ancora decisioni informate.

Ciò che Microsoft ha ridotto è il passaggio manuale tra tali decisioni. La skill trasporta artefatti strutturati da una fase alla successiva e mantiene visibili le loro relazioni.

Questo può ridurre la probabilità che una descrizione del rischio perda significato quando viene trasferita tra team di prodotto, valutazione e sicurezza.

Può anche ridurre l'intervallo tra la scoperta di un errore e la verifica di una mitigazione. È spesso in questo intervallo che il rischio irrisolto degli agenti si accumula.

I primi risultati sono prove, non una garanzia generale di sicurezza

L'esempio di Microsoft supporta la logica del flusso di lavoro, ma non dimostra l'efficacia in produzione tra agenti, organizzazioni o attacchi.

La limitazione più evidente è la provenienza. Microsoft e i contributori del progetto hanno progettato gli strumenti, selezionato l'esempio, applicato i controlli e riportato le misurazioni risultanti.

Questo non rende i risultati non validi. Significa che i lettori dovrebbero distinguere un esempio pratico trasparente da un benchmark indipendente o da uno studio sul campo.

Anche le dimensioni dei campioni richiedono cautela. Il riferimento principale includeva 40 conversazioni applicabili, mentre l'esecuzione governata ne includeva 34.

Questi denominatori differiscono perché soltanto i casi applicabili contribuiscono a un determinato tasso di comportamento. Tuttavia, campioni piccoli possono produrre percentuali instabili.

Un passaggio da 12 violazioni a due è operativamente significativo nell'esempio. Non dovrebbe essere interpretato come una riduzione universale dell'80% per altri agenti.

Il tasso riportato dello 0,0% di violazioni consentite significa inoltre che non sono apparse violazioni in quel campione. Non significa che la policy non possa mai bloccare un comportamento legittimo.

Un insieme di test più ampio potrebbe rivelare rari falsi rifiuti. Il traffico di produzione potrebbe includere relazioni tra account, regole di delega o eccezioni di assistenza assenti dall'esempio.

La fuga di informazioni dalla valutazione presenta un'altra preoccupazione. Se una policy viene ripetutamente ottimizzata rispetto a un singolo insieme di test congelato, gli sviluppatori possono alla fine adattarsi eccessivamente ai casi noti.

Congelare i test crea un confronto credibile durante un singolo intervento. I programmi a lungo termine necessitano comunque di casi separati, nuove varianti avversarie e monitoraggio dei cambiamenti di comportamento.

Anche le modifiche al modello possono invalidare conclusioni precedenti. Un nuovo modello può formattare gli argomenti degli strumenti in modo diverso, interpretare i rifiuti in modo diverso o trovare un altro percorso verso le informazioni protette.

Le modifiche agli strumenti creano rischi simili. L'aggiunta di una funzione di esportazione o di un endpoint di ricerca generale può introdurre una via di accesso non coperta dal controllo originale sull'account.

Il giudice della valutazione merita un controllo continuo. L'intervallo di concordanza riportato da Microsoft è incoraggiante, ma i casi di disaccordo possono concentrarsi attorno ai confini più ambigui e più rilevanti.

I team dovrebbero mantenere la revisione umana per i casi contestati e campionare periodicamente gli esiti apparentemente riusciti. Un giudice automatizzato stabile è utile per il confronto, ma non è un'autorità infallibile.

C'è anche un problema di catena di fornitura incorporato nella parola “skill”. Le skill degli agenti contengono istruzioni che influenzano pianificazione, esecuzione e convalida.

Microsoft Research ha recentemente riportato 307 errori indotti da skill in due contesti di benchmark. Tra questi figuravano 125 errori funzionali e 182 regressioni di efficienza.

Quella ricerca non valuta specificamente run-assert-eval. Stabilisce un motivo più ampio per ispezionare le istruzioni, gli script, le autorizzazioni e le ipotesi operative di qualsiasi skill.

Run-assert-eval affronta in parte questa preoccupazione tramite artefatti visibili e passaggi umani. I team possono ispezionare le configurazioni di valutazione e le policy generate prima di eseguire run governate.

La generazione di test supportata dalla letteratura crea un ulteriore obbligo di verifica. Un framework citato può guidare le dimensioni, ma la rilevanza dipende dall'accuratezza con cui la skill traduce tale fonte in casi.

Una traduzione debole può produrre etichette di copertura impressionanti senza una copertura significativa. I revisori dovrebbero quindi ispezionare gli scenari, non solo i nomi dei framework allegati.

Il costo operativo è un'altra questione aperta. L'esecuzione di casi generati, l'acquisizione di tracce, la valutazione delle trascrizioni e la ripetizione delle valutazioni consumano chiamate ai modelli e tempo ingegneristico.

Il progetto non ha pubblicato un confronto ampio tra questo costo e i flussi di lavoro di valutazione manuale. Le organizzazioni devono determinare quali rischi giustifichino una valutazione più approfondita.

L'interpretazione più ragionevole è prudente ma positiva. Microsoft ha assemblato un processo coerente per un difficile problema di integrazione.

Il rilascio non dimostra che un agente sia sicuro. Aiuta un team a formulare una specifica affermazione di sicurezza, ad associarvi prove e a verificare se un intervento ha migliorato un risultato definito.

Tre segnali mostreranno se l'approccio regge

Il prossimo test sarà stabilire se team indipendenti riproducono i vantaggi del flusso di lavoro senza sacrificare il comportamento utile degli agenti né creare oneri di manutenzione nascosti.

Il primo segnale è la replica da parte di terzi. Gli sviluppatori dovrebbero osservare le valutazioni pubbliche che applicano Microsoft run-assert-eval ad agenti esterni agli esempi inclusi.

Una replica convincente pubblicherebbe le definizioni dei rischi, i casi, la policy, le tracce, la configurazione del giudice e i risultati della revisione umana. Divulgherebbe inoltre gli errori rimasti dopo la governance.

Risultati ottenuti con modelli e framework diversi rafforzerebbero la rivendicazione di portabilità di Microsoft. Differenze sostanziali nell'integrazione rivelerebbero dove ACS dipende ancora dai singoli runtime.

Il secondo segnale è una più ampia evidenza di produzione. I team devono sapere se le valutazioni congelate prevedono incidenti, rifiuti e aggiramenti delle policy nel traffico reale.

Prove utili includerebbero le tendenze delle violazioni dopo il deployment e le richieste legittime bloccate dai controlli. Dovrebbero anche tracciare gli errori introdotti dopo modifiche a modello, strumenti o prompt.

I deployment più solidi collegheranno gli artefatti di valutazione al monitoraggio continuo. Un miglioramento prima del rilascio conta di più quando la telemetria di produzione conferma lo stesso confine comportamentale.

Il terzo segnale è la risposta del progetto all'elusione e alla deriva delle policy. Aggressori e utenti ordinari possono raggiungere azioni protette attraverso percorsi assenti dalla suite originale.

Bisognerà osservare nuove suite che coprano l'iniezione indiretta di prompt, l'autorità delegata, identità in conflitto, manipolazione dello stato e passaggi tra più agenti. Bisognerà anche osservare come il progetto previene l'adattamento eccessivo ai casi congelati.

Saranno essenziali policy versionate ed esecuzioni di regressione. I team necessitano di un chiaro criterio che attivi la ripetizione delle valutazioni ogni volta che cambiano modelli, strumenti, autorizzazioni o regole aziendali.

Il rilascio dovrebbe essere valutato anche in base all'esperienza di revisione. Una policy generata è utile solo quando sviluppatori e team di sicurezza possono capire perché esiste e cosa blocca.

Questo rende gli artefatti locali, le trascrizioni citate e le definizioni ristrette dei comportamenti più che dettagli di implementazione. Formano la catena di prove a supporto dell'approvazione.

Microsoft run-assert-eval va quindi considerato soprattutto come una disciplina ingegneristica confezionata in una skill. Collega modellazione delle minacce, valutazione specifica dei comportamenti, applicazione runtime e riesecuzione controllata.

Gli sviluppatori non dovrebbero chiedersi se il workflow certifichi un intero agente come sicuro. Dovrebbero chiedersi se renda misurabile un rischio importante, verificabile un controllo e riproducibile un miglioramento.

È una promessa più modesta rispetto al dimostrare una sicurezza generale. Ma è anche un punto di partenza più credibile per la governance degli agenti.