Un log di database mutabile non è una prova: chiunque abbia accesso in scrittura può modificarlo, e la tabella appare altrettanto affidabile dopo la modifica quanto prima. Una pista di controllo immutabile è diversa: un registro concatenato tramite hash e verificabile in modo indipendente, in cui ogni evento è collegato al precedente, così che la manomissione diventi rilevabile invece che semplicemente scoraggiata. Ecco cosa significa tecnicamente, e come si applica in modo specifico agli agenti IA.
Una pista di controllo immutabile per gli agenti IA è un registro di eventi di sola aggiunta, concatenato tramite hash, in cui l'hash crittografico di ogni voce incorpora l'hash della voce precedente, in modo che qualsiasi modifica, cancellazione o inserimento in qualsiasi punto della sequenza spezzi la catena e sia rilevabile in modo indipendente e matematico. Non è un database semplicemente protetto dalle modifiche per policy — è una struttura in cui la manomissione lascia inevitabilmente traccia di sé stessa.
Ogni sistema in produzione ha già dei log. Log applicativi, tracce delle richieste, una tabella Postgres con una colonna occurred_at e una chiave esterna verso l'agente che lo ha attivato. Il problema non è che questi elementi non esistano — è che non provano nulla riguardo alla propria integrità.
Niente di tutto ciò richiede intenti malevoli — è sufficiente un accesso operativo ordinario al database. Un log mutabile è un'affermazione: ecco cosa è successo, fidati di noi. Per un agente autonomo che compie azioni reali — inviare e-mail, spostare denaro, gestire dati dei clienti — un'affermazione non basta quando qualcuno prima o poi chiede «cosa ha effettivamente fatto questo agente, e come sappiamo che il registro è accurato?».
Il meccanismo è più semplice di quanto sembri. Ogni evento nel registro ha un content_hash — un hash crittografico del contenuto di quell'evento — calcolato sia a partire dai dati propri dell'evento sia dal previous_event_hash che punta alla voce immediatamente precedente. Questo significa che l'hash di ogni evento dipende dall'intera storia della catena fino a quel punto, non solo dall'evento stesso.
I nuovi eventi vengono aggiunti alla fine della catena. Nel design non esiste alcuna operazione di aggiornamento o eliminazione — il registro cresce soltanto.
L'hash dell'evento N incorpora l'hash dell'evento N−1. Modificare qualsiasi cosa relativa all'evento N−1, anche a posteriori, produce un hash diverso da quello che l'evento N aveva registrato come predecessore.
Un passaggio di verifica scorre ogni voce, ricalcola l'hash atteso a partire dal contenuto e dal predecessore registrato, e conferma che corrisponda a quanto memorizzato. Una sola discrepanza in qualsiasi punto spezza l'intera catena da quel punto in poi.
È la stessa idea strutturale alla base delle blockchain e delle cronologie dei commit Git — riferimenti concatenati e indirizzati per contenuto — applicata a un registro di audit anziché a una valuta o a una codebase.
VeriSwarm Vault è un registro di sola aggiunta, concatenato tramite hash, disponibile nel piano Max. Ogni evento elaborato attraverso la suite — decisioni di trust, risultati delle scansioni Guard, verifiche Passport, cambiamenti del ciclo di vita dell'agente — vi viene scritto automaticamente, senza bisogno di una chiamata di registrazione separata. Ogni voce del registro registra:
event_id, actor_type / actor_id, subject_type / subject_idevent_type, source, occurred_at, ingested_atcontent_hash — l'hash crittografico di questo eventoprevious_event_hash — l'hash della voce immediatamente precedenteL'integrità è verificabile su richiesta all'endpoint GET /v1/suite/vault/verify, che percorre la catena e restituisce se è intatta insieme a un conteggio delle voci verificate. Una verifica fallita viene trattata come un incidente di sicurezza, non come un problema di qualità dei dati, proprio perché una catena spezzata significa che il registro non dimostra più ciò che afferma di dimostrare. I dati del registro possono anche essere esportati (JSON o CSV, filtrabili per tipo di evento, attore o agente) con un checksum per la verifica offline. Il dettaglio completo a livello di campo è disponibile nella documentazione di Vault.
L'applicazione concreta più chiara al momento è l'EU AI Act. L'articolo 12 richiede che i sistemi di IA ad alto rischio registrino automaticamente gli eventi lungo tutta la loro vita utile, in una forma in grado di identificare situazioni di rischio e di sopravvivere alla finestra di conservazione di sei mesi prevista dall'articolo 26. Un registro concatenato tramite hash è ciò che trasforma «abbiamo dei log» in una prova su cui un regolatore o un revisore può davvero fare affidamento. Questo requisito, e il modo esatto in cui Vault vi corrisponde, è trattato in Registrazione ai sensi dell'articolo 12 dell'EU AI Act per gli agenti IA. Una pista di controllo immutabile è il meccanismo generale; l'articolo 12 è una ragione specifica, attualmente applicabile, per averne una.
L'immutabilità non significa che il livello di storage impedisca fisicamente le scritture — la maggior parte dei database può tecnicamente essere modificata da chiunque disponga di accesso sufficiente. Significa che la manomissione è rilevabile. In un registro concatenato tramite hash, l'hash del contenuto di ogni evento incorpora l'hash dell'evento precedente, così che ogni voce sia crittograficamente collegata alla precedente. Modificare, eliminare o inserire un record in qualsiasi punto della catena fa sì che tutti gli hash calcolati dopo quel punto smettano di corrispondere — la manomissione emerge immediatamente durante la verifica, invece di restare invisibile.
Un log normale — log applicativi, una tabella di audit Postgres, voci di CloudWatch — registra che un evento è accaduto. Non dimostra che il record non sia stato alterato da allora. Chiunque abbia accesso in scrittura a quella tabella (un ingegnere, una credenziale compromessa, uno script di pulizia automatizzato) può modificare o eliminare una riga, e la tabella appare esattamente altrettanto affidabile di prima. Un registro concatenato tramite hash colma questa lacuna: l'integrità non viene affermata, è matematicamente verificabile tramite la verifica della catena.
La verifica scorre il registro dal primo evento in avanti, ricalcolando l'hash atteso di ogni voce a partire dal suo contenuto e dall'hash registrato del predecessore, confermando che corrisponda a quanto memorizzato. VeriSwarm Vault espone questo tramite GET /v1/suite/vault/verify, che restituisce ok: true o false insieme a un conteggio delle voci verificate. Un risultato false indica che un record è stato modificato, eliminato o inserito al di fuori del normale funzionamento — l'indicazione di VeriSwarm è di trattarlo come un incidente di sicurezza, non come un bug di qualità dei dati.
In VeriSwarm Vault, ogni evento registrato tramite la suite — decisioni di trust (allow/review/deny), risultati delle scansioni di sicurezza Guard, verifiche di identità Passport, cambiamenti del ciclo di vita dell'agente (kill switch, concessioni di delega) — viene scritto automaticamente una volta che Vault è attivato. Ogni voce cattura attore, soggetto, tipo di evento, timestamp, payload e gli hash di concatenamento. Non è richiesta alcuna chiamata di registrazione separata; è un effetto collaterale del normale funzionamento dell'agente attraverso la piattaforma.
La regolamentazione è una ragione per volerne una — l'obbligo di tenuta dei registri dell'articolo 12 dell'EU AI Act ne è un esempio diretto — ma l'esigenza sottostante è più ampia. Qualsiasi agente dotato di autonomia significativa (accesso a strumenti, azioni rivolte ai clienti, gestione di dati finanziari o PII) crea un momento in cui qualcuno chiederà «cosa ha effettivamente fatto questo agente, e possiamo fidarci del registro?». Un log mutabile risponde a questo con un'affermazione. Uno immutabile e verificabile in modo indipendente risponde con una prova.
No — Vault, compresi il registro concatenato tramite hash e l'endpoint di verifica della catena, è una funzionalità del piano Max. Il piano gratuito di Gate copre il trust scoring e l'ingestione di eventi, ma il registro di audit immutabile in sé è una funzionalità a pagamento. Consulta /pricing per i dettagli attuali dei piani.
Vault è una funzionalità del piano Max — il registro concatenato tramite hash, la verifica della catena e le esportazioni non sono nel piano gratuito. Leggi il riferimento tecnico completo, oppure scopri come si applica a una regolamentazione specifica.