Lista de verificação para desligar agentes de IA com segurança

A saída de um funcionário é um dos poucos momentos em que o controle de acesso é testado contra o relógio. O procedimento comum de desativação de contas não basta para agentes de IA, porque o trabalho útil costuma acontecer por meio de processos locais, tarefas executadas sem supervisão, credenciais de API compartilhadas, material SSH e configurações copiadas para fora da identidade do funcionário que está saindo.

Trate o desligamento como uma transferência controlada de autoridade, não como uma tarefa de limpeza de TI. É preciso interromper novas ações, identificar o trabalho que já está em andamento, substituir a autoridade compartilhada e preservar os registros antes que alguém apague as evidências que explicam o que aconteceu.

Uma identidade desativada não revoga todos os caminhos até a produção

Desativar uma conta de diretório interrompe apenas os caminhos de acesso que realmente consultam esse diretório no momento do uso. Isso não revoga um token de API em um arquivo de configuração local, uma chave privada SSH carregada em um espaço de trabalho do agente, um token de acesso à nuvem emitido anteriormente ou uma credencial de serviço compartilhada injetada por uma tarefa de CI.

Essa diferença costuma ficar confusa porque uma pessoa, um processo de agente e uma credencial podem aparecer com o nome de um mesmo funcionário em um painel. São coisas diferentes e exigem ações diferentes:

• Uma identidade humana responde quem se autenticou.
• Um processo de agente local responde o que pode agir agora na máquina do funcionário.
• Uma credencial responde o que um serviço remoto aceitará.
• Uma sessão ou tarefa responde o que pode já estar executando.
• Um registro de auditoria responde o que será possível provar mais tarde.

Confundir essa diferença cria uma falha conhecida. O RH marca o funcionário como desligado às 09:00. A TI desativa o login único às 09:05. Às 09:20, uma tarefa agendada do agente é executada em um notebook que ainda não foi recolhido. Ela usa um token de implantação compartilhado armazenado no ambiente e altera uma configuração de produção. Todas as equipes envolvidas podem afirmar corretamente que removeram a conta do funcionário. Nenhuma removeu a autoridade usada pelo agente.

Comece o chamado de desligamento com uma pergunta objetiva: «Quais ações ainda poderiam ser concluídas se o login normal do funcionário deixasse de funcionar?». Não aceite «a conta foi desativada» como resposta.

A NIST SP 800-53 coloca controles relacionados em famílias separadas por um motivo. A AC-2 trata do gerenciamento de contas, a IA-5 trata do gerenciamento de autenticadores e a AU-9 trata da proteção das informações de auditoria. Equipes que transformam os três em uma única caixa de seleção normalmente descobrem o trabalho que faltou depois de um incidente.

Congele os caminhos de ação antes de recolher o notebook

Interrompa primeiro a autoridade remota, porque o recolhimento físico pode levar horas e um notebook ligado pode continuar funcionando. A pessoa responsável pelo desligamento deve avisar o responsável pela segurança e os responsáveis pelos serviços. Em seguida, deve suspender brevemente as ações automatizadas atribuíveis ao funcionário ou à estação de trabalho.

A primeira verificação deve abranger estes caminhos:

1. Revogue as sessões remotas ativas quando o provedor de identidade, a nuvem, o serviço de controle de código-fonte ou o sistema de acesso privilegiado oferecer esse recurso.
2. Desative ou isole runners de compilação registrados, tarefas agendadas do agente e sessões de desenvolvimento remoto pertencentes ao funcionário.
3. Remova o dispositivo do acesso por dispositivo confiável, VPN e gerenciamento, quando o processo operacional permitir.
4. Pause tarefas sem supervisão que possam fazer implantações, alterar a infraestrutura, enviar mensagens ou gravar dados em sistemas de clientes.
5. Recolha a estação de trabalho ou coloque-a sob restrições de rede gerenciadas antes que o funcionário deixe de supervisioná-la.

Não comece apagando arquivos locais. Se a saída for contestada, incomum ou relacionada a uma preocupação de segurança, preserve o estado do dispositivo conforme o procedimento de incidente. Uma limpeza apressada destrói o histórico do shell, as transcrições do agente, a configuração local, as filas de tarefas e os horários que podem esclarecer se uma ação foi autorizada.

Em uma saída planejada comum, o responsável pela segurança pode decidir que se aplicam as regras normais de devolução e recriação da imagem do dispositivo. Essa decisão deve aparecer no chamado. Ela não deve ficar apenas na memória de alguém.

Um ponto de controle útil é o limite do processo do agente. Registre o caminho do executável, o processo pai, o identificador do processo, o horário de início, o diretório de trabalho e a autoridade de assinatura do código antes de encerrar um agente em execução localmente. No macOS, um operador pode coletar um registro básico do processo assim:

ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent'

# Output shape:
# 8421   611 alice  Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release

O comando, por si só, não é uma prova. Ele fornece ao investigador uma pista delimitada no tempo e impede que a afirmação vaga de que «um agente estava em execução» se torne todo o registro.

Crie um inventário de autoridades, não um inventário de software

Uma lista de ferramentas de IA instaladas não informa quem pode alterar um serviço. Faça o inventário de todos os caminhos de autoridade, inclusive das ferramentas que você talvez não chame de IA. O funcionário pode ter usado um agente pelo terminal, por uma extensão do editor, por um runner de CI, por um script local ou por um ambiente remoto. O caminho importa mais que o rótulo.

Use uma linha para cada credencial ou relação de identidade. Se um token puder acessar três serviços, liste suas três consequências no campo de escopo, em vez de escondê-las nas notas.

A parte difícil é encontrar a autoridade compartilhada. Faça perguntas diretas aos responsáveis pelos serviços: esse funcionário conhece um token que continua válido depois da conta? Ele administrava uma conta de bot? O dispositivo dele pode se conectar com uma chave SSH? Alguma tarefa era executada com uma identidade genérica? Quem receberá os alertas dessa tarefa a partir de hoje?

Não faça do funcionário que está saindo a única fonte desse inventário. Ele pode ajudar, mas os repositórios, armazenamentos de segredos, arquivos de chaves autorizadas, configurações de CI, registros de propriedade dos serviços e logs de auditoria precisam confirmar a resposta. As pessoas esquecem um token criado durante uma interrupção. Também esquecem um runner de testes que se tornou parte da infraestrutura de produção dois anos depois.

Renove as credenciais compartilhadas na ordem das dependências

Renove qualquer credencial compartilhada que a pessoa que está saindo pudesse ter lido, copiado, exportado ou usado fora de um caminho confiável de revogação vinculado à identidade. Isso inclui chaves de API, senhas de autenticação básica, segredos de webhook, tokens de implantação, senhas de banco de dados, chaves SSH, chaves de acesso à nuvem e códigos de recuperação.

A recomendação popular, mas errada, é renovar tudo ao mesmo tempo. Isso parece decisivo e produz uma lista impressionante de segredos alterados. Também quebra dependências desconhecidas, torna a solução de problemas caótica e incentiva as equipes a restaurar o segredo antigo sob pressão. Faça a rotação em uma sequência que mantenha aberto um caminho de substituição com responsável definido.

Para cada credencial, siga esta ordem:

1. Nomeie o responsável pelo serviço e os chamadores exatos que usam a credencial.
2. Crie uma credencial substituta com o escopo mais limitado que o serviço aceitar.
3. Atualize os chamadores conhecidos e confirme que funcionam com a substituta.
4. Revogue a credencial antiga e teste se ela falha.
5. Registre o responsável pela substituta, seu horário de criação, seu escopo e o resultado da revogação.

Um teste de falha é importante. «Rotação concluída» geralmente significa que alguém criou um token novo e atualizou um aplicativo. Isso não significa que o token antigo deixou de funcionar. Faça uma solicitação autenticada inofensiva que a credencial antiga permitia. Registre a resposta de negação esperada pelo serviço, como HTTP 401 ou 403, sem colar segredos no chamado.

Para acesso SSH, remova a chave pública da pessoa desligada de todas as fontes de authorized-keys dos destinos e de qualquer sistema central de acesso. Depois, procure automações que usem a mesma chave privada. Se um agente usava uma identidade SSH compartilhada, gere um novo par de chaves, substitua a metade pública nos destinos, atualize o chamador aprovado e aposente a chave pública antiga. Remover uma chave apenas da estação de trabalho não faz nada com uma cópia da chave.

Nunca envie a substituta por chat ou e-mail como parte da transferência. Dê ao novo responsável permissão para obtê-la ou usá-la pelo mecanismo aprovado de segredos. O objetivo da rotação é reduzir o número de cópias que não podem ser contabilizadas.

Contas compartilhadas precisam de um responsável humano identificado

Uma conta de serviço pode ser legítima, mas uma conta compartilhada sem operador identificado é uma forma de esconder um problema de responsabilidade. A transferência deve nomear uma pessoa que aceite a responsabilidade pela finalidade, pelo escopo, pelo faturamento, pelo caminho de recuperação e pela futura rotação das credenciais da conta.

Separe a responsabilidade operacional da própria credencial. Um bot de releases pode precisar continuar fazendo implantações depois que um funcionário sair. Isso não significa que o funcionário substituto deva herdar o token pessoal do antigo funcionário ou usar a configuração local dele. Dê ao bot uma identidade própria quando o serviço permitir, atribua apenas as permissões necessárias e responsabilize o novo proprietário por ele.

Escreva um registro curto da transferência que responda a cinco pontos:

• Qual serviço ou fluxo de trabalho a conta apoia?
• Quais ambientes e ações ela pode alcançar?
• Quais sistemas a chamam hoje?
• Quem pode alterar suas credenciais ou recuperá-la?
• Quando alguém verificará se ela ainda precisa desse acesso?

É também aqui que as equipes encontram suposições do agente disfarçadas de conveniência. Uma configuração local pode instruir um agente a usar uma identidade genérica de implantação porque o desenvolvedor original não teve tempo de configurar uma identidade dedicada. Não preserve esse atalho em nome da continuidade. Substitua-o por um caminho de acesso com responsável definido antes de retomar o trabalho.

Preserve os registros antes que as tarefas de retenção os apaguem

Mantenha registros que permitam reconstruir a autoridade e as ações sem depender da explicação do funcionário que está saindo. Capture o chamado de desligamento, o inventário de acessos, o evento de desativação da identidade, as revogações de sessão, os eventos de rotação, o histórico de tarefas de CI, os registros de execução do agente, a decisão sobre a coleta do endpoint e as exportações de auditoria dos serviços. Registre o fuso horário e a fonte do relógio se os sistemas forem diferentes.

Preservar não é copiar algumas capturas de tela. Uma captura de tela perde campos, esconde filtros e raramente pode ser verificada. Exporte os registros originais em seu formato nativo quando possível, preserve hashes dos arquivos coletados, restrinja o acesso ao grupo do caso e documente quem manuseou cada cópia.

A nota de coleta a seguir é compacta o bastante para ser usada e específica o suficiente para auditoria:

Case: OFF-2025-041
Collected by: security-operator
Collected at: 2025-03-12T09:37:16Z
Source: build-service job history export
Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z
File: build-jobs.json
SHA-256: \u003crecorded digest\u003e
Storage: restricted evidence repository
Reason: employee exit and agent authority review

Mantenha a exportação original inalterada. Se um investigador filtrá-la ou fizer anotações, salve isso como uma cópia de trabalho separada. Essa separação simples evitou mais discussões que ferramentas forenses elaboradas: as pessoas podem examinar a análise sem alterar silenciosamente o registro de origem.

A NIST SP 800-92 descreve o gerenciamento de logs como um processo de geração, transmissão, armazenamento, análise e descarte. O ponto fraco do desligamento costuma ser o descarte. Um período padrão curto de retenção pode apagar o único registro de execução necessário para estabelecer se um agente agiu antes ou depois da alteração de acesso. Coloque em retenção os registros que sua política permite manter e depois libere a retenção pelo processo normal.

Torne a autorização do agente revogável por processo

A aprovação de um desenvolvedor para um processo de agente não deve se transformar em permissão geral para todos os processos que possam aparecer na máquina dele. Um processo pode ser substituído, reiniciado a partir de outro diretório de trabalho ou chamado por uma extensão do editor depois que a pessoa sair. O registro de autorização precisa identificar o processo e oferecer um caminho imediato de revogação.

É aqui que um gateway pode ajudar, mas apenas se ele se recusar a entregar credenciais ao agente. O Sallyport mantém credenciais de API e SSH em um cofre local criptografado, autoriza novos processos de agentes por sessão por padrão e registra sessões e ações individuais separadamente.

Para o desligamento, exporte ou preserve os registros de sessão e atividade relevantes, revogue as sessões ativas e bloqueie o cofre antes de transferir o dispositivo. Essa ordem cria um limite significativo: o agente não pode fazer uma nova chamada externa enquanto o registro de suas chamadas anteriores continua disponível para revisão.

Não confunda aprovação por sessão com aprovação para toda ação de consequência relevante. Um agente pode precisar legitimamente de uma sessão para ler um repositório, enquanto toda credencial que altera a produção exige confirmação a cada uso. Coloque o controle mais rigoroso nas credenciais cujo uso indevido exigiria resposta a um incidente, não em chamadas inofensivas somente de leitura que causarão fadiga de aprovações.

A fadiga de aprovações é uma falha de projeto. Se as pessoas receberem um aviso para cada solicitação rotineira, deixarão de ler os avisos. Se receberem um único aviso que cubra silenciosamente o acesso a sistemas de produção sem relação entre si, o aviso será amplo demais. Uma boa autorização cria um limite claro que um operador consegue explicar depois.

Inspecione o trabalho em execução e os gatilhos atrasados

A revogação de uma conta não interrompe com segurança o trabalho já aceito por um serviço remoto. Verifique compilações em fila, shells remotos, agendamentos de automação, disparos de fluxos de trabalho do repositório, tarefas de publicação de pacotes, planos de infraestrutura e filas de mensagens que possam iniciar trabalhos mais tarde.

Para cada item em execução ou na fila, decida se ele deve ser cancelado, concluído sob observação ou transferido para um novo responsável. A decisão deve depender da ação, do alcance do impacto e da possibilidade de reproduzir a tarefa. Uma implantação com uma alteração conhecida e registrada pode ser autorizada a terminar. Uma tarefa que possa alterar controles de acesso ou mover dados normalmente deve parar até que o responsável confirme a intenção.

Capture os identificadores antes do cancelamento. Um URL de tarefa sozinho é uma evidência fraca se o serviço apagar os detalhes depois do período de retenção. Armazene o ID da tarefa, a identidade que a disparou, a referência do commit ou da tarefa, os horários de início e término, as permissões usadas e o resultado. Se a tarefa falhar durante o desligamento, registre se a falha veio da revogação. Caso contrário, um investigador futuro poderá interpretar uma alteração bem-sucedida no controle de acesso como uma falha operacional.

Inspecione também a execução atrasada. Entradas do cron, launch agents, agendamentos de CI, regras de eventos na nuvem e fluxos de trabalho do repositório podem retomar a atividade depois que a equipe acreditar que o desligamento terminou. Uma tarefa recorrente deve ser transferida para um responsável gerenciado ou desativada. Deixá-la ativa em uma conta abandonada torna a próxima falha previsível e difícil de diagnosticar.

Feche apenas quando uma pessoa independente puder verificar o resultado

A pessoa que faz as alterações não deve ser a única a declarar o desligamento concluído. Peça a um colega da segurança, ao responsável pelo serviço ou ao gerente que verifique os itens mais importantes: a antiga identidade não consegue entrar, as credenciais compartilhadas antigas falham, não há trabalho agendado de agentes sob o antigo responsável e a coleta de evidências está legível e protegida.

Use uma declaração de encerramento que nomeie fatos testados, em vez de uma conclusão vaga:

Former identity: disabled and active sessions revoked
Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked
Agent work: 2 scheduled jobs transferred, 1 queued job canceled
Evidence: exports and collection hashes stored under case OFF-2025-041
Exceptions: none
Verified by: service owner and security reviewer

Se uma credencial não puder ser renovada imediatamente, mantenha o chamado aberto e registre a restrição compensatória, o responsável e o prazo. «Faremos isso depois» não é um controle. Uma restrição de firewall, um fluxo de trabalho desativado ou uma suspensão temporária do serviço pode ser um controle se alguém a verificar e souber quando ela expirará.

A primeira mudança útil é simples: adicione um inventário de autoridades e uma decisão sobre retenção de evidências ao chamado de desligamento do RH já existente. Esses dois campos obrigam a conversa certa antes que um notebook desapareça, um token continue válido ou uma tarefa de retenção de logs remova o único registro da ação de um agente.