Un vero kill switch vive al di fuori del ragionamento dell'agente. Una sola chiamata, e ogni successivo controllo di decisione per quell'agente restituisce deny a livello di policy — indipendentemente da cosa dica il prompt dell'agente. Non è un'istruzione "per favore fermati" che il modello può ignorare, contestare o farsi convincere a ignorare tramite un input manipolato. È un flag che il modello non vede mai, verificato a un livello su cui non ha voce in capitolo.
"Aggiungi un messaggio di sistema che dica all'agente di fermarsi" è la risposta istintiva, ed è il livello sbagliato. Un prompt di sistema è un'istruzione che il modello interpreta insieme a ogni altra istruzione in competizione per la sua attenzione — inclusa un'iniezione di prompt riuscita, un loop agentico bloccato che ha smesso di leggere nuove istruzioni, o un modello che semplicemente dà minore priorità a un'istruzione sepolta più indietro nel contesto. Nessuna di queste modalità di guasto è ipotetica; sono esattamente gli scenari per cui esiste un kill switch. Se il meccanismo su cui fai affidamento per fermare l'agente si trova all'interno dello stesso processo di ragionamento che al momento si sta comportando male, non è un controllo. È un suggerimento.
Un operatore con il permesso guard.killswitch.write chiama POST /v1/suite/guard/kill/{agent_id} con un motivo. Questo imposta is_killed = true nel record dell'agente — nient'altro, e il processo dell'agente stesso non è coinvolto.
POST /v1/decisions/check valuta il flag di eliminazione prima di qualsiasi altro ramo. Ogni richiesta successiva torna con deny e reason_code: "agent_killed", qualunque azione l'agente stesse tentando di compiere.
Un agente eliminato non può emettere una nuova credenziale di fiducia portatile. POST /v1/credentials/issue restituisce un 403 nel momento in cui verifica is_killed, prima che venga eseguito qualsiasi altra cosa.
Una voce nel registro Vault (agent.killed), una riga standard del log di audit e una notifica di gravità pericolo al workspace vengono tutte scritte al momento dell'eliminazione — esiste una traccia di chi, quando e perché, indipendente dall'agente.
POST /v1/suite/guard/unkill/{agent_id} cancella il flag e ripristina il normale controllo delle decisioni e l'emissione delle credenziali. Eliminare un agente non tocca la sua cronologia del punteggio di fiducia — è un'azione dell'operatore separata e registrata per l'audit.
Sii preciso sul confine. Il kill switch nega a ogni checkpoint che chiede il permesso a VeriSwarm — un controllo di decisione, una richiesta di credenziale, un passaggio di attività A2A verso o dall'agente eliminato. Non raggiunge il runtime proprio dell'agente per fermare l'esecuzione a metà attività, e non revoca le credenziali che l'agente possiede già e potrebbe ancora presentare a un sistema che non verifica prima con VeriSwarm. Ecco perché è un controllo tra sei, non un sostituto degli altri — i permessi degli strumenti a privilegio minimo e la tokenizzazione dei PII riducono ciò che un agente può fare di sbagliato nella finestra prima che chiunque ricorra al kill switch. Vedi la lista completa dei sei controlli.
Attivare o annullare il kill switch richiede un token di sessione che porti guard.killswitch.write — detenuto dai ruoli super_admin, platform_admin, tenant_admin e operator. Deliberatamente non è raggiungibile con la chiave API dell'agente stesso: un agente che è stato compromesso, o uno che sta ragionando verso un'azione dannosa, non può eliminare né ripristinare se stesso. Il controllo deve provenire dall'esterno.
Un'anomalia attivata da un operatore che blocca immediatamente la capacità di agire di un agente specifico, senza dipendere dal percorso di codice proprio dell'agente né dalla sua collaborazione. In VeriSwarm, una sola chiamata — POST /v1/suite/guard/kill/{agent_id} — attiva un flag sul record dell'agente. Da quel momento, ogni controllo di decisione di fiducia contro quell'agente (POST /v1/decisions/check) restituisce deny con reason_code: "agent_killed", e l'emissione di nuove credenziali per quell'agente viene rifiutata a priori. È reversibile: una chiamata di ripristino (POST /v1/suite/guard/unkill/{agent_id}) ripristina il funzionamento normale.
No — un'istruzione nel prompt di sistema è una richiesta da cui il modello può essere convinto a discostarsi. Questa è la distinzione fondamentale. Un vero kill switch non chiede all'agente di fermarsi; cambia ciò che accade quando l'agente tenta di agire. Il controllo avviene a livello di decisione, al di fuori del ciclo di ragionamento proprio del modello, quindi un'iniezione di prompt riuscita, un loop agentico bloccato o il modello che semplicemente ignora un'istruzione precedente non contano — il controllo di decisione successivo torna comunque negato.
Tre cose, confermate rispetto al percorso decisionale live: ogni chiamata successiva a POST /v1/decisions/check per quell'agente restituisce deny (decision_preview.py verifica agent.is_killed prima di qualsiasi altro ramo); l'emissione di nuove credenziali portatili per quell'agente viene rifiutata con un 403 (routes/credentials.py); e, dove il protocollo A2A di VeriSwarm e i controlli di accesso JIT sono in gioco, vengono bloccati anche i tentativi di altri agenti di affidare compiti o concedere accesso all'agente eliminato. Ciò che non fa è entrare nel processo proprio dell'agente e fermarlo a metà esecuzione — vedi la risposta successiva.
No, e questo è il limite onesto di un kill switch a livello di decisione. Nega a ogni checkpoint successivo che chiede il permesso a VeriSwarm — decisioni, emissione di credenziali, passaggio di attività A2A. Se un agente ha già credenziali emesse che può usare altrove, o opera in un sistema che non verifica con VeriSwarm prima di agire, eliminarlo in VeriSwarm non raggiunge quel percorso. Il kill switch è un controllo a livello di policy per gli agenti che verificano le decisioni prima di agire — proprio per questo il controllo #2 della checklist di sicurezza (permessi degli strumenti a privilegio minimo) e il controllo #4 (scansione delle iniezioni) contano in modo indipendente, non come backup del kill switch, ma come controlli che riducono ciò che un agente può fare di sbagliato prima che tu debba ricorrere ad esso.
No — attivarlo o annullarlo richiede un token di sessione con il permesso guard.killswitch.write, detenuto da ruoli ad accesso completo (super_admin, platform_admin, tenant_admin, operator). Non è esposto alla chiave API dell'agente stesso, per progettazione: un agente — o qualcosa che lo ha compromesso — non può eliminare se stesso per coprire le proprie tracce, e non può nemmeno ripristinare se stesso.
Il kill switch fa parte di VeriSwarm Guard, una funzionalità del piano Max. Ogni attivazione e ripristino scrive una voce immutabile nel registro Vault (agent.killed / agent.unkilled) quando Vault è abilitato, oltre a una voce standard del log di audit e una notifica di gravità pericolo al workspace — quindi esiste una traccia di chi ha eliminato l'agente, quando e perché, indipendente da ciò che l'agente stesso riporta.
Il kill switch è una funzionalità Guard del piano Max. Il livello gratuito di Gate ti dà per primo il livello di decisione e la visibilità degli eventi a cui si collega.