O que fazer quando segredos vazam para um agente de IA: revogação de acessos, auditoria e retomada do trabalho

Instruções verificadas com a documentação em 16 de setembro de 2026.

Quando um agente autônomo executa comandos como git diff, lê arquivos locais de configuração ou acidentalmente envia dumps de variáveis de ambiente diretamente no prompt do modelo, os segredos deixam o perímetro de confiança. Nessa situação, é necessário interromper os scripts em segundo plano, bloquear as credenciais comprometidas, auditar os logs com atenção às suas limitações e reiniciar o ambiente segundo o princípio do menor privilégio.

Separação entre configuração normal e vazamento de contexto

Antes de iniciar a resposta ao incidente, é fundamental distinguir o uso normal de APIs de um comprometimento real.

A operação normal pressupõe o envio da chave de API exclusivamente nos campos de autorização do provedor do modelo esperado (por exemplo, por meio das variáveis OPENAI_API_KEY ou ANTHROPIC_API_KEY) para autenticar as requisições da ferramenta ao modelo de linguagem. Variáveis como ANTHROPIC_BASE_URL ou OPENAI_BASE_URL definem o endereço de rede do endpoint (endpoint/base URL), e não um segredo ou token de autenticação.

Considera-se vazamento pelo modelo o evento em que segredos alheios da infraestrutura — tokens de acesso pessoal do GitLab, chaves de longo prazo do AWS IAM, chaves privadas SSH, credenciais de banco de dados ou tokens de rede corporativa — entram no corpo do prompt do usuário, no contexto do diálogo, em arquivos anexados ou no fluxo de saída de utilitários (stdout/stderr) e são efetivamente transmitidos para um serviço externo. Não se deve presumir malícia a priori de todos os servidores proxy ou gateways intermediários; contudo, o envio de um segredo para fora do perímetro isolado exige contenção imediata.

Primeiras ações: interrupção de processos e registro do incidente

A prioridade número um é evitar o envio adicional de dados:

1. Encerre o processo local do agente e desative tarefas em segundo plano associadas (tarefas cron, scripts de automação de CI/CD).
2. Registre os metadados do incidente em um relatório local sem duplicar o segredo em si: tipo de credencial comprometida, horário aproximado da primeira requisição, identificador da tarefa/sessão e endereço de rede (endpoint) do destinatário.
3. Não envie a chave exposta em texto puro para canais de suporte técnico ou em consultas de verificação a outras redes neurais.

Todas as operações de revogação e substituição de chaves devem ser realizadas exclusivamente a partir de uma estação de trabalho confiável, por meio dos consoles oficiais de gerenciamento dos provedores.

Revogação de acessos por tipo de serviço

Diferentes plataformas implementam o isolamento e o encerramento de privilégios de acordo com regras arquiteturais distintas.

Chaves de acesso a modelos (OpenAI API)

De acordo com as recomendações oficiais da OpenAI sobre segurança de chaves de API, a suspeita de comprometimento exige a rotação da chave e a verificação do consumo de recursos.

Ao suspeitar de um vazamento, a chave comprometida deve ser revogada primeiro:

1. Acesse imediatamente a interface web de gerenciamento de chaves de API da OpenAI e revogue (Revoke/Delete) a chave comprometida. Isso bloqueia novas chamadas não autorizadas ao custo de uma indisponibilidade temporária e controlada dos serviços dependentes; a revogação não deve ser adiada até a conclusão de uma auditoria completa ou de uma longa atualização em todos os clientes consumidores.
2. Gere uma nova chave e atualize as configurações dos serviços.
3. Abra o painel Usage e analise a atividade dentro da janela de exposição identificada, comparando-a com as operações esperadas.

Tokens de acesso pessoal do GitLab

Segundo a documentação do GitLab sobre Personal Access Tokens, a revogação de um token de acesso pessoal o invalida imediatamente:

1. Na interface do GitLab, clique no avatar no canto superior direito > Edit profile > Access > Personal access tokens.
2. Na tabela de tokens ativos, localize o identificador comprometido e clique em Revoke.

A função Rotate no GitLab invalida o token antigo, mas preserva os mesmos privilégios (scopes). Se o token comprometido possuía permissões excessivas, ele deve ser revogado por completo e substituído por um novo token com escopo mínimo. Na página de detalhes do token, estão disponíveis a data do último uso e os últimos cinco endereços IP únicos. Lembre-se de que esses indicadores são atualizados com atraso do sistema.

Chaves de acesso da AWS (IAM Access Keys)

O procedimento para neutralizar chaves do IAM é regido pelo guia da AWS sobre proteção de chaves de acesso e pela documentação de gerenciamento de chaves de acesso do IAM:

1. Faça login no AWS Management Console, acesse IAM > Users e abra a aba Security credentials.
2. Na seção Access keys, localize o identificador da chave comprometida e altere seu status para Deactivate.
3. Após restabelecer o controle, remova a chave clicando em Delete.

[!IMPORTANT] Alterar o status da chave para Deactivate impede a aceitação de novas requisições assinadas por essa credencial de longo prazo, mas não invalida credenciais temporárias emitidas anteriormente (tokens AWS STS) e não encerra sessões ativas automaticamente. A ação Revoke active sessions aplica-se apenas a sessões da respectiva IAM role; sessões ativas do IAM Identity Center e outros tipos de tokens STS exigem revogação separada conforme seus próprios mecanismos de autenticação. O administrador de segurança também deve correlacionar as chamadas por meio do AWS CloudTrail e da operação get-access-key-last-used. Não execute comandos destrutivos de exclusão em massa via CLI sem validação durante o incidente.

Chaves OpenSSH e autorização

Os procedimentos de autorização do OpenSSH são descritos nos manuais de referência man sshd(8) e sshd_config(5):

1. O administrador deve remover a chave pública comprometida do arquivo de autorização em todos os servidores. O caminho do arquivo é definido pela diretiva AuthorizedKeysFile (por padrão ~/.ssh/authorized_keys, mas a infraestrutura pode utilizar um arquivo centralizado ou validação de certificados via SSH CA).
2. Antes de aplicar as alterações, certifique-se de que há um canal de acesso independente de backup disponível (como o console web do provedor ou gerenciamento out-of-band), evitando perder o próprio acesso.
3. Remover a chave pública impede o estabelecimento de novas conexões, mas não encerra as sessões ativas.

O comando who exibe apenas os usuários com pseudoterminal (TTY) alocado e não serve como inventário completo de sessões: ele não mostra túneis, redirecionamentos de portas (port forwarding) ou comandos não interativos. Encerrar o processo raiz do sshd às cegas é inaceitável, pois não garante a finalização das sessões filhas e pode isolar o administrador do servidor. O administrador deve inspecionar de forma direcionada a árvore de processos, as conexões de rede e os logs de autorização, encerrando as sessões suspeitas específicas. Deletar a chave privada localmente ou alterar sua senha (passphrase) não tem efeito sobre uma chave que já foi copiada externamente.

Redes Tailscale e VPNs corporativas

De acordo com a documentação da Tailscale sobre Auth Keys, uma chave de autenticação serve exclusivamente para o registro de nós:

1. No console da Tailscale, acesse a seção Keys e revogue a auth key comprometida. Isso impedirá o registro de novos dispositivos.
2. Revogar uma auth key não desconecta nós já registrados. O administrador deve acessar a aba Machines, revisar a lista de equipamentos e remover manualmente (Remove/Delete) quaisquer dispositivos não autorizados.

Para VPNs corporativas tradicionais (IPsec, OpenVPN, WireGuard e soluções proprietárias), não existe um procedimento único e universal de revogação via CRL: o mecanismo específico depende do esquema de autorização adotado (certificados x509, chaves pré-compartilhadas estáticas, tokens RADIUS/IdP). Em muitos gateways, a alteração da senha da conta não resulta na queda imediata do túnel. O procedimento deve ser encaminhado ao administrador de rede para revogação do certificado/conta e encerramento forçado das sessões ativas pelo painel de controle do gateway VPN em questão.

Análise de consequências: logs, janelas de tempo e riscos irreversíveis

Ao correlacionar o incidente com os logs do sistema, considere as limitações técnicas da telemetria:

• Janela de exposição: determine o intervalo de tempo exato entre o primeiro envio do segredo ao agente e a confirmação da revogação da chave junto ao encerramento das sessões ativas.
• Limitações dos logs: leve em consideração o atraso no processamento dos eventos (ingestion delay), o período de retenção de logs (retention period) e os pontos cegos da telemetria (ausência de auditoria detalhada de parâmetros em determinadas APIs, ausência de logs para sessões sem TTY).
• Princípio da ausência de evidência: a inexistência de registros anômalos ou consumo zero de tokens na janela de logs disponível não comprova que o segredo não foi interceptado ou armazenado por terceiros para uso posterior.

A revogação de chaves bloqueia requisições futuras, mas não recupera dados, código-fonte ou variáveis de ambiente já transmitidos para um serviço externo. A funcionalidade de exclusão de conversas na interface web do agente ou da plataforma oculta o histórico, mas não serve como garantia técnica de que os dados foram expurgados dos logs ou do cache no provedor downstream.

Reinicialização segura: mitigação de riscos e validação do isolamento

O retorno do agente à operação deve reduzir o risco de reincidência do incidente:

1. Tokens de curta duração: utilize credenciais de sessão com tempo de expiração limitado sempre que as plataformas e a infraestrutura oferecerem suporte.
2. Fronteiras do espaço de trabalho: exclua arquivos .env, chaves privadas e diretórios com segredos do workspace do agente; mover segredos para fora não garante isolamento completo e não substitui o controle de acesso no nível do sistema operacional.
3. Validação de barreiras sem canários de rede: para testar as permissões, crie um diretório isolado temporário, completamente livre de segredos reais. Coloque ali um arquivo com um conteúdo fictício de teste e valide se o agente bloqueia o acesso a arquivos, a execução de comandos de shell e a leitura de variáveis via env. Não utilize serviços externos de canary tokens de rede para a validação básica de permissões.
4. Defesa em profundidade: bloquear com sucesso a leitura de um único caminho não comprova o isolamento total do processo se o agente mantiver acesso irrestrito ao terminal ou à rede.

Abordagens arquiteturais detalhadas para restringir chamadas de sistema e separar privilégios são analisadas no guia sobre gerenciamento de permissões e segredos no Claude Code. A minimização de privilégios e a eliminação de segredos estáticos reduzem os riscos ao delegar tarefas a ferramentas autônomas de IA.