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. 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, 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, documentação consultada em 12 de outubro de 2026. Propagação e verificação das alterações.