CrowdStrike AI Kill Switch: o que ele interrompe hoje e o que o runbook de agentes ainda precisa

O CrowdStrike AI Kill Switch oferece às equipes de segurança uma forma de isolar os agentes de IA dos modelos de que eles dependem, orientando os gateways de IA conectados a bloquear esse acesso. Bloquear esse acesso não comprova que o trabalho já iniciado pelo agente tenha parado. Um agente com a própria chave de API pode continuar recebendo respostas do modelo depois que o kill switch é acionado, até onde as fontes publicadas mostram.

O que o CrowdStrike AI Kill Switch faz hoje

Os detalhes abaixo vêm principalmente da publicação de lançamento da CrowdStrike e da reportagem do Channel Insider.

O AI Kill Switch foi anunciado em 3 de novembro, no Fal.Con Europe 2026, em Barcelona, e está disponível por meio do CrowdStrike Falcon Guardian. As equipes de segurança o ativam no Falcon Guardian, que orienta os gateways de IA conectados a bloquear o acesso aos modelos de IA que sustentam as decisões e ações dos agentes. O agente deixa de poder perguntar a um modelo o que fazer em seguida.

O Falcon AI Gateway está incluído no Falcon Guardian sem custo adicional. A CrowdStrike afirma que ele estende a segurança de IA a aplicações e cargas de trabalho além da cobertura direta dos sensores de endpoint, incluindo ambientes não gerenciados. Se você já usa o Falcon Guardian, o gateway talvez já esteja licenciado, e a questão em aberto passa a ser quanto do tráfego dos seus agentes realmente passa por ele.

O controle disponível hoje atua no caminho entre o agente e o modelo. O MLQ.ai relata que a cobertura independente não encontrou nenhum teste publicado por terceiros que mostre se o kill switch alcança agentes que operam fora de um gateway controlado.

Entregue versus prometido: como ler a linguagem do roadmap

O próprio blog da CrowdStrike traça o limite: "Em breve, a CrowdStrike estenderá o AI Kill Switch para além da aplicação no gateway, a fim de oferecer contenção coordenada de agentes em toda a plataforma Falcon." A reportagem do Channel Insider está de acordo: a interrupção baseada em gateway está disponível atualmente, enquanto o encerramento direto no endpoint e a contenção coordenada em outros sistemas continuam planejados. Sugerimos não programar a aposentadoria de nenhuma etapa manual apenas com base no roadmap.

A publicação complementar da CrowdStrike sobre o Falcon Guardian mostra por que esse limite importa. A empresa afirma que proteger agentes de IA exige visibilidade e controle em três camadas críticas: execução em tempo de execução no nível do sistema operacional, comunicações de rede e interações dos agentes. A camada de execução no nível do sistema operacional é onde ficam os processos iniciados, e o encerramento direto no endpoint ainda está na lista do que foi planejado.

Onde a cobertura do lançamento e o blog do fornecedor divergem

A matéria da CNBC sobre o lançamento apresenta o relato mais amplo. Na versão dela, trata-se de um kill switch projetado para permitir que as equipes de segurança interrompam agentes internos de IA que saiam do controle, os impeçam de reiniciar e cortem o acesso deles à rede corporativa. O blog da CrowdStrike descreve a aplicação no gateway como o mecanismo disponível e a contenção coordenada na plataforma Falcon como algo que virá em breve. A frase sobre o roadmap não menciona reinicializações, portanto o bloqueio de reinício continua não confirmado como um recurso que você possa usar hoje.

A diferença pode ser apenas uma redação mais solta no dia do lançamento ou um briefing mais amplo, mas isso é especulação nossa.

Obtenha o escopo por escrito: pergunte ao seu contato na CrowdStrike quais ações do kill switch estão disponíveis de forma geral hoje e qual licença ou pacote cada uma exige e, depois, que evidência confirma que uma ação surtiu efeito e onde ela fica registrada. Guarde a resposta datada junto com o runbook.

O que um bloqueio de modelo não interrompe

A arquitetura de gateway pode interromper as próximas solicitações de um agente a um modelo, mas isso, por si só, não mostra que comandos já emitidos foram revertidos nem que agentes e ferramentas a jusante pararam. Esse limite, exposto na análise do MLQ.ai, pesa mais no trabalho que já não precisa de um modelo para continuar. O Channel Insider acrescenta um segundo limite: bloquear o acesso ao modelo não encerra necessariamente todos os processos que um agente já iniciou nem revoga as credenciais que ele usou antes.

Imagine um agente de teste hipotético que inicia um job de exportação desacoplado pouco antes do bloqueio. O kill switch funciona como descrito e a próxima solicitação do agente ao modelo falha. O job de exportação nunca precisou do modelo, então continua em execução, e o token que recebeu permanece válido até que alguém o revogue ou ele expire.

Os hooks no nível do agente não fecham essa lacuna. A CrowdStrike descreve hooks para Claude Code, OpenAI Codex, GitHub Copilot, OpenCode e Cursor que permitem às organizações inspecionar prompts e bloquear atividades maliciosas na origem, antes que ações nocivas sejam executadas. Como atuam antes da execução, eles não tratam do trabalho já iniciado e só ajudam nos agentes em que estão instalados.

Quem aciona o kill switch e quem restaura o acesso

Detecção e decisão são funções diferentes. No relato da CNBC, o processo consegue detectar a atividade de agentes internos, mas uma pessoa precisa decidir cortar o agente e restabelecer o acesso. Defina esses nomes com antecedência, porque o playbook abaixo depende deles: quem pode acionar o kill switch e com base em quais evidências, quem deve ser informado (incluindo os responsáveis de negócio pelos agentes afetados), quem pode anular ou adiar um acionamento, quem aprova a recuperação e quem assume cada função fora do horário comercial.

A cobertura fora do horário comercial é onde um serviço gerenciado pode ajudar. O Falcon Complete for Guardian oferece monitoramento, investigação e resposta 24/7 para ameaças específicas de IA, o que pode cobrir o monitoramento e a resposta, mas a sua equipe ainda precisa confirmar quem detém a decisão de acionar e restaurar.

Combine também de antemão os critérios de impacto no negócio, já que um bloqueio em modelos ou gateways compartilhados pode interromper trabalho legítimo junto com o agente suspeito.

A lista de lacunas do runbook de agentes: um playbook de sete etapas

Criamos este checklist como uma estrutura de trabalho; ninguém o avaliou em benchmark, então adapte-o à sua organização. A Etapa 1 é de preparação, e as Etapas 2 a 7 são de resposta ao vivo. Os responsáveis indicados são sugestões.

Etapa 1: chaves e rotas diretas

Quando: antes de um incidente e, depois, em uma programação regular.

Responsável: engenharia de plataforma.

Ação: faça o inventário de todas as rotas de agentes até um modelo que evitem um gateway conectado e, em seguida, rotacione ou remova essas chaves. Dê a cada agente a própria identidade de serviço para que a Etapa 4 possa atribuir a atividade dele. Esta etapa vem primeiro porque, segundo o MLQ.ai, nenhum teste publicado por terceiros mostra se o kill switch alcança agentes que operam fora de um gateway controlado. Quando um agente realmente precisar de acesso à API, um proxy de credenciais que mantém as chaves de API fora dos agentes de IA é um padrão que vale a pena avaliar.

Comprovação de conclusão: um inventário com cada rota marcada como vinculada ao gateway, rotacionada ou removida.

Ponto de acionamento: ative o kill switch

A ativação é a primeira ação ao vivo, executada assim que a pessoa designada para decidir tomar a decisão. Ela interrompe novas decisões de modelo por meio dos gateways conectados enquanto a equipe avança pelas Etapas 2 a 7. Se uma rota direta aparecer nesse momento, desative-a imediatamente.

Etapa 2: tokens ativos

Quando: logo após a ativação.

Responsável: equipe de identidade.

Ação: revogue os tokens de acesso e os tokens de atualização separadamente, porque revogar o token de atualização pode deixar o token de acesso funcionando.

Comprovação de conclusão: chamadas de teste com cada token falham nos serviços que o agente de fato usou.

A RFC também alerta para um possível atraso de propagação em que alguns servidores têm conhecimento da invalidação e outros não, de modo que um token pode continuar funcionando em um serviço depois de ter sido rejeitado por outro.

Etapa 3: revogação com falha

Quando: à medida que chegam as respostas da Etapa 2.

Responsável: plantão de identidade.

Ação: trate toda revogação com falha como inacabada: tente novamente e registre o estado final. Quando um provedor não tiver endpoint de revogação, rotacione o segredo subjacente ou desative a identidade do agente e presuma que os tokens emitidos continuam ativos até expirarem. Uma resposta de revogação bem-sucedida também não comprova a propagação, portanto teste de novo.

Comprovação de conclusão: um registro com o status final e o resultado do novo teste de cada token.

Recomendamos o mesmo tratamento para timeouts e outros erros de servidor 5xx. Na nossa leitura, a RFC se aplica apenas a sistemas OAuth que a implementam, portanto chaves de API e credenciais proprietárias exigem verificações específicas de cada plataforma.

Etapa 4: evidências e atribuição

Quando: antes de qualquer encerramento, junto com as Etapas 2 e 3, se necessário.

Responsável: operações de segurança.

Ação: capture árvores de processos, logs e registros de sessão do agente antes de interromper qualquer coisa. Depois, atribua cada processo ao agente tanto pela linhagem do processo (a cadeia de pais e filhos até o runtime do agente) quanto pela identidade de serviço, já que um processo desacoplado pode perder a linhagem e uma conta compartilhada confunde a identidade. Se um processo estiver causando dano ativo, o comandante do incidente pode autorizar a interrupção após uma captura mínima, e o registro deve indicar isso.

Comprovação de conclusão: evidências com carimbo de data e hora armazenadas, além de uma lista de processos que marca cada item como atribuído, não relacionado ou desconhecido.

Etapa 5: processos em execução

Quando: depois da Etapa 4.

Responsável: operações de segurança.

Ação: encontre e interrompa o que o agente já iniciou usando ferramentas de host e de carga de trabalho, porque um bloqueio de modelo pode deixar esses processos em execução. Trabalhe a partir da lista da Etapa 4 e investigue tudo o que estiver marcado como desconhecido. O encerramento direto no endpoint ainda está apenas planejado, então, por enquanto, este continua sendo o seu procedimento.

Comprovação de conclusão: uma listagem feita após a interrupção, com as mesmas verificações, que mostre que não resta nenhum processo iniciado pelo agente.

Etapa 6: chamadas de ferramentas em andamento

Quando: junto com a Etapa 5.

Responsável: o responsável pela aplicação de cada ferramenta conectada.

Ação: presuma que o cancelamento pode perder a corrida. Verifique diretamente o estado a jusante nos sistemas que essas ferramentas acessam e liste tudo o que precisa ser revertido. O rastreamento OpenTelemetry GenAI para atividades de LLMs e agentes pode ajudar a montar essa lista, desde que já estivesse implantado antes do incidente.

Comprovação de conclusão: um registro revisado de cada chamada em andamento e do resultado real dela.

Etapa 7: trabalho em fila e recuperação

Quando: antes de o acesso voltar.

Responsável: comandante do incidente.

Ação: esvazie ou retenha as filas para que o trabalho pendente não seja executado no momento em que o acesso voltar. A forma como o seu runtime persiste e retoma o trabalho em fila determina o que você precisa esvaziar. Depois, peça a uma pessoa designada que aprove o acesso restaurado com base em um checklist escrito.

Comprovação de conclusão: um registro de recuperação assinado que vincule cada item do checklist à respectiva evidência.

Checklist do exercício de mesa

Faça o exercício no seu tenant real, mas em recursos isolados: um agente de teste, uma rota de gateway e um endpoint de modelo dedicados, que nenhum trabalho de produção utilize. Sugerimos confirmar primeiro até que ponto a ativação pode ter o escopo restringido. Se não for possível limitá-la à rota de teste, combine uma janela programada com os responsáveis de negócio afetados.

Aprovado: cada um termina com um status final registrado.

• [ ] Acione o kill switch contra o agente de teste. Aprovado: a próxima solicitação ao modelo é bloqueada e registrada.
• [ ] Tente uma chamada ao modelo a partir do mesmo agente usando qualquer chave direta. Aprovado: a chamada falha.
• [ ] Revogue os tokens de acesso e de atualização separadamente e teste cada um. Aprovado: ambos falham em todos os serviços usados.
• [ ] Capture evidências de um processo de teste iniciado antes do bloqueio. Aprovado: os registros são armazenados antes do encerramento e o processo é rastreado até o agente.
• [ ] Interrompa esse processo e um processo filho desacoplado. Aprovado: não resta nenhum processo atribuído.
• [ ] Cancele uma chamada de ferramenta de longa duração. Aprovado: o registro corresponde ao estado real a jusante.
• [ ] Retenha o trabalho em fila e consulte as tarefas. Aprovado: todas as tarefas mostram o status de canceladas e nada é executado quando o acesso volta.
• [ ] Conclua a aprovação da recuperação. Aprovado: o aprovador designado assina com base nas evidências vinculadas.

Ressalvas e o que ainda não foi comprovado

O MLQ.ai relata que a cobertura independente não encontrou nenhum teste publicado por terceiros que mostre a rapidez com que o kill switch atua ou se ele alcança agentes que operam fora de um gateway controlado. Críticos ouvidos na matéria da CNBC vão além e consideram um botão de parada de emergência complicado demais de implementar em vários sistemas, data centers e modelos complexos de IA. Esperamos que a resposta varie conforme a quantidade dos seus agentes que passa por um gateway conectado, o número de ferramentas que eles acessam e a forma como os seus runtimes lidam com o cancelamento.

Este é um lançamento recente e o escopo pode mudar, portanto consulte a documentação atual da CrowdStrike antes de finalizar os procedimentos.

As orientações de protocolo também exigem disciplina de versão.