Resumo

  • O texto inicial de AAuth Budgets, datado de 28 de setembro, propõe um teto de consumo que o serviço cobrado aplica a cada token de autorização.
  • Vários tokens podem ficar válidos ao mesmo tempo; cabe ao servidor da pessoa reservar o valor de todos eles e só liberar exposição desconhecida após uma leitura de consumo adequada.

O problema pode começar antes de qualquer chamada ao modelo. Um servidor autoriza uma missão com dez unidades de gasto e, quase simultaneamente, outra missão com mais dez. São números hipotéticos. O serviço que cobra pelo uso pode executar as duas autorizações dentro dos seus limites e apresentar uma conta de vinte. Se a pessoa imaginava ter autorizado apenas dez no conjunto, não houve necessariamente uma falha no medidor do serviço. Houve uma segunda promessa sobre o mesmo saldo disponível.

Foi para explicitar esse tipo de separação que Dick Hardt publicou, em 28 de setembro de 2026, o primeiro Internet-Draft AAuth Budgets. O próprio documento se apresenta como exploratório. “Standards Track” é o status pretendido, não alcançado; o registro atual do IETF Datatracker diz I-D Exists e não define uma trilha de RFC. Não é norma aprovada, decisão de um grupo de trabalho nem comprovação de uso generalizado. A extensão depende de outro rascunho AAuth: o agente solicita um orçamento, o recurso apresenta a unidade em que cobra e o montante possível, o servidor da pessoa e eventualmente um servidor de acesso podem restringir a concessão, e um token de autorização leva o valor final ao recurso. O recurso mede e impõe o teto; o servidor da pessoa guarda o limite mais amplo fora do token.

No lado do recurso, a proposta exige mais que mostrar uma barra de progresso. Para cada token, consumo já comprometido mais reservas de requisições em andamento não podem passar da concessão. O custo exato de uma saída gerada pode ser conhecido apenas no fim. Antes de atender, o serviço precisa, portanto, estabelecer um custo máximo finito, reservar esse máximo, lançar o custo real e devolver a diferença à disponibilidade. Uma chamada pode ser recusada porque seu máximo declarado não cabe, mesmo que o custo final provavelmente coubesse. A resposta coerente é reduzir o limite da chamada e tentar de novo.

O preço da recusa conservadora compra uma propriedade importante: impedir o gasto antes, em vez de notificar depois.

Esse limite é local ao token. O recurso também mantém números de consumo ligados à pessoa, mas não conhece o teto privado que ela combinou com seu servidor e não deve inventar uma segunda regra de recusa a partir da soma histórica. O emissor é quem deve dimensionar as autorizações simultâneas. O rascunho formula o risco de modo simples: n tokens concorrentes com valor X autorizam até nX durante sua validade. Isso descreve exposição possível, não um incidente observado. Um subagente tampouco herda uma fatia debitada automaticamente do token original. Seu token recebe outra concessão pelo servidor da pessoa, que precisa incluí-la na conta total.

Depois vem o problema do valor desconhecido. Um token pode expirar sem voltar ao emissor, ser abandonado quando o agente trava ou ser trocado numa renovação. O emissor sabe quanto autorizou, mas não quanto foi efetivamente consumido. O texto determina que ele trate temporariamente a alocação inteira como gasta. Um registro de consumo recebido num desafio informa o total de um token naquele momento; não o encerra se ainda puder ser usado. Uma consulta aos contadores do recurso, completa até um instante as_of, permite acertar alocações que já terminaram. Revogação registrada no recurso pode antecipar esse acerto. Se a revogação não for suportada ou seu resultado estiver indisponível, não se deve devolver imediatamente a reserva; operações em curso podem terminar. O comando “parar” não é sinônimo de estorno.

Há outras fronteiras importantes. Orçamento limita quanto, não o que o agente pode fazer: uma operação irreversível barata ainda depende de permissões adequadas. Se a pessoa tem mais de uma conta faturável no mesmo serviço, o orçamento sozinho não informa qual deve receber a cobrança. O cabeçalho AAuth-Budget proposto mostra ao agente custo e saldo para ajustar chamadas, mas não é assinado por padrão e não substitui o valor autorizado no token. A assinatura da resposta de uso é recomendada, não obrigatória; documenta o que o recurso declarou, não prova que o medidor ou a futura fatura estejam corretos. Relatos de implementações na seção própria do rascunho não foram verificados independentemente nesta apuração.

A extensão também não cobre o caso comum de inferência que o próprio provedor do agente paga sem um servidor da pessoa no circuito. Seu alvo relevante é o software do agente consumindo uma conta medida da pessoa. Nesse caso, perguntar apenas “qual é o limite deste agente?” é insuficiente. A pergunta responsável é “que outras autorizações continuam abertas contra a mesma margem e em que leitura a margem já pode ser liberada?”.

Fontes