Aprovação por sessão versus por chamada para ações de agentes

Um agente de IA não precisa de acesso irrestrito para ser útil. Ele precisa de autoridade suficiente para o trabalho atual, durante um período que você consiga explicar, com uma decisão humana colocada no ponto em que outra chamada mudaria o risco. Essa é a diferença prática entre aprovação por sessão e aprovação por chamada.

Já vi equipes cometerem dois erros opostos. Uma aprova toda consulta inofensiva e ensina as pessoas a clicar nos avisos sem lê-los. A outra concede uma sessão longa a um agente de programação e depois se surpreende quando um loop cria cinquenta tickets, dispara várias implantações ou exporta muito mais dados do que alguém pretendia. Nenhuma dessas falhas depende de uma exploração sofisticada. Ambas surgem quando o limite de aprovação é colocado no lugar errado.

A expressão-chave aprovação por sessão versus por chamada descreve uma escolha que precisa de três informações: por quanto tempo o trabalho será executado, quanta autoridade a credencial possui e o que uma solicitação válida repetida pode fazer. O verbo HTTP, o plano declarado pelo agente e o fato de um desenvolvedor estar observando são sinais mais fracos que esses três fatores.

Aprovação é uma permissão para agir dentro de um limite definido

A aprovação por sessão concede a um processo de agente identificado autoridade para usar uma credencial durante toda aquela execução. A aprovação por chamada exige uma decisão sempre que a credencial é usada. Elas respondem a perguntas diferentes, e tratá-las como equivalentes cria confiança cega ou atrito inútil.

Uma decisão de sessão diz: «Eu reconheço este processo, aceito esta execução limitada e considero seguras o bastante para serem repetidas durante ela as ações disponíveis por meio desta credencial.» Essa é uma decisão razoável para um agente que consulta alguns registros de issues enquanto investiga um bug. É uma decisão ruim para um agente que pode fazer alterações em produção sempre que seu próprio raciocínio concluir que outra mutação seria útil.

Uma decisão por chamada diz: «Aceito este uso exato desta credencial agora.» Ela é mais lenta por definição. O aviso deve representar um ponto em que uma pessoa consiga reconhecer a consequência e recusá-la sem perder a tarefa inteira. Se o aviso não transmitir uma escolha significativa, o desenho da aprovação está errado. Se ele aparecer antes de uma ação irreversível, esse segundo extra geralmente custa pouco.

Não confunda isso com autenticação. A autenticação informa ao sistema local quem pode desbloquear o armazenamento de credenciais. A autorização responde se uma execução de agente pode usar uma credencial específica. O controle por chamada acrescenta uma terceira pergunta: se esse uso, neste momento, merece uma nova decisão humana.

Essa distinção importa durante uma tarefa comum de programação. Um agente pode usar um token de API para ler o status da compilação e outro para disparar uma versão. O mesmo processo pode ser confiável o bastante para consultar o primeiro e ainda precisar de uma decisão explícita para o segundo. A identidade do processo não nivela o risco de todos os endpoints aos quais ele consegue chegar.

Um limite de aprovação útil tem quatro propriedades:

• Uma pessoa consegue dizer que trabalho o agente está realizando.
• O escopo da credencial corresponde a esse trabalho, e não a toda a lista possível de tarefas do agente.
• A aprovação termina quando o trabalho ou o processo identificado termina.
• A pessoa consegue descrever o pior resultado plausível se o agente repetir uma ação permitida.

A quarta propriedade revela mais projetos ruins que a maioria dos checklists. Se a resposta for «ele faria outra solicitação inofensiva», a aprovação por sessão pode ser adequada. Se a resposta incluir dinheiro, comunicação com clientes, estado de produção, exclusão, alterações de acesso ou uma grande exportação, mantenha uma decisão humana próxima de cada ação.

A duração da tarefa muda o significado de uma autorização de sessão

Uma sessão é mais segura quando é curta, limitada a uma única tarefa e vinculada a um processo que termina quando o trabalho acaba. Uma sessão que continua silenciosamente durante tarefas sem relação é uma permissão permanente com um nome mais simpático.

A duração afeta o risco porque um agente não para de raciocinar depois de concluir sua primeira ação planejada. Ele pode tentar novamente, seguir uma subtarefa recém-descoberta, consultar outro repositório ou obedecer a uma instrução ruim encontrada em um arquivo ou ticket. Quanto mais tempo o processo vive, menos útil se torna seu modelo mental original. Uma execução de dez minutos para analisar testes com falha tem um propósito compreensível. Um processo que roda a tarde inteira acumulou contexto, mudou de objetivo e teve mais oportunidades de encontrar entradas hostis ou enganosas.

Sempre que possível, use o limite da tarefa em vez do relógio. O encerramento do processo é uma condição final honesta: o agente aprovado deixou de existir. Um tempo limite fixo é um recurso secundário, não um controle equivalente. Aos quinze minutos, um agente pode ainda estar realizando o trabalho original ou outra ferramenta pode ter herdado a mesma autoridade. O tempo, sozinho, não informa qual das duas coisas aconteceu.

Para uma sessão limitada, escreva a unidade de trabalho antes de aprová-la. Uma boa descrição é concreta: «analise a execução de integração contínua com falha e abra um comentário de rascunho com as conclusões». Uma descrição ruim é «ajude com a versão». Uma linguagem ampla dá ao agente espaço para transformar uma pequena tarefa de diagnóstico em trabalho de lançamento.

Considere estes formatos de tarefa:

O atalho mais comum é aprovar uma sessão para toda tarefa porque as pessoas detestam interrupções. A reclamação é legítima quando os avisos aparecem em chamadas de baixo impacto. A solução é reduzir os avisos restringindo as credenciais e agrupando o trabalho rotineiro em sessões reais, não transformar uma execução longa do agente em uma janela de acesso total.

Reinicializações do agente merecem a mesma cautela. Para quem iniciou o comando, uma reinicialização pode parecer uma continuidade, mas trata-se de um novo processo que pode carregar instruções, código ou plugins diferentes. Peça uma nova autorização de sessão depois de uma reinicialização. Isso não é burocracia. A decisão original estava ligada a uma autoridade executável e a uma execução específicas, não à intenção vaga do desenvolvedor para aquela tarde.

A sensibilidade da credencial começa pela capacidade, não pelo tipo de segredo

Uma credencial é sensível pelo que pode causar, revelar ou delegar, e não por ter determinado nome. Uma chave de API usada apenas para ler um artefato público de compilação pode ser menos perigosa que um token que dá acesso administrativo a um workspace privado. Uma chave SSH que alcança um host de implantação tem um modo de falha diferente do token que chama uma API de cobrança, mas ambas podem precisar de controle por chamada.

Classifique cada credencial de acordo com as permissões reais do sistema remoto. Não aceite um rótulo como «token de leitura» sem verificar o que a API considera uma leitura. Alguns serviços expõem endpoints de exportação como leituras. Outros permitem que um endpoint supostamente somente de leitura inicie a geração de relatórios, consuma capacidade escassa ou retorne dados que o agente nunca deveria ver em massa.

Antes de escolher um nível de aprovação, faço quatro perguntas:

1. Esta credencial pode alterar o estado fora da máquina local?
2. Ela pode revelar informações que não podem ser colocadas com segurança no contexto ou na saída do agente?
3. Ela pode conceder mais acesso, diretamente ou por meio de um fluxo que consiga disparar?
4. Um chamador pode gastar dinheiro, consumir uma cota ou criar um compromisso contratual ou de reputação?

Responder sim a qualquer pergunta não exige sempre aprovação por chamada. Significa que a aprovação por sessão precisa de uma tarefa mais restrita, um escopo mais preciso e uma reversão plausível. Se várias respostas forem sim, pedir aprovação a cada uso costuma ser a escolha mais honesta.

Use o escopo como primeira redução e a aprovação como segunda. Um token que pode ler apenas um repositório oferece uma decisão de sessão muito melhor que um token que lê todos os repositórios da organização. Uma credencial limitada a um ambiente de staging é mais segura para uma sessão que uma credencial capaz de operar em produção. A aprovação humana não consegue corrigir um token absurdamente amplo depois que o agente já recebeu autoridade para fazer solicitações caras.

SSH merece tratamento especial porque as pessoas costumam chamá-lo de «apenas acesso ao shell». O acesso ao shell é um meio de entrada em uma superfície de ações ampla e mutável. O risco real depende da conta, do host, da conectividade de rede, dos comandos disponíveis, dos hooks de implantação e dos arquivos que a conta pode ler. Uma conta restrita capaz de executar um único comando de diagnóstico pode ser adequada para uma sessão. Uma conta de implantação, um host com dados de clientes ou uma conta que pode alterar controles de acesso deve ficar atrás de aprovação por chamada até que você consiga restringi-la.

Não deixe que a rotação de credenciais esconda essa análise. Uma chave recém-criada com amplos direitos de produção continua tendo amplos direitos de produção. Trocá-la depois de uma execução ruim limita abusos futuros, mas não desfaz as chamadas remotas que já tiveram sucesso.

A repetição transforma uma ação tolerável em uma ação cara

Uma solicitação pode ser aceitável individualmente e ainda assim se tornar insegura quando um agente a repete. Classifique a ação repetida, não apenas a primeira ação mostrada no aviso.

É aqui que as equipes dão peso demais aos nomes dos métodos HTTP. A RFC 9110 diz que os métodos seguros devem ser somente de leitura: GET, HEAD, OPTIONS e TRACE. Ela também alerta que um cliente não pode ser responsabilizado quando um servidor expõe um comportamento inseguro por meio de um método seguro, pois o proprietário do recurso escolhe esse comportamento. Essa redação importa. Um endpoint GET pode ter como intenção semântica recuperar informações, mas a aplicação pode torná-lo caro, expor uma grande exportação, atualizar um campo de auditoria ou disparar trabalho posterior. Os nomes dos métodos ajudam a iniciar uma investigação. Eles não a encerram.

Idempotência é outro termo que as pessoas usam mal. Uma solicitação é idempotente quando repeti-la tem o mesmo efeito pretendido sobre o estado do servidor que fazê-la uma vez. Isso não significa que repeti-la seja inofensivo. Uma solicitação PUT que define uma flag como true pode ser idempotente e ainda assim ativar um recurso de produção. Um DELETE pode ser idempotente depois da primeira exclusão e mesmo assim remover algo importante. Um GET pode ser seguro no sentido do protocolo e ainda esgotar um limite de taxa quando um agente entra em loop.

Teste o comportamento de repetição de um endpoint em uma conta descartável ou em um ambiente de staging. Envie a mesma solicitação duas vezes, examine o estado remoto e os efeitos colaterais e depois pergunte o que aconteceria se o agente a enviasse cem vezes. Não pare no corpo da resposta. Verifique mensagens enviadas, tarefas enfileiradas, registros de auditoria criados, cota consumida, webhooks disparados e dados copiados para outros lugares.

Para um endpoint que cria objetos, use uma chave de idempotência se o serviço oferecer suporte a ela. Este formato impede que uma nova tentativa de rede crie um segundo pagamento, ticket ou solicitação de provisionamento quando a primeira resposta se perde:

POST /v1/provisioning-requests HTTP/1.1
Authorization: Bearer injected-by-gateway
Idempotency-Key: agent-run-8b2f1-request-17
Content-Type: application/json

{"environment":"staging","version":"2025.04.18"}

Um serviço deve retornar o resultado original quando recebe novamente a mesma chave de idempotência. A resposta costuma ter o mesmo identificador de objeto e um status de sucesso, em vez de criar um objeto novo. Confirme esse comportamento na documentação do serviço e teste-o por conta própria. Uma chave de idempotência reduz a criação duplicada causada por novas tentativas, mas não torna apropriada uma implantação inadequada nem impede que um agente gere uma nova chave a cada tentativa equivocada.

A aprovação por chamada é adequada para ações com qualquer um destes perfis de repetição:

• Cada chamada cria algo novo, como uma fatura, conta, ticket, mensagem ou pedido.
• Cada chamada altera o estado ativo e é difícil reconstruir o estado anterior.
• Cada chamada pode revelar outra página, outro arquivo ou dados de outro cliente.
• Cada chamada pode criar um efeito público ou voltado ao cliente.
• Cada chamada pode disparar trabalho que custa dinheiro ou ocupa capacidade limitada.

Uma sessão é adequada para chamadas repetidas quando o sistema remoto trata as repetições como de baixo impacto, o escopo da credencial é pequeno e a tarefa tem uma saída clara. Cabe à equipe comprovar essa afirmação. «O agente provavelmente não entrará em loop» não é uma propriedade do endpoint.

Um rótulo de somente leitura não resolve o risco

O acesso de leitura pode criar riscos de privacidade, operacionais e de injeção de prompt mesmo quando não consegue alterar um registro remoto. Trate a exposição de dados como uma ação com consequências, especialmente quando o agente pode resumir, copiar ou usar o que recuperou para decidir seu próximo passo.

Suponha que um agente tenha permissão para pesquisar um sistema de suporte. Uma sessão pode ser razoável para uma tarefa limitada a um ticket e seus anexos. A mesma credencial se torna muito mais difícil de aprovar para uma execução que possa enumerar todos os tickets, recuperar exportações ou trazer conversas privadas de clientes para um contexto local. O endpoint pode usar GET o tempo todo. O limite de dados, não o verbo, define o risco.

A pergunta desconfortável é se o próprio agente tem permissão para ver o resultado retornado. Um gateway de credenciais que mantém os tokens fora do agente não torna automaticamente seguro todo resultado retornado. Segredos costumam vazar nas respostas: endpoints de configuração retornam strings de conexão, registros de usuários incluem dados pessoais, a saída de comandos inclui variáveis de ambiente e respostas de erro expõem caminhos ou identificadores internos.

Escolha aprovação por chamada para uma leitura quando um único resultado puder revelar uma classe sensível de informação ou quando a solicitação do agente puder ampliar seu próprio espaço de busca. Isso inclui pesquisas amplas, exportações, recuperação de segredos, enumeração de contas e comandos como cat sobre diretórios cujo conteúdo varia. Uma pessoa precisa ter a chance de ver o alvo antes de liberar esses dados para a execução.

Para leituras rotineiras, restrinja o formato da solicitação. Prefira uma credencial limitada a um projeto, repositório, ambiente ou grupo de recursos de uma API. Defina limites de página no servidor quando o serviço oferecer esse recurso. Sempre que possível, dê ao agente um mecanismo de consulta que aceite identificadores explícitos, em vez de um endpoint de pesquisa irrestrito. Essas escolhas reduzem a quantidade de avisos porque a própria chamada permitida é menor.

Um padrão de falha aparece na resposta a incidentes. Um agente começa com uma solicitação inofensiva para examinar logs, encontra um token em uma linha de log e depois pesquisa todas as ocorrências desse token em um arquivo amplo. Na mente de uma pessoa, a aprovação da sessão cobria a solução do problema, mas o escopo da credencial e o formato da consulta permitiram a coleta. O operador não vê nenhuma mutação na lista de atividades e presume que a execução foi segura. O ato sensível foi a recuperação dos dados.

Mantenha um registro separado do que foi solicitado, de qual credencial foi usada e de se a chamada foi aprovada como ação de sessão ou como ação por chamada. Esse registro ajuda o investigador a distinguir um agente comprometido de uma escolha ruim de aprovação. Ele também revela quais credenciais precisam de menos escopo. Registrar apenas mutações bem-sucedidas deixa as falhas mais difíceis de recuperação invisíveis.

Faça os avisos corresponderem a decisões que uma pessoa realmente possa tomar

A fadiga de aprovação é uma falha de projeto quando os avisos chegam com frequência demais para serem lidos ou são vagos demais para serem avaliados. A aprovação por chamada só funciona quando cada aviso informa o suficiente para que o revisor aceite ou rejeite uma consequência concreta.

Um aviso útil identifica o processo chamador, a credencial ou categoria de ação, o destino e o efeito relevante. «Permitir solicitação de API» não permite que ninguém tome uma boa decisão. «O processo de agente assinado solicita uma implantação em produção usando a credencial de lançamento» permite. Para uma leitura sensível, o aviso deve nomear o conjunto de dados ou o alvo, e não dizer apenas «solicitação GET». Para SSH, mostre o host e o comando ou uma classe de comandos significativa.

Não resolva o excesso de avisos escondendo o destino. Um desenvolvedor que aprova uma solicitação com base em um nome amigável de tarefa não consegue detectar um erro de digitação, uma instrução maliciosa ou uma mudança de rumo do agente. O aviso precisa ser específico o bastante para revelar uma divergência entre o trabalho pretendido e a ação real.

Ao mesmo tempo, não exija que as pessoas analisem um corpo HTTP bruto para cada solicitação rotineira. Isso produz aprovações cerimoniais. Coloque chamadas repetidas e de baixo impacto dentro de uma sessão limitada e reserve os avisos por chamada para as operações que atravessam uma fronteira real de decisão. A pessoa deve ver menos avisos, mas cada aviso restante deve importar.

Use uma nota curta de aprovação ao lado de cada configuração de credencial. Ela não é uma linguagem de políticas nem precisa se transformar em uma. Uma frase como «somente sessão para leituras do status de compilação de um repositório; aprovar cada lançamento em produção» torna as revisões posteriores concretas. Se a equipe não consegue escrever uma frase que separe o trabalho comum de uma ação consequente, a credencial provavelmente é ampla demais.

A identidade do processo mostrada durante a autorização da sessão também merece atenção. As pessoas devem aprovar a autoridade executável, não apenas uma linha de comando que pode ser copiada ou alterada. Um processo pai assinado e um auxiliar não assinado são decisões de confiança diferentes. A resposta correta a uma autoridade desconhecida é interromper a execução, descobrir por que ela mudou e aprová-la apenas se a mudança for esperada. Clicar porque a tarefa é urgente ensina a organização a aceitar um caminho de personificação.

Use uma matriz de decisão antes de alterar a configuração de aprovação

Uma matriz pequena evita discussões baseadas na tolerância pessoal aos avisos. Avalie a ação de acordo com sua consequência e escolha o nível mais rigoroso sempre que a pontuação apontar em duas direções.

Quando a tabela der respostas mistas, separe o fluxo em vez de escolher um meio-termo. Dê ao agente uma credencial aprovada por sessão para diagnósticos e uma credencial aprovada por chamada para remediação. Essa organização costuma ser mais natural que aprovar leituras repetidamente ou conceder uma sessão ampla para evitar aprovações de mutações.

Veja um exemplo. Um agente investiga uma implantação com falha. Ele precisa ler logs de compilação, consultar o status de um ambiente de staging específico e talvez reiniciar um serviço.

Os logs e as consultas de status podem usar aprovação por sessão se o token alcançar apenas aquele projeto e o processo terminar depois do diagnóstico. O reinício deve usar outra credencial com aprovação por chamada porque altera o estado em execução. Mesmo que reiniciar o serviço geralmente seja seguro, reinícios repetidos podem interromper trabalho ativo, esconder a causa raiz e disparar loops de recuperação automática. O fato de o agente ter descoberto o reinício como uma correção razoável não o torna rotineiro.

Agora altere um detalhe: a API de status pode consultar todos os ambientes de produção e a recuperação de logs pode buscar dados de clientes sem mascaramento. A aprovação por sessão já não é adequada para a credencial de diagnóstico. A equipe deve restringir esse acesso primeiro. Colocar a mesma credencial ampla atrás de aprovação por chamada limita um tipo de falha, mas um revisor não consegue avaliar de forma confiável cada solicitação de recuperação se o seletor de dados continuar sem restrições.

É por isso que uma única configuração por agente é um modelo ruim. A aprovação pertence ao canal de ação e ao escopo da credencial. Uma execução de agente pode combinar com segurança os dois níveis se os limites forem definidos de propósito.

Trilhas de auditoria explicam uma decisão ruim, mas não podem revertê-la

Um registro resistente a adulterações permite investigar uma execução do agente, revogar uma sessão ativa e descobrir se o agente repetiu uma ação. Ele não impede que um serviço remoto aceite uma chamada que você já aprovou.

Mantenha duas visões da atividade. Um registro de sessão responde quem executou, quando a execução começou, que autoridade de processo possuía e se alguém a revogou. Um registro de chamada responde qual caminho de credencial o agente usou, qual destino contatou e se a chamada tinha autorização de sessão ou uma aprovação nova. As equipes precisam dos dois. Uma lista de sessões não prova qual ação causou um problema, enquanto um conjunto de chamadas sem contexto do processo não explica quem as iniciou.

Faça a integridade da auditoria ser testável, em vez de tratá-la como um slogan. Um log encadeado por hash deve falhar na verificação se alguém alterar, remover ou reordenar registros na sequência armazenada. O teste é simples: verifique uma cópia conhecida como íntegra, altere um byte em uma cópia e verifique novamente. O verificador deve informar que a cadeia não é mais válida, enquanto o original continua válido. Faça isso em um dispositivo de teste, nunca editando seu armazenamento de auditoria de produção.

Os projetos Sallyport geram seus diários Sessions e Activity a partir de um log de auditoria criptografado, encadeado por hash e protegido contra gravação, e sp audit verify verifica essa cadeia offline sobre o texto cifrado sem precisar de uma chave do cofre. Essa separação é útil quando a pessoa que verifica os registros não deve receber as credenciais ou os dados das ações protegidos pelo cofre.

Os logs também revelam um erro comum de aprovação: tratar uma sessão como desculpa para parar de observar. Revise execuções que fizeram um número incomum de chamadas, contataram um novo destino, duraram muito mais que a descrição da tarefa ou usaram uma credencial fora de sua categoria habitual. Você não precisa de um mecanismo de regras para identificar esses padrões. Uma revisão humana semanal de uma pequena amostra detectará a ampliação de escopo antes que ela se torne um hábito operacional normal.

Quando um agente agir mal, preserve a identidade do processo, a entrada da tarefa, o registro da sessão, a sequência de chamadas e os logs do serviço remoto antes de alterar a configuração. Depois, faça uma pergunta mais específica que «o agente foi comprometido?». A ação era permitida pelo escopo da credencial? O nível de aprovação correspondia ao risco da repetição? O aviso fornecia informações suficientes para recusá-la? O processo mudou depois da autorização? Essas respostas levam a correções. Uma proibição genérica de autonomia não leva.

Um começo restrito é melhor que uma exceção ampla

Comece com um fluxo cujo impacto você consiga descrever sem evasivas e atribua aprovação por chamada à credencial que pode causar mais danos. Observe várias execuções reais antes de mover a parte rotineira para uma sessão limitada.

Em uma configuração de agente baseada em Mac, o Sallyport mantém credenciais de API e SSH em seu cofre criptografado e executa a ação em vez de passar o segredo ao agente. Isso reduz a exposição da credencial, mas você ainda precisa escolher o limite de aprovação com o mesmo cuidado, porque a ação remota continua sendo real.

A primeira configuração deve deixar o desenvolvedor levemente impaciente, não desprotegido. Se cada execução produzir uma pilha de avisos para leituras de status de compilação, o escopo ou o agrupamento de tarefas precisa ser melhorado. Se um agente puder alterar a produção durante uma hora depois de uma única aprovação, a sessão é ampla demais. Ajuste a credencial e o limite da tarefa antes de retirar a pessoa do circuito.

Escreva a próxima escolha de aprovação em termos operacionais: este processo assinado, para esta tarefa, pode fazer estas chamadas de baixo impacto até terminar; esta outra credencial exige uma nova decisão porque cada uso pode alterar algo que não conseguimos desfazer casualmente. Essa frase dá aos revisores um padrão que podem aplicar sob pressão. Qualquer formulação mais vaga acabará se transformando em uma exceção permanente.