L’historique d’audit d’OpenClaw

Quand quelque chose a mal tourné mardi dernier, un opérateur veut savoir quel agent a tourné, quand, comment l’exécution s’est terminée et quelles actions d’outils elle a exécutées, sans que le registre devienne une seconde copie de chaque conversation. La passerelle d’OpenClaw tient exactement cela : un registre d’audit borné et limité aux métadonnées dans la base d’état partagée, plus, quand l’audit des messages est activé, si un message entrant accepté a atteint la distribution et si un message sortant a atteint un état de livraison terminal. Voici ce que porte un enregistrement, ce qu’il ne stocke jamais, la couche d’identité facultative et ses états de preuve, les reçus d’approbation, les modes de cycle de vie des messages, le modèle de confidentialité, et les limites sur lesquelles la documentation insiste.

Ce qui est enregistré

• Le registre stocke l’identité, l’ordre, la provenance, l’action, l’état et des codes de résultat normalisés ; il ne stocke jamais les prompts, les corps de messages, les arguments d’outils, les résultats d’outils, les pièces jointes, les noms de fichiers, les URL, les sorties de commandes ni le texte brut des erreurs.
• Deux familles d’enregistrements sont activées par défaut, exécution d’agent démarrée et terminée et action d’outil démarrée et terminée ; la famille des messages, entrant traité et sortant mis en file, démarré côté plateforme et terminé, est désactivée par défaut. Chaque enregistrement porte un identifiant d’événement stable, une séquence monotone du propriétaire, un horodatage de cycle de vie, un acteur, une action, un état, une version de schéma et un marqueur de caviardage limité aux métadonnées.
• L’audit des messages a trois modes, désactivé, direct pour les seules conversations directes, et tout pour les messages directs, de groupe et de canal ; les lignes entrantes sont écrites quand un message accepté atteint la distribution centrale, la progression sortante quand la livraison durable en prend la garde et démarre la livraison côté plateforme, et les lignes terminales enregistrent envoyé, supprimé, échoué ou un inconnu explicite pour un envoi ambigu après un plantage.
• Le mode direct est une frontière de confidentialité : un message n’est classé direct que quand des faits de destination le prouvent, des signaux plus faibles ne peuvent le classer que comme groupe, et tout ce qui n’est pas prouvé est inconnu et non enregistré en mode direct, si bien que les canaux qui ne déclarent pas les types de conversation y enregistrent moins de lignes qu’en mode tout.

L’absence d’une ligne ne prouve rien.

Identité d’exécution et reçus

À côté du registre, la passerelle peut tenir un contexte d’identité d’exécution pour les exécutions nouvellement admises, désactivé par défaut sur les installations neuves et les mises à niveau et activé explicitement par un réglage de journalisation plus un redémarrage ; il fait autorité pour les faits d’identité qu’il contient mais ne rend pas le registre sans perte et ne transforme pas les enregistrements d’audit en preuve d’autorisation. Chaque tour externe admis reçoit un nouvel identifiant d’exécution opaque et un identifiant de contexte pour son enregistrement de preuve immuable, tandis que l’identifiant d’exécution de session reste une corrélation éventuellement partagée, si bien que l’inspecteur ne choisit jamais en silence la première ou la dernière exécution : une exécution de session avec plusieurs exécutions retenues renvoie ambigu avec au plus cinquante candidats. L’inspection rapporte le domaine de confiance, l’invocateur et l’entrée, le principal, la définition et l’instance d’exécution de l’agent, le sujet représenté et le commanditaire, les autorisations et les preuves d’assurance, et la lignée quand elle existe, et elle répond par des états typés plutôt que par des faits inventés : inconnu, non pris en charge, ambigu, non attribué quand aucun principal invocateur n’existe, et attribution seule quand l’attribution existe mais n’a jamais été évaluée pour l’autorisation. Les approbations terminales d’opérateur restent dans leur propre table et sont adaptées en reçus de décision avec des codes de raison stables, autorisé une fois ou toujours, refusé par le relecteur, expiré, annulé par interruption de l’exécution ou redémarrage de la passerelle, aucune route de livraison, verdict malformé, stockage corrompu, et liaisons d’exécution manquantes, malformées ou discordantes ; seul un triplet exact de contexte, d’exécution et d’exécution de session projette une approbation comme appliquée, et le reçu n’inclut jamais la commande, les arguments, le chemin, l’environnement ni l’appareil du relecteur.

Confidentialité et limites

• Les enregistrements de messages ne stockent jamais d’identifiants bruts de plateforme : les identifiants de compte, de conversation, de message et de cible ne sont exportés que comme pseudonymes à clé locaux à l’installation, dont la clé HMAC est générée au premier usage, séparée par domaine selon le genre d’identifiant, et gardée dans la même base. La documentation appelle cela une corrélation, pas une anonymisation, puisque quiconque peut lire la base détient aussi la clé, et si la clé manque ou est corrompue alors que des lignes sont retenues, la passerelle échoue fermée et abandonne les nouveaux enregistrements de messages plutôt que de tourner la clé et de rompre la corrélation.
• Le registre est au mieux et volontairement borné : les écritures passent par une file asynchrone détenue par le processus qui peut abandonner des enregistrements en cas de saturation, de défaillance de stockage ou de délai d’arrêt borné avec un seul avertissement opérationnel, les envois ambigus après plantage sont enregistrés comme inconnus, et les abandons avant admission ou les envois par des chemins locaux aux extensions peuvent ne laisser aucune ligne. Ce n’est pas une archive de conformité sans perte ; pour cela, la documentation renvoie à un système externe alimenté par OpenTelemetry.
• Les enregistrements vivent dans la base d’état partagée hors du chemin chaud de livraison, les requêtes ne renvoient jamais de lignes de plus de trente jours, le registre est plafonné à cent mille lignes, les contextes d’identité à cent mille, la progression sortante à deux cent mille et les faits de décision génériques à deux cent cinquante mille, avec une purge limitée à 1 024 lignes par transaction et une maintenance qui continue même quand la collecte est désactivée.

La boucle d’agent d’OpenClaw est l’exécution dont le début, la fin et les événements d’outils atterrissent ici, et Les approbations d’exécution d’OpenClaw les décisions natives de leur propriétaire que l’inspecteur adapte en reçus.

Qui peut le lire

Les appels d’activité et d’inspection exigent l’accès en lecture d’opérateur, et chaque client doté de cette portée dans le même domaine d’opérateur de la passerelle peut recevoir la catégorie d’identité retenue ; la documentation dit explicitement que cette portée couvre déjà les journaux et les lectures de sessions et n’est pas une frontière d’isolation entre locataires hostiles, si bien que des opérateurs qui ne doivent pas partager ces données de diagnostic ont besoin de domaines de confiance de passerelle séparés. OpenClaw à plusieurs utilisateurs couvre ces frontières, et OpenClaw doctor la commande qui migre au démarrage un registre plus ancien limité aux exécutions et aux outils.

Sur Diali

Sur Diali, le registre se trouve dans la base d’état de l’assistant sur son volume avec les valeurs amont par défaut, exécutions et actions d’outils activées, cycle de vie des messages désactivé, enregistrement d’identité désactivé, et rien de son contenu ne quitte l’instance. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière qui l’entoure.

• Identité, ordre, codes de résultat ; jamais de contenu.
• Les pseudonymes corrèlent ; ils n’anonymisent pas.
• Trente jours, des lignes bornées, la preuve de ce qui a été enregistré.