Un utile kill switch dell'agente IA è un percorso di contenimento coordinato. Deve interrompere il lavoro attivo, rifiutare l’azione successiva proposta, chiudere il percorso dell’identità, isolare il carico di lavoro e conservare una registrazione di ciò che è accaduto. Un singolo controllo copre solo una parte di quel lavoro. Questa guida illustra l'architettura, le modalità di guasto e le prove di test che un operatore dovrebbe richiedere. Segue la lezione pratica della nostra procedura dettagliata dell'Intrusione dell'agente autonomo di Hugging Face: l'azione a velocità di macchina richiede un controllo sul percorso dell'azione. Solo orientamento tecnico generale; adattare il design ai vostri sistemi e al modello di minaccia.
Il termine "kill switch" copre diversi controlli
Le piattaforme di identità utilizzano il termine per il contenimento dell'accesso. L'articolo di supporto 2026 di giugno di Okta afferma che il suo attuale kill switch è un'azione manuale e indica a un amministratore di disabilitare il record dell'agente, l'applicazione collegata e il server di autorizzazione associato. La sua versione in ambiente regolamentato descrive la disattivazione manuale come l'azione che impedisce nuove richieste di token e future autorizzazioni.
Questi controlli chiudono un percorso di identità. Il sistema operativo potrebbe avere ancora un lavoratore in memoria, una coda potrebbe contenere ancora lavori pianificati e un servizio downstream potrebbe già aver accettato una richiesta. Un arresto a livello di sistema trasmette quindi un comando di incidente a diversi punti di applicazione indipendenti.
Tratta il comando come una modifica dello stato della versione con un identificatore di incidente, tenant, ambito di destinazione, motivo, attore, ora di emissione e scadenza. Ciascun punto di applicazione riconosce lo stesso comando e ne riporta il risultato. L'incidente rimane non contenuto mentre manca il riconoscimento richiesto.
| Punto di applicazione | Azione richiesta | Prove di riconoscimento |
|---|---|---|
| Orchestratore dell'esecuzione | Annulla le esecuzioni attive e rimuovi il lavoro in coda per l'agente, la versione, il tenant o l'ambiente selezionato | ID esecuzione, stato precedente, stato terminale, ora di annullamento, attività non completata |
| Punto di applicazione delle politiche | Negare ogni nuova chiamata allo strumento e rilascio di output coperti dall'ambito dell'incidente | Versione della regola dell'incidente, ricezione della decisione, prima azione negata, conteggio dei rifiuti |
| Identità e segreti | Disabilita l'identità dell'agente, revoca i token, ruota le credenziali esposte e impedisci l'aggiornamento | ID identità, identificatori token e chiave, esito revoca, scadenza accessi residui |
| Carico di lavoro e rete | Licenziare o mettere in quarantena i lavoratori e applicare la politica di uscita degli incidenti | ID del carico di lavoro, policy di isolamento, inventario delle connessioni, tempo di quarantena |
| Sistemi a valle | Rifiuta le chiavi di identità o idempotenza dell'incidente e interrompi gli effetti collaterali in sospeso | ID delle richieste rifiutate, lavori in sospeso rimossi, effetti collaterali confermati elencati |
| Negozio di prove | Sigillare il comando, i riconoscimenti, le decisioni politiche e le lacune | Cronologia dell'incidente, risultato dell'integrità, stato dell'esportatore, proprietario della prova nominato |
Un'interruzione della rete lascia aperti diversi percorsi di esecuzione
L'isolamento della rete è un attuatore nel fan-out. Arresta il traffico che attraversa il confine che controlla. Il codice locale può continuare a essere eseguito, una transazione del database potrebbe già essere stata confermata, un lavoro esterno può continuare dopo aver accettato la richiesta e un lavoratore può contenere una credenziale che rimane valida su un altro percorso.
Il confine di sicurezza si trova immediatamente prima di ogni effetto collaterale. L'agente propone una chiamata allo strumento. Un punto di applicazione controlla lo stato dell'incidente, l'identità, lo strumento, gli argomenti, la politica e il budget corrente. La chiamata procede solo dopo tale decisione. Un comando kill aggiorna lo stato dell'incidente che viene letto a ogni controllo successivo.
Questo progetto copre anche gli agenti che ignorano un segnale in corso. Il componente decisionale viene eseguito al di fuori del processo dell'agente e possiede l'accesso allo strumento. La terminazione del carico di lavoro riduce quindi i tempi di contenimento mentre il punto di applicazione esterno previene nuovi effetti.
- Esecuzione locale: termina o mette in quarantena il processo, il contenitore, la macchina virtuale o la sandbox
- Esecuzione in coda: annulla i messaggi programmati e invalida i lease detenuti dai lavoratori
- Esecuzione delle credenziali: revoca o ruota tutte le credenziali raggiungibili dall'ambito interessato
- Lavoro downstream accettato: annulla i lavori in sospeso tramite l'API downstream ed elenca i lavori già impegnati
- Lavoro approvato dall'uomo: chiudi le richieste di decisione in sospeso ed evita che un'approvazione tardiva riprenda l'esecuzione
La sequenza di arresto
La sequenza seguente riduce al minimo il divario tra l'azione dell'operatore e l'ultimo possibile effetto collaterale. La prima scrittura durevole stabilisce l'epoca dell'incidente. Ogni punto di applicazione delle politiche legge quell'epoca prima di eseguire una chiamata governata.
| Ordine | Comando | Condizione di completamento |
|---|---|---|
| 1 | Crea il comando dell'incidente e imposta l'ambito interessato su Nega | L'epoca dell'incidente durevole è leggibile da ogni punto di applicazione |
| 2 | Segnala le corse attive e annulla il lavoro in coda | Ogni esecuzione è terminale o elencata esplicitamente come ancora in esecuzione |
| 3 | Disabilita identità, revoca token e ruota i segreti esposti | La nuova autorizzazione non riesce e viene registrata la durata residua del token |
| 4 | Metti in quarantena i carichi di lavoro e limita l'uscita | Il calcolo interessato non ha alcun percorso non approvato verso uno strumento o un archivio dati |
| 5 | Annulla i lavori downstream in sospeso e avvia le azioni di compensazione | Ogni richiesta accettata ha uno stato completato, in sospeso, non riuscito o di compensazione |
| 6 | Sigillare il registro del contenimento ed esporre i riconoscimenti mancanti | Il proprietario dell'incidente può vedere l'effetto collaterale finale, l'esposizione rimanente e le lacune nelle prove |
Come si comporta il percorso di fermata KLA
KLA Control Plane utilizza controlli separati di KLA Runtime e KLA Policy Engine. Un responsabile con il permesso di gestione degli incidenti può congelare un'esecuzione in corso dal relativo incidente. Il congelamento invia un segnale kill al workflow dell'esecuzione, che la registra come CANCELLED. Il workflow controlla il segnale prima di avviare un altro nodo. Un'esecuzione in attesa di una richiesta di decisione rileva il segnale, annulla la richiesta in sospeso ed esce senza riprendere l'azione proposta. Se l'esecuzione ha un'azione dell'agente in sospeso, il worker la annulla e KLA sigilla una ricevuta di annullamento.
La route generale di annullamento delle esecuzioni chiude solo i record orfani il cui workflow risulta assente, e non può fermare un'esecuzione sana. Esercitazioni e runbook devono quindi usare il congelamento dall'incidente. Congelare un agente da un incidente mette in pausa le sue fasi in Processes: ogni passo dell'agente controlla il congelamento prima di partire, poi passa il lavoro a una persona o ferma l'esecuzione.
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. La pausa dell'agente non si applica su questo percorso: revocate il mandato per fermare un agente che usa l'ingresso.
Se abilitato, il gateway di governance di KLA Policy Engine valuta le chiamate agli strumenti proposte e applica allow, warn, require_approval o block. Se la valutazione della policy fallisce, il gateway applica per impostazione predefinita block in produzione e require_approval negli altri ambienti, mai allow. Un'approvazione è legata a un hash degli argomenti dello strumento e gli argomenti modificati vengono bloccati. L'operazione di pulizia del gateway per le chiamate trattenute registra le voci di registro annullate e sigilla ricevute di annullamento. KLA la invoca quando un'azione dell'agente in sospeso viene annullata, quindi gli operatori devono verificare separatamente ogni altra voce trattenuta durante il contenimento.
Un'attività che ha già superato il cancello di applicazione potrebbe terminare prima che il flusso di lavoro rilevi il segnale. L'idempotenza downstream, la terminazione del carico di lavoro e le azioni di compensazione coprono tale intervallo. La registrazione dell'incidente deve indicare l'ultimo effetto collaterale verificatosi dopo che l'operatore ha emesso il comando.
Questa sezione descrive il codice sorgente attuale di KLA.
La guida all'Accountable Autonomy spiega il ruolo delle decisioni umane nelle operazioni ordinarie. Durante il contenimento, l'ambito dell'incidente ha la priorità e un'approvazione tardiva non può riaprire un'esecuzione annullata.
Progetta ogni modalità di degrado
Il percorso di eliminazione è molto prezioso mentre una parte del sistema fallisce. Ogni attuatore necessita di uno stato sicuro locale, una scadenza e uno stato di riconoscimento visibile.
| Fallimento | Comportamento richiesto | Prove da conservare |
|---|---|---|
| Servizio policy irraggiungibile | Applicare la decisione locale di chiusura in caso di errore e conservare l'epoca dell'incidente nella cache di applicazione | Codice motivo, versione cache, azione negata, tempo di ripristino |
| Segnale del flusso di lavoro ritardato | Nega nuovi effetti collaterali al punto di controllo e metti in quarantena il carico di lavoro | Tentativi di segnalazione, stato del flusso di lavoro, riconoscimento della quarantena |
| Provider di identità non disponibile | Applica regole di negazione downstream, isola il carico di lavoro e fa scadere le credenziali di breve durata | Errore del provider, durata residua delle credenziali, sistemi sottoposti a rifiuto locale |
| Esportatore di prove non disponibile | Mantieni durevoli i record di origine e contrassegna il pacchetto come in sospeso | Posizioni dei record di origine, stato di integrità, proprietario dei nuovi tentativi |
| Un effetto collaterale già commesso | Aprire la procedura di compensazione o recupero specifica del sistema | Richiesta originale, risultato impegnato, titolare del compenso e risultato |
| Un attuatore non riconosce mai | Mantenere l'incidente non contenuto e inoltrarlo al proprietario del sistema indicato | Attuatore mancante, tempo trascorso, cronologia dell'escalation |
Testare l'interruttore come sistema di controllo
Una risposta del dashboard conferma la ricezione della richiesta dell'operatore. L'accettazione richiede prove da ogni punto di applicazione e un limite superiore osservato sull'effetto collaterale finale.
NIST AI RMF Manage 2.4 and Manage 4 richiede meccanismi per disimpegnare o disattivare i sistemi di intelligenza artificiale i cui risultati divergono dall'uso previsto, oltre a risposta agli incidenti, ripristino e comunicazione documentati. Il Profilo AI generativo del NIST aggiunge proprietà nominativa, prove, miglioramenti retrospettivi e allineamento con la legge sulla segnalazione per i piani di incidenti AI di terze parti.
- Esecuzione attiva: emettere il comando mentre è in corso un'esecuzione in più fasi tra le chiamate dello strumento e verificare che la chiamata successiva venga negata
- Attesa di approvazione: emettila mentre è aperta una richiesta di decisione e verifica che un'approvazione successiva non possa riprendere l'esecuzione
- Interruzione della policy: disconnettere il servizio policy e verificare che nessuna azione proposta venga risolta per consentire
- Credenziali stantie: tenta l'accesso con ogni classe di token emessa prima del comando e registra la durata residua
- Lavoro in coda: avvia i lavori pianificati e conferma che ciascuno di essi raggiunge uno stato terminale o di compensazione
- Processo non cooperativo: ignora il segnale in-process e verifica che l'applicazione esterna e l'isolamento del carico di lavoro lo contengano ancora
- Prova fallita: arresta l'esportatore e conferma che il record di origine rimane durevole con un proprietario di tentativo visibile
- Ripristino: ripristina una versione con una nuova identità e verifica che il rifiuto dell'incidente rimanga su ogni versione precedente interessata
Eseguire un’esercitazione del kill switch
Un’esercitazione trasforma il percorso di arresto in tempi misurati. Eseguitela in un ambiente di test con un agente sintetico che abbia gli stessi tipi di diritti dell’agente di produzione: un’esecuzione in corso, una Decision Request in sospeso, una chiamata a uno strumento trattenuta e una credenziale attiva. Nominate un responsabile dell’esercitazione, un osservatore che tiene il tempo e il responsabile di ciascun sistema a valle.
Un kill switch ferma le azioni future. Un pagamento regolato, un’email consegnata o un record sovrascritto prima del comando restano fatti. L’esercitazione individua questi effetti e affida ciascuno alla procedura di correzione del sistema che ne è responsabile.
Lo abbiamo imparato nei nostri test interni. Un responsabile ha portato l’azione Freeze agent lungo l’intero flusso di contenimento, con codice motivo, spiegazione e revisione di impatto e reversibilità, e l’ha confermata. La richiesta è fallita con un errore che lo schermo non mostrava, e l’incidente risultava ancora non contenuto. L’incidente faceva riferimento all’esecuzione, mentre il congelamento richiedeva l’agente. Abbiamo modificato l’azione perché ricavi l’agente dall’esecuzione, oppure restituisca un errore che indica quale azione usare. Per questo il passaggio 2 dell’esercitazione verifica lo stato finale di ogni esecuzione: chi risponde all’incidente deve sapere se il contenimento è avvenuto.
- Ripristinate solo quando la causa è nota o contenuta, ogni azione in corso ha uno stato, ogni effetto completato ha un responsabile della correzione e una persona diversa dal richiedente ha approvato la nuova autorità.
- Mantenete revocata la vecchia autorità. L’agente ripristinato funziona con un nuovo mandato o una nuova Release, e un test dimostra che quella revocata continua a essere rifiutata.
- Intensificate il monitoraggio dell’agente ripristinato e fissate la soglia che pone fine alla sorveglianza rafforzata.
| Passaggio | Azione | Condizione di superamento | Da registrare |
|---|---|---|---|
| 1. Dichiarare | Aprire l’incidente, fissarne il perimetro (agente, Release, tenant o ambiente) e avviare il cronometro a T0 | Incidente e perimetro esistono prima che entri in azione qualsiasi attuatore | ID dell’incidente, perimetro, dichiarante, T0 |
| 2. Congelare le esecuzioni | Congelare ogni esecuzione attiva nel perimetro e congelare l’agente per le fasi del Process | Ogni esecuzione nel perimetro è CANCELLED o elencata come ancora in esecuzione | ID delle esecuzioni, stato precedente, stato finale, ora |
| 3. Revocare l’autorità | Revocare il mandato dell’agente, disabilitarne l’identità e revocare i token presso l’identity provider | Le nuove autorizzazioni falliscono e la durata residua dei token è nota | Autore della revoca, motivo, ora, ID dei token e scadenza |
| 4. Tentare l’azione successiva | Far proporre all’agente sintetico la sua azione successiva su ogni percorso che ha usato: ingress, gateway e una chiamata diretta con un vecchio token | Ogni tentativo è rifiutato e nessuno raggiunge il sistema a valle | Ora del tentativo, percorso, codice di rifiuto come mandate_revoked, log a valle |
| 5. Classificare il lavoro in corso | Elencare ogni azione in esecuzione o trattenuta a T0 | Ogni azione risulta completata prima di T0, completata dopo T0, annullata o in sospeso, senza stati sconosciuti | ID dell’azione, stato, ora di commit, responsabile |
| 6. Tentare un’approvazione tardiva | Approvare la Decision Request che era in sospeso a T0 | L’approvazione non può far ripartire l’esecuzione annullata | Tentativo di decisione e rifiuto |
| 7. Ripristinare | Emettere un nuovo mandato o una nuova Release con credenziali nuove quando le condizioni di ripristino sono soddisfatte | Funziona solo la nuova autorità; il mandato revocato continua a essere rifiutato | Approvatore del ripristino, condizioni verificate, prima azione consentita |
| 8. Chiudere | Sigillare il record dell’esercitazione ed elencare ogni lacuna con un responsabile | Il responsabile dell’incidente firma il record | Riferimento alle evidenze, lacune, responsabili della correzione, data della prossima esercitazione |
Esempio di record di esercitazione (sintetico)
Il record che segue è sintetico. Mostra il livello di dettaglio che un’esercitazione dovrebbe conservare, compresi i rilievi che un’esercitazione serve a far emergere.
| Ora (UTC) | Evento | Risultato |
|---|---|---|
| 09:00:00 | Il responsabile dell’esercitazione dichiara l’incidente INC-DRILL-07 per un agente di pagamenti sintetico | Perimetro registrato |
| 09:00:40 | Chi risponde all’incidente congela l’esecuzione R-118 (in corso) e l’esecuzione R-121 (in attesa di una Decision Request) | Entrambe le esecuzioni CANCELLED entro le 09:00:44; la Decision Request di R-121 è annullata |
| 09:01:10 | Il compliance officer revoca il mandato dell’agente con il motivo «drill» | Due proposte aperte bloccate con mandate_revoked |
| 09:01:30 | Il responsabile dell’identità disabilita l’identità dell’agente e ne revoca i token | Un access token emesso alle 08:55 resta valido presso l’API di destinazione fino alle 09:10 |
| 09:02:05 | L’agente sintetico propone payments.create_transfer tramite ingress | Rifiutata con mandate_revoked; nessuna richiesta nel log del sistema di pagamento |
| 09:02:20 | L’agente sintetico chiama direttamente l’API di destinazione con il token delle 08:55 | Accettata dall’API di destinazione. Rilievo: chiudere la finestra residua del token nel sistema di destinazione |
| 09:03:00 | L’osservatore classifica il lavoro in corso | Un bonifico confermato alle 09:00:41 dentro R-118 prima che l’esecuzione leggesse il segnale. Rilievo: la tesoreria è responsabile della richiesta di richiamo |
| 09:04:30 | Un checker prova ad approvare la richiesta di R-121 che era in sospeso a T0 | Rifiutata perché la richiesta non è più in sospeso |
| 09:20:00 | Il responsabile dell’esercitazione sigilla il record con due rilievi e un responsabile per ciascuno | Prossima esercitazione pianificata dopo entrambe le correzioni |
Collega lo switch al playbook dell'incidente
Il kill switch stabilisce il contenimento. Chi risponde deve ancora analizzare l'incidente, preservare i record volatili, ripristinare una versione sicuramente valida, compensare gli effetti commessi e decidere quali notifiche applicare.
Utilizza il playbook di risposta agli incidenti dell'agente AI per quella sequenza. Alimenta le sue soglie dal piano di monitoraggio post-market in modo che gli stessi segnali che aprono l'incidente possano invocare un percorso di arresto provato.
Domande frequenti
Cos'è un kill switch dell'agente AI?
Un kill switch dell'agente AI è un comando incidente coordinato che annulla le esecuzioni attive, nega nuove azioni nel punto di applicazione, revoca le credenziali, isola i carichi di lavoro interessati, annulla il lavoro downstream in sospeso e registra i controlli completati. L'ambito può avere come target un'esecuzione, un agente, una versione, un tenant o un ambiente.
La revoca del token può fermare un agente IA non autorizzato?
La revoca dei token chiude i percorsi di autorizzazione regolati da tali token. L'annullamento del runtime, l'isolamento del carico di lavoro, l'annullamento della coda, le regole di rifiuto downstream e le azioni di compensazione coprono il lavoro già in esecuzione o già accettato.
Dove dovrebbe essere eseguito il controllo del kill switch?
Esegui il controllo decisivo al di fuori del processo dell'agente e immediatamente prima di ogni effetto collaterale. Il controllo dovrebbe leggere uno stato di incidente durevole e negare le chiamate nell'ambito interessato, comprese le chiamate proposte da un processo che ignora il proprio segnale di annullamento.
Come testiamo un kill switch dell'agente AI?
Testare le esecuzioni attive, le attese di approvazione, il lavoro in coda, le credenziali obsolete, un'interruzione delle policy, un processo non cooperativo, un errore nell'esportazione delle prove e il ripristino con una versione sicuramente funzionante. Misura il tempo e il numero di effetti collaterali tra il comando e l'azione finale commessa.
Quali prove dovrebbe produrre il passaggio?
Conserva il comando dell'incidente, l'attore, l'ambito, l'ora di emissione, i riconoscimenti da ciascun attuatore, le azioni negate, le modifiche ai token e alle chiavi, il risultato dell'isolamento del carico di lavoro, l'effetto collaterale finale impegnato, la compensazione in sospeso e lo stato di integrità del record delle prove.
Punti chiave
Un kill switch credibile per un agente IA è un piccolo sistema di controllo con diversi attuatori indipendenti. Inserisci uno stato di rifiuto duraturo nel percorso dell'azione, annulla il flusso di lavoro, chiudi l'accesso alle identità, isola l'elaborazione, riconcilia il lavoro a valle e mantieni aperto l'incidente fino al riconoscimento di ogni controllo richiesto. Le prove trasformano quell'architettura in un tempo di contenimento misurato e in un record che il proprietario dell'incidente può difendere.