Summary

  • O rascunho AACP põe um Serviço de Confirmação para apresentar, fora da inferência do modelo, todos os parâmetros marcados para aprovação e assinar a resposta do usuário.
  • Quem executa confere a prova com a operação real, o destinatário, um desafio recente e o prazo. Uma recusa assinada não vira a mesma coisa que uma pessoa fora de alcance.

Um agente pode escrever “o cliente aprovou” com a segurança de quem acabou de sair de uma reunião. A frase não mostra a tela que o cliente viu. O rascunho Agent Action Confirmation Protocol, publicado em 2 de novembro, leva essa lacuna até a porta do sistema que vai agir. O agente responsável pela operação monta uma descrição estruturada. Um Serviço de Confirmação apresenta os campos exigidos ao usuário, oferece aceitar e recusar, registra a escolha e assina a evidência. Esse serviço pode morar no aplicativo do usuário, na infraestrutura de autorização da empresa ou em um aplicativo próprio. A escolha precisa passar por uma interface programática, fora da etapa de inferência da IA.

A lista de campos importa tanto quanto o botão. Cada parâmetro sujeito à escolha humana recebe confirm=true e um rótulo legível. O serviço tem de mostrar todos antes de apresentar os controles de decisão. Textos e valores da descrição entram como dados, sem virar links executáveis ou instruções para a interface. Assim, um resumo simpático escrito pelo agente não pode substituir o valor, o destino ou o efeito de uma operação que o usuário deveria examinar.

Depois do clique, a assinatura vem do componente que exibiu a pergunta e recolheu a resposta. O verificador recalcula um resumo criptográfico a partir da operação que está prestes a executar. Também valida a chave do serviço conforme sua própria política, o agente ao qual a evidência se destina, o desafio recém-criado, a validade e o histórico de uso do identificador. A aprovação de uma tarefa não serve como passe para outra. Para ações difíceis de desfazer, o texto recomenda conferir ainda um resumo do conjunto de campos efetivamente mostrado.

A diferença é concreta: saber que alguém clicou não comprova que o valor e o destinatário apareceram antes do clique.

O rascunho dá nomes diferentes a problemas diferentes. Denied registra uma recusa assinada; uma nova tentativa só pode partir do usuário. Unobtainable informa, sem assinatura de decisão, que não foi possível colher resposta. Prova vencida, repetida, alterada, enviada a outro agente ou impossível de verificar recebe outro resultado. A API não pode aproveitar uma parte válida e executar o resto. Para pagamentos e registros duradouros, essa separação define se o sistema para, tenta recuperar o canal ou pede uma nova decisão humana.

O Datatracker da IETF classifica o documento como submissão individual. Falta um teste entre implementações independentes que rejeite um campo trocado após a exibição, um campo obrigatório oculto e uma evidência reapresentada. Esse teste mostrará se a assinatura protege a decisão inteira ou apenas produz um recibo bonito para uma pergunta incompleta.