Resumo

  • A revisão 01 do draft-kuehlewind-audit-architecture, datada de 7 de setembro de 2026, acrescenta armazenamento em banda: cada agente pode operar seu próprio Audit Store e enviar registros pela conexão usada na interação.
  • O texto trata essa configuração como alternativa, não substituta, a um armazenamento externo, e permite combinar os dois caminhos. Também reconhece que a operação pela mesma parte deposita mais confiança no operador do agente.
  • Armazenar é apenas uma função da auditoria. A minuta distingue Recorder, Auditing Service, atestação, registro de transparência, auditor e verificador.
  • O documento continua sendo um Internet-Draft individual. O Datatracker informa que ele não é endossado pela IETF e não tem posição formal no processo de padronização.
  • Daniel Kade propõe um recibo de topologia de custódia que identifique o operador de cada função. Trata-se de análise editorial, não de exigência do documento.

O atalho novo já vem com um aviso de confiança

A alteração mais reveladora da revisão 01 ocupa um único parágrafo. A nova seção 3.2 diz que, em vez de exportar os registros para um Audit Store externo e separado, cada agente pode executar seu próprio Store. Ele poderá enviar os eventos ao Store do agente com o qual interage, reaproveitando a conexão existente e dispensando um canal adicional fora de banda.

Há uma justificativa operacional real. Um agente de vida curta talvez já disponha de uma ligação autenticada com a contraparte. Reutilizá-la reduz integrações e pode fazer o registro acompanhar uma cadeia distribuída. Os autores não descrevem o armazenamento próprio como resposta única: chamam-no de alternativa ao Store externo, autorizam o uso combinado e registram a contrapartida. Se a mesma parte opera o agente e o Store, a arquitetura confia mais nessa parte do que confiaria num armazenamento externo independente.

Esse trecho não aparece na revisão 00, de maio. A notícia, portanto, é uma mudança textual verificável, e não uma interpretação nova de material antigo.

A palavra “auditoria” encobre atos diferentes

O problema não é declarar inválido todo armazenamento em banda. Ele surge quando uma implantação comprime várias funções na frase confortável “o agente é auditado”. A própria revisão 01 oferece termos para evitar essa redução.

Os atores principais produzem registros a partir de pontos de observação distintos. A interface do usuário pode preservar intenção e aprovações. O agente pode emitir sinais de ações, delegações e transições de autorização. Um serviço ou ferramenta pode registrar a requisição observada no ponto em que ocorreu o efeito. O Audit Recorder captura ou transforma esses sinais. O Audit Store conserva e apresenta registros. O Auditing Service os canoniza, assina com identidade própria e submete a um log de transparência. Depois, um auditor avalia a evidência conforme uma política, enquanto um verificador examina alegações específicas.

Cada função responde a uma pergunta. O armazenamento diz onde encontrar o registro. A assinatura vincula uma declaração a uma chave. A atestação pode sustentar alegações sobre o ambiente produtor. Um recibo de transparência ajuda a demonstrar que uma declaração existia em determinado momento e a detectar certas apresentações inconsistentes. A independência do auditor diz respeito a quem formula o juízo. Nenhum desses elementos, isoladamente, prova que todos os participantes registraram tudo de forma verdadeira.

A distinção é crucial porque a minuta aceita agregação de papéis. Um papel é uma função, não necessariamente uma empresa ou unidade de implantação. O processo hospedeiro do agente pode implementar também o Recorder. Isso simplifica a operação, mas o documento identifica ameaça de conluio e cita como mitigações um Recorder independente ou a não repudiação por registro transparente. Em outro ponto, a revisão 01 diz que as propriedades de responsabilização da arquitetura requerem um Auditing Service independente.

Não existe contradição se os limites forem preservados. Um Store da mesma parte pode transportar e reter eventos enquanto um serviço independente os canoniza ou produz o primeiro compromisso externo. Um terceiro pode hospedar o Store sem julgar a auditoria. No sentido inverso, um produto externo pode continuar sob o mesmo grupo econômico, administrador ou guardião de chaves. “Externo” descreve posição; “independente” descreve controle e incentivos.

O endereço do Store não demonstra sua custódia

Compare duas configurações. Na primeira, o agente grava num Store dentro do próprio processo, mas um serviço separado registra imediatamente compromissos assinados num sistema de transparência que o operador não consegue reescrever sozinho. Na segunda, o agente exporta eventos para uma conta de logs em nuvem administrada pela mesma equipe que opera o agente e pode alterar a origem e a cópia antes de qualquer compromisso externo.

O segundo Store está fora em termos geográficos. O primeiro talvez imponha uma restrição histórica mais cedo. O exemplo não certifica completude nem conformidade em nenhum dos casos. Ele mostra por que um diagrama de rede ou uma contagem de fornecedores não substitui a cadeia de custódia.

A RFC 9334 faz separação semelhante na atestação remota: o Attester produz Evidence, o Verifier a avalia e o Relying Party aplica sua própria política. A RFC 9943 também separa declarações assinadas, serviços de transparência, recibos e decisões das partes usuárias. O nome de um componente não cria um nível de garantia. Papéis, políticas, chaves e percurso da evidência definem o alcance da confiança.

A situação institucional do documento deve permanecer visível. O Datatracker não mostra fluxo RFC, diretor de área responsável nem adoção por Working Group, e exibe o aviso de que o Internet-Draft individual não tem endosso da IETF. A opção de armazenamento é uma proposta em evolução, não uma regra da IETF para sistemas de agentes.

Fontes