Summary

  • Publicada em 1º de novembro, a revisão -02 troca a avaliação de todos os agentes pela checagem do principal e do agente atual na entrada do serviço.
  • A suspensão posterior de um agente que participou antes pode aparecer nos recibos vinculados. Pela regra proposta, ela não basta para barrar a próxima chamada.

Uma rede de agentes pode produzir uma ótima ficha de antecedentes e, mesmo assim, deixar a catraca aberta. O novo texto de Agent Execution Evidence torna esse desencontro visível. A requisição passa por vários agentes. Quando chega ao serviço, um nome anterior da cadeia já está suspenso. O serviço decide conforme o principal da transação e o agente que faz a chamada agora.

A mudança responde a uma frase concreta. A revisão -01 dizia que o recebedor avaliaria cada agente. Os autores explicam que aquela versão foi enviada a partir de um estado anterior do documento. A -02 elimina a instrução e deixa os atores passados no actor_chain como histórico de auditoria. A seção 6.7.2 proíbe usá-los para a admissão. É a linha traçada pela RFC 8693, na qual as declarações de nível superior do token e o ator atual alimentam o controle de acesso.

O histórico ainda pode cobrar contas. A proposta vincula recibos gerados pelo lado que chama e pelo que recebe, de modo que uma verificação posterior encontre o caminho disponível, a base de admissão registrada em cada salto e a continuidade do trabalho após a suspensão de um agente anterior. Isso ilumina a sequência de decisões. O próprio texto reconhece que o recebedor não pode recusar uma chamada apenas porque um ator anterior foi suspenso depois. Saber mais tarde não equivale a impedir na hora.

Há outro limite: na entrada, a cadeia é uma história declarada pelo emissor do token. Recibos coincidentes podem sustentar sua consistência, não sua completude; tampouco mostram que cada repasse reduziu os poderes do agente. O status do agente que chama no momento, em contraste, precisa ter a atualização exigida pela política do serviço. Se esse agente estiver restrito, só entram operações da classe permitida.

A seção 14 mantém em aberto uma admissão baseada em todo o histórico. Ela exigiria regras de confiança e completude e resolver o conflito com a RFC 8693. O registro do IETF identifica um rascunho individual atualizado em 1º de novembro. O dado que falta para mudar a avaliação operacional é uma regra efetivamente aplicada que consulte a suspensão dos antecessores antes de admitir a chamada.