Resumo

  • A revisão 01 de um Internet-Draft individual acrescenta ao registro de auditoria de agentes o limite acumulado, o gasto realizado, o dinheiro reservado para permissões sem desfecho, o novo pedido e a versão do saldo consultado.
  • Se a resposta de uma ferramenta se perde, a reserva continua. Repetir a mesma chamada não conta duas vezes; uma chamada diferente autorizada com saldo antigo pode passar do teto delegado.

O silêncio da ferramenta não devolve o dinheiro

O agente pede a uma ferramenta que execute uma compra. A ferramenta não responde. Na próxima linha da planilha, o valor está livre ou comprometido? A nova versão do rascunho de Sankalp Gilda o mantém comprometido até que um registro da mesma solicitação mostre o efeito observado. Falta de resposta é problema de comunicação, não comprovante de estorno.

O texto foi anunciado em 27 de outubro como Internet-Draft individual, conforme o Datatracker da IETF. Não descreve uma compra real. A diferença em relação à versão 00 é a seção sobre limites cumulativos: ela pergunta quanto da autoridade de gasto já foi consumido ou prometido antes de conceder a próxima permissão.

Uma data recente no saldo não basta. Se ele esqueceu uma chamada aprovada e ainda não liquidada, a próxima autorização pode parecer correta sozinha e violar o teto no conjunto. O campo consumption-state reúne o documento que define o limite, a unidade monetária, limit, consumed, reserved, requested, uma lista dos pedidos pendentes e stateRevision, a edição do estado que a decisão leu. É um retrato da conta no instante do «sim», com as pendências à vista.

O reenvio é o mesmo pedido; a próxima compra não

O próprio projeto usa um exemplo de 50 mil pence de limite. Já saíram 30 mil, e 12 mil estão reservados para uma chamada anterior. Se ela é reenviada com o mesmo resumo criptográfico da solicitação, o total continua em 42 mil. Cobrar a reserva outra vez puniria o usuário pela resposta perdida. Mas uma compra diferente de 12 mil levaria a soma a 54 mil e deve ser negada. Os números são do exemplo do autor, não de pagamentos observados.

O valor reservado só sai da espera quando outro registro do mesmo pedido informa o que aconteceu. Efeito occurred: vai para consumido. Efeito none: volta ao disponível. Resposta ausente não é nenhum dos dois. O resultado pode ser um saldo temporariamente apertado mesmo quando a operação falhou; é o preço de não gastar de novo uma verba cujo destino ainda se desconhece.

O ponto mais interessante é a conferência entre registros. Um segundo pedido pode ler uma stateRevision anterior à reserva do primeiro. Nesse estado envelhecido, a conta parece ter espaço. A nova regra manda comparar as decisões sob o mesmo documento de limite em ordem de revisão: cada permissão anterior ainda pendente precisa aparecer como reserva ou gasto nas posteriores, até haver liquidação. A ausência revela a janela em que o teto pode ser comprometido duas vezes. Também chama atenção a liberação da reserva sem prova de efeito nulo.

Um registro que relata permissão acima do teto continua bem formado. O formato precisa guardar evidência de que o decisor passou do ponto, não descartá-la como dado inválido. Isso não converte uma assinatura em prova da realidade inteira: a própria seção de segurança separa coerência do arquivo e fatos que exigem observação fora dele.

O saldo pertence à autorização, não à interface

Alguém delega o teto. Um serviço decide com base no saldo que leu; uma ferramenta pode executar; outro componente observa e arquiva. Para quem audita, a pergunta é se a próxima decisão viu os compromissos anteriores e se a liberação tinha um resultado verificável. Sem o conjunto de registros, até uma conta bem formatada pode ser uma conta incompleta.

O projeto oferece as colunas para essa conversa. A organização que o usar terá de definir quem controla o estado, quem pode encerrar uma reserva e quem guarda as provas quando uma decisão é contestada. O dinheiro não volta ao orçamento só porque a máquina ficou calada.

Registros originais