# Acesso bloqueado ao cofre local: um guia operacional para o trabalho de agentes

O trabalho autônomo falha de uma forma muito previsível quando as pessoas tratam um cofre local bloqueado como um incômodo. O agente encontra uma barreira de credenciais no meio da tarefa, alguém se sente pressionado a terminar, e um segredo acaba copiado para uma variável do shell, um arquivo de configuração ou uma mensagem de conversa. A tarefa termina no curto prazo. A equipe também criou um caminho de credencial não rastreado que continuará existindo depois da tarefa.

Um cofre bloqueado deve orientar o plano de trabalho antes de o agente começar. O operador precisa decidir três coisas separadas: quando desbloquear o acesso, qual processo de agente pode agir durante essa execução e quais ações individuais ainda exigem uma decisão humana. Equipes que juntam essas decisões em um vago «pode prosseguir» acabam soterradas por prompts ou contornam os controles.

Isso não significa manter uma pessoa acompanhando cada comando. Significa colocar a atenção humana onde ela muda o resultado. A descoberta somente para leitura muitas vezes pode ocorrer em uma sessão delimitada. Uma exclusão em produção, uma mudança de permissão ou a publicação de uma versão merecem uma nova decisão no momento em que acontecem. O restante depende de um plano de execução que o operador consiga entender antes de o agente começar.

## As janelas de desbloqueio precisam de um responsável e de um horário de término

O operador deve desbloquear um cofre local para uma janela de trabalho definida, com uma pessoa responsável pela decisão e uma condição conhecida para encerrá-la. «Deixe aberto enquanto eu estiver trabalhando» parece prático, mas falha quando uma reunião, o almoço, o computador entrando em repouso ou uma mudança de contexto interrompe o trabalho. Um cofre aberto então vira uma autoridade que ninguém está considerando ativamente.

A decisão de desbloquear concede a forma mais ampla de acesso na cadeia. Se o cofre continuar bloqueado, nenhuma sessão de agente e nenhuma solicitação individual deve passar por ele. Isso torna o estado bloqueado útil, mas somente se a equipe o tratar como uma barreira operacional, e não como uma etapa cerimonial de login.

Use uma janela de trabalho que acompanhe o ritmo natural da tarefa. Um reparo pequeno pode precisar de uma única janela curta. Uma migração planejada pode precisar de uma janela que cubra preparação, execução e verificação, com uma pausa programada antes de qualquer fase irreversível. Uma investigação que apenas lê logs deve usar uma janela separada daquela que altera configurações de produção.

Antes de abrir o acesso, o operador deve registrar cinco fatos:

- quem é responsável pela decisão de autorização;
- que trabalho o agente pode executar;
- quais ambientes e contas o trabalho pode acessar;
- qual condição encerra a janela;
- quem revisará o resultado se o responsável precisar se ausentar.

Esse registro não precisa de uma grande cerimônia. Um comentário no ticket ou uma nota da execução basta quando define limites reais. «Corrigir problema de implantação» não é suficiente. «Inspecionar a implantação de staging que falhou e depois repetir somente a implantação identificada se o digest da imagem corresponder ao build aprovado» dá ao revisor algo que pode ser verificado.

Evite usar apenas o relógio como condição de encerramento. Um horário limite ajuda, mas o trabalho costuma atrasar porque o agente encontra uma dependência inesperada. Combine um limite de tempo com um limite de estado: encerre depois da verificação planejada, quando surgir o primeiro destino inesperado ou quando o responsável se afastar. Uma tarefa que ultrapassar o limite deve solicitar uma nova janela. Essa pequena interrupção obriga alguém a decidir se a autorização original ainda se aplica ao trabalho.

A alternativa popular é a conveniência permanente: desbloquear no começo do dia e bloquear no fim. As equipes escolhem isso porque os desbloqueios interrompem o fluxo. É o padrão errado para o trabalho autônomo, pois o agente pode continuar na velocidade da máquina enquanto a atenção humana que justificou o acesso se deslocou para outro lugar. Se desbloqueios repetidos parecerem insustentáveis, melhore o agrupamento do trabalho e o desenho das aprovações. Não remova a barreira.

## Desbloqueio do cofre, aprovação da execução e aprovação da ação respondem a perguntas diferentes

Um cofre local bloqueado precisa de três decisões distintas porque cada uma controla um risco diferente. O desbloqueio responde se ações com credenciais podem acontecer. A aprovação de uma execução responde se esse processo de agente identificado pode usar o caminho de ação disponível para seu trabalho delimitado. A aprovação de uma chamada individual responde se esse uso específico de uma credencial específica merece uma nova decisão humana.

As equipes frequentemente confundem as duas primeiras. Elas desbloqueiam o cofre e presumem que todo processo na máquina agora tem permissão para agir. Isso transforma uma verificação de presença física ou local em uma autorização ampla de software. O outro padrão ruim é aprovar cada solicitação inofensiva porque a equipe nunca definiu o que a aprovação de uma sessão significa. Os operadores aprovam dezenas de leituras rotineiras e acabam parando de ler os cartões.

A diferença é mais importante quando uma tarefa muda de forma. Suponha que um agente receba aprovação para inspecionar um build que falhou, consultar uma API de implantação e coletar logs. Ele descobre que uma permissão ausente pode explicar a falha. A execução original não incluía alterar controles de acesso. O agente deve parar e solicitar uma nova decisão, mesmo que o cofre esteja aberto e sua sessão de processo continue aprovada. O objetivo da tarefa mudou de diagnóstico para administração.

Uma divisão sensata é esta:

- Desbloqueie o acesso enquanto uma pessoa responsável puder supervisionar o trabalho planejado.
- Aprove um único processo de agente identificado para a execução descrita, incluindo as ações comuns que se enquadram no contrato.
- Exija uma aprovação separada para chamadas de alto impacto, como publicar, excluir, alterar permissões, rotacionar credenciais ou gravar em produção.

As categorias exatas de ação variam entre as equipes. O importante é classificá-las pela consequência, não pelo número de chamadas de API. Uma solicitação para revogar uma conta de produção merece mais atenção do que cinquenta solicitações para buscar metadados de build.

É nesse ponto que a sequência fixa de decisões do Sallyport é intencionalmente limitada: a barreira do cofre bloqueia todas as ações enquanto ele está bloqueado, a autorização por sessão aprova um novo processo de agente durante sua existência e uma configuração por chave pode exigir aprovação em cada uso. O desenho não pede que os operadores escrevam uma linguagem de políticas que se torne outro programa de segurança para depurar durante uma indisponibilidade.

Não diga que uma barreira por chamada torna qualquer credencial segura. Ela apenas disponibiliza uma decisão humana no ponto de uso. O operador ainda precisa de contexto suficiente para julgar a solicitação. Se o prompt disser apenas «use o token de produção», o controle já perdeu a maior parte do seu valor. Inclua destino, ação e efeito esperado no plano de execução e compare a solicitação com esse plano.

## Programe o acesso de acordo com os estados do trabalho, não com o horário comercial

A equipe deve planejar o trabalho do agente como uma sequência de estados, com pontos explícitos onde a autoridade começa, pausa, se reduz ou termina. O horário comercial ajuda no dimensionamento da equipe, mas não descreve o trabalho real. Uma tarefa pode começar durante o horário supervisionado, esperar por um sistema externo e continuar muito depois de a pessoa que a aprovou ter ido embora.

Use quatro estados no registro da tarefa: preparação, execução ativa, suspensa e revisão. A preparação não tem ações com credenciais. O agente pode inspecionar o repositório, montar comandos, validar entradas e explicar as chamadas pretendidas sem acesso ao cofre. A execução ativa começa somente quando um operador abre a janela de acesso e aprova a execução. Suspensa significa que o agente chegou a uma condição de espera, a uma decisão inesperada ou ao fim do escopo aprovado. A revisão fecha o ciclo antes de a equipe conceder autoridade para uma continuação relacionada.

Esse modelo simples evita uma falha comum. Um engenheiro inicia um agente para limpar recursos de uma implantação às 16h30. O agente executa testes, identifica recursos obsoletos e espera uma operação na nuvem terminar. Às 17h15, ele continua, descobre que outra conta precisa de limpeza e segue em frente porque a sessão ainda existe. O operador original já foi embora. Mesmo que todas as chamadas de API tenham sucesso, a equipe permitiu que a tarefa migrasse para outro escopo sem uma decisão responsável.

Escreva as regras de pausa antes da execução. Boas regras de pausa são observáveis:

- pare se a conta, o host ou o ambiente de destino for diferente do registrado;
- pare se o agente precisar de uma classe de credencial que não esteja no plano;
- pare antes de qualquer ação que crie, exclua, publique ou altere permissões;
- pare depois de uma gravação que falhar, até o operador revisar o erro retornado;
- pare quando o operador identificado ficar indisponível.

Uma pausa não é uma falha. É uma transição de estado limpa. O agente deve preservar o comando ou a solicitação exata que pretendia fazer, as entradas coletadas e o motivo da parada. O próximo operador poderá então decidir se deve continuar sem reconstruir a tarefa a partir de uma conversa confusa.

Isso também mantém a urgência sob controle. Se um trabalho fora do horário precisar de uma ação, alguém deve decidir se o impacto para o negócio justifica abrir uma nova janela de acesso. Às vezes as equipes chamam toda tarefa bloqueada de urgente porque o agente já trabalhou por dez minutos. Isso é pensar pelo custo irrecuperável. Uma barreira de credencial deve fazer o humano escolher novamente quando as circunstâncias mudarem.

## A identidade do processo precisa estar visível antes de uma execução ganhar confiança

Uma aprovação deve identificar o processo de agente por mais do que um rótulo de terminal ou um nome fornecido pelo usuário. Um processo chamado «deploy-agent» pode ser o executável esperado, um script local ou algo iniciado por uma dependência comprometida. O operador precisa de um sinal significativo sobre quem produziu e iniciou o programa que está pedindo autoridade.

A identidade de assinatura de código é útil porque vincula a decisão de aprovação a uma autoridade executável, em vez de vinculá-la a um texto que qualquer processo pode imprimir. Isso não prova que todos os prompts dados ao agente foram sensatos. Mas oferece uma resposta mais forte a uma pergunta básica de incidente: qual processo recebeu permissão para usar o cofre?

Exija que a nota da execução informe o ponto de entrada do agente e o diretório de trabalho ou repositório. Isso dá ao operador duas verificações antes da aprovação: a identidade do processo mostrada pelo sistema e o contexto da tarefa esperado pela equipe. Se os dois forem diferentes, negue a solicitação e inspecione a máquina. Não aprove primeiro só porque a tarefa parece familiar.

Um fluxo de aprovação limpo tem uma quantidade moderada de atrito. A primeira chamada com credenciais de um novo processo dispara a aprovação. O operador confirma a autoridade do processo e o objetivo da execução. O processo pode continuar dentro da sessão aprovada até sair, ser revogado pelo operador ou o cofre ser bloqueado. Um processo novo solicita aprovação novamente.

Esse último detalhe bloqueia uma forma sutil de contorno. Se a equipe aprovar uma sessão de terminal identificada em vez de um processo, alguém poderá iniciar um programa sem relação com a tarefa no mesmo terminal e herdar uma confiança que pertencia à execução anterior. Faça a autorização se vincular ao processo real do agente, não a uma janela, uma conta de usuário ou uma pasta de projeto.

O Sallyport mostra a autoridade de assinatura de código do processo quando solicita autorização por sessão, que é o detalhe de que o operador precisa antes de aprovar uma execução. Ainda assim, as equipes devem manter o objetivo escrito da execução ao lado desse sinal, pois a identidade informa quem está pedindo, enquanto o contrato informa se a solicitação faz parte da tarefa.

## As barreiras por chamada pertencem às autoridades irreversíveis

A aprovação por chamada funciona quando protege ações que uma pessoa consegue julgar em segundos, mas pode lamentar por muito mais tempo. Coloque-a em credenciais capazes de criar compromissos externos, alterar acessos, destruir dados ou afetar um serviço de produção. Não a aplique a todas as credenciais por hábito.

O erro comum é marcar uma conta inteira de produção como «perigosa» e exigir aprovação para toda solicitação. O agente então faz muitas leituras inofensivas, o operador as aprova rapidamente e a única gravação destrutiva chega entre prompts familiares. O controle virou um metrônomo. As pessoas têm dificuldade para manter a atenção diante de confirmações repetitivas e com pouca informação.

Separe as autoridades quando o provedor permitir. Use uma credencial de leitura para descoberta, uma credencial de gravação com escopo limitado para manutenção comum e uma credencial de maior impacto para ações que exigem uma decisão por chamada. Se o provedor oferecer apenas um token amplo, trate todo uso desse token como autoridade ampla. Não finja que apenas o método HTTP determina o risco. Um POST pode buscar dados, e um endpoint GET pode iniciar uma operação em APIs mal projetadas.

A RFC 6750 descreve claramente um token bearer: qualquer parte que o possua pode usá-lo. Essa propriedade explica por que entregar um token a um agente, mesmo «só para esta tarefa», cria um problema maior que a operação imediata. O contexto do prompt do agente, o histórico do shell, os logs, os plugins e futuras transferências podem se tornar locais de vazamento da posse. Mantenha o token dentro do cofre local e retorne apenas o resultado da operação.

Para SSH, evite o encaminhamento do agente como atalho para contornar o controle local. O manual `ssh_config` do OpenSSH alerta que encaminhar um agente de autenticação permite que um host remoto use o agente local e afirma que os usuários precisam confiar no host remoto. O trabalho autônomo amplia essa preocupação, pois um agente pode se conectar por um host cuja configuração ou destino não inspecionou completamente. Use um caminho SSH direto, nomeie o host permitido no contrato e pause quando surgir um host intermediário ou um destino novo.

Coloque a barreira por chamada na credencial, não em uma ideia vaga de «modo de produção». Essa escolha continuará compreensível depois. Um revisor poderá ver que essa credencial sempre exigia uma decisão, independentemente do agente que a solicitou ou do projeto que forneceu o prompt.

## Um contrato de execução evita aprovações baseadas em suposições

Um contrato de execução deve caber em um comentário curto de ticket e tornar a decisão de aprovação verificável. Ele não é um plano de projeto. Registra o menor conjunto de fatos que permite ao operador aprovar, negar, pausar e revisar o trabalho sem ler toda a transcrição do agente.

Use este modelo antes de o operador desbloquear o acesso:

```text
Run ID: 2025-03-incident-cleanup-01
Owner: name of approving operator
Purpose: inspect failed release and remove only the listed temporary resource
Agent process: expected executable and repository directory
Targets: staging account, api.example.internal, named SSH host
Allowed actions: read deployment state; delete resource tmp-4821 after match check
Per-call actions: delete request, any permission change, any production request
Stop conditions: target mismatch; unexpected credential; failed write; owner unavailable
Expected evidence: request IDs, resource IDs, command output, final status
Review owner: name of reviewer
```

O exemplo usa um identificador semelhante a uma data para facilitar a leitura, não como controle de segurança. Escolha um identificador que a equipe consiga pesquisar no sistema de tarefas e nos registros de atividade. As linhas importantes são os destinos, as ações permitidas e as condições de pausa. Elas impedem que uma execução se expanda porque o agente encontrou uma próxima tarefa plausível.

O contrato também revela planos ruins mais cedo. «Corrigir permissões» não informa o destino, a alteração permitida nem as evidências para revisão. Um operador não pode aprová-lo com responsabilidade. «Adicionar o grupo X à função Y em staging e verificar o vínculo da função com uma solicitação de leitura» é específico o bastante para ser revisado. Se o agente descobrir que o grupo X não existe ou que a função Y pertence à produção, deverá parar.

Não torne o modelo tão detalhado que as pessoas o preencham com uma precisão inventada. Uma lista longa de endpoints cria uma falsa sensação de controle quando o risco real é uma operação de negócio, como publicar um build ou remover uma conta. Nomeie endpoints quando eles esclarecem a barreira. Caso contrário, informe o recurso, o ambiente e o efeito.

Para tarefas recorrentes, mantenha um contrato estável com histórico de revisões. Um contrato recorrente não significa autoridade permanente. O operador ainda abre uma janela e aprova a execução específica do processo. O texto estável reduz a ambiguidade, mas não deve virar uma permissão abrangente que ninguém relê.

## Uma tarefa bloqueada precisa de um caminho seguro para pausar

As equipes criam soluções improvisadas quando um agente bloqueado não tem uma forma adequada de parar. O agente pode ter reunido metade das entradas, o operador pode estar indisponível e a tarefa pode parecer perto demais do fim para ser abandonada. Se as únicas opções parecerem ser «terminar agora» ou «perder todo o progresso», alguém exportará o segredo.

Crie um caminho de pausa que preserve o contexto sem preservar as credenciais. O agente registra o que observou, a ação externa exata que deseja executar, as entradas não secretas necessárias para continuar e o motivo pelo qual a barreira de aprovação o interrompeu. Ele nunca deve registrar um token, uma chave privada, um cabeçalho de autorização ou uma linha de comando que contenha um segredo.

Para uma operação HTTP, o registro de pausa pode conter o método, o host, a rota, o identificador do recurso, a classe de status esperada e o formato redigido do corpo. Para uma operação SSH, pode conter o alias do host, o nome de usuário remoto se isso não for sensível, o comando pretendido, a saída esperada e o resultado da verificação do host. Um operador pode inspecionar esse registro antes de abrir a próxima janela.

Uma nota de transferência útil poderia ser assim:

```text
State: held
Reason: planned cleanup target was absent; agent found a second temporary resource.
Observed: tmp-4821 absent, tmp-5930 created by the same failed release.
Requested next action: delete tmp-5930 after operator confirms it belongs to this incident.
No external write occurred after the original target check failed.
Evidence to review: deployment query result and resource metadata IDs.
```

Essa nota dá ao próximo operador uma escolha real. Ele pode autorizar a segunda exclusão, rejeitá-la ou pedir uma investigação adicional. O agente não pode reinterpretar silenciosamente «remover o recurso temporário listado» como «remover qualquer coisa parecida».

Não deixe o agente continuar tentando uma operação negada. A negação pode significar que o operador detectou uma divergência, que o cofre foi bloqueado ou que a barreira por chamada exigia uma decisão que não chegou. Loops de repetição transformam uma pausa clara em uma pilha de prompts. Trate a negação como estado de parada, a menos que o operador autorize explicitamente a mesma ação novamente.

A mesma regra vale quando uma chamada de API expira depois de uma solicitação de gravação. O agente não deve presumir que houve falha e repetir a solicitação. Quando possível, deve consultar o estado resultante com uma leitura segura, registrar a ambiguidade e esperar se a operação puder ter sido concluída. Gravações duplicadas causam alguns dos incidentes mais trabalhosos, pois parecem inofensivas no log de comandos até o sistema externo alcançá-las.

## Revise as evidências antes da próxima janela de acesso

A equipe deve revisar os resultados ao fim de uma execução, antes de conceder nova autoridade para um trabalho relacionado. Essa revisão identifica desvios enquanto o operador ainda se lembra do motivo da ação. Se a revisão esperar até o fim da semana, o ticket, a conversa, o terminal e a transcrição do agente contarão histórias ligeiramente diferentes.

O revisor deve comparar as evidências com o contrato de execução, e não com uma impressão geral de que a tarefa parece concluída. Verifique os destinos reais, as ações que tiveram sucesso, as que falharam, os identificadores retornados e as chamadas que saíram da sequência esperada. Uma falha pode ser aceitável. Um destino sem explicação não é.

Mantenha a revisão curta, mas concreta:

- O agente contatou somente os ambientes e hosts aprovados?
- Toda gravação correspondeu a uma ação permitida ou recebeu sua própria aprovação?
- O sistema externo retornou os identificadores esperados de recurso ou solicitação?
- O agente pausou em cada condição de parada definida?
- Uma tarefa de continuação precisa de um novo contrato, em vez de uma extensão deste?

Revisar a saída é diferente de revisar a autoridade. Um registro de sessão pode mostrar que um processo recebeu aprovação às 10h02 e terminou às 10h19. Um registro de ações pode mostrar as operações individuais de API e SSH realizadas nessa sessão. Você precisa das duas visões para responder se o processo fez apenas o que a execução permitia.

Um log de auditoria encadeado por hashes acrescenta outra propriedade: torna detectável uma alteração posterior. O Sallyport mantém visões de sessões e atividades projetadas a partir de um log de auditoria criptografado e sem possibilidade de gravação, e `sp audit verify` pode verificar essa cadeia offline sobre o texto cifrado, sem acesso à chave do cofre. Isso é útil quando alguém precisa estabelecer se um registro mudou depois de um evento, mas não substitui a leitura do resultado por um operador enquanto os fatos ainda estão recentes.

Use a revisão para melhorar o próximo contrato. Se toda execução pausa porque uma busca de metadados inofensiva foi omitida, inclua essa busca na próxima vez. Se uma tarefa recorrente pede aprovação por chamada para um endpoint somente de leitura, mova essa credencial para a classe de sessão comum. Se os revisores encontrarem gravações inesperadas repetidamente, reduza as instruções do agente e os escopos das credenciais antes de executá-lo novamente.

## Evidências de adulteração ajudam depois de uma contestação, não antes dela

Um registro resistente a adulterações dá à equipe uma forma de verificar se o histórico ainda mantém continuidade. Ele não decide se uma ação foi autorizada, sensata ou segura. Tratar as evidências de auditoria como um controle preventivo leva as equipes a aprovar execuções amplas porque acreditam que poderão resolver tudo depois.

A diferença importa em um incidente real. Imagine que uma sessão de agente contate a API de implantação esperada e depois faça uma exclusão contra um recurso inesperado. Um log encadeado pode ajudar a estabelecer que a solicitação de exclusão apareceu na sequência registrada. Ele não restaura o recurso excluído, não explica por que o processo recebeu autoridade ampla nem prova que o operador pretendia incluir aquele recurso no escopo.

Use a verificação de auditoria quando precisar preservar o registro antes de escalar um incidente, transferir uma investigação ou revisar uma execução suspeita. Execute o verificador sobre o material de log retido, registre se ele foi bem-sucedido e mantenha esse resultado de verificação junto às notas do incidente. Não edite nem «limpe» manualmente as entradas de atividade para facilitar a leitura de um relatório. As notas explicativas devem ficar ao lado do registro, não dentro dele.

A cadeia também muda a forma como as equipes devem lidar com o acesso aos logs. Às vezes as pessoas presumem que a criptografia torna um registro inútil sem descriptografia imediata. Um verificador que consiga conferir a continuidade da cadeia sobre o texto cifrado permite que um investigador estabeleça um fato limitado, mas importante, sem abrir o cofre: se o registro criptografado retido ainda se encaixa na sequência. Mantenha essa distinção clara. A verificação confere a continuidade da integridade; a descriptografia revela o conteúdo; nenhuma das duas concede direito de executar outra ação.

Uma equipe que planeja janelas de desbloqueio, identifica processos de agentes, usa barreiras por chamada para autoridades importantes e revisa os resultados rapidamente precisará de evidências de auditoria com menos frequência. Quando precisar do registro, também terá o contrato de execução e as notas de pausa necessários para interpretá-lo. Um log sem contexto de aprovação informa o que aconteceu. Um log acompanhado de um plano de trabalho disciplinado informa se a equipe permitiu aquilo por um motivo.

A primeira mudança é pequena: exija uma condição de parada escrita antes que alguém desbloqueie credenciais locais para um agente. Essa única linha obriga a equipe a decidir o que o agente deve fazer quando a tarefa deixar de seguir o plano. Ela também elimina a desculpa habitual para exportar um segredo quando o trabalho se torna inconveniente.