Resumo

  • O primeiro Internet-Draft individual AAuth Events, de 28 de setembro de 2026, propõe que um recurso envie um evento assinado ao Agent Provider (AP) de um agente inscrito, mesmo quando o agente não está acessível.
  • O AP só pode devolver 202 Accepted após registrar duravelmente o evento aceito. A resposta não comprova entrega, verificação ou ação pelo agente, e um token vencido não autoriza uma ação tardia.

Do ponto de vista do recurso, a operação parece concluída: a solicitação saiu, o provedor respondeu 202 e o log registra sucesso. Seria cômodo chamar isso de notificação entregue. O texto de AAuth Events não permite esse salto. O êxito visto pelo recurso pertence ao primeiro trecho de uma cadeia; o destinatário que precisa interpretar a mudança pode estar desligado. Separar aceitação, retransmissão, validação e ação é o trabalho de governança criado por esse rascunho.

Dick Hardt publicou a versão inicial -00 em 28 de setembro de 2026. Trata-se de um Internet-Draft individual com intenção de seguir Standards Track, não de uma RFC aprovada nem de comprovação de implantação. O Datatracker da IETF atesta a existência do texto na data da consulta, não resultados de operação. A proposta complementa outro rascunho AAuth para agentes que usam recursos em nome de uma pessoa. Agora a questão é assíncrona: depois da transação inicial, o recurso precisa comunicar algo novo, mas o agente pode não manter um endereço público ou uma conexão contínua.

O agente estabelece uma inscrição para eventos do recurso. Quando acontece um evento, o recurso cria um token assinado, associa o corpo da mensagem e o envia ao AP. O provedor verifica a assinatura do recurso, o destinatário indicado pelo token, a inscrição ativa e a correspondência do corpo ao resumo body_s256. O rascunho permite identificar duplicatas pelo emissor e pelo identificador do evento. São barreiras importantes contra postagem indevida ou conteúdo adulterado no primeiro recebimento. Nenhuma delas informa se o processo do agente está ativo ou se ele já examinou a mensagem.

Antes de responder 202, o AP tem uma obrigação específica: gravar de modo durável o evento aceito para entrega posterior. O recurso não deve receber sinal de sucesso por um pacote apenas visto na memória e prestes a desaparecer. Essa distinção torna o recibo útil, mas também define seu limite. O mecanismo que leva o evento do AP ao agente é específico de cada plataforma e fica fora do escopo do rascunho. O documento não estabelece uma rota universal de push ou busca, um comprovante final do agente, uma cadência de novas tentativas nem uma garantia de ponta a ponta. O 202 é evidência de custódia pelo intermediário, não de conclusão do fluxo.

O tempo torna a diferença operacional. O JWT do evento traz expiração; ao receber, o agente deve conferir a validade, o público destinatário, o hash do corpo e seu contexto local. Não deve agir com base em token vencido ou em corpo que não confere. Pense em uma mudança de preço que permite cancelar uma reserva por poucos minutos enquanto o agente está sem conexão. O AP pode guardar a notificação corretamente e entregá-la depois; ela pode chegar íntegra quando já não é válida para fundamentar uma decisão. É um cenário ilustrativo, não um relato de falha de produto. A durabilidade preserva a prova da mensagem, não o prazo do direito de agir.

Também não basta apontar para body_s256 como se ele cobrisse toda a cadeia. O resumo detecta alteração ou substituição do corpo pelo AP. O próprio rascunho avisa que ele não impede retenção ou atraso pelo provedor. Um evento fiel pode ser inútil por ter chegado tarde. Um evento entregue pode ser recusado pelo agente por destinatário ou contexto inadequado. Um evento validado pode exigir decisão humana ou encontrar uma operação já encerrada. Seria incorreto transformar todas essas etapas em um único estado “entregue e resolvido”.

Há um custo de visibilidade no desenho do endereço permanente. O AP aprende em quais recursos seus agentes mantêm inscrições e vê os corpos dos eventos. O texto reconhece que isso se afasta da tentativa do protocolo AAuth principal de não expor ao AP o uso dos recursos de uma pessoa. Não é prova de vigilância em qualquer implantação específica; é um novo ponto onde informação se concentra. Um operador pode reduzir o conteúdo enviado, restringir retenção e controlar acesso, mas tais escolhas não surgem automaticamente da resposta 202 ou do hash. Sem essa análise, a disponibilidade conquistada para agentes intermitentes pode vir acompanhada de uma exposição não assumida.

O caso oferece uma pergunta simples para a direção técnica: após o recurso receber sucesso, qual evidência permite afirmar que o agente recebeu um evento ainda válido e conseguiu decidir? A resposta precisa vir da plataforma que implementa o último trecho, não do primeiro recibo padronizado pelo rascunho. Em paralelo, é preciso perguntar por que o AP conhece os nomes dos recursos e quanto do conteúdo precisa manter. A proposta é inicial e pode mudar; anunciar confiabilidade total ou privacidade herdada do protocolo principal seria ir além de seu alcance atual.

Fontes