Un responsabile delle operazioni revoca a un agente il permesso di dare corso ai pagamenti. Il processo principale dell’agente termina. Un pagamento resta in coda, un’attività delegata è ancora in esecuzione e un worker potrebbe ripetere una richiesta dall’esito incerto. Ciascuno di questi elementi richiede un esito attribuito a un responsabile prima che il responsabile dell’incidente possa dire che cosa si è fermato.
Lo scenario è illustrativo. Inquadra una domanda di ricerca: quali osservazioni sostengono l’affermazione che l’autorità revocata a un agente non può più causare un’azione, entro un ambito dichiarato? Questo articolo esamina ricerche recenti e specifiche di protocollo, riporta una piccola riproduzione di un verificatore di chiusura pubblicato e fornisce una scheda che il responsabile dell’incidente può compilare. Questo articolo fa parte di una serie di ricerca in tre parti sull’autorità degli agenti, pubblicata il 26 ottobre 2026: prove di arresto, policy nella memoria degli agenti e standard di controllo degli agenti.
Definite prima l’ambito dell’affermazione
Le ricerche recenti distinguono fasi che un unico stato «revocato» può nascondere. Revocation Is Not Complete at Receipt, preprint di ottobre 2026 di Lifei Liu, Haoran Yu e Danping Zhang, distingue il commit e la consegna di una revoca dalla sua applicazione nei gateway e dalla prevenzione degli effetti protetti durante una finestra di osservazione. I suoi esperimenti usano una sola topologia di consegna, partizionata di proposito, e gli autori non indicano alcun tasso di errore valido per l’intero settore. Leggi il paper.
Un preprint di settembre 2026 di Genliang Zhu e Chu Wang tratta l’autorità che prosegue attraverso la delega e il lavoro asincrono. Il suo protocollo traccia da dove proviene l’autorità e come cambia lo stato di autorizzazione, ed esegue controlli nel punto in cui un’azione produce il suo effetto. Tiene conto anche del lavoro che prosegue sotto un’altra autorità valida. Entrambi i paper sono preprint; i risultati riportati dipendono dalle ipotesi dichiarate. Leggi il protocollo e la valutazione.
Il passo pratico consiste nello scrivere l’affermazione prima di raccogliere le prove a suo sostegno. Indicate l’autorità revocata, le azioni interessate, i percorsi di applicazione e la finestra di osservazione. Registrate esplicitamente le esclusioni. Una dichiarazione sul esecuzione dei pagamenti dovrebbe precisare se copre i job pianificati, i tentativi ripetuti, i worker delegati e le richieste che un prestatore di servizi di pagamento aveva già accettato.
Consegna e annullamento hanno limiti definiti
I protocolli esistenti coprono già parti di questo problema. La specifica OAuth sulla revoca dei token tratta il ritardo di propagazione, e la specifica sull’introspezione dei token descrive il costo per la sicurezza della memorizzazione in cache delle risposte di introspezione. Entrambi i punti contano quando i worker di un agente consultano copie diverse dello stato di autorizzazione. RFC 7009, RFC 7662.
Le specifiche finali OpenID CAEP 1.0 e Shared Signals Framework 1.0 definiscono contratti di evento e di consegna che possono coordinare una modifica tra sistemi. Il responsabile dell’incidente ha comunque bisogno di prove di ciò che ogni ricevente e ogni punto di applicazione a valle ha fatto con il segnale. CAEP 1.0, Shared Signals Framework 1.0.
Anche l’annullamento ha i suoi limiti. La specifica del Model Context Protocol datata 2025-06-18 rende facoltative le notifiche di annullamento e riconosce che l’elaborazione può essere già completata o impossibile da annullare. Un rapporto sull’esito di un workflow deve tenere conto di queste race condition. Annullamento MCP.
Cosa abbiamo verificato in modo indipendente
RISU Research pubblica un verificatore di chiusura separato, bounded-agent-closure. È citato nei lavori correlati ed è distinto da entrambi i preprint citati sopra. Abbiamo eseguito la sua suite di test, senza modifiche, al commit ef07236 (pacchetto 0.3.1, Node 20): tutti i 75 test sono stati superati. Abbiamo poi sottoposto al verificatore gli otto pacchetti di prove sintetici forniti con il progetto e conservato le decisioni restituite. Repository upstream al commit fissato.
- Una vista mancante è una lacuna. Quando mancava la vista dello scheduler, il verificatore ha restituito UNKNOWN.
- Un’attività ancora pianificata è lavoro non concluso. La presenza di tale attività ha prodotto INCOMPLETE, anche quando il pacchetto dichiarava il successo.
- Lo storico può restare. In questo profilo, le prove storiche conservate erano compatibili con CLOSED.
- I successori sono espliciti. Un trasferimento a un successore si è chiuso alle condizioni codificate nel caso di test.
| Caso di test fornito | Risultato osservato |
|---|---|
| Attività sopravvissuta diretta | INCOMPLETE |
| Attività sopravvissuta transitiva | INCOMPLETE |
| Impegno in sospeso | INCOMPLETE |
| Prove conservate | CLOSED |
| Trasferimento a un successore | CLOSED |
| Copertura mancante | UNKNOWN |
| Successo dichiarato con un’attività ancora pianificata | INCOMPLETE |
| Chiusura completata con scansioni finali stabili | CLOSED |
Cosa la riproduzione non dimostra
Il verificatore valuta le prove che riceve. La nostra esecuzione non ha avviato alcun agente, coda o pagamento, non ha cercato code nascoste e non dimostra che un sistema di raccolta reale riporti tutto in modo veritiero. La suite di test e la riesecuzione dei casi si sovrappongono, quindi gli otto casi di test non costituiscono otto ulteriori convalide indipendenti. Il risultato di un verificatore vale quanto l’ambito delle prove e il processo di raccolta che lo sostengono.
Non abbiamo riprodotto nessuno dei due preprint. Il primo paper riporta 112 effetti protetti su 225 tentativi nella sua topologia partizionata; il secondo riporta 17 casi accettati e 44 mutazioni respinte per il suo strumento di controllo. Entrambe le cifre sono degli autori. L’endpoint dell’artefatto del primo paper non ha restituito contenuti utilizzabili tramite i nostri strumenti.
Date al responsabile dell’incidente un registro delle prove
Abbiamo trasformato la ricerca in una scheda delle prove di arresto (in inglese). Chiede l’autorità revocata, il lavoro a valle, i punti che applicano la revoca, gli effetti già prodotti e le osservazioni non risolte. Prevede spazio per il lavoro di un successore sotto un’autorità indipendente e per la persona responsabile della riconciliazione.
Considerate un worker che ha inviato una richiesta di pagamento prima della revoca e riceve la ricevuta dopo. La ricevuta va nel registro dell’incidente. L’azione successiva del worker richiede un proprio controllo dell’autorizzazione corrente. Un effetto già prodotto può richiedere una risposta di business separata, come una riconciliazione o uno storno autorizzato. La scheda registra queste responsabilità e non presume che un effetto possa essere annullato.
| Campo | Cosa registrare |
|---|---|
| Autorità revocata | Identificatori dell’autorità radice e della delega; identificatori della richiesta di revoca e della modifica confermata |
| Finestra di osservazione | Fonti orarie, incertezza, inizio e fine |
| Ambito | Azioni e destinazioni degli effetti incluse; percorsi esclusi e motivo di ciascuna esclusione |
| Percorsi di applicazione | L’ultima versione dell’autorizzazione osservata su ciascun percorso |
| Attività in sospeso | Voci in coda, tentativi ripetuti, lavoro delegato e impegni in sospeso |
| Esito per elemento | Impedito, completato prima, trasferito, in sospeso o sconosciuto |
| Dopo l’istante di riferimento | Tentativi ed effetti prodotti; ricevute tardive e azioni di riconciliazione |
| Lacune | Sistemi di raccolta mancanti, viste non aggiornate o prove contraddittorie |
| Responsabili | Azioni residue, responsabili e data della prossima revisione |
Scrivete la dichiarazione di arresto con i suoi limiti
La scheda si chiude con una dichiarazione che il responsabile dell’incidente può riutilizzare: «Per [autorità] e [percorsi dichiarati], le osservazioni da [inizio] a [fine] mostrano [risultato]. [Elementi] restano non risolti a causa di [lacuna specifica nelle prove]. [Responsabile] è responsabile della riconciliazione.»
Mantenete le precisazioni sui limiti temporali e sull’ambito quando la dichiarazione viene copiata in un riepilogo dell’incidente. La dichiarazione indica allora quali azioni sono state impedite, quali avevano già prodotto i loro effetti, quali attività sono state trasferite e quali osservazioni non sono disponibili. I responsabili delle operazioni, dell’ingegneria e del rischio possono esaminare un unico registro in cui la parola «fermato» ha un significato chiaro.
Come il percorso di arresto di KLA si collega alla scheda
Gli agenti che agiscono tramite l’ingresso delle azioni degli agenti di KLA operano sotto un mandato dell’agente. La revoca del mandato blocca le proposte aperte collegate con il codice motivo mandate_revoked, annulla le relative richieste di decisione in sospeso e rifiuta la successiva azione proposta dall’agente. Un’azione già ammessa può completarsi, quindi va registrata nelle righe «Completato prima» o «Dopo l’istante di riferimento» della scheda.
La ricerca descritta in questo articolo non ha testato KLA. La guida all’architettura del kill switch descrive l’intero percorso di arresto di KLA, compreso il congelamento dall’incidente, e il playbook di risposta agli incidenti copre il resto del registro dell’incidente.
Domande frequenti
Come si dimostra che un agente AI si è fermato?
Formulate prima l’affermazione: l’autorità revocata, i percorsi coperti e la finestra di osservazione. Registrate poi l’ultima versione dell’autorizzazione vista su ciascun percorso di applicazione, l’esito di ogni elemento in coda, ripetuto o delegato, gli effetti prodotti dopo l’istante di riferimento e le prove mancanti. L’affermazione vale solo entro quell’ambito e quella finestra.
La revoca del token di un agente ferma il lavoro già in corso?
Non necessariamente. La revoca OAuth può richiedere tempo per propagarsi e un’introspezione in cache può essere non aggiornata. Il lavoro già in coda, delegato o accettato da un sistema a valle può ancora completarsi, e l’annullamento MCP è facoltativo e può entrare in concorrenza con il completamento. Ogni elemento richiede un proprio esito registrato.
Le azioni completate da un agente revocato si possono annullare?
La revoca ferma le nuove azioni. Un effetto già prodotto permane: un pagamento, per esempio, richiede una risposta di business separata, come una riconciliazione o uno storno autorizzato, registrata con il suo responsabile.
Che cosa ha mostrato la riproduzione del verificatore di chiusura?
Al commit ef07236 tutti i 75 test upstream sono stati superati, e gli otto pacchetti sintetici forniti hanno restituito tre CLOSED, quattro INCOMPLETE e un UNKNOWN. L’esecuzione ha valutato solo le prove fornite. Non ha avviato alcun agente o coda e non dice nulla sulla completezza di un sistema di raccolta reale.
Punti chiave
Un agente si è fermato solo entro un ambito che qualcuno ha messo per iscritto: l’autorità, i percorsi e la finestra temporale. Raccogliete le prove per quell’ambito, date un esito a ogni elemento aperto e indicate le lacune con i relativi responsabili. Partite dalla scheda delle prove di arresto e leggete l’architettura del kill switch per i controlli che producono le prove.
Le fonti sono state verificate il 26 ottobre 2026. I due preprint non sono stati riprodotti in modo indipendente. Le nostre osservazioni usano casi di test sintetici pubblicati e non contengono alcun risultato di produzione di KLA.