Resumo

  • A IETF anunciou uma reunião virtual interina do grupo OAuth para 28 de setembro de 2026, com a pauta “Anthropic & OpenAI Agentic Use Cases”. O anúncio não comprova apoio das empresas a um draft nem adoção de solução pelo grupo.
  • RAR expressa autorização fina e DPoP liga token a chave. A falha restante surge quando o modelo cria a chamada concreta: seus próprios argumentos não podem ser proposta e fonte de permissão ao mesmo tempo. Uma base independente deve aprovar os valores finais, que precisam ser verificados e consumidos no primeiro ponto capaz de gerar efeito.

O caso não começa com um invasor usando um token roubado. Começa com o cliente legítimo usando uma API legítima. Uma mensagem envenenada altera o beneficiário; o agente conserva a operação pay, a audiência e a chave esperadas. Todos os indicadores de identidade ficam verdes enquanto a consequência se desvia do mandato.

O comunicado da IETF marca a reunião para 17:00–18:00 UTC. A pauta prova que casos agênticos ligados a Anthropic e OpenAI serão tema. Não revela conteúdo, apoio, presença de uma proposta comum ou consenso. Um texto individual continua individual.

A carta do OAuth descreve delegação de acesso limitado sem entregar credenciais duradouras, ou até identidade, ao terceiro. RFC 9396 define authorization_details. Seu exemplo de pagamento inclui valor e credor: quando os dados já foram estabelecidos e aprovados, o resource server pode recusar qualquer POST divergente. Portanto, a crítica correta não é que OAuth só conhece escopos genéricos.

O debate iniciado em 1º de setembro pergunta pelo estágio seguinte, quando {tool, arguments} nasce do modelo. Na troca sobre RAR, a distinção amadurece: descrever exatamente a saída não define quem lhe deu autoridade. Copiar os mesmos valores não confiáveis para um objeto detalhado faz uma boa representação e uma decisão circular.

A fonte independente pode ser limite de orçamento aceito antes, regra corporativa versionada, pedido já validado, registro assinado por serviço separado ou aprovação de exceção. Não é sinônimo de clique humano em toda chamada. É a impossibilidade de o candidato cunhar a própria permissão.

O draft Chen mostra uma tarefa de piquenique iniciada na segunda-feira e uma tela de consentimento exibida na terça, depois da escolha do parque. Escopos como parks.book perderam motivo, local e custo: o contexto desabou. O texto afirma que OAuth não precisa interpretar a fala nem orquestrar a tarefa; precisa permitir que limites anteriores sejam relacionados à execução.

O draft Liu propõe uma operação estruturada em JWT sem a frase original e, depois, um token para a operação confirmada. O draft Yossif separa T0, quando o principal autoriza limites, de T1, quando o agente atua sem ele. Pedir autorização humana para milhares de passos elimina autonomia; chegar a T1 sem os limites elimina controle. Esse documento não especifica protocolo.

São Internet-Drafts, sujeitos a mudança e expiração. A pauta de setembro não lhes dá status de RFC.

Para ligar decisão e ato, os bytes precisam de canonicalização versionada. Ordem de chaves, números, defaults, URLs e campos vivos podem alterar identidade ou consequência. Ferramenta, destino, valor, objeto e classe de efeito devem integrar o digest. Mas o hash só confirma igualdade. Ele preserva com exatidão um destinatário malicioso se esse foi o valor que entrou.

O draft Das descreve um perfil possível: manter Candidate Act sem efeito, canonicalizar, validar, registrar evidência, emitir autoridade, verificá-la e consumi-la no dispatch sink, então invocar. É submissão Informational individual com nota de propriedade intelectual, não escolha da IETF. Sua pergunta útil é operacional: onde tool_use vira invoke()?

O sink é o primeiro ponto que muda o exterior. Pode ser resource server, função local, controlador de navegador ou wrapper do cliente MCP. Proteger apenas um servidor não basta se outra biblioteca conserva as credenciais. Um follow-up da lista sugere, como formulação de participante, recusar a chamada quando o digest final não combina com uma policy assertion autorizada. O teste deve ocorrer antes do efeito e consumir autoridade de uso único para impedir corrida e replay.

RFC 9449 usa DPoP para restringir o token ao detentor da chave e detectar replay. Não autoriza a decisão errada do detentor correto. RFC 8693 troca tokens e preserva semântica de delegação ou impersonation, mas não julga os argumentos terminais.

Depois do invoke, surge a incerteza da recuperação. Se a autoridade foi consumida e o host cai antes da resposta, repetir pode duplicar o efeito; não repetir pode abandonar um ato que não aconteceu. É preciso idempotency ID comum e estados separados para autorizado, enviado, aceito, efetivado e observado. Um HTTP 200 não prova que o objetivo do usuário foi atingido.

O recibo começa no mandato: identidade e versão da política, contexto e limites; ferramenta candidata, consequência, versão canônica e digest; fonte independente, emissor, audiência, validade e chave; sink, digest vivo, replay e consumo; resposta, estado persistente, compensação e resultado visível. Sem essa genealogia, cancelar a tarefa não alcança os efeitos derivados.

O princípio de especificação inicial mínima de Heng Lu recomenda padronizar apenas o necessário para identificar mandato, ato, vínculo, sink e recibo. As camadas da realidade separam fato de protocolo, autorização, implementação, estado externo e resultado. A primazia do código em execução exige mudar o destino após aprovação, disputar autoridade única, contornar wrapper e derrubar o host. O efeito sem recibo compatível denuncia uma autorização apenas simbólica.

Fontes