Resumo

  • O GAR-07 foi anunciado no arquivo da IETF em 3 de setembro de 2026. O Datatracker o classifica como Internet-Draft individual, sem endosso da IETF, posição formal no processo, fluxo de RFC ou Area Director responsável.
  • O GAR-06 aplicava assinatura externa a R-3 e descrevia a classe como falha de integridade de atestação. O MAD-03 citado, contudo, definia R-3 como ausência de resposta e não passava de R-7.
  • O GAR-07 transfere a assinatura externa para R-8, amplia os campos de revogação até oito classes e torna o evento de reatestação exclusivo de R-8.
  • O MAD-04, datado de 4 de setembro, cria R-8 para comprometimento de mandato ou credencial. A resposta é imediata, exige reautorização humana e alcança os descendentes, mas o sinal precisa ser autenticado para não virar um mecanismo de falsa revogação.
  • Os textos correntes estão alinhados, enquanto a bibliografia normativa do GAR-07 permanece em MAD-03. Uma alegação reproduzível deve fixar as duas revisões, seus hashes e a matriz de testes da recuperação.

A lógica estava certa; o código, não

O GAR-06 já recusava uma circularidade importante. Se o componente de imposição da governança pode ter sido comprometido, ele não deve ser a única entidade a assinar a prova de que recuperou a própria identidade. O término da reatestação KIA precisaria de um serviço verificador externo.

A regra foi associada a R-3, chamado ali de falha de integridade de atestação. No MAD-03, que o GAR cita normativamente, R-3 significa Non-Response: uma sessão não respondeu a um sinal dentro do prazo. A taxonomia tem R-1 a R-7 e nenhuma classe independente para comprometimento.

Uma plataforma não pode tratar a diferença como apresentação. A falta de resposta pode permitir uma continuação emitida pelo operador. O comprometimento coloca em dúvida a credencial que sustentava a autoridade e exige um principal humano. Se o código não distingue os casos, a mesma entrada de auditoria pode abrir duas portas de recuperação.

O GAR-07 muda o dono da prova

Na revisão 07, a regra de assinatura passa para R-8 Compromise. O evento ALE_KIA_REATTESTATION_COMPLETED só dispara nessa classe. Os campos de revogação da sessão e do filho, antes limitados a R-1–R-6, passam a incluir R-7 e R-8. O trecho sobre o risco de um componente comprometido que ainda assina também adota R-8.

O registro separa a parte examinada da parte que confirma o retorno. Identifica o verificador, preserva sua assinatura Ed25519 e liga a atestação anterior à nova, ao hash da política e à versão do núcleo. O intervalo sem atestação e as sessões executadas nesse período não desaparecem; tornam-se dados explícitos no pacote de auditoria.

O próprio texto limita a promessa. Um componente comprometido, ainda capaz de assinar, pode produzir registros falsos que passam na verificação criptográfica. A assinatura externa protege um ponto do fluxo. Não torna verdadeiros todos os atos anteriores. Níveis inferiores de conformidade não devem anunciar essa garantia ampliada.

O MAD-04 acrescenta o evento que faltava

O MAD-04, de 4 de setembro, explica que R-8 surgiu quando uma revisão cruzada encontrou reason: compromise no perfil de eventos do mandato sem código correspondente na taxonomia MAD.

O gatilho cobre suspeita ou confirmação de que um mandato ou uma credencial foi atingido por ataque externo: exposição de material de chave, furto da credencial ou falha de atestação que indique divergência entre a identidade em execução e a condição atestada. Isso não é R-1. R-1 ocorre quando o agente viola um limite da autoridade concedida; em R-8, é a própria autoridade apresentada que pode estar corrompida.

A sessão para sem aguardar um ponto natural e jamais recebe conclusão limpa. Um humano precisa autorizar qualquer continuação. A credencial comprometida e material derivado não podem voltar. Todos os descendentes são revogados e os registros de composição de subagentes e referências efêmeras são anulados, pois nasceram do mandato sob suspeita.

O rascunho não ignora o preço dessa severidade. Um atacante que falsifique o sinal poderia derrubar a árvore. Por isso, o componente deve validar a autenticidade e a integridade da fonte com as chaves da autoridade emissora antes de registrar R-8. O evento conserva o tipo de detecção e a referência específica, se disponível.

O elo normativo continua no MAD-03

Nas páginas atuais do GAR e do MAD, as versões 07 e 04 se encaixam. A referência normativa impressa no GAR-07, porém, ainda nomeia draft-sato-soos-mad-03. Esse arquivo imutável não conhece R-8 e reserva R-3 para ausência de resposta.

A proximidade das datas permite uma hipótese modesta: o documento que define R-8 veio um dia depois do que passou a usá-lo. O registro público não mostra intenção, portanto não autoriza uma narrativa sobre o motivo. Ele demonstra apenas que seguir o alias corrente e seguir a versão citada produzem grafos de dependência diferentes.

Um link vivo é excelente para leitura. Para auditoria, pode apagar o estado anterior. “Compatível com GAR e MAD” não é uma declaração estável se os nomes mudam de conteúdo. Fixar apenas o GAR-07 também não basta quando a dependência fixada não contém a classe acionada.

Uma ficha para cada decisão R-8

A ficha mínima junta os nomes, revisões, SHA-256 e horários de captura dos dois textos; o motivo original; a classe; a chave que verificou o sinal; a raiz e os descendentes afetados; o estado incompleto; o decisor humano; o verificador externo; e o evento final de restauração.

Os casos negativos dão valor à ficha. R-3 por não resposta não pode entrar na reatestação de comprometimento. R-8 autenticado precisa parar a cadeia. R-8 forjado deve ser rejeitado sem perda de autoridade. Autoassinatura do componente investigado, chave derivada do material comprometido e estado parcial pendente precisam impedir a volta por motivos distinguíveis.

Uma revisão futura não apaga o recibo antigo. Ela cria outro, com a mudança do elo de dependência. Assim o operador consegue reconstruir a regra que o código aplicou, e não apenas a regra que a página apresenta hoje.

A primazia do código em operação de Heng Lu é usada aqui como critério editorial, nunca como evidência de implantação. Publicação não produz efeito operacional sozinha. A especificação inicial mínima deve evitar autoridade desnecessária e, ao mesmo tempo, permitir que validadores independentes cheguem à mesma transição.

Rascunho individual não é decisão da IETF

O Datatracker declara que qualquer pessoa pode submeter um Internet-Draft e que estes dois não têm endosso nem posição formal na IETF. Não há fluxo, AD responsável ou telechat. A intenção Standards Track escrita pelo autor no cabeçalho não altera o estado institucional.

Também não apareceu evidência de implementação, interoperabilidade, uso em produção, aceitação regulatória ou incidente real. Os textos ainda podem mudar, ser substituídos ou expirar.

A conclusão, portanto, deve permanecer precisa. Não existe um novo padrão da IETF para agentes de IA. Existem duas propostas individuais que alinharam uma rota importante de revogação e recuperação. O pequeno desalinhamento restante mostra por que a governança verificável precisa preservar a regra e a sua origem de versão no mesmo registro.

Fontes

  1. Anúncio do GAR-07 no arquivo IETF
  2. Datatracker — Governance Audit Record
  3. GAR-07
  4. GAR-06
  5. Diferenças GAR-06/GAR-07
  6. Datatracker — Multi-Agent Delegation
  7. MAD-04
  8. MAD-03
  9. Diferenças MAD-03/MAD-04
  10. Heng Lu — Running-Code Primacy
  11. Heng Lu — especificação inicial mínima
  12. Heng Lu — realidade, não defesa de causa