A vinculação da solicitação de aprovação impede mudanças depois do clique

Uma aprovação humana só tem valor se autorizar uma ação que não possa mudar depois. Exibir a requisição HTTP ou o comando SSH proposto por um agente e permitir que esse mesmo agente envie os detalhes finais mais tarde abre uma brecha entre a verificação e o uso, larga o bastante para deixar passar uma requisição destrutiva.

Já vi esse erro chegar com uma aparência tranquilizadora: uma tela de aprovação elegante, um selo com a identidade do processo, um estado verde de confirmação. Depois, a implementação envia um token de aprovação mantido pelo cliente de volta pelo protocolo e aceita uma nova URL ou comando ao lado dele. A pessoa aprovou uma coisa. O executor fez outra. Isso é um projeto de autorização falho, mesmo quando ninguém pretendia contorná-lo.

Uma prévia precisa descrever um objeto de autorização imutável

A tela de aprovação deve renderizar um objeto de ação armazenado, e o executor deve enviar esse mesmo objeto depois da aprovação. A tela é uma visão do estado oficial, não um pedido para que o cliente repita a proposta com mais cuidado.

Crie o objeto antes de exibir qualquer aprovação. Dê a ele um identificador de ação aleatório, associe-o ao processo e à sessão que fizeram a solicitação, resolva as entradas específicas do canal e mantenha-o na memória ou em armazenamento local criptografado sob o controle do executor. O cliente pode receber um status pendente e um identificador. Ele não deve receber uma capacidade que permita anexar novos parâmetros de execução mais tarde.

Um modelo mental útil é o de um pedido de restaurante, não o de uma autorização em branco. A cozinha não pede ao cliente que descreva o jantar novamente depois que o garçom marca o pedido como aprovado. Ela prepara o pedido que tem em mãos. Se o pedido mudar, a cozinha recebe um novo pedido e o cliente vê a mudança.

O objeto imutável deve incluir mais do que os campos visíveis em uma prévia compacta. Ele também precisa da identidade do processo, do identificador da sessão, do horário de criação, do horário de expiração, do canal, da referência da credencial, dos detalhes normalizados da ação e de um digest de vinculação. O digest permite detectar mutações acidentais e substituições deliberadas, mas é a posse do objeto pelo executor que realiza o trabalho de segurança.

Uma resposta de aprovação deve significar somente isto: «aprovar a ação 7c91... com o digest de vinculação sha256:...». Ela não deve significar «este processo pode fazer uma chamada HTTP» ou «o chamador pode executar o comando X mais tarde». Essas declarações mais amplas têm seu lugar na autorização da sessão, mas não substituem o consentimento para um efeito colateral específico.

Essa distinção é mais importante com agentes autônomos porque o cliente não é um funcionário confiável que transcreve fielmente uma decisão humana. É um programa ativo que pode repetir operações, compor chamadas seguintes, alterar o plano depois do resultado de uma ferramenta ou simplesmente conter um bug. Considere suspeito todo campo que ele ainda possa influenciar depois da prévia.

Uma prévia HTTP precisa nomear todas as entradas efetivas

Uma aprovação HTTP vincula o método, o destino completo, os cabeçalhos efetivos, o corpo e o comportamento de envio que podem alterar o significado da requisição. Uma prévia que diga «POST para o serviço de cobrança» dá informação insuficiente para que alguém aprove uma chamada que altera estado.

A RFC 9110 separa o método, o destino, os campos e o conteúdo da requisição porque os servidores podem atribuir significados diferentes a cada um deles. O código de autorização deve manter essa separação. Não monte uma frase agradável para a tela de aprovação e deixe uma camada inferior preencher as partes incômodas.

Para uma requisição de saída, capture estes valores depois de resolver templates e padrões:

• Esquema, nome do host, porta, caminho e string de consulta.
• Método HTTP e indicação de que a requisição pode ou não seguir redirecionamentos.
• Cada nome e valor de cabeçalho efetivo, exceto o material secreto que o cofre injeta.
• Os bytes finais do corpo, seu tipo de conteúdo, comprimento e digest.
• A referência da credencial e o modo de injeção, como bearer ou cabeçalho personalizado.

O valor da credencial não pertence à prévia nem ao contexto do agente. A pessoa ainda precisa de informação suficiente para avaliar seu uso. «Credencial de pagamentos de produção enviada somente para api.example.test como token bearer» conta uma história diferente de «credencial anexada». O executor pode renderizar essa descrição a partir de um registro do cofre sem expor o token.

Não aprove um template não expandido. Suponha que o agente proponha POST /users/{id}/role com um corpo que contenha {role}. Se outro componente expandir essas variáveis depois da aprovação, ele poderá mudar o destino efetivo ou o privilégio. Resolva as variáveis primeiro e então crie o objeto de ação. Quando uma entrada estiver intencionalmente indisponível até mais tarde, peça aprovação no momento em que ela se tornar concreta.

Os cabeçalhos exigem mais cuidado do que a maioria das equipes dedica a eles. Um cabeçalho duplicado, um Content-Type alterado, um cabeçalho de substituição adicionado ou uma codificação de consulta diferente podem mudar o comportamento do servidor enquanto o resumo amigável permanece idêntico. Preserve os campos repetidos na ordem original quando o protocolo ou o servidor de destino der importância à ordem. Recuse entradas ambíguas em vez de juntá-las silenciosamente com vírgulas.

Uma estrutura interna de dados razoável poderia ser assim. Este é um padrão de implementação, não um contrato de endpoint:

{
  "action_id": "7c91e2d4",
  "binding": "sha256:4f06...",
  "caller": {"session": "p-481", "process_start": "..."},
  "http": {
    "method": "PATCH",
    "url": "https://api.example.test/v1/users/42",
    "headers": [["content-type", "application/json"]],
    "body_sha256": "a4d8...",
    "body_length": 31,
    "redirects": "deny"
  },
  "credential_ref": "vault:payments-prod"
}

Depois que a pessoa aprovar esse objeto, a camada de transporte lê http e credential_ref de seu próprio registro armazenado. Ela não aceita uma segunda URL, um novo mapa de cabeçalhos ou outro corpo enviado pelo cliente. Essa última regra impede o bug; o digest apenas prova a qual registro a aprovação se referia.

Os comandos SSH precisam do contexto de execução resolvido

Uma prévia de comando SSH deve vincular o contexto de execução remoto, porque uma string de comando sozinha não informa à pessoa o que será executado. O mesmo texto pode ter efeitos diferentes sob outro usuário, host, shell, diretório de trabalho, ambiente ou fluxo de stdin.

A RFC 4254 define uma solicitação de protocolo de conexão SSH para execução de comandos, mas não cria uma fronteira de aprovação legível por humanos. O SSH transporta uma string de comando até o servidor. A interpretação pelo shell remoto, a configuração da conta, os comandos forçados e os wrappers de comando podem acrescentar significados que uma prévia básica omite.

Armazene e apresente o nome do host, a porta, o usuário remoto, a expectativa de autenticação do host, a referência da identidade, os bytes exatos do comando, o modo de execução, a alocação do terminal, o diretório de trabalho, o ambiente fornecido e o digest e comprimento do stdin. Para uma operação de arquivo feita por meio de um auxiliar SSH, vincule também o caminho remoto, o tipo de operação, o digest do arquivo e qualquer comportamento de sobrescrita.

O modo de execução não é um detalhe cosmético. Estes comandos não são equivalentes:

/usr/local/bin/deploy --environment=staging
sh -lc '/usr/local/bin/deploy --environment=staging'

O primeiro solicita execução direta, se o auxiliar oferecer esse recurso. O segundo solicita explicitamente que um shell interprete a string. A interpretação pelo shell introduz expansão, substituição de comandos, comportamento de inicialização do shell e regras de aspas. Se o produto aceitar os dois modos, identifique-os claramente e nunca converta um no outro depois da aprovação.

Não crie uma prévia a partir de um comando formatado para exibição e execute um vetor montado separadamente. Uma string exibida pode esconder um argumento vazio, uma quebra de linha, um caractere não imprimível ou uma diferença entre --file=/tmp/a b e dois argumentos. Renderize uma representação com escape seguro a partir da sequência exata de bytes ou do vetor de argumentos que o auxiliar usará. Se o comando contiver bytes que não possam ser exibidos com segurança, recuse-o ou mostre uma representação explicitamente codificada que o usuário possa inspecionar.

Mudanças no destino remoto exigem a mesma disciplina que os redirecionamentos HTTP. Um alias da configuração SSH local, um proxy jump ou uma consulta à configuração do host pode transformar um nome curto em um destino diferente. Resolva o plano final de conexão antes da aprovação e vincule-o. Em sistemas onde o rebinding de DNS faz parte do modelo de ameaça, acrescente com cuidado uma política separada para endereços de host. Fixar um endereço pode interromper um failover normal, enquanto ignorar um resolvedor hostil pode enviar um nome válido para a máquina errada. Não finja que uma prévia de comando resolve esse problema separado.

O intervalo vulnerável começa depois do clique da pessoa

A falha ocorre quando a interface verifica os detalhes propostos, registra um sim e um caminho de execução posterior lê detalhes mutáveis do cliente. Ela costuma ficar escondida atrás de um código assíncrono comum.

Considere um processo de agente que pede a um gateway para transferir fundos:

1. O cliente envia POST https://api.example.test/transfers com um corpo para 50 unidades.
2. O gateway cria uma prévia e espera a aprovação de uma pessoa.
3. A pessoa aprova depois de ler o destino e o valor.
4. O cliente envia execute com o identificador de aprovação e um novo corpo para 5.000 unidades.
5. O gateway verifica apenas se o identificador de aprovação é válido, injeta a credencial e envia o novo corpo.

Nada nessa sequência exige uma interface comprometida ou uma credencial roubada. O cliente usou uma API oferecida pelo gateway. Um teste que aprova a requisição original e verifica apenas se o identificador funciona passará. Um teste que compare os bytes finais enviados com os bytes representados pelo objeto aprovado falhará, exatamente como deve acontecer.

A mesma falha aparece quando um gateway armazena por referência um objeto de requisição mutável. Um worker de prévia o lê, um handler de repetição no agente o edita e o worker de envio depois transmite a versão editada. Copiar o objeto não resolve tudo se mapas aninhados, buffers de corpo ou callbacks continuarem compartilhados. Crie um valor imutável sem referências pertencentes ao cliente ou serialize-o em uma representação oficial e reconstrua-o apenas a partir dessa representação.

A expiração não corrige o estado mutável. Uma aprovação que dure trinta segundos ainda pode autorizar uma requisição alterada enviada no primeiro segundo. Os limites de taxa também não corrigem o problema. Eles reduzem a frequência com que o cliente pode explorar um erro, mas não determinam se a pessoa aprovou o efeito.

Mantenha a máquina de estados pequena o bastante para ser auditada:

proposed -\u003e frozen -\u003e awaiting_human -\u003e approved -\u003e dispatched
                         |                 |
                         v                 v
                      rejected           expired

Somente a transição de approved para dispatched pode realizar a ação externa. Essa transição precisa carregar o registro congelado pelo identificador da ação, verificar novamente o chamador e a expiração e entregar o registro diretamente ao executor HTTP ou SSH. Qualquer pedido para mudar os detalhes volta a proposed e cria um novo identificador.

Vincule os bytes quando o significado puder variar

Uma vinculação precisa de uma representação estável, ou dois componentes podem acreditar que aprovaram a mesma requisição enquanto constroem dados diferentes para a rede. A parte difícil é decidir qual representação terá autoridade.

Para requisições JSON simples, normalize uma estrutura seguindo regras documentadas, serialize-a uma vez e mantenha os bytes finais do corpo e seu digest. A prévia pode mostrar JSON legível enquanto o caminho de envio transmite os bytes armazenados. Nunca analise, formate e serialize novamente depois da aprovação, a menos que essa saída transformada seja o objeto aprovado.

Para formulários, uploads multipart, cabeçalhos repetidos ou entradas binárias arbitrárias, os bytes costumam ser uma fronteira mais segura. Vincule os bytes exatos, o tipo de conteúdo e as decisões de enquadramento da transmissão que afetam a interpretação do servidor. Um digest permite que a interface identifique um corpo grande sem despejar um documento privado em uma tela de aprovação, mas o executor precisa manter ou regenerar esses bytes exatos a partir de um estado confiável.

A canonicalização de URLs é outra armadilha. Normalizar maiúsculas e minúsculas do nome de um host geralmente não causa problemas. Decodificar e recodificar um caminho, ordenar pares da query, remover um valor vazio ou tratar + e %20 como idênticos pode mudar a forma como um aplicativo encaminha ou valida uma requisição. Escolha uma forma canônica definida de maneira restrita, documente-a e recuse entradas que tenham mais de uma interpretação plausível. «Normalizamos URLs» não é uma propriedade de segurança.

Para SSH, um vetor de argumentos é melhor do que uma string de shell quando o auxiliar de protocolo consegue executá-lo sem chamar um shell. Vincule cada argumento como uma sequência distinta de bytes. Quando o lado remoto necessariamente receber uma única string de comando shell, vincule essa string exatamente e apresente seus escapes com fidelidade. Não afirme que um analisador na máquina local pode provar o que um arquivo arbitrário de inicialização do shell remoto fará.

O digest de aprovação deve abranger uma codificação versionada e separada por domínio. Prefixe os dados codificados com um rótulo fixo, como action-v1/http ou action-v1/ssh, inclua todos os campos imutáveis com comprimentos inequívocos ou um serializador determinístico e então aplique hash. O versionamento impede que uma interpretação antiga se torne silenciosamente uma nova depois de uma atualização. A separação por domínio impede que um objeto HTTP corresponda a um objeto SSH apenas porque seus bytes serializados coincidentemente são iguais.

A identidade do chamador e a vinculação da ação resolvem problemas diferentes

A autorização por sessão informa qual processo em execução pode solicitar ações. A vinculação da ação informa qual ação exata esse processo pode executar. Você precisa das duas, e nenhuma substitui a outra.

Vincule a ação à identidade do processo observada pelo gateway, não a um nome enviado pelo cliente. No macOS, isso pode incluir a autoridade de assinatura do código do processo, o identificador do processo e a instância de início do processo. A instância de início importa porque o sistema operacional pode reutilizar um identificador de processo. Se o processo terminar, descarte suas ações pendentes e aprovadas junto com a autoridade da sessão.

Não permita que um processo filho herde uma aprovação ampla apenas porque conhece o identificador do pai. Observe cada processo conectado na fronteira do gateway. Se uma arquitetura de ferramentas tornar isso impossível, declare a limitação claramente e reduza o período de aprovação em vez de inventar uma confiança que você não tem.

A aprovação humana também precisa de uma validade curta e limitada. A expiração pertence ao objeto congelado e à decisão de aprovação, não apenas a um timer dentro da interface. Quando a validade terminar, o executor deve recusar o envio mesmo que o cliente tenha mantido uma resposta antiga durante todo o período. Uma sessão revogada também deve impedir o envio de qualquer ação aprovada, mas ainda não usada, que pertença a ela.

A autorização por sessão do Sallyport pode estabelecer se um processo de agente recém-conectado pode usar uma execução, enquanto um gateway de ações ainda precisa dessa fronteira imutável separada para cada efeito colateral exibido em uma prévia. Uma decisão de sessão é deliberadamente ampla; uma aprovação de requisição HTTP ou comando SSH precisa continuar exata.

Não use a identidade do processo como motivo para mostrar menos detalhes. Um código assinado e confiável pode ter defeitos, receber entradas inesperadas de prompt injection ou conter um plugin que tomou um caminho diferente do esperado por seu autor. O valor de uma barreira humana está em permitir que a pessoa veja o efeito concreto antes que ele saia da máquina.

Repetições e redirecionamentos precisam permanecer dentro da fronteira aprovada

Uma repetição de transporte pode reutilizar a aprovação apenas quando reenviar a mesma ação congelada sob condições registradas. Muitas implementações de repetição violam essa regra silenciosamente ao reconstruir requisições a partir de um estado mutável do cliente.

Defina o comportamento permitido para repetições quando congelar a ação. Por exemplo, permita um único reenvio depois de uma falha de conexão, antes de qualquer resposta HTTP, com a mesma URL, os mesmos cabeçalhos, os mesmos bytes do corpo e a mesma referência de credencial. Registre cada tentativa com o mesmo identificador de ação. Não repita uma requisição não idempotente depois de uma resposta incerta, a menos que o protocolo e a API de destino ofereçam um mecanismo confiável de idempotência.

Um token de idempotência só é útil se também estiver vinculado. Se o executor gerar um, gere-o ao congelar a ação e mantenha-o no conjunto de cabeçalhos aprovados. Se o cliente fornecer um, trate-o como parte da requisição aprovada. Substituí-lo em uma repetição pode fazer uma única aprovação produzir um segundo efeito colateral.

A recuperação de autenticação merece a mesma desconfiança. Se um cofre atualizar uma credencial internamente, mas enviar a mesma requisição aprovada para o mesmo destino, a ação pode continuar dentro da fronteira. Se a recuperação mudar o tenant, o destino, o escopo ou os cabeçalhos visíveis ao aplicativo, será uma requisição diferente e precisará de uma nova aprovação. Evite um mecanismo em segundo plano que transforme uma falha de autorização em uma chamada alternativa não revisada.

O comportamento padrão de redirecionamento HTTP deve ser recusar redirecionamentos em ações aprovadas. Um redirecionamento que preserve todos os campos relevantes ainda pode atravessar para uma autoridade diferente. Se o produto aceitar seguir redirecionamentos, inspecione cada salto antes do envio e exija um novo objeto de ação quando o host, a porta, o método ou o corpo mudar. Trate um redirecionamento relativo na mesma autoridade de acordo com uma regra explícita, não conforme o comportamento casual de uma biblioteca de cliente subjacente.

As reconexões SSH seguem uma regra semelhante. Reconecte somente ao plano de host vinculado, com a identidade e o comando vinculados. Uma nova impressão digital do host, uma rota de proxy alterada ou um resultado diferente de resolução do host podem exigir uma nova decisão humana, dependendo do seu modelo de ameaça. O código de repetição precisa ser simples o bastante para que um auditor veja que ele não pode ampliar a aprovação original.

Audite a aprovação e a execução como eventos separados

Um registro de auditoria precisa preservar tanto a ação revisada pela pessoa quanto as tentativas feitas pelo executor. Um log que registre apenas a requisição final não pode provar se a prévia correspondia a ela, e um log que registre apenas a aprovação não pode provar se o envio ocorreu.

Registre o identificador da ação congelada, o digest de vinculação, a identidade do chamador, os campos seguros para a prévia, o identificador da referência da credencial, o horário da aprovação, a expiração e o resultado. Depois, registre cada tentativa de envio com o mesmo identificador, o resultado do transporte, o motivo da repetição, se houver, e um digest do corpo ou comando realmente enviado. Mantenha os valores secretos fora do diário voltado ao usuário e da resposta do agente.

É aqui que um log encadeado por hash mostra seu valor. Uma cadeia pode revelar a remoção ou a reorganização de entradas anteriores quando a verificação cobre a sequência armazenada. Ela não transforma um evento vago em algo útil. Se o registro disser apenas «ação SSH aprovada», a cadeia preservará fielmente um evento vago para sempre.

Para um gateway que mantém um log criptografado, encadeado por hash e sem possibilidade de escrita, um verificador offline deve conferir a cadeia de textos cifrados independentemente do acesso ao cofre. O Sallyport oferece essa verificação por meio de sp audit verify, o que é útil porque um investigador pode verificar a continuidade sem abrir primeiro o cofre de credenciais.

A saída da auditoria deve tornar a vinculação visível. Um revisor deve conseguir ver que a aprovação 7c91e2d4 cobria o digest 4f06..., que o envio usou o mesmo digest e que o executor recusou qualquer proposta incompatível. Evite logs que imprimam um resumo humano no momento da aprovação e uma requisição bruta separada no momento da execução, sem uma ligação durável entre os dois.

Teste o cliente como se ele quisesse mudar de ideia

Um teste normal de integração prova que uma ação aprovada é bem-sucedida. Um teste de segurança precisa provar que uma ação aprovada não pode se transformar em outra, mesmo quando o cliente se comporta mal depois do clique da pessoa.

Crie um harness que pause imediatamente depois da aprovação. Enquanto o envio espera, altere um de cada vez os campos controlados pelo cliente: método, host, porta, caminho, query, valores de cabeçalho, cabeçalhos repetidos, corpo, seletor de credencial, configuração de redirecionamento, usuário SSH, comando, ambiente, stdin e digest do arquivo. O executor deve enviar a ação original armazenada ou recusar a tentativa. Nunca deve enviar a alteração.

Teste as condições de corrida com a mesma intenção das mudanças de campos. Envie duas mensagens execute para um identificador aprovado. Cancele a aprovação e envie execute no mesmo instante. Deixe o processo solicitante terminar e depois conecte um novo processo que tente usar o identificador antigo. Reinicie a interface enquanto uma aprovação espera. Preencha o armazenamento de ações pendentes até que a limpeza da expiração seja executada. Esses são eventos comuns do ciclo de vida, e o código de autorização costuma falhar nas brechas entre eles.

Use um servidor HTTP falso que informe o método exato, o destino, os cabeçalhos duplicados e o digest do corpo que recebeu. Use um endpoint SSH controlado que registre o usuário remoto, os bytes do comando, a solicitação de terminal, o ambiente e o digest do stdin. Faça asserções com base nessas observações, não apenas no objeto de intenção do gateway. O objetivo é detectar uma divergência entre a intenção e o transporte.

Por fim, torne os testes com falha fáceis de entender. Uma falha útil diz que o digest de aprovação 4f06... cobria PATCH /v1/users/42, enquanto o envio tentado trazia um digest diferente e foi recusado. Uma mensagem vaga como «autorização falhou» manda os engenheiros de volta a instruções de impressão e os incentiva a enfraquecer as verificações até o teste passar.

Coloque a fronteira de imutabilidade ao lado do executor

O componente que mantém as credenciais e abre a conexão HTTP ou SSH deve ser o responsável pela ação aprovada congelada. Qualquer fronteira anterior deixa outra camada livre para reinterpretá-la, reconstruí-la ou substituí-la.

Esse projeto também mantém a interação humana honesta. A pessoa vê uma prévia gerada a partir do objeto que será enviado; o agente recebe resultados, não credenciais; e o registro de auditoria tem um identificador que relaciona intenção, aprovação e execução. São benefícios distintos, mas todos dependem da mesma recusa em aceitar mudanças depois do clique.

Se o fluxo atual devolve um token de aprovação ao agente e aceita novos campos de ação depois disso, corrija essa parte antes de melhorar o texto, acrescentar controles de política ou incluir outra caixa de diálogo de aprovação. Congele a requisição primeiro. Depois faça o executor provar que usou o registro congelado.