TRACE chega à Linux Foundation para tornar ações de agentes auditáveis

Em 25 de agosto de 2026, a Linux Foundation anunciou a incorporação do TRACE, especificação aberta para criar evidências verificáveis sobre a execução de agentes de IA e outras cargas confidenciais. O comunicado da Linux Foundation informa que a tecnologia foi contribuída pela OPAQUE, desenvolvida com AMD, Intel, Microsoft e Technology Innovation Institute e ficará sob governança neutra; a versão atual, porém, ainda é a v0.2 em Developer Preview.

Uma reportagem da SecurityWeek publicada na mesma data confirmou a mudança de governança e a proposta de reunir ambiente, software, políticas, classificação dos dados e ferramentas acionadas em um registro criptograficamente verificável. É nesse sentido delimitado que o TRACE torna ações auditáveis: ele produz provas sobre aspectos observáveis da execução, sem certificar todo o comportamento ou o raciocínio interno do agente.

O que entra em um Trust Record

O artefato central do TRACE é o Trust Record, um registro assinado ligado a uma execução específica. Ele pode identificar a carga ou o agente, o modelo, a plataforma e a medição do ambiente de execução, a proveniência do software, a política aplicada e a classificação dos dados processados.

O registro também comporta evidências sobre ferramentas chamadas pelo agente. Em vez de necessariamente carregar diálogos, argumentos e respostas sensíveis, ele pode guardar a contagem das chamadas e um resumo criptográfico do transcript, permitindo detectar alterações no material de referência. A cobertura depende de a interação atravessar uma superfície instrumentada, como uma integração MCP ou A2A.

Uma avaliação do verificador e uma referência para um registro de transparência também podem integrar o artefato. Isso separa a declaração produzida durante a execução da conclusão posterior de quem avaliou assinatura, atestação e demais evidências. O Trust Record, portanto, funciona como um recibo estruturado, não como uma gravação integral da sessão.

Como a criação e a verificação funcionam

O fluxo começa no runtime que executa o agente. Esse ambiente reúne as afirmações sobre identidade, medição, política, dados e ferramentas e as organiza no formato definido pelo TRACE. Quando há um ambiente de execução confiável, a chave usada para assinar o registro fica vinculada à raiz de confiança do hardware e às medições da carga.

1. O runtime coleta as afirmações referentes à execução.
2. Os dados são reunidos em um Trust Record e protegidos por uma assinatura.
3. O registro pode receber uma prova de inclusão em um log de transparência.
4. Um verificador confere o formato, a assinatura, a cadeia de atestação, as medições e as políticas exigidas por quem consumirá a evidência.

Uma assinatura válida demonstra que o conteúdo assinado não foi modificado, mas não basta para aceitar a execução. O verificador ainda precisa comparar as medições com referências confiáveis, avaliar a origem da chave, checar o perfil da especificação e aplicar sua própria política de confiança. Quando a decisão depende de atualidade, também precisa examinar validade, revogação e mecanismos contra a reutilização de um registro antigo.

Por que não é apenas mais um log

Logs convencionais continuam sendo mais adequados para depuração, métricas, busca de eventos e monitoramento cotidiano. A limitação probatória é que normalmente são escritos e administrados pelo próprio sistema auditado; conforme a arquitetura, um operador privilegiado pode alterar, excluir ou produzir eventos sem uma raiz externa de confiança.

O TRACE tenta reduzir essa dependência ao ligar um conjunto limitado de afirmações a uma assinatura e, nos níveis apoiados por hardware, à medição de um ambiente confiável. Outra parte pode transportar o artefato para fora da infraestrutura que o criou e verificar sua integridade. A ancoragem opcional em um registro de transparência acrescenta uma referência durável de inclusão.

Isso não torna o Trust Record mais completo que a telemetria operacional. Ele pode ser muito mais estreito, mas oferece evidências mais fortes sobre os campos contemplados. Na arquitetura proposta, logs explicam eventos e sustentam operações; o TRACE busca comprovar determinadas condições da execução sem exigir confiança irrestrita no operador que a hospedou.

Atestação não substitui controles de segurança

A atestação responde se certas afirmações estão ligadas a uma chave, a uma medição e a um ambiente reconhecido. Ela não autentica automaticamente quem está solicitando uma operação nem concede permissão para acessar dados ou ferramentas. Autenticação, autorização e revisão das políticas permanecem controles separados.

O hash de uma política pode comprovar qual versão estava associada à execução, mas não demonstra que suas regras eram adequadas. Da mesma forma, um transcript de ferramentas cobre interações observadas no ponto instrumentado; não revela a cadeia interna de raciocínio do modelo nem prova quais dados de uma resposta influenciaram a chamada seguinte.

Um registro válido tampouco comprova que a resposta estava correta, que o objetivo humano foi atendido ou que uma ação no mundo físico terminou como esperado. Monitoramento, proteção e revogação de chaves, armazenamento das evidências, detecção de anomalias e resposta a incidentes continuam necessários. O TRACE acrescenta um formato de prova a essa arquitetura, não a substitui.

A versão 0.2 já está pronta para produção?

A resposta mais precisa é que a v0.2 pode ser avaliada e integrada, mas não deve ser tratada como especificação estabilizada para decisões críticas. O repositório oficial do TRACE classifica a versão como Developer Preview, publica uma suíte de conformidade e recomenda consultar as limitações antes de depender dela em produção.

O nível de garantia varia conforme a origem do registro. Uma assinatura feita somente por software permite testar estrutura e integridade, mas uma pessoa com controle privilegiado sobre a máquina pode produzir um registro aparentemente válido para uma execução inexistente. A documentação reserva esse nível para desenvolvimento, trilhas internas e ambientes de homologação; uma alegação apoiada em hardware exige uma cadeia de atestação e referências confiáveis adequadamente verificadas.

Mesmo com hardware, a conclusão depende da política do verificador, da proteção das chaves, da verificação de revogação e da qualidade das medições de referência. Atestação também não elimina ataques de canal lateral contra o ambiente confiável. A chegada à Linux Foundation estabelece a nova casa institucional do projeto, enquanto a maturidade para produção ainda dependerá da evolução posterior à v0.2, da resolução das limitações documentadas e da interoperabilidade entre implementações.