A trilha de auditoria

Correção de 12/10/2026 (PR #898, 11/10/2026). (1) Quem pode o quê mudou: ver a trilha e verificar a integridade exigem "Ver a governança"; alterar a retenção, anexar evidência e gravar um evento manual exigem "Gerenciar acesso". Alterar a retenção depende de administrar a organização — a leitura da configuração de retenção continua aberta a qualquer membro. A observação de que "esta tela segue o papel na organização e não a governança" vale hoje só para a leitura da retenção. (2) Das seis categorias, as de ciclo de vida do ativo, decisão de entrada em produção e mudança de configuração de avaliação não têm mais quem as grave (os módulos saíram); continuam aceitas porque o histórico as tem. (3) O monitoramento que este documento citava não existe mais. (4) Há uma aba Auditoria nova, descrita abaixo. A ancoragem diária (04:00) segue agendada.

A aba Auditoria da Governança (desde 11/10/2026)

Na aba Auditoria a pessoa vê "quem mudou o quê" no período escolhido (24 horas a 90 dias): cartões com quantas mudanças de configuração aconteceram, quantas pessoas as fizeram, quantas vieram por agente (MCP/API), quais fontes externas estão conectadas (só para quem vê consumo de terceiros) e quais recursos estão ligados e desde quando; e a lista de eventos, que se filtra por pessoa, ação, origem (tela, MCP ou API) e alvo (por exemplo, o histórico de um agente ou de uma regra). Cada linha mostra o autor com foto, a ação traduzida, o alvo, a origem e o resultado. Dá para exportar em CSV o período inteiro (até 50 mil linhas), com a permissão "Ver a governança". As ações como pausar um agente, trocar o dono e criar uma classificação ou guardrail aparecem aqui.

Camada funcional

Um registro que não pode ser alterado depois — nem por quem administra o sistema. Serve às situações em que o registro precisa ter valor probatório: auditoria formal, exigência regulatória, disputa sobre o que foi decidido e quando.

É diferente da trilha operacional, que responde "quem chamou o que" no dia a dia. Aquela serve para investigar; esta serve para provar.

Onde o "não pode ser alterado" é imposto

A distinção que faz essa frase valer alguma coisa: a garantia não está no código da aplicação — está no próprio armazenamento, uma camada abaixo de tudo que o produto executa.

O que isso significa na prática:

• Só dá para acrescentar. Não existe caminho que altere, apague ou esvazie um registro já gravado, e a tentativa é recusada onde o dado mora, não onde o pedido chega.
• Só por uma porta. Gravar passa sempre pelo mesmo caminho controlado; escrever direto não é uma opção que exista, nem para quem tem a credencial mais privilegiada do sistema.

Ou seja, "nem quem administra consegue alterar" não é uma política que alguém pode reverter num arquivo de configuração. Vale enquanto o armazenamento for o que é — e é por isso que a seção sobre o limite da âncora, mais abaixo, fala do único cenário em que essa garantia deixa de bastar.

A cadeia, e por que ela vale mais que a tabela

Cada evento carrega o resumo criptográfico do evento anterior, formando uma corrente por organização que começa num ponto de origem conhecido.

O efeito é o que interessa: remover ou alterar um evento no meio quebra a corrente de um jeito detectável. É o que transforma "confie no banco" em "verifique você mesmo" — e a tela tem um botão para essa verificação, que é o que dá sentido a todo o resto.

A ancoragem diária

Uma vez por dia, de madrugada, o topo da corrente de cada organização é assinado, e essa marca fica gravada de forma imutável. Rodar duas vezes no mesmo dia não duplica nada.

Por que ancorar, se a corrente já encadeia: sem a âncora, alguém com poder suficiente poderia reescrever a corrente inteira de forma consistente — e uma corrente consistente do começo ao fim não denuncia nada. A assinatura periódica congela pontos no tempo: a corrente só é válida se bater com as âncoras já assinadas.

O limite disso, dito com todas as letras

A assinatura é simétrica: a mesma chave assina e verifica, e ela é da própria plataforma.

Isso prova integridade a quem já confia no operador. Não prova, a um terceiro adversarial, que o operador não reescreveu a própria trilha. Provar isso exigiria uma assinatura que qualquer um pudesse conferir sem ter a chave, ou publicar a marca fora daqui — e nenhuma das duas existe hoje.

Dizemos isso porque, num módulo cujo valor é prova, a distinção entre "verificável por quem confia" e "verificável por quem desconfia" é exatamente a que importa saber antes de prometer.

Três cuidados que evitam alarme falso

• Uma âncora por topo. Duas execuções simultâneas da rotina não geram âncora duplicada — a segunda trata o caso como já ancorado.
• O horário é normalizado antes de assinar. Sem isso, o mesmo instante devolvido em outro formato produziria uma "violação" que não existe.
• Chave trocada não vira acusação. Cada âncora guarda a impressão digital — não secreta — da chave que a assinou. Depois de uma troca, âncoras cuja chave não está mais disponível são reportadas como não verificáveis, nunca como violadas.

A terceira é a mais madura das três: distinguir "não consigo verificar" de "foi adulterado" é exatamente o que separa uma trilha útil de uma que grita lobo.

O que fica registrado

Todo evento entra numa de seis categorias: ciclo de vida de um ativo, decisão de entrada em produção, mudança na configuração de avaliação, acesso administrativo, segurança, e uma última para o que não se encaixa. (Corrigido em 12/10/2026: as três primeiras só existem no histórico; hoje se grava acesso administrativo, segurança e outros.)

E todo evento nomeia quem foi: pessoa, agente, chave de API, sistema ou serviço. Poder registrar que o autor foi um agente é essencial num produto onde parte das ações não tem pessoa por trás.

Um caso em que o nome do autor não conta a história inteira: durante um atendimento de quem opera a plataforma, os eventos saem no nome da pessoa em cujo lugar se entrou. A entrada em si fica registrada à parte, nesta mesma trilha, na categoria de acesso administrativo — e é com ela que se explica um evento que aparece no nome de alguém que não estava trabalhando naquela hora. Quem apura por autor deve olhar as duas coisas.

As evidências anexadas ficam num armazenamento privado dedicado, separado do registro textual — o que permite anexar prova sem inchar a trilha.

Por quanto tempo fica guardada

A política de retenção tem três campos:

Como a trilha é somente-acréscimo e a exclusão está bloqueada, o piso funciona como limite para qualquer ferramenta futura de expurgo — ele não apaga nada hoje.

Esta tela não segue o controle de acesso da governança — segue o papel na organização. Ver a configuração de retenção depende de ser membro; alterá-la depende de administrar (corrigido em 12/10/2026: alterá-la depende da permissão "Gerenciar acesso").

Vale dizer isso em voz alta porque a página de acesso mostra um quadro em que membro não alcança nenhuma das cinco ações de governança, e as duas coisas parecem se contradizer. Não se contradizem: aquele quadro fala das cinco ações, e ver um prazo de retenção não é nenhuma delas. São dois sistemas de autorização, e cada tela é governada por um.

O que dá para fazer, e onde