Como revogar com segurança o acesso de um agente de IA durante uma tarefa ativa

Um agente de IA ativo não precisa ter intenção maliciosa para causar um incidente. Uma instrução inadequada, uma concessão de ferramenta ampla demais, um arquivo contaminado no repositório ou um operador confuso podem levá-lo a um ciclo destrutivo enquanto ele ainda tem acesso. A resposta precisa interromper rapidamente novas ações sem descartar o registro que explica o que aconteceu.

A reação inadequada mais comum é fechar o terminal, revogar todas as credenciais disponíveis e reconstruir o evento de memória na manhã seguinte. Isso cria uma interrupção maior e muitas vezes destrói a distinção entre o que o agente tentou fazer, o que um serviço remoto aceitou e o que realmente mudou. Trate um incidente com agente como um trabalho de contenção e preservação de evidências, não como uma interrupção constrangedora a ser escondida.

A revogação precisa interromper a autoridade futura antes de apagar a cena

Revogar um agente significa impedi-lo de realizar sua próxima ação privilegiada e, ao mesmo tempo, preservar estado suficiente para determinar se as ações anteriores tiveram sucesso. Encerrar uma janela visível de chat ou terminal pode não atender a nenhum desses objetivos. O processo pode ter filhos, o agente pode manter uma conexão remota aberta e uma solicitação HTTP pode continuar em execução depois que o processo local desaparece.

Separe estas quatro coisas antes de alterar os controles:

• O processo do agente é o programa local que gera decisões e chamadas de ferramentas.
• A sessão é a autoridade concedida àquela execução específica do processo.
• A credencial é o segredo ou a identidade aceito por um sistema externo.
• A operação remota é o trabalho já aceito por uma API, fila, host ou plano de controle de nuvem.

As pessoas costumam confundir revogação de sessão com alteração de credencial. A consequência é dolorosa. Se você alterar um token de implantação compartilhado para interromper um agente, pode quebrar a automação de produção enquanto a solicitação já aceita pelo agente continua em execução. Se apenas encerrar o processo do agente depois que ele copiou um token para o espaço de trabalho, pode deixar um segredo reutilizável para trás.

Por isso, a contenção deve seguir o controle confiável mais próximo do agente. Primeiro, negue a execução ativa. Depois, interrompa ou cancele o trabalho que passou para sistemas remotos. Recorra à desativação da credencial quando as evidências indicarem que o segredo pode não estar mais confinado ou quando não for possível confiar no limite da sessão.

Defina previamente uma regra simples para o incidente: a pessoa que perceber um comportamento suspeito pode interromper o agente imediatamente, sem esperar uma reunião. A revisão vem depois. Um processo de aprovação atrasado faz sentido para uma implantação, não para retirar a autoridade de um processo ativo.

Crie um mapa de ações antes do primeiro incidente

Não é possível revogar aquilo que não pode ser identificado. Cada execução de agente precisa de um identificador presente no registro do processo local, nos logs das ferramentas e nas solicitações que chegam aos sistemas remotos. Um ID de execução aleatório é suficiente, desde que seja transmitido de forma consistente. Não use um nome de pessoa nem um rótulo vago como coding-agent; ambos misturam atividades não relacionadas no mesmo grupo.

Para cada caminho pelo qual um agente pode agir, registre as respostas a cinco perguntas operacionais:

1. Qual processo local controla o caminho e como podemos interrompê-lo?
2. Qual sessão ou token representa esse processo para o gateway de ações?
3. Quais operações remotas podem continuar ativas depois da revogação local?
4. Onde logs de serviço independentes registram essas operações?
5. Quem pode desativar o caminho quando a pessoa normalmente responsável estiver indisponível?

Isso não é burocracia sem propósito. Durante um incidente, o operador não deveria precisar descobrir se uma migração de banco de dados passa por um processo filho do shell, um trabalho de CI, uma solicitação HTTP ou um fluxo de trabalho separado na nuvem.

Use o ID da execução como cabeçalho da solicitação sempre que uma API permitir. Para um agente com o ID de execução run_2025_04_18_7f3c, um wrapper pode adicionar um cabeçalho de correlação sem colocar um segredo no prompt ou no ambiente do agente:

export AGENT_RUN_ID="run_2025_04_18_7f3c"
curl -sS -X POST "$ACTION_ENDPOINT" \\
  -H "X-Agent-Run-ID: $AGENT_RUN_ID" \\
  -H "Content-Type: application/json" \\
  --data @request.json

O serviço receptor deve registrar o ID da execução junto com o ID normal da solicitação, a identidade do chamador, o endpoint, o status da resposta e o horário. Um registro útil tem uma estrutura como esta:

time=2025-04-18T14:12:09Z request_id=req_91a run_id=run_2025_04_18_7f3c caller=agent-gateway method=POST path=/deployments status=202

Um 202 é importante. Ele indica que o serviço aceitou o trabalho, não que o trabalho terminou. É aqui que muitas análises de incidentes dão errado: as equipes tratam a última saída da ferramenta do agente como o resultado, embora o sistema remoto tenha apenas confirmado o envio para uma fila.

Para SSH, mapeie a conta remota, os hosts de destino, eventuais comandos forçados e o local que registra logins e atividades de comandos. Uma transcrição do terminal local é útil, mas não prova que um comando não foi executado remotamente. Os próprios logs do host e a trilha de auditoria do serviço relevante é que respondem a essa pergunta.

Interrompa a execução ativa em uma ordem que preserve o controle

Comece registrando o horário e o motivo imediato da revogação. Depois, impeça novas ações e encerre o agente. Os comandos exatos variam conforme o sistema operacional e o ambiente de execução, mas a sequência não deve mudar, pois ela separa a contenção da limpeza.

1. Registre o ID da execução, o ID do processo local, o operador, o comportamento observado e o horário atual no registro do incidente. Faça uma cópia da transcrição atual do agente e da última chamada de ferramenta visível antes de fechar a interface.
2. Revogue ou bloqueie a sessão ativa no gateway que autoriza as ações. Confirme que uma nova chamada de teste do mesmo processo recebe uma negativa, caso exista uma operação segura somente de leitura.
3. Suspenda o processo local antes de encerrá-lo, quando o sistema operacional permitir. A suspensão oferece uma árvore de processos e uma lista de arquivos abertos estáveis. Encerre-o apenas depois de capturar esse estado, a menos que a execução contínua cause dano imediato.
4. Encontre e interrompa processos filhos, trabalhos em segundo plano, contêineres e sessões remotas ligados à execução.
5. Cancele o trabalho remoto aceito usando o mecanismo de cancelamento do próprio serviço e preserve a resposta e o status.

No macOS ou Linux, comece com uma inspeção, em vez de executar kill -9 às cegas. Substitua o ID de processo do exemplo pelo que você registrou:

ps -o pid,ppid,pgid,lstart,command -p 48192
pgrep -P 48192 -a
lsof -nP -p 48192
kill -STOP 48192

O primeiro comando registra a relação entre processos e o horário de início. pgrep mostra os filhos diretos, e lsof geralmente revela arquivos do espaço de trabalho, sockets e pipes abertos que vale a pena preservar. kill -STOP congela um processo cooperativo sem lhe dar outra oportunidade de emitir um comando de limpeza. Ele não congela um filho já separado, um trabalho remoto nem uma solicitação de API que atravessou o limite da rede.

Depois de copiar as saídas para a pasta do incidente, enumere o grupo de processos. Um processo pode iniciar um filho que muda de grupo, portanto não pare em um único comando. Inspecione os ambientes de contêiner e os gerenciadores de trabalhos em segundo plano que o agente puder usar. Se o agente tiver acesso SSH, verifique também as sessões ativas em cada host de destino.

Quando a tarefa realizar trabalho remoto, use o ID da operação do sistema remoto. Por exemplo, uma API pode retornar isto ao aceitar uma solicitação:

{
  "operation_id": "op_4e2b7c",
  "status": "queued"
}

Armazene essa resposta e depois chame o endpoint de cancelamento documentado ou use o console do serviço sob controle humano. Registre o resultado do cancelamento. Uma resposta cancel_requested significa que ainda é preciso consultar a operação até que ela informe cancelled, completed ou outro estado final. Não escreva «interrompido» nas notas do incidente apenas porque o processo local desapareceu.

Preserve as evidências antes de redefinir o espaço de trabalho

Capture as evidências em uma pasta de incidente separada antes de excluir branches, reiniciar serviços ou executar um script de limpeza automática. Você precisa de um registro em ordem cronológica que outro desenvolvedor possa analisar sem depender da memória do operador.

Colete o material a seguir e preserve os horários originais sempre que possível:

• A transcrição do agente, as entradas e saídas das ferramentas e a configuração usada na execução.
• A saída da inspeção de processos, os IDs dos processos pai e filhos, as conexões abertas e o histórico do shell relevante para a execução.
• Os registros da sessão no gateway e os logs de ações, incluindo negativas depois da revogação.
• Eventos de auditoria dos serviços remotos, IDs de operações, resultados de cancelamentos e identificadores dos recursos alterados.
• O estado do repositório: commit atual, diff, arquivos não rastreados e artefatos gerados.

Calcule o hash dos arquivos depois da coleta. Um manifesto simples permite que revisores posteriores detectem alterações acidentais enquanto as cópias passam entre a pessoa de plantão, a equipe de segurança e o desenvolvedor responsável pelo sistema afetado:

mkdir -p incident-run_2025_04_18/evidence
cp agent-transcript.txt incident-run_2025_04_18/evidence/
ps -o pid,ppid,pgid,lstart,command -p 48192 \u003e incident-run_2025_04_18/evidence/process.txt
shasum -a 256 incident-run_2025_04_18/evidence/* \u003e incident-run_2025_04_18/SHA256SUMS.txt

O manifesto de saída deve ter esta aparência:

8f7c...  incident-run_2025_04_18/evidence/agent-transcript.txt
30b1...  incident-run_2025_04_18/evidence/process.txt

Um hash não torna um arquivo verdadeiro. Ele prova que o revisor recebeu o mesmo arquivo cujo hash foi calculado. Compare-o com logs mantidos por sistemas que o agente não poderia editar, como a trilha de auditoria de um provedor de API ou um serviço central de logs somente para inclusão.

O Computer Security Incident Handling Guide da NIST, SP 800-61, trata contenção, erradicação, recuperação e atividades pós-incidente como etapas distintas. Essa separação se aplica bem a incidentes com agentes. As equipes costumam pular direto para a erradicação, excluindo o diretório de trabalho ou alterando um token. Depois descobrem que a transcrição excluída continha o corpo exato da solicitação necessário para encontrar um recurso remoto.

Não copie segredos para a pasta do incidente apenas porque está preservando o contexto. Registre identificadores de credenciais, responsáveis, escopo, horário de criação e registros do último uso. Armazene valores reais de segredos somente se o processo de incidentes existente permitir isso explicitamente e puder protegê-los. Um arquivo de incidente deve reduzir a incerteza, não criar um segundo vazamento de segredo.

Um processo pai encerrado não prova que o trabalho parou

Presuma que um agente ativo possa deixar trabalhos para trás até provar o contrário. Os casos mais problemáticos não são comandos de shell dramáticos. São ações assíncronas comuns que um desenvolvedor mal perceberia durante o trabalho normal.

Considere um agente de programação que envia uma solicitação de implantação, inicia um comando SSH que executa uma migração em segundo plano e depois espera pelos testes. O operador vê um destino de produção inesperado e interrompe o agente pai. O serviço de implantação já aceitou a solicitação, enquanto o shell remoto iniciou um comando com nohup. Ambos continuam. A última linha do terminal pode indicar apenas que a conexão foi fechada.

A análise precisa de três verificações diferentes:

Inspecione o trabalho aceito pelas APIs

Pesquise o serviço afetado usando o ID da execução, o ID da solicitação, a identidade da conta e a janela de tempo. Determine se cada solicitação foi rejeitada, colocada em fila, iniciada, concluída ou cancelada. Para alterações concluídas, liste os IDs concretos dos recursos e compare o estado resultante com o estado solicitado.

Não dependa apenas do status HTTP. Um 200 pode descrever uma alteração síncrona, um documento de status ou uma resposta de um intermediário. Um 202 normalmente indica processamento aceito, mas a documentação do serviço define o significado final. Leia essa documentação antes de criar um procedimento de cancelamento para o serviço.

Inspecione o trabalho separado do agente

Nos sistemas de destino, verifique as sessões da conta remota, a árvore de processos, os trabalhos agendados, os diretórios temporários e os logs do serviço. Pesquise a linha de comando registrada, o diretório de trabalho, o ID da execução ou um arquivo gerado exclusivo. Se uma tarefa remota usar um agendador, cancele-a por meio desse agendador, em vez de encerrar um shell que talvez já não a controle.

Verifique também callbacks. Um script gerado pode ter configurado um webhook, criado um fluxo de trabalho de pull request ou acionado CI. Esses são atores separados, com suas próprias credenciais e agendas. Revogar o agente original não os revoga.

É por isso que um gateway de ações restrito é mais seguro do que entregar ao agente um shell geral com um ambiente amplo. Você pode enumerar um número limitado de canais e exigir que toda chamada privilegiada passe por um ponto de controle. Um shell cheio de credenciais herdadas transforma cada subprocesso em um novo ramo do incidente.

Altere credenciais somente quando a exposição justificar

Altere uma credencial quando houver motivo para acreditar que o agente, seus subprocessos, seus logs ou seu espaço de trabalho possam ter mantido o segredo. Não altere credenciais apenas para criar a aparência de uma resposta. Uma alteração ampla interrompe usuários legítimos e pode dificultar a análise se modificar os registros que ainda precisam ser examinados.

As condições a seguir justificam desativação ou alteração imediata:

• O agente recebeu um segredo em texto simples em um prompt, variável de ambiente, arquivo de configuração, linha de comando ou saída de ferramenta.
• Uma credencial apareceu em uma transcrição, diff do repositório, arquivo temporário ou log de CI com acesso além da equipe do incidente.
• Você não consegue explicar um processo filho, uma sessão remota ou uma conexão de saída que poderia ter lido o segredo.
• A credencial tem privilégios amplos e não possui logs confiáveis de cada uso.
• O provedor afetado informa que a credencial foi usada por uma identidade ou localização desconhecida.

Se um gateway injetou a credencial e retornou ao agente apenas o resultado da ação, a situação é bem diferente. O agente pode ter realizado uma ação não autorizada, mas não necessariamente tinha um segredo reutilizável. Desative a sessão ativa e o caminho de ação afetado, examine o registro de auditoria e altere a credencial subjacente se a análise encontrar uma rota que contorne esse limite ou uma preocupação no nível do provedor.

Evite recomendar a alteração de todos os segredos depois de cada erro de um agente. Essa prática é popular porque parece decisiva e porque credenciais vazadas têm consequências graves. Como padrão, ela está errada porque confunde uso não autorizado com divulgação de credencial, cria falhas evitáveis em produção e ensina as equipes a ignorar uma análise cuidadosa do escopo. Altere rapidamente quando a divulgação for plausível. Caso contrário, preserve a capacidade de distinguir a execução comprometida das demais.

Quando a alteração for necessária, documente o identificador da credencial antiga, o horário da desativação, os sistemas downstream que a utilizam, a pessoa responsável pela substituição e um teste que prove que a credencial antiga não funciona mais. Não coloque nenhum dos valores em um chamado ou transcrição. Um gerenciador de segredos ou o mecanismo protegido de rotação do provedor deve cuidar da substituição.

O registro do incidente precisa permitir uma análise cética

Uma análise de incidente deve permitir que um desenvolvedor que não estava de plantão reconstrua a sequência sem confiar em um único log mutável. Comece pela intenção do agente e pelo registro do processo local. Depois, compare essa história com os registros do gateway e as evidências do serviço remoto.

Crie uma linha do tempo com rótulos explícitos de confiança. Por exemplo, «agente propôs a solicitação» vem de uma transcrição. «gateway executou a solicitação» vem do registro de ações do gateway. «provedor aceitou a operação» vem da entrada de auditoria do provedor. «recurso foi alterado» vem do estado final e do histórico de alterações do recurso. Essas são afirmações diferentes e merecem evidências diferentes.

Um log de auditoria somente para gravação, encadeado por hash, tem uma propriedade útil aqui: o componente que executa as ações não consegue reescrever silenciosamente seu próprio histórico depois do fato. A verificação sobre o texto cifrado também permite que um revisor confira a continuidade sem obter acesso a todos os segredos ou cargas das ações. Isso não torna o log completo. Ele ainda registra apenas as atividades que passaram pelo gateway, por isso os logs dos serviços remotos continuam sendo parte da análise.

O Sallyport registra sessões de agentes e ações individuais em um único log de auditoria criptografado e encadeado por hash. O comando sp audit verify verifica a cadeia offline sem uma chave do cofre. Isso oferece ao revisor do incidente um teste simples para executar em uma cópia exportada do log:

sp audit verify /path/to/exported-audit-log

Uma verificação bem-sucedida estabelece a continuidade do registro criptografado recebido. Uma verificação malsucedida deve interromper a limpeza informal e acionar o tratamento de evidências, pois será preciso determinar se a falha foi causada por danos na exportação, corrupção do armazenamento ou alteração deliberada.

A análise deve produzir respostas, não uma lista vaga de observações. Identifique a instrução ou entrada que disparou o evento, a autoridade concedida à execução, cada ação externa confirmada, cada ação ainda incerta, as credenciais que podem ter escapado e a alteração de controle que teria interrompido o evento antes. Se a equipe não conseguir indicar o primeiro controle que falhou, provavelmente adicionará um prompt de aprovação incômodo em vez de corrigir o caminho exposto.

Retome o desenvolvimento com um limite novo, não com uma sessão reaberta

Os desenvolvedores podem continuar trabalhando depois da contenção, mas não devem retomar pelo mesmo processo, estado do espaço de trabalho ou concessão de autoridade. A execução interrompida pode conter instruções não analisadas na memória, contexto antigo da tarefa, scripts gerados ou um processo filho que a primeira resposta não encontrou.

Crie uma execução nova com uma identidade de sessão nova. Revise o diff do repositório e os arquivos gerados antes de expor a nova execução a credenciais ou destinos de produção. Se a tarefa anterior precisar continuar, entregue à nova execução uma passagem escrita e curta, indicando quais ações remotas foram concluídas, quais continuam canceladas e quais recursos precisam ser inspecionados.

Use um conjunto de permissões mais restrito para a tarefa retomada. Uma tarefa de revisão de código raramente precisa de autoridade de implantação. Uma tarefa que precisa consultar a produção normalmente não precisa de acesso de gravação. Não se trata de obrigar todos os desenvolvedores a usar uma linguagem de políticas complexa. Trata-se de não carregar a concessão ampla de ontem para uma execução iniciada depois de um incidente.

A autorização por sessão é especialmente útil quando um novo processo local começa depois de uma interrupção, pois obriga uma pessoa a reconhecer que se trata de uma execução diferente. A aprovação por chamada é adequada para ações cujo custo de uma gravação equivocada é alto o bastante para justificar uma interrupção. Se um cartão de aprovação não identificar o processo chamador e a ação específica, corrija isso antes de confiar nele durante um incidente.

O primeiro exercício deve durar quinze minutos: inicie uma tarefa inofensiva de agente, revogue sua sessão durante uma chamada de API, preserve os registros locais e remotos e confirme que a tarefa não pode continuar usando a autoridade antiga. Execute o exercício em um destino descartável. Você encontrará IDs de solicitação ausentes, filhos separados e problemas de acesso aos logs quando o custo for baixo, em vez de descobrir tudo durante um erro real em produção.

Torne a revogação uma ação normal do operador

Uma equipe que trata a revogação como uma emergência rara hesitará quando um agente se comportar de maneira estranha. Os controles devem tornar rápida a decisão segura: bloqueie o limite de ação, revogue a sessão, verifique o que já o atravessou e deixe um registro que sobreviva à limpeza.

A escolha de design mais forte é simples: separar as funções. Os agentes podem planejar e solicitar ações. Um ponto de controle local mantém as credenciais, identifica o processo que solicita, registra a solicitação e pode negar esse processo sem entregar o segredo a ele. Quando o operador pressiona o botão de parada, a próxima chamada privilegiada precisa falhar e as chamadas anteriores precisam continuar disponíveis para análise.

Teste essa afirmação com as ferramentas que seus agentes realmente usam. Se a equipe não consegue interromper uma única execução ativa sem alterar uma credencial compartilhada, não consegue associar uma operação remota a essa execução ou não consegue verificar seu histórico de ações depois do fato, o fluxo de trabalho de incidentes ainda não está completo.