L’audit d’OpenClaw

La plupart des fonctions d’audit promettent plus qu’elles ne tiennent. La passerelle OpenClaw prend le parti inverse : elle tient un journal borné, limité aux métadonnées, dans la base d’état partagée, et elle dit clairement que le résultat est la preuve de ce qui a été enregistré, pas la preuve de ce qui s’est passé. Le journal répond à des questions d’exploitation comme quel agent a tourné, quand, et comment cela s’est terminé, ainsi que quelles actions d’outil une exécution a lancées. Il stocke l’identité, l’ordre, la provenance, l’action, le statut et des codes de résultat normalisés, et ne stocke jamais les invites, le corps des messages, les arguments d’outils, les résultats d’outils, les pièces jointes, les noms de fichiers, les adresses, la sortie des commandes ni le texte brut des erreurs.

Ce que le journal enregistre

• Les enregistrements d’exécution d’agent, qui couvrent les événements de démarrage et de fin, sont actifs par défaut dès que l’audit est activé, tout comme les enregistrements d’action d’outil pour les appels commencés et terminés.
• Les événements de cycle de vie des messages se font sur inscription et sont désactivés par défaut, avec des lignes entrantes écrites quand un message accepté atteint la répartition centrale et des lignes de progression sortantes écrites quand la livraison durable partagée prend la garde de la file et démarre l’envoi vers la plateforme.
• Chaque enregistrement porte un identifiant d’événement stable, une séquence propriétaire monotone, un horodatage de cycle de vie, un acteur, une action, un statut, une version de schéma égale à un et une marque de rédaction indiquant que la ligne ne contient que des métadonnées.
• Les enregistrements vivent dans la base d’état partagée, sont écrits hors du chemin critique de livraison, ne sont jamais renvoyés par les requêtes au delà de 30 jours et sont plafonnés à 100 000 lignes, les lignes expirées étant purgées au démarrage, lors de la maintenance horaire et lors des écritures ultérieures.

L’enregistrement de l’identité d’exécution est désactivé par défaut, y compris sur les installations neuves et les mises à niveau.

Identité, reçus et preuves

À côté du journal d’activité, la passerelle tient un contexte d’identité d’exécution pour les exécutions d’agent nouvellement admises, et elle prend soin de préciser que ce contexte fait autorité uniquement pour les faits d’identité qu’il contient. La collecte exige que le journal d’audit et l’enregistrement de l’identité d’exécution soient tous deux activés, et aucun alias de variable d’environnement ni migration silencieuse n’active la fonction. Chaque tour externe admis reçoit un nouvel identifiant d’exécution opaque, un identifiant de contexte qui désigne son enregistrement de preuve immuable, et un identifiant de corrélation qui reste une corrélation de routage, de session ou de reprise, parfois partagée. Cette distinction sert vraiment, car lorsque cet identifiant de corrélation porte plusieurs exécutions conservées, l’inspection renvoie un résultat ambigu avec au plus 50 identifiants candidats et exige une sélection exacte, la passerelle ne choisissant jamais en silence la première ni la dernière. Les approbations d’opérateur terminales restent dans leur propre table et sont adaptées en reçus de décision plutôt que copiées dans le journal, avec une correspondance fixe entre chaque résultat d’approbation enregistré et un code de raison stable. Un reçu est marqué comme appliqué seulement quand le propriétaire a changé le résultat et que le triplet exact de contexte, d’exécution et de corrélation se valide. Quand la preuve est mince, l’inspecteur renvoie un diagnostic typé au lieu d’inventer des faits, notamment inconnu, non pris en charge, ambigu, non attribué et attribution seule. La persistance elle même reste au mieux possible, car la saturation de la file, une panne de stockage, un délai d’arrêt et les plantages de processus peuvent perdre des preuves, et ils journalisent seulement un avertissement d’exploitation borné au lieu d’interrompre l’exécution.

Le modèle de confidentialité

• Les enregistrements d’activité et de progression des messages ne stockent jamais d’identifiants de plateforme bruts, et les identifiants de compte, de conversation, de message et de cible ne sont exportés que sous forme de pseudonymes à clé locaux à l’installation.
• La clé HMAC est générée à la première utilisation, séparée par domaine selon le type d’identifiant, et elle vit dans la même base d’état que le journal, ce qui en fait une corrélation et non une anonymisation, puisque quiconque peut lire cette base détient aussi la clé.
• Si le matériel de clé est absent ou corrompu alors que des lignes de message sont conservées, la passerelle se ferme par sécurité et abandonne les nouveaux enregistrements de message plutôt que de basculer en silence vers une nouvelle clé, ce qui scinderait la corrélation.

Les enregistrements d’exécution et d’outil conservent une clé de session et un identifiant de session pour la corrélation, et les clés de session canoniques peuvent elles mêmes contenir des identifiants de compte ou de correspondant, ce qui explique précisément pourquoi les enregistrements de message omettent les deux. Lisez cette page à côté de le modèle de sécurité d’OpenClaw pour le modèle d’ensemble, et à côté de l’appairage des appareils pour comprendre pourquoi un appareil appairé ajoute une assurance d’appareil sans jamais devenir une personne.

Annoncer les limites franchement

La partie la plus utile de cette page est celle qui dit ce que le journal ne peut pas faire. L’absence d’une ligne ne prouve rien : les rejets entrants avant admission, les envois par des chemins locaux aux extensions ou directs qui contournent la livraison durable partagée, une enveloppe d’admission perdue et un travail en file perdu lors d’un plantage peuvent tous ne laisser aucune trace. Les écritures passent par une file asynchrone bornée, donc la saturation, une panne de stockage ou un délai d’arrêt borné peuvent abandonner des enregistrements et journaliser un seul avertissement d’exploitation. Les envois sortants rendus ambigus par un plantage sont enregistrés comme inconnus plutôt que dotés d’un résultat inventé. La page dit ensuite tout haut ce que d’autres taisent, à savoir qu’il s’agit d’une surface de débogage et de revue d’exploitation et non d’une archive de conformité sans perte, et qu’un système externe est la réponse quand vous en avez besoin d’une. La même franchise explique pourquoi la portée de lecture est discutée ouvertement, puisque tout client disposant de la portée de lecture opérateur dans le même domaine d’opérateurs peut recevoir cette catégorie d’identité conservée, et que des domaines de confiance séparés sont le remède quand des opérateurs ne doivent pas la partager. Lisez les portées opérateur à côté de cette page, et le bac à sable si vous réfléchissez plus largement à l’isolement.

Sur Diali

Sur Diali, chaque client fait tourner son propre assistant et l’état vit sur un volume persistant, si bien qu’un journal écrit aujourd’hui sera encore là la semaine prochaine ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). La configuration du runtime est générée depuis le tableau de bord et remplacée à chaque version. Voir OpenClaw hébergé sur Diali pour ce que nous hébergeons, et Les tarifs Diali pour ce que cela coûte.

• Métadonnées seules : ni invites, ni corps de message, ni arguments d’outils.
• L’audit des messages se fait sur inscription, celui des exécutions par défaut.
• L’absence d’une ligne ne prouve rien, et la page le dit noir sur blanc.