Autorização do agente após a reinicialização: permissões que expiram

Uma reinicialização do Mac cria um limite técnico claro para as equipes. Use-o. O processo do agente termina, sua memória desaparece e toda aprovação ligada àquela execução específica deve terminar com ela. Tentar retomar o trabalho autônomo de forma invisível depois de uma reinicialização costuma transformar uma permissão restrita e verificável em acesso permanente, com uma explicação vaga sobre quando ele expira.

Isso não significa que uma reinicialização deva apagar tudo. As equipes precisam das evidências que explicam ações anteriores, das credenciais criptografadas que dão suporte ao trabalho futuro e de contexto suficiente da tarefa para retomá-la de forma deliberada. A disciplina é simples: preserve registros e materiais protegidos; descarte a autoridade ativa. Depois, exija que alguém aprove o processo recém-iniciado antes que ele se comunique com o mundo externo.

A autorização do agente após a reinicialização deve começar com um estado de execução vazio

A autorização do agente após uma reinicialização deve começar sem concessões ativas de processo, sem cofre desbloqueado, sem segredo de sessão herdado e sem uma aprovação lembrada que um novo processo possa usar. Uma reinicialização encerra o objeto que recebeu a aprovação. Tratar o processo substituto como equivalente só porque ele usa o mesmo checkout, comando ou nome de agente é um erro de identidade.

É comum alguém argumentar que isso cria atrito depois de uma atualização do sistema operacional ou de uma interrupção de energia. De fato, cria uma pausa intencional. Essa pausa obriga alguém a examinar o processo que agora quer autoridade, e não o processo aprovado horas antes em condições diferentes.

Um limite de reinicialização bem definido tem quatro propriedades úteis:

• Limpa materiais voláteis, como tokens de acesso em memória, referências a chaves descriptografadas, confirmações pendentes e identificadores de processo.
• Impede que um agente carregue uma aprovação durante um período sem supervisão, quando o operador talvez já não esteja presente.
• Oferece à equipe um marcador de auditoria confiável para reconstruir se uma ação ocorreu antes ou depois da reinicialização.
• Expõe dependências ocultas de caches locais, helpers em segundo plano e multiplexadores de conexão.

Não confunda reinicialização com logout do usuário. O logout também deve encerrar a autoridade do agente, mas a reinicialização é mais fácil de testar porque termina praticamente todos os processos comuns. Se uma concessão sobreviver a ela, alguém armazenou essa concessão de propósito ou criou um helper que vive fora do ciclo de vida do agente. Em ambos os casos, é preciso investigar.

A regra vale mesmo quando o binário do agente é assinado e não mudou. A assinatura de código pode ajudar o operador a identificar o editor do programa. Ela não prova que o processo em execução tem as mesmas instruções, variáveis de ambiente, estado do repositório, configuração de ferramentas ou intenção do operador da execução anterior. Um processo assinado ainda pode receber um prompt perigoso depois da reinicialização.

A mesma regra vale para uma tarefa planejada. Suponha que um agente tenha preparado uma migração de banco de dados, pedido aprovação e que o Mac tenha reiniciado antes da execução. O plano pode permanecer em um diretório de trabalho. A autoridade para executá-lo não pode. Depois da reinicialização, o agente deve apresentar novamente a operação pretendida, e o operador deve decidir se ela continua correta.

É nesse ponto que muitos projetos se tornam descuidados. Eles salvam um registro permanente que diz «aprovado» e o chamam de sessão. Esse registro vira uma permissão transferível porque um processo posterior pode reivindicá-lo. Uma concessão de sessão precisa estar ligada a uma instância de processo ativa e ter uma duração curta e definida. Quando o processo termina, o registro de autorização deve indicar que ela acabou, em vez de continuar disponível para reutilização.

Preserve evidências e configuração, descarte concessões ativas

A equipe deve preservar fatos que expliquem o trabalho e configurações que possam ser reutilizadas com segurança, eliminando ou invalidando todo objeto que conceda autoridade imediata. Coloque essas categorias em armazenamentos e ciclos de vida diferentes. Misturá-las produz o problema conhecido em que um registro de auditoria se transforma acidentalmente em um token de autorização.

A separação a seguir funciona bem na prática:

A primeira coluna dá continuidade ao trabalho. A segunda impede que continuidade se transforme em retenção silenciosa de privilégios.

Preserve o status do trabalho interrompido, mas faça com que ele seja descritivo. Bons registros dizem que a execução R-1842 solicitou um comando SSH, recebeu aprovação e parou antes da execução porque o host reiniciou. Registros ruins dizem que a execução R-1842 pode executar as ações restantes depois do próximo lançamento. O primeiro permite que o operador decida. O segundo decide antecipadamente, sem saber o que o processo posterior fará.

A armazenagem de credenciais exige a mesma precisão. Uma chave de API armazenada de forma criptografada em um cofre pode permanecer após a reinicialização. A forma descriptografada não deve continuar disponível só porque a máquina reiniciou rapidamente. Bloquear o cofre cria um ponto explícito em que a pessoa diante do Mac restabelece sua presença. Isso é separado da decisão sobre se um processo de agente pode usar determinada credencial.

O Sallyport segue essa separação: sua barreira do cofre bloqueia toda ação enquanto ele está bloqueado, e sua autorização por sessão se aplica a um processo de agente recém-conectado, não a um rótulo de tarefa lembrado. São duas decisões diferentes, e juntá-las torna a análise de incidentes muito mais difícil.

Não preserve uma aprovação escondendo-a em recursos de conveniência. Alguns exemplos parecem inofensivos até se acumularem:

• Um launch agent reinicia um cliente MCP e fornece a ele o arquivo de sessão antigo.
• Um cliente SSH mantém um socket de controle em /tmp ou em um diretório de cache do usuário.
• Um script copia um token bearer para um arquivo de ambiente para que as tentativas funcionem depois da reinicialização.
• Um executor encontra um trabalho inacabado e o executa antes de perguntar se o destino mudou.

Cada recurso promete preservar o progresso. Cada um também pode preservar autoridade sem mostrar ao operador quem ou o que a possui agora.

Use um registro de interrupção. Dê a ele uma referência da tarefa, o identificador da execução anterior, um resumo da lista de ações pretendidas, os nomes dos destinos e um status como stopped_by_reboot. Não inclua uma credencial utilizável, cookie, token de aprovação nem instrução que um launcher possa executar. Na execução seguinte, mostre esse registro como contexto para uma pessoa. Contexto ajuda na análise; a autoridade deve vir de uma decisão recente.

Uma reinicialização não é um evento de rotação de credenciais

Uma reinicialização deve expirar as permissões do agente, mas não deve trocar automaticamente chaves de API ou chaves SSH. Esses controles respondem a modos de falha diferentes. A expiração da autorização limita quem pode usar uma credencial existente e por quanto tempo. A rotação substitui a credencial porque há suspeita de exposição, perda, uso indevido ou mudança na necessidade de acesso.

As equipes perdem tempo e quebram integrações quando tratam toda reinicialização como um evento de exposição. Também criam uma falsa sensação de segurança quando a rotação rotineira mascara uma credencial vazada sem identificar onde ela escapou. Trocar uma chave não corrige um projeto que entregou essa chave a um agente, colocou-a em um transcript ou escreveu-a no histórico do shell.

A publicação NIST Special Publication 800-63B separa o gerenciamento de sessões do ciclo de vida dos autenticadores. Suas orientações tratam o encerramento da sessão e a reautenticação como controles explícitos, enquanto a substituição do autenticador aborda outro problema. Essa distinção se adapta bem aos sistemas de agentes. Encerre a execução ativa do agente na reinicialização. Troque as credenciais subjacentes apenas quando houver evidências ou uma política que exija isso.

Use a rotação depois da reinicialização quando a própria reinicialização tiver ocorrido após um evento de exposição plausível. Exemplos incluem descobrir que um segredo chegou a um log de prompt, encontrar um processo desconhecido com acesso ao ambiente do agente, perder um laptop ou saber que uma ex-pessoa da equipe reteve uma credencial copiada. Nesses casos, a reinicialização é um detalhe incidental. A suspeita de vazamento é o que determina a rotação.

Credenciais bearer de longa duração merecem atenção especial porque podem funcionar em qualquer lugar permitido pela rede. Se um agente receber seu valor em texto simples, o gateway já perdeu a fronteira limpa que torna significativa a expiração após a reinicialização. O agente pode armazenar ou transmitir esse valor antes que a máquina reinicie. Uma nova aprovação de sessão não consegue recuperá-lo.

O SSH tem suas próprias armadilhas. Uma chave privada pode continuar protegida em um cofre local, mas uma conexão SSH existente pode continuar executando canais remotos até ser encerrada. O multiplexamento de conexões SSH também pode deixar um socket de controle local que um cliente posterior usa. Em circunstâncias normais, a reinicialização deve limpar ambos, mas não faça suposições. Teste as opções reais do cliente e o comportamento dos helpers usados pela equipe.

A política prática é esta: preserve as credenciais de origem criptografadas, bloqueie-as na reinicialização, encerre todas as concessões e transportes ativos e exija uma nova autorização do processo antes que o gateway use novamente uma credencial. Adicione gatilhos de rotação baseados em exposição e mudanças de pessoal, não em um evento arbitrário de inicialização.

Essa política também mantém a resposta a incidentes honesta. Se um operador disser «reiniciamos, então o acesso foi redefinido», pergunte se a credencial chegou a sair do armazenamento protegido e se o provedor remoto mantém sessões independentes. Uma reinicialização redefine o estado de execução local. Ela não invalida um token no provedor de nuvem, a menos que o provedor receba um evento de revogação ou rotação.

Desbloqueio do dispositivo, presença humana e aprovação do processo são fatos separados

Uma retomada segura precisa de respostas separadas para três perguntas: o Mac pode acessar credenciais protegidas, há uma pessoa responsável presente e qual processo está pedindo para usá-las? Um projeto que usa um único sinal para responder às três perguntas dá significado demais a esse sinal.

O desbloqueio do dispositivo controla o acesso ao ambiente do usuário local. Ele pode indicar que alguém passou pela proteção de login do Mac. Em hardware compatível, um cofre pode usar Secure Enclave e Touch ID para manter os segredos indisponíveis enquanto estiver bloqueado. Isso protege o material em repouso e cria um limite de ação claro, mas não diz nada específico sobre o próximo processo lançado por uma estrutura de agente.

A presença humana é um momento no tempo. Uma confirmação biométrica ou um clique pode estabelecê-la para uma decisão específica. Permitir que uma verificação de presença aprove silenciosamente todas as ações externas futuras até a próxima reinicialização torna esse momento muito mais amplo do que o operador pretendia. O risco aumenta quando um agente de programação pode continuar por horas, ler arquivos de repositório que mudam ou aceitar instruções de pull requests e comentários de issues.

A aprovação do processo responde a uma pergunta mais restrita: autorizo este programa recém-iniciado a fazer chamadas ao gateway durante esta execução? A tela de aprovação deve identificar o processo com evidências duráveis, como a autoridade de assinatura do código, e evitar pedir que o operador interprete um título de processo mutável. Um rótulo como agent não é identidade. Qualquer pessoa pode escolher esse rótulo.

A ordem importa. Primeiro, o cofre precisa estar disponível. Depois, o gateway pode identificar o processo. Em seguida, o operador pode aprovar esse processo para a execução solicitada. Para credenciais especialmente sensíveis, peça uma confirmação a cada uso. Assim, a equipe tem três controles com funções diferentes, em vez de um único botão «permitir agente» com significado amplo.

Não use o nome da conta do Mac como substituto da identidade do processo. Uma conta local compartilhada pode executar várias sessões de terminal, ferramentas de compilação, editores e hosts de agentes. Se uma aprovação acompanhar a conta inteira, um comando de shell malicioso ou um segundo agente poderá gastar uma autoridade destinada a outro processo.

A decisão de aprovação também não deve fingir responder a perguntas de escopo que ela não responde. Uma concessão no nível do processo diz quem pode chamar o gateway durante determinada execução. Ela não deve implicar silenciosamente permissão para toda credencial ou toda ação para sempre. Combine-a com seleção de credencial e, quando necessário, confirmação por chamada. Isso impede que uma credencial de alto impacto herde a conveniência de uma chamada de API de baixo risco.

Existe a tentação de resolver isso com uma linguagem de políticas elaborada, com condições sobre horário, caminho de origem, nome da branch, hostname, padrões de comando e prompts. Esses sistemas podem funcionar para equipes dedicadas à segurança, mas criam outro risco quando desenvolvedores comuns não conseguem prever o resultado. Um conjunto pequeno de decisões visíveis é mais fácil de executar depois da reinicialização e de explicar durante uma revisão.

Retome uma execução identificada, não uma permissão ampla da equipe

As equipes podem retomar trabalhos interrompidos com segurança quando tornam o item de trabalho permanente e a autorização temporária. O agente reiniciado deve receber contexto suficiente para continuar, mas precisa obter nova autoridade como um novo processo. Uma aprovação lembrada para todo o projeto é o atalho errado, porque permite que trabalhos sem relação herdem uma decisão antiga do operador.

Dê a cada execução relevante uma referência permanente que as pessoas já entendam. Um caminho de repositório e uma branch podem funcionar para tarefas de desenvolvimento. Um número de ticket, uma solicitação de mudança, um nome de ambiente ou um identificador de incidente pode funcionar melhor para tarefas operacionais. A referência não concede permissão. Ela permite que uma pessoa compare a execução reiniciada com o trabalho esperado.

Um cartão de retomada ou prompt de terminal útil contém cinco informações:

1. O identificador da execução anterior e o motivo de seu fim, como stopped_by_reboot.
2. A referência do trabalho e a revisão do repositório ou artefato de implantação usado pela execução anterior.
3. A próxima ação externa proposta pelo novo processo, incluindo destino e rótulo da credencial.
4. As evidências de identidade do processo atual, não apenas do processo anterior.
5. Uma opção para aprovar esta execução, rejeitá-la ou consultar o registro da ação anterior.

Não restaure uma fila inteira de ações sem revisão. O mundo externo pode ter mudado enquanto o Mac estava desligado. Uma pull request pode ter recebido um force-push, um registro DNS pode apontar para outro lugar, uma implantação pode ter sido concluída por outro caminho ou uma janela de manutenção pode ter terminado. O fato de um agente ter formado um plano antes não torna apropriados seus efeitos posteriores.

Considere um agente que atualizava uma frota por meio de uma API HTTP. Antes da reinicialização, ele alterou com sucesso os hosts A a D e preparou chamadas para E a H. O Mac reinicia. Ao iniciar, o agente encontra sua fila antiga e tenta continuar. Uma implementação descuidada reutiliza o token e envia E a H. Uma implementação mais segura lê o registro de interrupção, cria uma nova execução, solicita autorização, consulta o estado atual e apresenta as chamadas restantes pretendidas. Ela pode descobrir que outro operador já alterou F e G. A autorização recente deu à pessoa a chance de perceber isso.

O comportamento de novas tentativas precisa de um limite claro. Se o gateway negar uma chamada porque o cofre está bloqueado ou porque o processo não tem aprovação, o cliente deve parar e informar qual ação foi bloqueada. Ele não deve entrar em loop, abrir prompts repetidos, recorrer ao acesso direto à rede ou substituir a credencial por uma variável de ambiente. Uma nova tentativa depois de uma falha de rede transitória é razoável somente se a chamada ainda tiver uma autorização válida.

Essa abordagem não exige que um agente esqueça seu trabalho. Preserve o plano, a saída do comando, o diff do repositório e uma nota em linguagem simples que descreva a interrupção. Trate esses artefatos como evidências para uma nova decisão. A diferença parece pequena em uma reunião de projeto e se torna enorme durante um incidente: o plano salvo explica a intenção, enquanto uma concessão herdada executa uma ação sem uma nova decisão responsável.

Para operações sensíveis, peça ao agente reiniciado que leia o estado atual antes de propor a próxima ação. Isso é especialmente útil para chamadas destrutivas de API e comandos SSH cujos efeitos dependem do estado atual do host. A leitura adicional não é uma permissão. É uma verificação de que o plano antigo ainda descreve o mundo.

HTTP e SSH precisam de regras explícitas para reinicialização

APIs HTTP e SSH precisam de uma nova autorização do agente depois da reinicialização, mas seus estados ocultos são diferentes o bastante para que uma afirmação vaga de «redefinição de sessão» deixe passar falhas. Escreva o comportamento de redefinição de cada canal e teste os caminhos realmente usados pelos agentes.

No HTTP, diferencie a credencial de um token de acesso ou cookie emitido por um serviço remoto. Um gateway pode manter a credencial criptografada localmente e injetá-la em uma solicitação apenas depois da aprovação. O agente deve receber a resposta, não a credencial bearer. Depois da reinicialização, descarte qualquer token de acesso local em cache, cabeçalhos de solicitação guardados para novas tentativas, cookies usados pela automação e estado de conexões abertas.

Um provedor pode preservar uma sessão remota depois da reinicialização se um cliente apresentar posteriormente um refresh token ou cookie ainda válido. Por isso, o agente não deve possuir esses artefatos. Se possuir, ele poderá chamar o provedor diretamente e contornar as regras locais de reinicialização. Coloque a injeção e a renovação de credenciais no lado de ação da fronteira, onde um processo autorizado recentemente as invoca.

No SSH, encerre as conexões do cliente e inspecione o multiplexamento. O OpenSSH pode reutilizar uma conexão mestre por meio de ControlMaster e ControlPath; isso ajuda usuários interativos, mas pode dificultar saber qual invocação é dona de uma sessão remota. Um gateway de agente deve usar um caminho de execução stateless ou um ciclo de vida que encerre corretamente qualquer helper quando a execução do agente terminar. Nunca suponha que um comando remoto parou porque a interface local foi fechada.

Use este teste de reinicialização reproduzível para os dois canais:

1. Inicie uma execução do agente e aprove uma solicitação HTTP inofensiva ou um comando SSH em um destino que não seja de produção.
2. Registre o identificador da execução, a identidade do processo, a solicitação pretendida e o horário da última ação concluída.
3. Reinicie o Mac antes que o agente execute uma segunda ação previamente combinada.
4. Inicie novamente o host do agente sem alterar os arquivos da tarefa e peça que ele faça essa segunda ação.
5. Confirme que a primeira tentativa é negada até que o cofre esteja disponível e o novo processo receba aprovação. Depois, examine o registro para garantir que a segunda ação pertence a um identificador de execução diferente.

Para um gateway que ofereça um verificador de auditoria pela linha de comando, execute o verificador antes e depois do teste:

sp audit verify

O comando deve informar se a cadeia de auditoria criptografada pode ser verificada, sem exigir que o cofre seja desbloqueado. Não escreva automações que analisem uma mensagem de sucesso inventada a partir de um comando voltado para pessoas. Verifique o status de saída documentado e preserve a saída do comando junto com o registro do teste. O Sallyport projeta os diários de sessão e de chamadas individuais a partir de um log de auditoria criptografado, encadeado por hash e protegido contra gravação, portanto o verificador oferece aos operadores uma checagem de integridade offline depois de uma reinicialização.

O teste também deve cobrir o caminho de falha. Tente usar uma variável de ambiente antiga, um perfil de cliente HTTP em cache, um socket de controle SSH e um segundo processo de agente local. Se algum deles alcançar o destino sem uma nova autorização, o limite de reinicialização é apenas decorativo. Corrija o desvio, em vez de adicionar mais um lembrete aos operadores.

Os registros de auditoria devem explicar a execução antiga e a nova

Um registro de auditoria após a reinicialização deve mostrar onde uma execução terminou e onde outra começou. A separação precisa continuar visível mesmo quando o mesmo usuário, repositório e estrutura de agente retomam a mesma tarefa. Se o registro juntar esses eventos em uma única sessão longa, não poderá responder quem autorizou a ação posterior à reinicialização.

Registre explicitamente o estado final da execução anterior. Valores úteis incluem saída normal, negada pelo bloqueio do cofre, negada enquanto aguardava aprovação, desligamento do host, falha de rede e revogação pelo operador. Não substitua esse estado quando o novo processo iniciar. Um registro de reinicialização deve apontar para a execução anterior, não se fundir a ela.

Na nova execução, registre as evidências de identidade do processo apresentadas na autorização, o horário da aprovação e a primeira chamada externa. A primeira chamada importa porque aprovação nem sempre significa uso. Um operador pode aprovar uma execução que termina antes de agir. Distinguir aprovação de execução impede que uma revisão afirme que uma ação ocorreu quando o operador apenas permitiu essa possibilidade.

Os registros de chamadas individuais devem preservar contexto suficiente para reconstruir a ação sem armazenar um segredo. Para HTTP, capture destino, método, rótulo da credencial, classe do resultado e uma representação redigida dos metadados da solicitação. Para SSH, registre destino, rótulo da conta, comando ou um resumo aprovado dele, status de saída e metadados do resultado. O tratamento exato da retenção da saída do comando depende de sua sensibilidade, mas não elimine o fato de que uma ação ocorreu.

O encadeamento por hash facilita a detecção de adulterações posteriores, mas não torna a adulteração impossível. Ele é útil porque cada registro se compromete com os registros anteriores, e a verificação offline pode revelar uma sequência quebrada. Isso não prova que uma ação aprovada foi sensata nem impede alguém com autoridade de emitir uma ação. As equipes ainda precisam de revisão e limites de aprovação disciplinados.

Mantenha o verificador de auditoria fora do caminho normal do agente. Um agente que possa reescrever ou validar suas próprias evidências cria uma afirmação circular de confiança. Os operadores devem conseguir executar a verificação de forma independente, inclusive enquanto o cofre permanece bloqueado. Também devem testar o que acontece quando um registro é alterado em uma cópia dos dados de auditoria, para conhecer o comportamento esperado de falha antes de precisarem dele.

A revogação imediata também precisa registrar seu escopo. Se um operador revogar uma sessão depois da reinicialização, o diário deve mostrar qual execução perdeu autoridade e quais chamadas foram negadas depois disso. Evite uma afirmação global como «acesso do agente desativado», a menos que isso seja literalmente o que aconteceu. Registros precisos impedem que a equipe tenha de adivinhar se outro processo ainda mantinha uma aprovação.

Defina as regras de expiração antes que a automação as defina

Uma política segura de reinicialização é curta o bastante para que qualquer pessoa desenvolvedora consiga repeti-la corretamente: uma reinicialização bloqueia o material protegido, encerra toda concessão de processo do agente e preserva as evidências e o contexto de tarefa não executável. Um processo recém-lançado recebe uma nova autorização revisada. As credenciais só são trocadas quando regras de exposição ou de ciclo de vida exigirem isso.

Escreva essa política em termos operacionais e atribua uma pessoa responsável a cada exceção. Se uma equipe disser que precisa manter a automação ininterrupta durante reinicializações, pergunte que ação continuaria, qual conta seria responsável, como ela seria monitorada e por que um limite de aprovação humana seria inaceitável. Isso pode descrever uma carga de trabalho de conta de serviço, não um agente de programação interativo. Dê a ela um projeto separado, em vez de transformar silenciosamente uma sessão de agente em uma credencial de servidor.

Defina uma resposta previsível para o primeiro dia útil após uma reinicialização inesperada. O operador verifica a integridade da auditoria, confere a última chamada concluída da execução anterior, desbloqueia o material protegido se for apropriado, inicia um novo processo de agente, revisa a tarefa retomada e aprova apenas o trabalho que ainda pertence à situação atual. É uma interrupção modesta em comparação com reverter uma ação executada sob uma aprovação que ninguém percebeu que havia sobrevivido.

Não prometa que a lógica de reinicialização tornará o trabalho autônomo seguro por si só. Ela pode apenas criar um ponto de decisão limpo. A qualidade dessa decisão ainda depende de uma identidade clara do processo, uso restrito de credenciais, descrições legíveis das ações e registros que outra pessoa possa analisar mais tarde.

Quando a próxima reinicialização interromper uma tarefa real, resista à vontade de adicionar uma opção «continuar automaticamente». Preserve o plano. Preserve as evidências. Faça o novo processo perguntar novamente antes de gastar autoridade.