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
Il piano di controllo KLA utilizza controlli KLA Runtime e KLA Policy Engine separati. L'API di annullamento risolve un'esecuzione con ambito tenant nello stato PENDING, RUNNING o GATED, invia un segnale kill al relativo flusso di lavoro e registra l'esecuzione come CANCELLED. Il flusso di lavoro controlla il segnale prima di avviare un altro nodo. Anche un'esecuzione in attesa di una richiesta di decisione rispetta l'annullamento e esce senza riprendere l'azione proposta.
Se abilitato, il gateway di governance di KLA Policy Engine valuta le chiamate agli strumenti proposti e applica allow, warn, require_approval o block. Se la valutazione della politica fallisce, il gateway utilizza per impostazione predefinita block in produzione e require_approval in altri ambienti. Il gateway include un'operazione di pulizia separata per le chiamate allo strumento in attesa che registra i movimenti contabili annullati e sigilla le ricevute di annullamento. Il percorso di annullamento dell'esecuzione oggi non richiama tale operazione, quindi gli operatori devono verificare separatamente le voci trattenute 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.
Questi comportamenti vengono verificati nell'ambiente di sviluppo KLA, che è l'unico ambiente attualmente eseguito da 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
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.