# Agentes de resposta a incidentes: acesso à produção sem caos

Os agentes de resposta a incidentes de produção devem investigar primeiro e só iniciar a recuperação depois que uma pessoa aprovar uma ação pequena e identificada. Esse limite é prático, não cerimonial. Durante uma interrupção, um agente consegue reunir evidências dispersas mais depressa do que uma pessoa cansada, mas não pode assumir a decisão de alterar o estado em produção.

O projeto problemático dá ao agente um shell de produção, uma função ampla na nuvem e uma frase no runbook que diz «use o bom senso». Isso parece rápido até que o agente reinicie o pool de trabalhadores errado, aumente a escala de uma implantação com defeito, altere uma credencial que uma dependência ainda precisa ou transforme uma falha isolada em uma interrupção maior. Um bom projeto fornece um mapa de diagnóstico e mantém as ações de recuperação em uma quantidade pequena o bastante para que uma pessoa entenda cada uma.

## Autoridade de diagnóstico e autoridade de recuperação são permissões diferentes

O trabalho de diagnóstico pergunta ao sistema o que aconteceu. O trabalho de recuperação diz ao sistema para se tornar diferente. As equipes confundem os dois porque um comando como `restart` parece rotineiro e porque muitos painéis permitem inspecionar e alterar o mesmo recurso na mesma tela. Tratar ambas as coisas como uma única permissão é o caminho para transformar um assistente útil em um operador de produção cuja responsabilidade não está clara.

As ações de diagnóstico não devem alterar o comportamento do serviço. Elas podem ler métricas, consultar logs dentro de um intervalo definido, obter metadados de implantação, consultar endpoints de saúde, comparar revisões de configuração e coletar informações limitadas do banco de dados. Uma ação de diagnóstico pode revelar informações sensíveis, por isso ainda precisa de escopo e registros de auditoria. Ela não precisa ter autoridade para alterar o estado da aplicação.

As ações de recuperação alteram alguma parte do sistema em execução. Elas incluem reversão, reinicialização, mudança de tráfego, escalonamento, alterações em feature flags, rotação de credenciais, reprocessamento de filas, failover, reparo de banco de dados e desativação de uma integração. Algumas ações são reversíveis, mas nenhuma é inofensiva por padrão. Uma reinicialização pode encerrar o único processo que mantém um lease. O escalonamento pode esgotar uma dependência compartilhada. O reprocessamento de uma fila pode duplicar mensagens de clientes.

Use este teste ao classificar uma ação: se repetir exatamente a mesma ação no mesmo momento puder produzir um resultado diferente porque ela altera o estado, coloque-a na categoria de recuperação. Se uma ação alterar um cache, criar um chamado de suporte, enviar uma mensagem, mudar o silenciamento de um alerta ou gravar uma anotação consumida por outra automação, ela também altera o estado. Não chame essas ações de leituras apenas porque elas não tocam o banco de dados principal.

A NIST SP 800-61 Revision 2 separa contenção, erradicação e recuperação de detecção e análise. Essa divisão é útil aqui. Um agente pode reduzir bastante o tempo de detecção e análise. No momento em que propõe contenção ou recuperação, uma pessoa responsável precisa escolher a ação e aceitar suas consequências. O documento não resolve seu modelo de autorização, mas suas fases de incidentes evitam uma ficção perigosa: investigação e intervenção não são o mesmo trabalho.

Uma função somente leitura não é automaticamente segura. Consultas de logs podem conter tokens de acesso. Atributos de rastreamento podem expor identificadores de contas. Um endpoint de configuração pode retornar credenciais. Inclua mascaramento e limites de campos na interface de diagnóstico, em vez de dar ao agente a capacidade de buscar artefatos brutos arbitrários. A visibilidade de produção precisa de seu próprio limite.

## Dê ao agente perguntas, não um shell de produção genérico

Um agente trabalha melhor sob pressão quando suas ferramentas expressam diretamente as perguntas do incidente. Um shell genérico obriga o agente a descobrir o sistema e o procedimento seguro enquanto o relógio corre. Ele também torna a revisão quase impossível, pois `kubectl`, CLIs de nuvem, clientes de banco de dados e SSH podem fazer muito mais do que o incidente exige.

Exponha ações de diagnóstico baseadas nas evidências que uma pessoa pediria nos primeiros minutos:

- obter taxa de erros, latência, saturação e disponibilidade de um serviço e intervalo de tempo nomeados
- localizar a implantação, a revisão de configuração e as alterações nas dependências próximas do primeiro erro
- pesquisar logs estruturados usando um conjunto de campos permitido e um tamanho máximo de resultados
- consultar a saúde e os eventos recentes de um componente especificado
- comparar um canário ou uma região com um equivalente conhecido por estar saudável

Cada ação precisa de um contrato de entrada restrito. `get_service_errors(service, start, end, group_by)` informa ao revisor o que o agente solicitou. `run_query(text)` não informa praticamente nada e convida a varreduras completas acidentais, predicados inseguros ou texto de consulta injetado por um prompt.

Coloque limites rígidos na ferramenta, em vez de pedir ao modelo que se lembre deles. Uma ferramenta de métricas deve rejeitar um intervalo de tempo amplo demais. Uma ferramenta de logs deve limitar os registros retornados e mascarar os campos configurados antes que o modelo os receba. Uma consulta de implantação deve aceitar um identificador de aplicação vindo de um inventário conhecido, não uma URL arbitrária fornecida por um comentário de issue. Esses limites reduzem custos e impedem que um incidente se transforme em um exercício de exfiltração de dados.

O catálogo de ações a seguir é intencionalmente sem graça. Em uma interrupção, isso é um elogio.

```yaml
incident_actions:
  diagnostics:
    - name: service_summary
      inputs: [service, start_time, end_time]
      limits: {max_window_minutes: 180}
    - name: recent_deployments
      inputs: [service, since_time]
    - name: log_sample
      inputs: [service, start_time, end_time, error_code]
      limits: {max_records: 200, redact_fields: [authorization, cookie, token]}
    - name: dependency_health
      inputs: [dependency, region]
  recovery:
    - name: rollback_release
    - name: set_traffic_weight
    - name: restart_component
    - name: disable_feature_flag
```

Esse fragmento impede uma falha comum em ferramentas internas: um agente supostamente somente leitura recebe um endpoint de consulta universal porque isso é conveniente para a primeira demonstração. Mais tarde, alguém descobre que ele consegue obter todas as linhas de log de todos os serviços ou chamar um caminho de escrita oculto. Os nomes das ferramentas não criam segurança. Validação de entrada, uma lista de permissões, saída limitada e credenciais que não podem escrever, sim.

Não dê SSH de produção a um agente de diagnóstico apenas porque SSH facilita a inspeção. O acesso ao shell reúne leitura de arquivos, controle de processos, acesso à rede e, muitas vezes, um caminho até as credenciais. Se for necessário expor informações do host, forneça comandos específicos, como status de processos, uso de disco, entradas selecionadas do journal ou um wrapper de comandos controlado. O wrapper deve rejeitar pipes, redirecionamentos, substituição de comandos e flags arbitrárias. Uma instrução em linguagem natural não torna um shell seguro.

## Um catálogo de recuperação deve ser curto o bastante para ser ensaiado

Uma pessoa não consegue aprovar de forma significativa um menu interminável de alterações em produção. Defina um catálogo curto de recuperação para cada classe de serviço, com descrições simples, parâmetros fixos sempre que possível e um responsável definido. Se uma ação de recuperação não puder ser explicada em um único cartão de aprovação, ela precisa ser dividida antes que um agente possa solicitá-la.

Um catálogo sensato pode incluir reverter para a versão aprovada imediatamente anterior, definir em zero o peso de tráfego de uma revisão não saudável, reiniciar um componente stateless nomeado, desativar uma feature flag preexistente ou pausar um consumidor nomeado. Ele não deve incluir «executar correção arbitrária», SQL arbitrário, alterações amplas no IAM ou scripts improvisados copiados de uma conversa com o agente.

Para cada item do catálogo, registre cinco fatos antes que um incidente force a discussão:

1. Diga exatamente o que muda, incluindo o ambiente e o escopo do recurso.
2. Nomeie os pré-requisitos que o agente precisa coletar, como um identificador de versão confirmado ou um fallback saudável.
3. Informe o que deve ser observado depois da execução e o tempo máximo de espera antes da escalação.
4. Nomeie a ação de reversão ou compensação, se houver.
5. Defina a função humana que pode aprová-la.

O catálogo precisa de limites para os parâmetros. «Definir o peso do tráfego» é amplo demais. «Definir a revisão `orders-v184` como zero por cento em `eu-west` depois que a revisão estável estiver saudável» é uma solicitação que pode ser aprovada. A solicitação não deve permitir que o modelo escolha uma região, uma revisão e uma porcentagem sem restrições.

Não faça a lista de ações parecer completa. Ela deve deixar de fora ações que exigem julgamento específico. Reparo de migração de banco, exclusão de dados, comunicação com clientes, concessão de acesso e rotação de credenciais geralmente envolvem informações que nenhum agente genérico de incidentes consegue inferir. O resultado correto para uma ação não listada é uma recusa clara acompanhada das evidências já coletadas.

Um catálogo curto também permite realizar exercícios. Execute um incidente de teste e pergunte se a pessoa designada para aprovar consegue distinguir uma solicitação para pausar um consumidor de uma solicitação para excluir sua fila pendente. Se a resposta depender da leitura do código-fonte ou da confiança no resumo do agente, o texto da aprovação é fraco.

## A aprovação deve vincular uma solicitação exata a uma pessoa e a um momento

Uma aprovação humana só é útil quando autoriza uma ação proposta específica, não uma sessão vaga de incidente. «Aprovar correção para pagamentos» deixa espaço para o agente escolher uma alteração depois que a pessoa parou de observar. Vincule a aprovação ao tipo de ação, ao destino, aos parâmetros, ao identificador do incidente, à identidade do solicitante e a uma expiração curta.

Uma solicitação de aprovação deve mostrar as evidências que sustentam a ação, mas deve separar a evidência da alteração solicitada. As pessoas responsáveis pelo incidente precisam ver que as taxas de erro subiram depois da versão `184`, que a versão anterior continua disponível e que a região selecionada tem capacidade saudável. Elas também precisam ver exatamente o que acontecerá se clicarem em aprovar.

Use um objeto de solicitação com campos imutáveis e rejeite a execução se algum campo aprovado mudar:

```json
{
  "incident_id": "inc-2025-041",
  "action": "rollback_release",
  "target": {"service": "orders", "environment": "production", "region": "eu-west"},
  "parameters": {"from_release": "184", "to_release": "183"},
  "evidence_refs": ["metric:err-17", "deploy:184", "health:183"],
  "requested_by": {"agent_session": "sess-8f2a", "process_identity": "signed-agent-build"},
  "expires_at": "2025-03-08T14:35:00Z"
}
```

O executor deve retornar um resultado que preserve o identificador da solicitação e registre se a ação foi iniciada, concluída, falhou ou expirou. Uma mensagem de status como «reversão concluída» é vaga demais para uma linha do tempo de incidente. O agente deve ler o resultado e executar novamente suas verificações de diagnóstico. Ele não deve presumir que uma resposta bem-sucedida da API restaurou o serviço.

Não use uma única aprovação inicial para todas as ações posteriores. O cansaço causado por aprovações é real, mas uma autorização abrangente troca o cansaço pela ambiguidade. Agrupe apenas ações que compartilhem o mesmo destino, efeito esperado e risco. Uma pessoa pode aprovar a remoção do tráfego e a reversão de uma versão como um único pacote de recuperação se ambas estiverem definidas previamente. Isso não deve aprovar uma alteração no banco, uma rotação de credencial ou uma região diferente.

Exija uma nova aprovação quando a hipótese do agente mudar. Isso captura uma sequência de falha comum: o agente começa suspeitando de uma implantação, recebe aprovação para revertê-la, depois encontra um erro de banco e decide executar uma ação diferente com a autorização antiga. A aprovação anterior expirou em termos práticos, mesmo que o relógio diga que ainda não.

## Sessões de incidente evitam autoridade permanente em produção

Um agente de incidentes precisa de uma identidade separada da pessoa operadora e também separada do transcript da conversa. Registre qual executável ou processo remoto solicitou acesso, a qual incidente ele pertence, quais ações de diagnóstico invocou e quem aprovou cada solicitação de recuperação. Sem essa separação, a revisão pós-incidente se transforma em uma busca por prosa, em vez de um registro da autoridade exercida.

Uma sessão deve começar com uma referência ao incidente, um ambiente declarado, um escopo de diagnóstico explícito e uma expiração. Ela deve terminar quando o processo do agente sair, quando a expiração passar ou quando uma pessoa operadora a revogar. A revogação precisa ter efeito antes da próxima ação, inclusive das leituras. Durante um possível comprometimento de credenciais ou um evento de injeção de prompt, o acesso contínuo de leitura ainda pode aumentar o dano.

A autorização por sessão é um padrão melhor do que tratar cada chamada de diagnóstico como um prompt isolado. A primeira solicitação de um novo processo de agente dá à pessoa operadora a chance de verificar de onde veio a solicitação e por que ela tem visibilidade da produção. Depois, o agente pode coletar evidências sem pedir aprovação para cada gráfico ou amostra de log. A recuperação ainda precisa de aprovação própria para cada chamada.

A distinção entre identidade do agente e identidade do usuário importa em máquinas compartilhadas e ambientes semelhantes a CI. Uma conta humana pode estar autorizada a responder a incidentes, enquanto um processo de agente copiado ou um wrapper de ferramenta malicioso não está. Capture a autoridade de assinatura de código ou outra identidade de processo verificável quando o ambiente permitir. O título de uma janela e um rótulo fornecido pelo usuário não são identidade.

O Sallyport usa um bloqueio absoluto do cofre, autorização de sessão para um novo processo de agente e uma opção por chave para cada uso individual. Esse arranjo se adapta ao trabalho de incidentes porque a pessoa pode permitir uma execução de diagnóstico limitada e reservar credenciais sensíveis de recuperação para uma nova decisão.

Evite passar credenciais pelo contexto do agente, mesmo temporariamente. Uma credencial colada em um prompt de agente não pode ser retirada, e o agente pode reproduzi-la em um comando, transcript, log ou solicitação externa. O executor deve manter a credencial, realizar a ação permitida na API ou por SSH e retornar apenas o resultado necessário à investigação.

## Os registros de auditoria devem explicar a intenção e a execução

As notas de incidentes costumam registrar o que as pessoas acreditam que aconteceu. Raramente registram a solicitação exata feita pelo agente, a autoridade que a permitiu e o resultado retornado pelo sistema downstream. Você precisa dos quatro elementos. Uma linha do tempo que diga «o agente reverteu orders» não consegue responder se o agente solicitou uma reversão, se alguém aprovou a versão `183` ou se o sistema de implantação realmente aceitou o comando.

Registre um evento durável para a criação da sessão, a chamada de diagnóstico, a proposta de recuperação, a aprovação ou negação, a tentativa de execução, o resultado, a revogação e o fim da sessão. Cada evento deve incluir timestamp, identificadores de correlação, identidade do processo, nome da ação, destino, parâmetros normalizados e código de resultado. Armazene o conteúdo sensível das solicitações com cuidado: a auditoria precisa preservar o significado sem se tornar outro repositório de segredos sem controle.

Uma cadeia de hashes torna alterações posteriores detectáveis porque cada registro incorpora o hash do registro anterior. Ela não prova que o coletor recebeu todos os eventos desde o início. Projete para as duas propriedades. Torne o gravador de eventos difícil de reescrever pelo executor da ação, preserve os identificadores das solicitações upstream e verifique periodicamente a cadeia fora do controle do agente.

Um comando de verificação offline deve produzir um resultado simples e fácil de inspecionar:

```text
$ sp audit verify
verified: 1842 records
first sequence: 2025-03-08T12:01:09Z
last sequence:  2025-03-08T14:42:31Z
chain: valid
```

O Sallyport projeta um diário de sessão e um diário de atividades individuais a partir de um único log criptografado e encadeado por hash, e `sp audit verify` pode verificar a cadeia sobre o texto cifrado. Isso é útil como evidência de incidente porque a verificação não exige abrir o cofre apenas para descobrir se o histórico foi alterado.

Mantenha a revisão da auditoria fora do ciclo ativo do agente. O agente pode citar os identificadores das ações que registrou, mas a liderança ou o revisor do incidente deve conseguir inspecionar o registro de forma independente. Caso contrário, um agente que descreve incorretamente o que fez também pode controlar as evidências que a pessoa responsável vê.

## Uma reversão que falha mostra por que a evidência deve vir antes da intervenção

Considere um serviço cuja taxa de erros aumenta pouco depois de uma implantação. O agente percebe a coincidência temporal e propõe uma reversão. Um agente com acesso amplo à produção poderia executá-la imediatamente. Isso é rápido, mas pode estar errado.

Um agente disciplinado primeiro obtém a divisão dos erros por versão e região, os registros de implantação recentes, a saúde das dependências e a saturação dos recursos. As evidências mostram que apenas uma região falha, mas tanto a revisão nova quanto a anterior falham nela. Uma reversão gastaria tempo, criaria um segundo evento de implantação e deixaria a interrupção da dependência sem solução.

O agente não propõe nenhuma ação de recuperação. Ele informa que a falha é regional e que o endpoint de saúde da dependência está falhando. Uma pessoa então aprova uma mudança de tráfego previamente definida para afastar o tráfego dessa região, se a capacidade e as regras de dados do serviço permitirem. O agente executa a ação somente depois da aprovação, observa a taxa de erros resultante e registra a solicitação e o resultado.

Agora mude um detalhe. A ação de diagnóstico retorna um erro porque o intervalo de tempo solicitado é amplo demais. O agente deve informar que as evidências estão incompletas, em vez de tentar novamente em silêncio com uma exportação ampla de logs. Limites não são inconvenientes a contornar durante um incidente. Eles impedem que um modelo transforme incerteza em uma solicitação de acesso maior.

Outra variação é mais desconfortável: a mudança de tráfego aprovada é bem-sucedida na API, mas a taxa de erros não cai. O agente não deve se promover sozinho a reiniciar, reverter ou fazer rotação de credenciais. Ele deve coletar as próximas observações permitidas e preparar uma nova proposta. Pessoas também tomam decisões ruins durante incidentes, mas pelo menos devem tomar a decisão que fica registrada.

É por isso que a recomendação popular de conceder acesso amplo «somente durante incidentes» falha. Incidentes reduzem a atenção, aumentam a urgência e frequentemente envolvem telemetria parcial ou enganosa. Essas condições tornam interfaces restritas e aprovações explícitas mais necessárias, não menos.

## Inclua os caminhos de recusa no runbook antes da próxima interrupção

Um agente seguro de incidentes precisa de casos claros em que deve parar. O runbook deve instruí-lo a recusar uma alteração não listada, uma ação fora do ambiente declarado, uma solicitação sem pré-requisitos, uma aprovação expirada e qualquer operação depois da revogação da sessão. Cada recusa deve nomear a condição e preservar as evidências já coletadas.

Teste o caminho de recusa com o mesmo cuidado usado no caminho bem-sucedido. Peça ao agente que investigue um incidente de produção e injete uma solicitação de um ticket não confiável pedindo a recuperação de um valor secreto de configuração. Verifique se a ferramenta o rejeita. Solicite uma reversão depois que a aprovação expirar. Verifique se o executor a rejeita mesmo que o agente repita exatamente o texto da ação. Revogue a sessão enquanto uma sequência de diagnóstico estiver ativa. Verifique se a próxima chamada falha.

Mantenha as credenciais de recuperação separadas das credenciais de diagnóstico. Se a mesma credencial puder ler logs e excluir uma fila, uma tela de aprovação não corrigirá essa autoridade subjacente. O executor deve selecionar uma credencial cujas permissões correspondam à ação catalogada. Quando um sistema não puder oferecer essa separação, não o coloque atrás de um agente autônomo até adicionar um ponto de controle mais seguro.

A primeira implantação em produção desse padrão deve ter como alvo uma falha conhecida com uma correção limitada. Escolha um serviço em que as pessoas responsáveis já usem um pequeno conjunto de chamadas de leitura e uma ação de recuperação bem compreendida. Meça se as evidências do agente reduzem o tempo gasto reunindo fatos, se as pessoas aprovadoras entendem as solicitações sem ler um transcript e se o registro de auditoria reconstrói o evento. Amplie o catálogo somente depois que essas respostas se confirmarem nos exercícios.

Um agente de produção conquista confiança ao fazer menos escolhas do que uma pessoa responsável pelo incidente, não escolhas maiores. Dê a ele o trabalho de encontrar os fatos, preserve a decisão humana no ponto da alteração e torne visível cada passagem da evidência para a ação depois que o pager parar.