---
title: "Teste o kill switch com a sessão ainda aberta"
slug: "teste-o-kill-switch"
date: "2026-10-12"
publishedAt: "2026-10-12T06:04:00-03:00"
author: "Rodrigo Jorge"
summary: "Parar o agente, revogar uma sessão e impedir novas credenciais são tarefas diferentes. O teste de desligamento precisa mostrar quais ações ainda podem acontecer."
origem: "Análise"
status: "published"
---

**Rodrigo Jorge** · Preparado em 12 de outubro de 2026, às 06:04 (horário de Brasília, UTC-3). Horário de publicação a confirmar.

Na demonstração, o operador desliga o agente e a tela para de receber mensagens. Isso comprova que a interface parou. A API ainda aceita a credencial que ele usava?

Esse é um cenário de teste, não o relato de um incidente. Como CISO, eu pediria essa verificação antes de autorizar um agente a alterar o ambiente. O objetivo do kill switch é interromper a capacidade de agir. Uma confirmação no painel não mostra, sozinha, que isso aconteceu.

## Sessão antiga, credencial nova

A documentação do AWS IAM oferece um exemplo concreto dessa diferença. Ao revogar sessões de um role, a AWS aplica a policy `AWSRevokeOlderSessions`, com um corte baseado na emissão das credenciais. Sessões emitidas depois do corte não ficam abrangidas por essa negação. A AWS também documenta atrasos na propagação de alterações de IAM.

Isso não é evidência de falha de um agente nem uma regra para toda plataforma. É o comportamento documentado de um mecanismo de revogação. Para um agente que usa esse mecanismo, a inferência operacional é direta: revogar sessões anteriores exige também verificar se ele continua autorizado a obter outras.

São dois testes. Com a sessão já aberta, tentar uma operação que antes era permitida. Depois, tentar obter uma nova sessão pelo caminho que a integração realmente usa. Uma recusa no primeiro teste não responde ao segundo. Esses testes devem usar uma identidade dedicada e recursos de laboratório, sem expor credenciais nos logs.

## A tarefa pode ter saído do agente

Considere um fluxo que envia um job a outro serviço. Depois que esse serviço aceita o pedido, parar o processo que o enviou pode deixar o job em execução. Aqui estamos descrevendo uma possibilidade arquitetural, não um comportamento comprovado em todos os serviços.

Por isso, minha proposta para o ensaio de desligamento inclui três observações: novas tarefas deixam de entrar; as credenciais já emitidas deixam de autorizar a ação prevista; tarefas aceitas por outro serviço são identificadas e tratadas conforme o mecanismo de cancelamento disponível.

Não é preciso pedir a um modelo que julgue essas condições. A evidência pode vir de respostas de API, estado da fila e registros de execução. O responsável pelo desligamento precisa conseguir acessá-la mesmo que o agente esteja indisponível ou comprometido.

[Ver o diagrama: o que verificar depois de acionar o kill switch](/assets/artigos/teste-o-kill-switch-pt.svg). Roteiro conceitual de teste, sem tempos medidos.

## O que eu pediria na avaliação

Um registro com o instante do comando de parada, a última ação aceita e a primeira recusa observada. Também a tentativa de renovação da sessão e o destino das tarefas pendentes. Se houver propagação de policy, o intervalo deve ser medido naquele ambiente; não há neste artigo um prazo universal de desligamento.

O teste precisa revelar ainda quem mais foi afetado. Revogar sessões de um role compartilhado pode interromper outros usuários. Identidades separadas por integração ajudam a delimitar esse impacto, mas não dispensam a conferência das permissões efetivas.

A decisão de liberar a operação deve considerar o que ainda pode acontecer nesse intervalo e o que já foi executado. Uma ação concluída exige avaliação e, quando possível, recuperação. O kill switch não desfaz o passado.

### Referências

- [AWS IAM: Revoke IAM role temporary security credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html), documentação consultada em 12 de outubro de 2026. Escopo da revogação e impacto em usuários do role.
- [AWS IAM: Changes that I make are not always immediately visible](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html#troubleshoot_general_eventual-consistency), documentação consultada em 12 de outubro de 2026. Propagação e verificação das alterações.