Um log de banco de dados mutável não é evidência — qualquer pessoa com acesso de escrita pode alterá-lo, e a tabela parece tão confiável depois da edição quanto antes. Uma trilha de auditoria imutável é diferente: um ledger encadeado por hash e verificável de forma independente, em que cada evento se conecta ao anterior, de modo que a adulteração se torne detectável em vez de apenas desencorajada. Eis o que isso significa tecnicamente, e como se aplica especificamente a agentes de IA.
Uma trilha de auditoria imutável para agentes de IA é um log de eventos somente-adição, encadeado por hash, no qual o hash criptográfico de cada entrada incorpora o hash da entrada anterior, de modo que qualquer modificação, exclusão ou inserção em qualquer ponto da sequência quebra a cadeia e se torna detectável de forma independente e matemática. Não é um banco de dados meramente protegido por política contra edições — é uma estrutura em que a adulteração deixa evidências inevitáveis de si mesma.
Todo sistema em produção já tem logs. Logs de aplicação, traces de requisições, uma tabela do Postgres com uma coluna occurred_at e uma chave estrangeira para o agente que o disparou. O problema não é que essas coisas não existam — é que elas não provam nada sobre a própria integridade.
Nada disso exige intenção maliciosa — o acesso operacional comum ao banco de dados já é suficiente. Um log mutável é uma afirmação: foi isso que aconteceu, confie em nós. Para um agente autônomo que realiza ações reais — enviar e-mails, movimentar dinheiro, tocar em dados de clientes — uma afirmação não basta quando, eventualmente, alguém pergunta “o que esse agente realmente fez, e como sabemos que o registro é preciso?”.
O mecanismo é mais simples do que parece. Cada evento no ledger tem um content_hash — um hash criptográfico do conteúdo desse evento — calculado tanto a partir dos próprios dados do evento quanto do previous_event_hash que aponta para a entrada imediatamente anterior. Isso significa que o hash de cada evento depende de todo o histórico da cadeia até aquele ponto, não apenas do próprio evento.
Novos eventos são adicionados ao final da cadeia. Não existe operação de atualização ou exclusão no design — o ledger apenas cresce.
O hash do evento N incorpora o hash do evento N−1. Alterar qualquer coisa no evento N−1, mesmo depois do fato, produz um hash diferente daquele que o evento N registrou como seu predecessor.
Uma passagem de verificação percorre cada entrada, recalcula o hash esperado a partir do conteúdo e do predecessor registrado, e confirma que ele corresponde ao que está armazenado. Uma única discrepância em qualquer ponto quebra toda a cadeia a partir daquele ponto.
É a mesma ideia estrutural por trás das blockchains e dos históricos de commits do Git — referências encadeadas e endereçadas por conteúdo — aplicada a um log de auditoria em vez de uma moeda ou uma base de código.
VeriSwarm Vault é um ledger somente-adição, encadeado por hash, disponível no plano Max. Cada evento processado pela suíte — decisões de confiança, achados de scan do Guard, verificações do Passport, mudanças no ciclo de vida do agente — é gravado nele automaticamente, sem exigir uma chamada de registro separada. Cada entrada do ledger registra:
event_id, actor_type / actor_id, subject_type / subject_idevent_type, source, occurred_at, ingested_atcontent_hash — o hash criptográfico deste eventoprevious_event_hash — o hash da entrada imediatamente anteriorA integridade pode ser verificada sob demanda em GET /v1/suite/vault/verify, que percorre a cadeia e retorna se ela está intacta, junto com uma contagem de entradas verificadas. Uma verificação com falha é tratada como um incidente de segurança, não como um problema de qualidade de dados, justamente porque uma cadeia quebrada significa que o ledger não prova mais o que afirma provar. Os dados do ledger também podem ser exportados (JSON ou CSV, filtráveis por tipo de evento, ator ou agente) com um checksum para verificação offline. O detalhamento completo em nível de campo está na documentação do Vault.
A aplicação concreta mais clara neste momento é o EU AI Act. O Artigo 12 exige que sistemas de IA de alto risco registrem eventos automaticamente ao longo de sua vida útil, de uma forma capaz de identificar situações de risco e sobreviver à janela de retenção de seis meses do Artigo 26. Um ledger encadeado por hash é o que transforma “temos logs” em evidência em que um regulador ou auditor pode realmente confiar. Esse requisito, e exatamente como o Vault se alinha a ele, é abordado em Registro do Artigo 12 do EU AI Act para agentes de IA. Uma trilha de auditoria imutável é o mecanismo geral; o Artigo 12 é um motivo específico, atualmente aplicável, para ter uma.
Imutabilidade não significa que a camada de armazenamento impeça fisicamente as gravações — a maioria dos bancos de dados pode, tecnicamente, ser editada por alguém com acesso suficiente. Significa que a adulteração é detectável. Em um ledger encadeado por hash, o hash de conteúdo de cada evento incorpora o hash do evento anterior, de modo que cada entrada é criptograficamente vinculada à sua predecessora. Alterar, excluir ou inserir um registro em qualquer ponto da cadeia faz com que todos os hashes calculados a partir daquele ponto deixem de corresponder — a adulteração aparece imediatamente sob verificação, em vez de permanecer invisível.
Um log normal — logs de aplicação, uma tabela de auditoria do Postgres, entradas do CloudWatch — registra que um evento aconteceu. Ele não prova que o registro não foi alterado desde então. Qualquer pessoa com acesso de escrita a essa tabela (um engenheiro, uma credencial comprometida, um script de limpeza automatizado) pode editar ou excluir uma linha, e a tabela parece exatamente tão confiável quanto antes. Um ledger encadeado por hash fecha essa lacuna: a integridade não é afirmada, é matematicamente verificável por meio da verificação de cadeia.
A verificação percorre o ledger a partir do primeiro evento, recalculando o hash esperado de cada entrada a partir de seu conteúdo e do hash registrado de sua predecessora, e confirmando se corresponde ao que está armazenado. O VeriSwarm Vault expõe isso como GET /v1/suite/vault/verify, que retorna ok: true ou false junto com uma contagem de entradas verificadas. Um resultado false significa que um registro foi modificado, excluído ou inserido fora da operação normal — a orientação da VeriSwarm é tratar isso como um incidente de segurança, não como um bug de qualidade de dados.
No VeriSwarm Vault, todo evento registrado pela suíte — decisões de confiança (allow/review/deny), achados de scan de segurança do Guard, verificações de identidade do Passport, mudanças no ciclo de vida do agente (kill switch, concessões de delegação) — é gravado automaticamente assim que o Vault é ativado. Cada entrada captura ator, sujeito, tipo de evento, timestamp, payload e os hashes de encadeamento. Nenhuma chamada de registro separada é necessária; é um efeito colateral do funcionamento normal do agente pela plataforma.
A regulamentação é um motivo para querer uma — a exigência de manutenção de registros do Artigo 12 do EU AI Act é um exemplo direto —, mas a necessidade subjacente é mais ampla. Qualquer agente com autonomia significativa (acesso a ferramentas, ações voltadas para o cliente, manuseio de dados financeiros ou de PII) cria um momento em que alguém perguntará “o que esse agente realmente fez, e podemos confiar no registro?”. Um log mutável responde a isso com uma afirmação. Um log imutável e verificável de forma independente responde com uma prova.
Não — o Vault, incluindo o ledger encadeado por hash e o endpoint de verificação de cadeia, é um recurso do plano Max. O nível gratuito do Gate cobre trust scoring e ingestão de eventos, mas o próprio ledger de auditoria imutável é um recurso pago. Veja /pricing para os detalhes atuais do plano.
O Vault é um recurso do plano Max — o ledger encadeado por hash, a verificação de cadeia e as exportações não estão no nível gratuito. Leia a referência técnica completa, ou veja como isso se relaciona com uma regulamentação específica.