Un journal de base de données modifiable n'est pas une preuve — n'importe qui disposant d'un accès en écriture peut le modifier, et la table paraît tout aussi fiable après la modification qu'avant. Une piste d'audit immuable est différente : un registre chaîné par hash et vérifiable de façon indépendante, où chaque événement est lié au précédent, de sorte que la falsification devient détectable plutôt que simplement dissuadée. Voici ce que cela signifie techniquement, et comment cela s'applique spécifiquement aux agents IA.
Une piste d'audit immuable pour les agents IA est un journal d'événements en ajout seul, chaîné par hash, dans lequel le hash cryptographique de chaque entrée intègre le hash de l'entrée précédente, de sorte que toute modification, suppression ou insertion, n'importe où dans la séquence, brise la chaîne et devient détectable de façon indépendante et mathématique. Ce n'est pas une base de données simplement protégée des modifications par une politique — c'est une structure où la falsification laisse une preuve inévitable d'elle-même.
Tout système en production dispose déjà de journaux. Journaux d'application, traces de requêtes, une table Postgres avec une colonne occurred_at et une clé étrangère vers l'agent qui l'a déclenché. Le problème n'est pas que ces éléments n'existent pas — c'est qu'ils ne prouvent rien sur leur propre intégrité.
Rien de tout cela ne nécessite d'intention malveillante — un accès opérationnel ordinaire à la base de données suffit. Un journal modifiable est une affirmation : voici ce qui s'est passé, faites-nous confiance. Pour un agent autonome qui effectue des actions réelles — envoyer des e-mails, déplacer de l'argent, toucher des données clients — une affirmation ne suffit pas lorsque quelqu'un finit par demander « qu'est-ce que cet agent a réellement fait, et comment savons-nous que l'enregistrement est exact ? ».
Le mécanisme est plus simple qu'il n'y paraît. Chaque événement du registre possède un content_hash — un hash cryptographique du contenu de cet événement — calculé à la fois à partir des propres données de l'événement et du previous_event_hash qui pointe vers l'entrée immédiatement précédente. Cela signifie que le hash de chaque événement dépend de tout l'historique de la chaîne jusqu'à ce point, pas seulement de l'événement lui-même.
Les nouveaux événements sont ajoutés à la fin de la chaîne. Il n'existe aucune opération de mise à jour ou de suppression dans la conception — le registre ne fait que croître.
Le hash de l'événement N intègre le hash de l'événement N−1. Modifier quoi que ce soit sur l'événement N−1, même après coup, produit un hash différent de celui que l'événement N avait enregistré comme prédécesseur.
Une passe de vérification parcourt chaque entrée, recalcule le hash attendu à partir du contenu et du prédécesseur enregistré, et confirme qu'il correspond à ce qui est stocké. Une seule incohérence, n'importe où, brise toute la chaîne à partir de ce point.
C'est la même idée structurelle que celle des blockchains et des historiques de commits Git — des références chaînées et adressées par contenu — appliquée à un journal d'audit plutôt qu'à une monnaie ou à une base de code.
VeriSwarm Vault est un registre en ajout seul, chaîné par hash, disponible dans l'offre Max. Chaque événement traité via la suite — décisions de confiance, résultats de scan Guard, vérifications Passport, changements de cycle de vie des agents — y est écrit automatiquement, sans qu'un appel de journalisation séparé soit nécessaire. Chaque entrée du registre enregistre :
event_id, actor_type / actor_id, subject_type / subject_idevent_type, source, occurred_at, ingested_atcontent_hash — le hash cryptographique de cet événementprevious_event_hash — le hash de l'entrée immédiatement précédenteL'intégrité peut être vérifiée à la demande à GET /v1/suite/vault/verify, qui parcourt la chaîne et indique si elle est intacte, ainsi que le nombre d'entrées vérifiées. Une vérification échouée est traitée comme un incident de sécurité, pas comme un problème de qualité des données, précisément parce qu'une chaîne brisée signifie que le registre ne prouve plus ce qu'il prétend prouver. Les données du registre peuvent également être exportées (JSON ou CSV, filtrables par type d'événement, acteur ou agent) avec une somme de contrôle pour une vérification hors ligne. Le détail complet au niveau des champs se trouve dans la documentation de Vault.
L'application concrète la plus claire aujourd'hui est l'EU AI Act. L'article 12 exige des systèmes d'IA à haut risque qu'ils enregistrent automatiquement les événements sur toute la durée de vie du système, sous une forme capable d'identifier des situations à risque et de survivre à la fenêtre de rétention de six mois de l'article 26. Un registre chaîné par hash est ce qui transforme « nous avons des journaux » en une preuve sur laquelle un régulateur ou un auditeur peut réellement s'appuyer. Cette exigence, et la manière exacte dont Vault y répond, est traitée dans Journalisation de l'article 12 de l'EU AI Act pour les agents IA. Une piste d'audit immuable est le mécanisme général ; l'article 12 est une raison spécifique, actuellement applicable, d'en avoir une.
L'immuabilité ne signifie pas que la couche de stockage empêche physiquement les écritures — la plupart des bases de données peuvent techniquement être modifiées par quelqu'un disposant d'un accès suffisant. Cela signifie que la falsification est détectable. Dans un registre chaîné par hash, le hash de contenu de chaque événement intègre le hash de l'événement précédent, de sorte que chaque entrée est cryptographiquement liée à celle qui la précède. Modifier, supprimer ou insérer un enregistrement n'importe où dans la chaîne fait que tous les hashes calculés après ce point cessent de correspondre — la falsification apparaît immédiatement lors de la vérification, au lieu de rester invisible.
Un journal normal — journaux d'application, une table d'audit Postgres, des entrées CloudWatch — enregistre qu'un événement s'est produit. Il ne prouve pas que l'enregistrement n'a pas été modifié depuis. Quiconque dispose d'un accès en écriture à cette table (un ingénieur, un identifiant compromis, un script de nettoyage automatisé) peut modifier ou supprimer une ligne, et la table paraît tout aussi fiable qu'avant. Un registre chaîné par hash comble cet écart : l'intégrité n'est pas affirmée, elle est mathématiquement vérifiable via la vérification de la chaîne.
La vérification parcourt le registre depuis le premier événement, en recalculant le hash attendu de chaque entrée à partir de son contenu et du hash enregistré de son prédécesseur, puis en confirmant qu'il correspond à ce qui est stocké. VeriSwarm Vault expose cela via GET /v1/suite/vault/verify, qui renvoie ok: true ou false accompagné d'un nombre d'entrées vérifiées. Un résultat false signifie qu'un enregistrement a été modifié, supprimé ou inséré en dehors du fonctionnement normal — la recommandation de VeriSwarm est de traiter cela comme un incident de sécurité, pas comme un bug de qualité des données.
Dans VeriSwarm Vault, chaque événement enregistré via la suite — décisions de confiance (allow/review/deny), résultats de scan de sécurité Guard, vérifications d'identité Passport, changements de cycle de vie des agents (kill switch, octrois de délégation) — est écrit automatiquement dès que Vault est activé. Chaque entrée capture l'acteur, le sujet, le type d'événement, l'horodatage, la charge utile et les hashes de chaînage. Aucun appel de journalisation séparé n'est requis ; c'est un effet secondaire du fonctionnement normal de l'agent sur la plateforme.
La réglementation est une raison d'en vouloir une — l'exigence de tenue de registres de l'article 12 de l'EU AI Act en est un exemple direct — mais le besoin sous-jacent est plus large. Tout agent doté d'une autonomie significative (accès à des outils, actions orientées client, traitement financier ou de données personnelles) crée un moment où quelqu'un demandera « qu'est-ce que cet agent a réellement fait, et pouvons-nous faire confiance à l'enregistrement ? ». Un journal modifiable répond à cela par une affirmation. Un journal immuable, vérifiable de façon indépendante, y répond par une preuve.
Non — Vault, y compris le registre chaîné par hash et le point de terminaison de vérification de chaîne, est une fonctionnalité de l'offre Max. L'offre gratuite de Gate couvre le scoring de confiance et l'ingestion d'événements, mais le registre d'audit immuable lui-même est une capacité payante. Consultez /pricing pour les détails actuels des offres.
Vault est une fonctionnalité de l'offre Max — le registre chaîné par hash, la vérification de chaîne et les exports ne sont pas dans l'offre gratuite. Lisez la référence technique complète, ou découvrez comment cela s'applique à une réglementation spécifique.