Runbook de emergência: retome o controle de agentes de IA

Sistemas controlados por agentes precisam de um procedimento de emergência antes de precisarem de mais uma configuração de permissão. Quando um agente pode chamar uma API, abrir uma sessão SSH, modificar uma implantação ou enviar dados para um serviço externo, uma pessoa precisa conseguir interromper o trabalho, remover a autoridade e reconstruir o que aconteceu sob pressão.

Um runbook de emergência não torna seguro um projeto inseguro. Ele dá às pessoas uma forma de conter a incerteza antes que ela cause danos. A versão útil cabe em uma página para os primeiros quinze minutos, identifica a autoridade real em vez de se basear apenas em cargos e foi testada por pessoas que não participaram de sua elaboração.

A autoridade de emergência deve pertencer a funções nomeadas

Um runbook de emergência só funciona quando diz quem pode agir sem buscar outra autorização.

«A equipe de plataforma» e «a segurança» não são respostas às 02:00, especialmente quando várias pessoas presumem que outra pessoa é responsável pela decisão.

Defina quatro funções e associe cada uma a pessoas atuais e substitutas. A mesma pessoa pode ocupar duas funções em uma equipe pequena, mas não permita que uma pessoa concentre todas elas.

• O líder do incidente declara o modo de emergência, define o objetivo imediato e registra as decisões.
• O responsável pela revogação desativa a sessão do agente, seu canal de ação ou as credenciais às quais ele consegue chegar.
• O responsável pelo serviço decide se uma carga de trabalho crítica pode ser pausada com segurança e valida a recuperação.
• O responsável pelo registro mantém um log de eventos com horários e protege o pacote de evidências.

O responsável pela revogação precisa ter autoridade técnica antes de um incidente. Isso significa poder desativar o processo do agente, remover o acesso no ponto de ação e solicitar a rotação de credenciais quando necessário. Dar a essa pessoa um número de telefone de emergência, mas não o acesso ao console necessário, cria uma função apenas simbólica.

Sempre que possível, use dois responsáveis pela revogação, um principal e um substituto, de linhas de reporte diferentes. O responsável pelo serviço pode se opor a uma indisponibilidade prolongada, mas não deve poder vetar a contenção inicial quando o líder do incidente acredita que um agente ativo pode ser inseguro. O serviço pode ser restaurado depois que a situação for compreendida. Uma chamada a uma API externa ou um comando SSH destrutivo não pode ser desfeito.

Inclua no runbook, para cada função, o nome, o substituto, o método de contato durante o expediente, o método fora do horário, se houver, e os sistemas que a pessoa realmente consegue controlar. Revise a lista depois de mudanças na equipe. Uma lista de contatos desatualizada não é um pequeno problema administrativo. Ela força os responsáveis a improvisar justamente quando deveriam executar o procedimento.

Separe autoridade de consulta. A área jurídica, compliance, suporte ao cliente e a liderança sênior podem precisar ser avisados, dependendo do trabalho afetado. Essas pessoas não devem formar uma fila diante da contenção. O líder do incidente deve informá-las depois da primeira ação segura, salvo quando uma obrigação legal específica exigir o contrário.

Parar, revogar e preservar são ações diferentes

Parar um processo de agente, revogar sua autoridade e preservar evidências resolvem problemas diferentes. As equipes costumam misturá-los e depois acreditam que um processo inativo perdeu o acesso, quando isso não aconteceu.

Parar impede que aquele processo continue trabalhando. Isso pode significar encerrar um processo local, desativar uma tarefa agendada, pausar um executor de agente ou remover um gatilho de repositório. Pare primeiro se o processo ainda estiver ativo e seu comportamento for incerto.

Revogar remove a autoridade que tornou a ação possível. Isso pode envolver desativar uma sessão de ação, retirar uma identidade de serviço, bloquear um cofre de acesso, substituir um token upstream ou bloquear uma integração específica. Um agente parado hoje pode ser reiniciado amanhã a partir de uma fila de novas tentativas ou em outra máquina. Sua autoridade não pode continuar disponível por acidente.

Preservar significa capturar o que os responsáveis precisam antes que a recuperação de rotina substitua essas informações. Registre a identidade do processo, a revisão de origem ou o contexto do prompt quando relevante, a conta do operador, os horários de início e parada, os serviços de destino e a última ação confirmada. Preserve logs e snapshots de configuração de acordo com suas regras de retenção. Não cole segredos em um ticket de incidente durante a coleta de evidências.

Use este cartão de decisão nos primeiros minutos:

ID do incidente:
Declarado por / horário:
Processo ou sessão do agente afetado:
Risco imediato: chamadas ativas / possível exposição de credencial / desconhecido

[ ] Parar a execução atual
[ ] Revogar a autorização do agente
[ ] Bloquear ou trocar o caminho da credencial afetada
[ ] Preservar a identidade do processo e os registros de ações
[ ] Avisar o responsável pelo serviço

Responsável pela revogação / horário:
Responsável pelo registro / horário:
A recuperação é proibida até que o líder do incidente a aprove.

A última linha evita uma falha conhecida. Um desenvolvedor percebe que o trabalho de produção foi pausado, reinicia o agente para liberar a fila e destrói a fronteira clara que os responsáveis acabaram de criar. A recuperação precisa de uma decisão separada porque altera o risco novamente.

Não exija que os responsáveis provem um comportamento malicioso antes de agir. Um destino estranho, um fluxo de aprovação que falhou, um agente que não para ou uma diferença entre as ações esperadas e observadas já é suficiente para conter primeiro. A revisão poderá distinguir depois um defeito, uma configuração equivocada e um ataque.

O trabalho urgente precisa de um caminho estreito de aprovação

Às vezes, um trabalho urgente não pode esperar pelo responsável habitual, mas «urgente» costuma ser usado para ignorar justamente os controles que revelariam uma solicitação inadequada. O runbook deve permitir uma exceção restrita sem transformar todo incidente em uma aprovação geral.

Defina trabalho urgente como um resultado específico do serviço que sofrerá um dano relevante se esperar pelo caminho normal. Uma implantação pendente porque alguém quer terminar antes do almoço não é urgente. Restaurar uma dependência de produção que falhou pode ser urgente. A descrição deve identificar a ação exata, o alvo, o resultado esperado e o último horário em que a conclusão ainda será útil.

Use esta sequência de aprovação:

1. O solicitante informa o impacto no serviço, a ação exata proposta, a conta ou o ambiente afetado e o horário de expiração.
2. O líder do incidente confirma que a contenção continua ativa e nomeia um responsável pelo serviço ou delegado para validar o escopo.
3. O responsável pela revogação concede apenas a autoridade necessária para aquela ação, com expiração explícita e aprovador registrado.
4. O solicitante executa o trabalho enquanto o responsável pelo registro captura o registro da ação e o resultado.
5. O responsável pela revogação remove a autoridade temporária imediatamente depois que o resultado é verificado.

O registro da aprovação deve ser simples e completo. Não aceite «aprovado, corrija por favor» em um chat. Exija uma declaração como esta:

Autorização de trabalho de emergência
ID da solicitação: IR-2025-041
Ação solicitada: reiniciar a implantação payment-worker em produção
Escopo: uma implantação nomeada, sem gravações no repositório, sem alterações de conta
Motivo: a fila está falhando e a janela de recuperação manual termina às 14:30 UTC
Aprovador: delegado do responsável pelo serviço
Responsável pela concessão: responsável pela revogação de acesso
Expira: 14:30 UTC
Resultado e horário da remoção:

O exemplo não dá ao responsável permissão para reiniciar qualquer coisa. Ele mostra o nível de especificidade que evita o aumento do escopo. «Restaurar a produção» esconde dezenas de ações possíveis. Uma implantação nomeada e um horário de expiração podem ser verificados.

Se puder evitar, não use uma credencial de emergência permanente nesse caminho. As equipes gostam do acesso de emergência permanente porque ele parece rápido. Ele também cria um alvo de alto valor permanente e, com o tempo, as pessoas passam a usá-lo no trabalho comum por conveniência. Use uma autoridade concedida para uma ação delimitada e remova-a depois.

Se nenhuma pessoa autorizada puder aprovar uma ação urgente, mantenha a contenção e escale pela cadeia de responsabilidade. Uma recuperação atrasada prejudica. Uma recuperação não autorizada que amplia um incidente pode prejudicar muito mais.

Os primeiros quinze minutos devem ser mecânicos

Sob estresse, as pessoas esquecem horários, discutem termos e presumem que um colega realizou uma ação. Um runbook precisa de uma sequência ordenada de primeira resposta que funcione mesmo quando a causa ainda é desconhecida.

No minuto zero, a pessoa que observa o problema cria um registro de incidente e declara o fato observável. Escreva «o processo do agente enviou solicitações para um endpoint não reconhecido», em vez de «o agente foi comprometido». Fatos resistem melhor à revisão posterior do que teorias iniciais.

O líder do incidente então declara um de dois estados: investigação ou contenção de emergência. Investigação significa que não há indicação de autoridade insegura ativa e que a equipe pode inspecionar sem pausar o trabalho. Contenção de emergência significa que a equipe não consegue determinar com segurança a autoridade ou as ações atuais do agente. O segundo estado autoriza o responsável pela revogação a agir.

Durante os quinze minutos seguintes, faça o seguinte, nesta ordem:

1. Identifique o processo ou a sessão ativa e registre sua identidade visível, host, responsável, horário de início e tarefa atual.
2. Interrompa novas execuções se ela ainda estiver ativa ou se um agendador puder relançá-la.
3. Revogue a autoridade disponível para esse processo, começando pelo caminho de ação externa mais relevante.
4. Avise o responsável pelo serviço afetado de que a contenção está ativa e informe claramente a consequência operacional.
5. Preserve os registros de ações e o contexto da configuração antes de alterar configurações não relacionadas.

Evite uma limpeza ampla nesse período. Não reconstrua hosts, apague diretórios de trabalho, troque todos os segredos da empresa nem altere configurações de implantação apenas porque a situação parece alarmante. Essas ações podem ser justificadas mais tarde, mas enterram as evidências e criam indisponibilidades sem relação com o incidente.

O responsável pelo registro deve manter uma linha do tempo simples em um único local compartilhado:

14:07  Observador relatou uma solicitação externa inesperada da execução A-184 do agente.
14:09  Líder do incidente declarou contenção de emergência.
14:10  Responsável pela revogação interrompeu a execução A-184 e desativou sua autorização de ação.
14:12  Responsável pelo serviço confirmou que o processamento de pedidos pode ser pausado.
14:14  Responsável pelo registro salvou os registros de ações e o resumo da configuração.
14:18  A equipe iniciou a revisão do escopo. Nenhuma autoridade de recuperação foi concedida.

Isso é mais útil do que uma longa narrativa escrita depois. Mostra o que a equipe sabia, quem agiu e quando a autoridade mudou. Mantenha opiniões e hipóteses em uma nota de investigação separada.

A fadiga de aprovações é uma falha de projeto

As pessoas ignoram avisos quando o mesmo prompt aparece tanto para um trabalho inofensivo quanto para um trabalho de grande consequência. Repetir aprovações não gera cuidado. Ensina as pessoas a clicar no cartão para que o trabalho continue.

Seu runbook de emergência deve indicar quais ações exigem uma decisão humana explícita e quais podem prosseguir dentro da autoridade normal. Torne essa fronteira relevante. Uma ação que altera a infraestrutura, alcança um novo destino externo, modifica uma conta ou usa uma credencial fora do caminho esperado do serviço merece mais análise do que uma operação de leitura que permanece dentro de um escopo conhecido.

Não tente resolver isso com uma política escrita enorme, cheia de condições. Durante um incidente, o responsável precisa de poucas escolhas claras: negar, parar, revogar, conceder uma ação de emergência delimitada ou restaurar a operação normal. Se o procedimento exigir a interpretação de vinte cláusulas de exceção, ele falhará de uma forma diferente para cada pessoa.

A tela ou o registro de aprovação deve identificar o chamador de forma suficiente para que uma pessoa diferencie uma execução esperada de uma inesperada. O nome do processo, sozinho, é uma evidência fraca, porque nomes são fáceis de copiar. Capture a origem do processo, a identidade de assinatura de código quando o sistema operacional a fornecer, o contexto de inicialização e o identificador da sessão. Assim, o aprovador pode dizer «esta é a ferramenta de desenvolvimento esperada, iniciada a partir deste caminho», em vez de «o rótulo parece familiar».

Uma recomendação ruim e comum diz que toda chamada sensível deve exigir aprovação humana. Parece segura porque coloca uma pessoa em cada etapa. Falha quando uma tarefa legítima faz muitas chamadas: o operador aprova sem olhar, o agente não consegue concluir uma manutenção delimitada e a equipe acaba desativando a configuração. Reserve a aprovação de uso único para autoridades com consequência relevante e use aprovação no nível da sessão apenas quando a identidade da sessão estiver clara e seu escopo for aceitável.

O Sallyport segue essa divisão prática com um bloqueio do vault, autorização padrão por sessão e uma exigência opcional por chave para aprovar cada uso. Isso não substitui um runbook, porque uma pessoa ainda precisa ter autoridade para interromper o trabalho e decidir se uma exceção urgente é justificável.

Os logs devem responder quem agiu e quem aprovou

Um registro de incidente que diz «foi o agente» está incompleto. Agentes funcionam por meio de processos, identidades, canais de ação e caminhos de aprovação humana. Suas evidências precisam mostrar cada elo.

Para cada chamada importante, preserve a identidade da sessão ou do processo do agente, a pessoa ou o sistema que a iniciou, o serviço ou host de destino, a ação solicitada, o estado da autorização, o resultado e um horário confiável. Para trabalhos de emergência, registre o aprovador, o responsável pela revogação, o escopo solicitado, a expiração e o horário da remoção junto ao registro da chamada.

Mantenha o registro da aprovação separado do resultado da ação e associe-os por um identificador de incidente ou solicitação. Essa distinção importa. Uma aprovação significa que alguém autorizou uma tentativa delimitada. Ela não prova que a tentativa foi bem-sucedida, que tocou apenas no objeto pretendido ou que parou na expiração.

Faça estas perguntas durante a revisão:

• Qual processo fez a solicitação e como ele foi iniciado?
• Qual autoridade permitiu a solicitação naquele momento?
• Quem aprovou o trabalho de emergência e qual escopo exato foi aprovado?
• O resultado correspondeu a esse escopo?
• Um revisor independente consegue detectar registros alterados ou ausentes?

A NIST Special Publication 800-61 Revision 2, Computer Security Incident Handling Guide, trata preparação, detecção e análise, contenção, erradicação e recuperação e atividades pós-incidente como trabalhos conectados. Suas orientações sobre documentar e preservar dados de incidentes continuam úteis, mas as operações com agentes acrescentam um detalhe que runbooks antigos costumam ignorar: é necessário registrar a autoridade de máquina delegada, não apenas os logins humanos.

Não confunda logs comuns da aplicação com uma trilha de auditoria. Os logs da aplicação podem omitir o contexto de autorização, permitir alterações administrativas amplas ou desaparecer quando uma máquina for reconstruída. Preserve-os, mas documente o que cada registro pode e não pode provar.

Para sistemas que mantêm uma cadeia criptográfica de auditoria, inclua a verificação no exercício. O Sallyport oferece verificação offline com sp audit verify, permitindo que um revisor confira seu log de auditoria criptografado e encadeado por hash sem precisar da chave do vault. Execute esse comando contra um conjunto de evidências copiado durante o ensaio, não pela primeira vez quando o comandante do incidente estiver esperando uma resposta.

A recuperação precisa reconquistar a autoridade

Restaurar o serviço não é o mesmo que encerrar o incidente. A equipe deve restaurar apenas a autoridade que consegue explicar e fazer isso em etapas pequenas o suficiente para que uma recorrência tenha um limite visível.

Antes da recuperação, o líder do incidente precisa de três respostas: o que causou a decisão de contenção, qual autoridade foi exposta ou usada e qual controle agora impede uma repetição. Talvez a causa completa ainda não seja conhecida. Ainda assim, é preciso confiança suficiente para explicar por que a primeira ação restaurada é segura.

Restaure o serviço em etapas delimitadas. Comece, quando possível, com uma validação somente leitura, depois uma única ação conhecida e então uma execução curta monitorada. Não reative todos os agentes, integrações e credenciais porque um serviço se recuperou. Preserve a fronteira do incidente até que o responsável pelo serviço e o líder do incidente concordem que o caminho afetado foi compreendido.

Use uma autorização de recuperação diferente da aprovação de trabalho urgente. A aprovação de emergência permite uma ação necessária apesar do incidente. A aprovação de recuperação confirma que a autoridade normal pode retornar depois da contenção. Crie um registro separado:

Autorização de recuperação
ID do incidente:
Causa ou incerteza restante:
Autoridade a restaurar:
Validação realizada:
Responsável pelo monitoramento e horário da revisão:
Aprovado pelo líder do incidente e pelo responsável pelo serviço:

A expiração também importa aqui. Se uma concessão temporária de recuperação continuar disponível depois de um teste bem-sucedido, ela se transforma em acesso permanente não documentado. O responsável pela revogação deve confirmar sua remoção como parte do registro de recuperação.

A rotação de credenciais exige avaliação, não cerimônia. Faça a rotação quando a credencial puder ter chegado a um processo, destino, repositório, log ou pessoa não confiável, ou quando não for possível estabelecer seu limite de uso. Não diga que a rotação resolveu o incidente se um agente ainda tiver um caminho para obter a substituta pelo mesmo caminho inseguro. Corrija esse caminho primeiro.

A revisão pós-incidente deve gerar alterações, não apenas observações. Substitua «a comunicação não foi clara» por «o responsável pelo registro usará o modelo de linha do tempo e a página do responsável pelo serviço listará um substituto». Substitua «o acesso foi difícil» pela permissão exata que faltou, pela pessoa responsável por concedê-la e pela data do próximo exercício.

O ensaio revela as partes que ninguém assume

Um runbook que nunca foi exercitado é uma proposta. O primeiro uso real revelará contatos desatualizados, autoridade ausente e divergências sobre quem pode reiniciar o trabalho. Um ensaio transforma essas incógnitas em defeitos corrigíveis enquanto o risco ainda é baixo.

Faça primeiro um exercício de simulação e depois um exercício técnico controlado. Na simulação, dê aos participantes um cenário curto com informações incompletas, como um agente fazendo uma conexão SSH inesperada durante uma implantação. Peça que executem a árvore de contatos, decidam se devem conter, preencham o registro de aprovação e digam quais evidências preservariam. Não deixe o autor do runbook responder a todas as perguntas.

No exercício técnico, use um alvo que não seja de produção ou um caminho de teste explicitamente isolado. Inicie um processo de agente conhecido, autorize uma ação inofensiva, acione a contenção, confirme que novas ações falham, preserve os registros e faça uma recuperação limitada. Cronometre as ações, mas não transforme o exercício em uma competição de velocidade. Uma resposta rápida que não revoga o acesso é pior do que uma resposta mais lenta que estabelece uma fronteira clara.

Avalie o exercício com verificações observáveis:

• O observador conseguiu chegar ao líder do incidente e ao responsável pela revogação usando os métodos documentados?
• O responsável pela revogação tinha a autoridade necessária sem que um administrador precisasse improvisar o acesso?
• A equipe distinguiu parar o processo de remover sua autoridade?
• Um revisor conseguiu associar a aprovação de emergência ao registro da ação resultante?
• O acesso temporário desapareceu no horário de expiração ou remoção informado?

A NIST SP 800-61 recomenda explicitamente testar as capacidades de resposta a incidentes e apresenta uma razão prática: os exercícios revelam lacunas nos procedimentos, no treinamento e nos controles técnicos. Não limite os testes à equipe de resposta a incidentes. Inclua as pessoas que executam o agente, são responsáveis pelo serviço afetado e aprovam trabalhos urgentes. Geralmente são as suposições dessas pessoas que fazem o processo falhar.

Atualize o runbook imediatamente depois do exercício, enquanto os nomes, atrasos e instruções confusas ainda estão frescos. Depois agende o próximo exercício e atribua cada correção a uma pessoa responsável. Se ninguém for responsável por uma correção, você registrou um defeito e escolheu não corrigi-lo.

Coloque o cartão da primeira ação onde a falha não possa se esconder

O runbook completo pode ficar no sistema controlado de documentação, mas os responsáveis precisam de um cartão curto que continue disponível quando as ferramentas comuns estiverem lentas ou afetadas. Mantenha-o em um local que a equipe consiga acessar sem depender do ambiente do agente e garanta que o cartão aponte para contatos atuais, em vez de copiar detalhes que mudam com frequência.

O cartão deve dizer ao observador para quem ligar, informar ao líder do incidente quando ele pode declarar contenção, dizer ao responsável pela revogação qual autoridade remover primeiro e lembrar a todos que a recuperação exige uma nova decisão. Também deve indicar o registro de evidências e o local onde o responsável pelo registro escreve a linha do tempo.

Revise o cartão sempre que mudar os executores de agentes, os canais de ação, a responsabilidade ou os sistemas que concedem acesso. Não espere uma auditoria anual. No momento em que uma equipe muda a forma como um agente alcança o mundo externo, seu procedimento de emergência pode ter virado ficção.

Um bom exercício termina com uma lista um pouco constrangedora de suposições que não foram percebidas. Guarde essa lista. A equipe que encontra suas falhas no ensaio fez o trabalho necessário para não encontrá-las durante uma indisponibilidade.