Um kill switch real existe fora do raciocínio do agente. Uma única chamada, e toda verificação de decisão subsequente para esse agente retorna deny na camada de política — independentemente do que o prompt do agente diga. Não é uma instrução de "por favor, pare" que o modelo possa ignorar, contestar ou ser convencido a ignorar por uma entrada manipulada. É um sinalizador que o modelo nunca vê, verificado em uma camada sobre a qual ele não tem nenhum voto.
"Adicione uma mensagem de sistema dizendo ao agente para parar" é a resposta instintiva, e é a camada errada. Um prompt de sistema é uma instrução que o modelo interpreta junto com toda outra instrução competindo por sua atenção — incluindo uma injeção de prompt bem-sucedida, um loop agêntico travado que parou de ler novas instruções, ou um modelo que simplesmente despriorize uma instrução enterrada mais cedo no contexto. Nenhum desses modos de falha é hipotético; são exatamente os cenários para os quais um kill switch existe. Se o mecanismo em que você está confiando para parar o agente está dentro do mesmo processo de raciocínio que está se comportando mal no momento, não é um controle. É uma sugestão.
Um operador com a permissão guard.killswitch.write chama POST /v1/suite/guard/kill/{agent_id} com um motivo. Isso define is_killed = true no registro do agente — nada mais, e o próprio processo do agente não está envolvido nisso.
POST /v1/decisions/check avalia o sinalizador de eliminação antes de qualquer outro ramo. Toda solicitação subsequente volta com deny e reason_code: "agent_killed", qualquer que fosse a ação que o agente estava tentando realizar.
Um agente eliminado não pode emitir uma nova credencial de confiança portátil. POST /v1/credentials/issue retorna um 403 no momento em que verifica is_killed, antes que qualquer outra coisa seja executada.
Uma entrada no ledger do Vault (agent.killed), uma linha padrão de log de auditoria e uma notificação de gravidade de perigo para o workspace são todas escritas no momento da eliminação — existe um registro de quem, quando e por que, independente do agente.
POST /v1/suite/guard/unkill/{agent_id} limpa o sinalizador e restaura a verificação normal de decisões e a emissão de credenciais. Eliminar um agente não afeta seu histórico de pontuação de confiança — é uma ação de operador separada e registrada em auditoria.
Seja preciso sobre o limite. O kill switch nega em todo checkpoint que pede permissão à VeriSwarm — uma verificação de decisão, uma solicitação de credencial, uma transferência de tarefa A2A de ou para o agente eliminado. Ele não alcança o próprio runtime do agente para interromper a execução no meio de uma tarefa, e não revoga credenciais que o agente já possui e ainda poderia apresentar a um sistema que não verifica com a VeriSwarm primeiro. É por isso que ele é um controle entre seis, não um substituto para os outros — permissões de ferramentas de privilégio mínimo e tokenização de PII reduzem o que um agente pode fazer de errado na janela antes de alguém sequer recorrer ao kill switch. Veja a lista completa dos seis controles.
Ativar ou reverter o kill switch requer um token de sessão que carregue guard.killswitch.write — em posse dos papéis super_admin, platform_admin, tenant_admin e operator. Ele é deliberadamente inacessível com a própria chave de API do agente: um agente que foi comprometido, ou um que está raciocinando seu caminho até uma ação ruim, não pode eliminar nem restaurar a si mesmo. O controle precisa vir de fora.
Uma anulação acionada por um operador que bloqueia imediatamente a capacidade de um agente específico de agir, sem depender do próprio caminho de código do agente nem de sua cooperação. Na VeriSwarm, uma única chamada — POST /v1/suite/guard/kill/{agent_id} — ativa um sinalizador no registro do agente. A partir desse momento, toda verificação de decisão de confiança contra esse agente (POST /v1/decisions/check) retorna deny com reason_code: "agent_killed", e a emissão de novas credenciais para esse agente é recusada de imediato. É reversível: uma chamada de restauração (POST /v1/suite/guard/unkill/{agent_id}) restaura a operação normal.
Não — uma instrução no prompt de sistema é um pedido do qual o modelo pode ser convencido a se afastar. Essa é a distinção central. Um kill switch real não pede ao agente para parar; ele muda o que acontece quando o agente tenta agir. A verificação acontece na camada de decisão, fora do próprio loop de raciocínio do modelo, então uma injeção de prompt bem-sucedida, um loop agêntico travado, ou o modelo simplesmente ignorando uma instrução anterior não importa — a próxima verificação de decisão volta negada de qualquer forma.
Três coisas, confirmadas em relação ao caminho de decisão ao vivo: toda chamada subsequente a POST /v1/decisions/check para esse agente retorna deny (decision_preview.py verifica agent.is_killed antes de qualquer outro ramo); a emissão de novas credenciais portáteis para esse agente é recusada com um 403 (routes/credentials.py); e, onde o protocolo A2A da VeriSwarm e as verificações de acesso JIT estão em jogo, as tentativas de outros agentes de repassar tarefas ao agente eliminado ou conceder acesso a ele também são bloqueadas. O que ele não faz é alcançar o próprio processo do agente e interrompê-lo no meio da execução — veja a próxima resposta.
Não, e esse é o limite honesto de um kill switch na camada de decisão. Ele nega em todo checkpoint subsequente que pede permissão à VeriSwarm — decisões, emissão de credenciais, transferência de tarefa A2A. Se um agente já tem credenciais emitidas que pode usar em outro lugar, ou opera em um sistema que não verifica com a VeriSwarm antes de agir, eliminá-lo na VeriSwarm não alcança esse caminho. O kill switch é um controle na camada de política para agentes que verificam decisões antes de agir — que é exatamente por que o controle #2 da checklist de segurança (permissões de ferramentas de privilégio mínimo) e o controle #4 (varredura de injeção) importam de forma independente, não como um backup para o kill switch, mas como controles que reduzem o que um agente pode fazer de errado antes de você precisar recorrer a ele.
Não — ativá-lo ou revertê-lo requer um token de sessão com a permissão guard.killswitch.write, em posse de papéis de acesso total (super_admin, platform_admin, tenant_admin, operator). Ele não é exposto à própria chave de API do agente, por design: um agente — ou algo que o comprometeu — não pode se eliminar para cobrir seus rastros, e também não pode se restaurar.
O kill switch faz parte da VeriSwarm Guard, uma capacidade do plano Max. Toda ativação e reversão escreve uma entrada imutável no ledger do Vault (agent.killed / agent.unkilled) quando o Vault está habilitado, além de uma entrada padrão de log de auditoria e uma notificação de gravidade de perigo para o workspace — então existe um registro de quem eliminou o agente, quando e por quê, independentemente do que o próprio agente relate.
O kill switch é uma capacidade do Guard no plano Max. O nível gratuito do Gate te dá primeiro a camada de decisão e a visibilidade de eventos à qual ele se conecta.