# Checklist de transferência de acesso de agentes de IA em mudanças de função

Uma mudança de função é o momento em que um modelo de acesso de agentes de IA se prova ou começa a falhar silenciosamente. As equipes costumam transferir permissões de repositórios e esquecer o caminho de credenciais que permite a um agente chamar APIs de produção, abrir uma sessão SSH ou iniciar uma implantação. O agente continua funcionando, mas ninguém sabe dizer quem pode aprová-lo, quem lê seus registros ou quem pode interrompê-lo às 2 da manhã.

Um checklist de transferência de acesso de agentes de IA precisa transferir quatro responsabilidades distintas: custódia das credenciais, autoridade para aprovar ações, responsabilidade pela revisão de auditoria e autoridade para agir durante um incidente. Tratar tudo isso como uma noção vaga de «propriedade» é como permitir que um desenvolvedor que saiu continue sendo, na prática, o responsável por um caminho de produção muito depois da mudança de função.

## Uma mudança de função transfere autoridade, não apenas segredos

A equipe precisa transferir a capacidade de autorizar e prestar contas pelas ações do agente, mesmo quando a credencial nunca sai do armazenamento seguro. Um segredo pode continuar no mesmo cofre, mas seu responsável, uso permitido, aprovador e revisor podem mudar. São informações diferentes, e cada uma precisa de uma resposta registrada.

Comece separando as pessoas que costumam ser reunidas em um único nome:

- O responsável pela credencial pode alternar, desativar ou substituir o segredo.
- O responsável pelo serviço decide se o agente deve continuar com acesso ao sistema.
- O aprovador aceita ou rejeita uma ação tentada quando a aprovação é necessária.
- O revisor de auditoria verifica o que o agente realmente fez e acompanha as exceções.
- O responsável pela revogação de emergência pode interromper o acesso quando o responsável habitual não estiver disponível.

Equipes pequenas costumam atribuir as cinco responsabilidades a um único engenheiro. Isso pode ser razoável para uma credencial de desenvolvimento limitada, mas registre a decisão claramente e indique um substituto. Caso contrário, um feriado, uma saída inesperada ou uma disputa de permissões transforma uma pessoa ausente em uma dependência operacional difícil de substituir.

Não confunda a responsabilidade pelo repositório com a autoridade para executar ações. Um desenvolvedor pode perder o acesso de escrita a um repositório enquanto um processo de agente configurado anteriormente ainda consegue acessar um rastreador de problemas, uma API de nuvem ou um host de produção. Da mesma forma, um novo líder de equipe pode ser responsável pelo repositório, mas não ter autoridade para aprovar o uso de uma credencial de lançamento pelo agente. Revise os dois planos separadamente.

Já vi transferências falharem porque a pessoa que chegava recebeu uma lista de nomes de APIs, mas não o motivo da existência de cada credencial. Um registro que diz «token de implantação» quase não ajuda o sucessor. Informe o serviço de destino, a ação permitida, o ambiente, o responsável, o modo de aprovação e o método de rotação. Se ninguém consegue explicar a finalidade de uma credencial em uma frase, desative-a até que isso seja possível.

## Congele as mudanças antes de transferir a responsabilidade

Pause novas mudanças de acesso dos agentes enquanto a transferência estiver em andamento. Um alvo em movimento produz um documento que já estava errado quando alguém o assinou.

O congelamento não significa desligar todas as execuções de agentes por uma semana. Significa que ninguém adiciona credenciais, amplia escopos, altera configurações de aprovação ou concede acesso a uma nova máquina sem que os responsáveis que estão saindo e chegando registrem a mudança. Mantenha a janela curta e explícita. Em uma mudança planejada, comece quando a data for conhecida e termine antes que a pessoa perca o acesso. Em uma saída abrupta, revogue primeiro e reconstrua o inventário a partir dos registros.

Registre o limite do processo. Inclua agentes executados em máquinas de desenvolvedores, automações agendadas, tarefas de CI que chamam um agente e ambientes de teste que guardam credenciais reais. As equipes costumam esquecer ferramentas locais porque elas não aparecem no console de nuvem. O acesso local ainda chega a sistemas externos.

Um aviso de congelamento útil responde a quatro perguntas práticas:

1. Quais credenciais e endpoints entram na transferência.
2. Quem pode aprovar uma exceção durante o congelamento.
3. Onde ficam o inventário atual e os registros de ações.
4. Quando o responsável que chega aceita a responsabilidade.

Não aceite «vamos limpar isso depois» para credenciais que acessam produção ou dados de clientes. É depois que as pessoas descobrem que um agente ainda tem um token que nenhum funcionário se lembra de ter criado. Um congelamento curto custa menos que uma rotação de emergência feita sem saber quais automações vão quebrar.

Uma distinção é importante: revogar a conta de uma pessoa não é o mesmo que revogar a autoridade de um agente. Uma credencial pode pertencer a uma conta de serviço compartilhada. Uma aprovação pode estar vinculada a um processo de agente local. Uma chave pública SSH pode autorizar um host independentemente da conta do provedor de identidade do desenvolvedor que saiu. A transferência precisa encontrar cada rota, não apenas fechar a conta do funcionário.

## Crie um registro que descreva o uso, não os valores secretos

O registro da transferência deve identificar as credenciais sem copiar material secreto para uma planilha ou chamado. A pessoa que chega precisa de um mapa operacional, não de um segundo cofre, menos protegido, cheio de tokens.

Use um identificador opaco, uma impressão digital ou o nome do registro no cofre. Para material SSH, registre a impressão digital da chave pública e os hosts autorizados. A equipe pode consultar uma impressão digital pública sem expor a chave privada:

```sh
ssh-keygen -lf ~/.ssh/agent_deploy.pub
256 SHA256:exampleFingerprint agent-deploy (ED25519)
```

A impressão digital exata será diferente. O importante é que o registro contenha o identificador resultante, a conta do host e o motivo da existência da chave. Nunca cole uma chave privada ou um token bearer no artefato de transferência para deixá-lo «completo». Isso cria um novo ponto de vazamento e dificulta a verificação da rotação.

Copie esta estrutura para a documentação operacional protegida da equipe, uma vez para cada credencial ou caminho de acesso:

```yaml
access_id: prod-release-api-01
channel: HTTP
service_and_environment: release API / production
allowed_action: create approved release
secret_reference: encrypted-vault record prod-release-api-01
credential_custodian: incoming platform owner
service_owner: release engineering lead
approval_mode: every use
approver_backup: operations manager
audit_reviewer: security duty engineer
emergency_revoker: platform on-call
rotation_method: replace token in service console, then test read-only endpoint
last_verified: 2025-03-08
```

As datas e os nomes acima são exemplos. Substitua-os por pessoas e datas reais e proteja o registro como metadado operacional. Ele não contém um segredo, mas informa a um invasor onde está a autoridade.

Inclua o escopo, não apenas um rótulo. «Token de nuvem» pode significar acesso de leitura a uma conta de teste ou acesso de administrador a várias contas de produção. Peça ao responsável pelo serviço que confirme o escopo, em vez de confiar na memória do desenvolvedor que está saindo. Os consoles de fornecedores mudam, integrações antigas permanecem e o nome dado a uma credencial há dois anos muitas vezes tem pouca relação com o que ela consegue fazer hoje.

O registro também precisa de uma decisão explícita: manter, alternar, reduzir o escopo ou revogar. «Transferir» não é uma decisão final. Se uma credencial não tem uso atual, revogue-a. As equipes mantêm acessos inativos porque a rotação parece arriscada. Acessos inativos são mais difíceis de supervisionar e mais fáceis de esquecer.

## As expectativas de aprovação precisam de uma decisão humana nomeada

Uma configuração de aprovação só oferece controle quando a equipe concorda com a responsabilidade assumida pela pessoa que aprova. «Alguém vai clicar em permitir» não é uma expectativa. É uma falha esperando uma pessoa apressada.

Defina se o agente precisa de permissão uma vez por execução ou a cada uso da credencial. Uma aprovação de sessão diz: «Reconheço este processo de agente e permito que ele execute, durante esta sessão, a classe de ações que recebeu». Uma aprovação por chamada diz: «Revisei agora esta tentativa específica de uso». Elas tratam de riscos diferentes.

Use aprovação de sessão para trabalhos delimitados em que solicitações repetidas fariam as pessoas aprovarem automaticamente. Por exemplo, um agente que corrige uma suíte de testes pode precisar de várias chamadas de leitura e escrita para um serviço de desenvolvimento. O aprovador ainda deve saber qual processo solicitou o acesso e quando a autorização termina.

Use aprovação por chamada quando uma ação individual puder gerar uma consequência relevante: implantar em produção, apagar dados, alterar permissões, enviar mensagens para fora da organização ou usar uma credencial de escopo amplo. A pausa adicional é intencional. Se a ação for rotineira demais para justificar uma decisão humana, reduza o escopo da credencial ou mova a operação para uma automação revisada. Não resolva o cansaço causado por prompts dando uma aprovação de sessão ampla a todas as credenciais sensíveis.

Na transferência, registre estas expectativas em linguagem simples:

- A pessoa ou função que pode aprovar cada classe de ação.
- As situações que exigem aprovação por chamada.
- As evidências que o aprovador deve analisar antes de permitir a ação.
- A condição de expiração da autorização de sessão.
- O aprovador substituto quando o responsável habitual estiver ausente.

As evidências podem ser modestas, mas precisam ser concretas: ambiente de destino, operação solicitada, identidade da credencial, processo de agente de origem e resultado esperado. Um aprovador não consegue decidir bem a partir de uma mensagem genérica que apenas diz que um agente quer acesso.

Uma recomendação ruim e comum é desligar as aprovações depois que a equipe «confiar» no agente. Ela é popular porque os prompts interrompem o trabalho. Está errada porque confiar na geração de código de um agente não lhe dá autoridade para usar todas as credenciais externas. Reduza as aprovações quando o caminho de ação tiver escopo limitado e bons testes. Mantenha-as quando a consequência exigir uma pessoa capaz de explicar por que permitiu a ação.

## A revisão de auditoria pertence a uma pessoa e a uma agenda

Os logs não criam responsabilidade apenas por existirem. A transferência precisa indicar quem revisa a atividade do agente, o que essa pessoa procura e o que faz quando uma entrada não faz sentido.

A NIST Special Publication 800-53 separa o gerenciamento de contas, no controle AC-2, da revisão de auditoria, em AU-6. Essa separação se aplica bem ao acesso de agentes. A pessoa que gerencia uma credencial pode não ser a pessoa certa para avaliar se o uso do agente correspondeu ao trabalho aprovado. Uma revisão independente identifica tanto erros quanto suposições convenientes.

Defina uma periodicidade de revisão compatível com o acesso. Uma credencial de produção usada para lançamentos pode exigir revisão depois de cada lançamento e de qualquer tentativa falha ou negada. Uma integração de desenvolvimento de baixo impacto pode ser revisada em uma agenda definida. Não escreva «periodicamente». Essa palavra sobrevive a todas as reuniões perdidas porque não promete nada.

O revisor deve responder a um pequeno conjunto de perguntas a partir do registro de ações:

- Qual processo de agente fez a solicitação e quem autorizou a execução?
- Qual credencial ou caminho de acesso foi usado?
- Qual destino foi alcançado e qual resultado retornou?
- A solicitação correspondia a uma tarefa nomeada ou a um registro de mudança?
- Alguma ação negada, repetida ou inesperada exigia investigação?

Exija que o revisor registre uma decisão para eventos incomuns: esperado, corrigido, escalado ou não resolvido. A equipe não precisa de um relatório cerimonial para cada leitura inofensiva de API. Mas precisa de uma decisão visível quando um agente acessa produção fora de uma janela planejada ou pede repetidamente uma credencial de que não deveria precisar.

Preserve os registros antes de alternar ou revogar uma credencial se houver possibilidade de incidente. A rotação corrige a exposição futura, mas não explica ações passadas. Certifique-se de que o novo revisor saiba onde os registros são mantidos, quem pode exportá-los e como verificar sua integridade. Um rastro de auditoria que só um engenheiro que está saindo consegue interpretar é um diário particular, não um registro operacional.

## Ensaie a revogação antes da data de saída

Um plano de revogação só está completo quando a equipe o testa com uma solicitação inofensiva. A primeira tentativa não deve ocorrer durante um incidente, quando todos estão tentando adivinhar se uma negativa significa que o controle funcionou ou que o serviço está quebrado.

Percorra uma falha comum. Um desenvolvedor muda de equipe e perde o acesso ao controle de código-fonte. A configuração antiga do agente continua funcionando em um laptop gerenciado com uma credencial de implantação compartilhada. A credencial continua válida porque pertence à conta de serviço de lançamento, não ao desenvolvedor. Um colega pede ao agente para «verificar o status do lançamento», e o agente ainda consegue chamar o endpoint de produção. A equipe achou que o desligamento havia ocorrido porque a conta do funcionário foi desativada. O caminho compartilhado continuava aberto.

Teste a rota real. O responsável pelo serviço pode organizar uma solicitação não destrutiva, como uma leitura de status em um destino de teste, usando a autorização antiga. Em seguida, revogue a autorização anterior, desative a credencial ou remova a rota permitida, conforme exigido pela transferência. Repita a solicitação e confirme três fatos: o acesso falha, a falha tem o motivo esperado e o registro de auditoria identifica a tentativa.

Esse teste encontra mais do que uma credencial esquecida. Ele detecta configurações locais antigas, uma segunda cópia de uma autorização SSH, automações que usam uma conta de serviço inesperada e um revisor que não consegue encontrar o registro correspondente.

Mantenha o teste limitado. Não é preciso executar operações destrutivas para provar a revogação. Uma chamada de status negada ou uma tentativa de conexão rejeitada fornece evidência suficiente quando o gateway de acesso registra tudo corretamente. Documente o comando ou a solicitação usada, o resultado esperado, o resultado real e a pessoa que acompanhou o teste.

Se o teste falhar, não encerre a transferência com uma promessa de investigar. Trate a credencial como ativa, mas sob responsabilidade indefinida. Escale para o responsável pela revogação de emergência, restrinja o caminho de acesso e identifique todos os locais que armazenaram ou reutilizaram a autorização. O teste falho está cumprindo seu papel ao revelar a rota enquanto a pessoa que está saindo ainda pode responder às perguntas.

## Os contatos de emergência precisam de autoridade e de um caminho ativo

Contatos de emergência não são apenas um campo de diretório. São as pessoas que podem tomar uma decisão urgente quando um agente tenta executar uma ação insegura ou quando o responsável habitual não responde.

Indique um contato principal e um substituto para cada grupo de acesso sensível. Inclua como contatá-los durante um incidente, o escopo que podem revogar e o responsável pelo serviço que decidirá se o acesso será restaurado depois. Não liste uma caixa de e-mail geral como único contato de emergência. Caixas de e-mail recebem mensagens, mas não assumem responsabilidade.

Defina as condições de acionamento em termos operacionais. Exemplos incluem uma ação do agente fora de uma mudança aprovada, autorizações negadas repetidamente, um novo processo de agente inesperado solicitando uma credencial de produção ou um registro de auditoria que não pode ser associado a um trabalho. O contato deve saber se precisa pausar todas as ações dos agentes, revogar uma única credencial, desativar uma conta de host específica ou chamar o responsável pelo serviço.

Uma boa transferência também trata do caso desconfortável em que o responsável pela revogação de emergência é a própria pessoa que está mudando de função. Transfira essa capacidade antes que a mudança entre em vigor e teste a capacidade de ação do substituto. Evite compartilhar um segredo de «quebra de emergência» em chats. Isso destrói a atribuição e geralmente permanece no histórico de alguém muito depois do fim da emergência.

Escreva também a regra de restauração. A revogação de emergência deve ser fácil. A restauração deve exigir que o responsável pelo serviço confirme o escopo, que o revisor de auditoria analise o evento e que o novo responsável pela credencial aceite a responsabilidade. As equipes que ignoram essa regra costumam restaurar um acesso amplo apenas para fazer uma tarefa bloqueada desaparecer.

## Um gateway deve tornar a transferência visível

Um gateway local de ações pode reduzir os pontos em que essa transferência falha, mas não substitui as decisões de responsabilidade. O Sallyport mantém as credenciais em um cofre criptografado, exige que o cofre esteja aberto antes da execução das ações e registra tanto as execuções dos agentes quanto as chamadas individuais. Isso dá ao revisor da transferência locais concretos para consultar.

A distinção entre autorização de sessão e aprovação por chamada é útil para definir as expectativas acima. A pessoa que chega deve decidir quais credenciais precisam de uma nova decisão humana a cada uso, em vez de herdar a configuração conveniente escolhida pelo desenvolvedor que está saindo.

Para verificar offline seu registro de auditoria criptografado e encadeado por hash, o novo revisor pode executar este comando:

```sh
sp audit verify
```

Um resultado bem-sucedido deve informar que a verificação foi concluída com sucesso. Um resultado malsucedido deve indicar que a verificação falhou, em vez de tratar silenciosamente o registro como confiável. Execute o comando como parte das evidências da transferência e salve o resultado com o registro. O comando verifica a cadeia sobre o texto cifrado e não precisa da chave do cofre. Isso é útil quando o revisor precisa verificar os registros sem receber acesso às credenciais.

Não transforme o gateway em um projeto geral de políticas. Um documento longo de regras, com exceções para cada equipe, envelhece mal e dificulta as transferências. Mantenha os pontos de decisão compreensíveis: o cofre pode permitir alguma ação, essa execução do agente tem autorização e essa credencial exige uma pessoa a cada uso? Depois, certifique-se de que pessoas nomeadas sejam responsáveis pelas respostas.

## A aprovação final deve provar que a equipe consegue operar sem a pessoa que saiu

Encerre a transferência somente depois que a equipe que chega demonstrar controle sobre cada caminho ativo. Um documento assinado sem teste de revogação, revisor nomeado e rota de escalonamento funcionando é burocracia, não evidência.

Use esta checklist final para cada grupo de credenciais incluído no escopo:

1. O registro identifica o serviço, o escopo, o responsável pela credencial, o aprovador, o revisor, o substituto e o responsável pela revogação de emergência.
2. O responsável pelo serviço escolheu manter, alternar, reduzir o escopo ou revogar, e a equipe registrou o resultado.
3. O novo aprovador aceitou por escrito as expectativas de aprovação de sessão e por chamada.
4. O revisor de auditoria encontrou registros recentes de ações e verificou a integridade quando havia uma checagem disponível.
5. A equipe testou a revogação ou a negativa com uma solicitação inofensiva e registrou o resultado.

Peça ao desenvolvedor que está saindo para assinar apenas a precisão do que foi informado, não ações futuras depois do fim da função. Peça ao novo responsável pela credencial e ao responsável pelo serviço que aceitem suas responsabilidades separadamente. Essa divisão importa quando um incidente posterior revela um caminho de acesso antigo: a equipe consegue ver se a falha veio de uma credencial não informada, de uma rotação não realizada ou de um responsável que nunca aceitou o trabalho.

O teste final é simples. Peça às pessoas que chegam para responder, sem chamar o desenvolvedor que saiu: qual agente consegue acessar este serviço, quem pode aprová-lo, quem lê o registro e quem pode interrompê-lo esta noite? Se alguma resposta for vaga, a transferência ainda não terminou.