Des pistes d'audit inviolables pour les agents IA qui prouvent leurs actions

Les agents IA n'ont pas besoin d'une meilleure transcription de conversation. Ils ont besoin de preuves produites au moment où une action quitte la machine.

Cette distinction détermine si vous pouvez répondre à une question d'incident comme « Cet agent a-t-il déployé en production, avec quel processus, sous quelle approbation, et qu'a renvoyé le système distant ? » Un récapitulatif conversationnel ne peut pas porter ce niveau de preuve. Un journal inviolable peut le faire, à condition de préciser exactement ce qu'il prouve et ce qu'il ne prouve pas.

J'ai vu des équipes traiter la sortie du terminal d'un agent comme un relevé d'audit parce qu'il était facile de la sauvegarder. C'est prendre le problème à l'envers. La sortie du terminal est utile pendant le débogage, mais constitue une preuve médiocre : le processus qui l'a écrite a pu échouer avant l'effet de bord, masquer l'argument important ou être entièrement remplacé.

La réponse la plus sobre est la bonne.

Une passerelle d'actions doit créer l'enregistrement pendant l'exécution d'un appel HTTP ou d'une commande SSH, sceller cet enregistrement dans un journal ordonné et rendre visibles les modifications ultérieures. L'enquêteur dispose alors d'un artefact qui ne dépend ni de la mémoire de l'agent, ni de son invite, ni de sa volonté d'avouer.

Une transcription et une piste d'audit ne répondent pas aux mêmes questions

Une transcription indique ce que l'agent affirme avoir tenté. Une piste d'audit indique ce que la limite d'action a accepté et renvoyé. Confondre ces deux artefacts crée une faille précisément au moment où le travail autonome devient risqué.

Prenons un agent qui affirme avoir exécuté terraform apply après avoir ouvert une session SSH. Ce texte ne prouve pas que la connexion SSH a réussi, que la commande a atteint l'hôte prévu ou que l'hôte l'a acceptée. Il peut s'agir d'une commande prévue et affichée avant l'exécution, d'une commande qui a échoué dès la première ligne ou d'un texte modifié ultérieurement par un intermédiaire.

Un enregistrement d'action utile rassemble des faits provenant de plusieurs couches :

• l'exécution de l'agent qui a demandé l'action
• l'identité du processus local qui a reçu l'autorisation
• le canal et la destination, par exemple l'hôte SSH ou l'origine HTTP
• un résumé normalisé de l'action et le statut du résultat
• la position dans le journal et le hachage de l'entrée précédente

L'enregistrement ne doit pas devenir une copie exhaustive de la surveillance. Écrire chaque corps de requête et chaque corps de réponse complet dans un journal permanent est souvent imprudent. Une API de déploiement peut renvoyer un jeton d'accès. Une commande SSH peut contenir un secret temporaire dans une affectation d'environnement. Capturez les faits nécessaires pour reconstituer la décision de sécurité, puis imposez des limites strictes à la conservation des données sensibles.

La norme NIST SP 800-92 considère la gestion des journaux comme un processus couvrant leur génération, leur stockage, leur analyse et leur suppression, et non comme un dossier dans lequel les applications déversent du texte. Cette recommandation ancienne s'applique étonnamment bien aux agents : la génération doit avoir lieu au niveau de l'exécuteur, le stockage doit survivre à l'incident et l'analyse ne doit pas exiger de faire confiance à l'acteur examiné.

C'est à la limite d'action que la vérité devient plus précise. C'est une bonne chose.

Si un agent ne reçoit jamais l'identifiant et demande plutôt à une passerelle locale d'effectuer l'appel, la passerelle peut journaliser la requête qu'elle a réellement envoyée. L'agent peut toujours être compromis. Depuis son propre contexte, il ne peut pas réécrire discrètement l'historique des actions terminées par la passerelle.

Inviolable ne signifie pas immuable

« Inviolable » signifie qu'un vérificateur peut détecter certaines modifications. « Immuable » signifie que personne ne peut modifier ou supprimer les données. Ce sont deux promesses différentes, que les fournisseurs confondent régulièrement parce que « immuable » semble plus facile à acheter.

Une chaîne de hachage fait dépendre chaque entrée de l'entrée précédente. Une entrée simplifiée pourrait ressembler à ceci :

record_1042 = {
  sequence: 1042,
  run_id: "run_7f3c",
  time: "2026-03-18T14:22:09Z",
  action: "ssh.exec",
  destination: "deploy@release-host",
  result: "exit 0",
  previous_hash: "a4c1...",
  hash: "8d72..."
}

L'implémentation sérialise les champs de manière déterministe, calcule un hachage sur cette sérialisation et place le hachage de l'entrée précédente dans l'entrée suivante. Remplacez exit 0 par exit 1, modifiez l'hôte ou réordonnez deux entrées : la vérification échoue à partir de ce point.

Le Secure Hash Standard du NIST définit des algorithmes de hachage approuvés qui produisent des condensats de longueur fixe. Un condensat n'est ni un chiffrement ni une signature. C'est le lien compact qui permet à une entrée ultérieure de dépendre exactement des octets précédents.

Cela détecte les modifications. Cela ne détecte pas toutes les formes de malhonnêteté.

Un attaquant capable de réécrire le journal et de recalculer tous les hachages suivants peut produire une chaîne qui se vérifie correctement. Un attaquant qui supprime les 40 dernières entrées peut laisser un préfixe antérieur valide. Un attaquant qui entretient deux chaînes distinctes peut montrer des historiques différents à des examinateurs différents. La chaîne indique qu'une séquence présentée est cohérente en interne. Elle ne peut pas, à elle seule, établir que cette séquence est complète ou globalement unique.

C'est pourquoi je m'oppose à ceux qui qualifient une chaîne de hachage locale de « non-répudiation ». Ce n'en est pas une. La non-répudiation exige un lien avec une identité et une méthode de vérification qui résiste à la partie accusée d'avoir agi. Une chaîne locale reste utile, mais appelez-la par son nom : une preuve solide contre les modifications occasionnelles et la corruption du stockage.

Une chaîne a besoin d'un ancrage hors de portée de l'auteur

Une chaîne de hachage est beaucoup plus difficile à réécrire lorsque des tiers conservent des points de contrôle que l'auteur du journal ne peut pas remplacer discrètement. Sans référence externe, l'attaquant qui contrôle l'auteur contrôle aussi le début de votre histoire.

Il existe plusieurs façons d'ancrer un journal. Elles diffèrent par leur coût et leur adéquation opérationnelle.

• Exporter les points de contrôle signés vers un compte distinct avec des droits d'écriture limités.
• Envoyer périodiquement les racines du journal vers un système de stockage des événements de sécurité que l'hôte de l'agent ne peut pas administrer.
• Répliquer les segments chiffrés du journal vers un stockage hors ligne ou en ajout uniquement.
• Demander à un moniteur indépendant de conserver les racines observées et de signaler les incohérences.

Ne confondez pas multiplication des destinations et amélioration des preuves. Cinq copies dans des compartiments cloud contrôlés par le même administrateur peuvent échouer ensemble. La séparation des autorités compte davantage que le nombre de répliques.

Certificate Transparency fournit un modèle mental utile. La RFC 9162 utilise des arbres de Merkle pour prendre en charge les journaux en ajout uniquement, les preuves d'inclusion et les preuves de cohérence entre les têtes d'arbre publiées. La RFC énonce également clairement la difficulté principale : un journal malhonnête peut tenter de montrer des vues incohérentes à différents clients.

Une simple chaîne de hachage n'est pas un arbre de Merkle. Elle offre une vérification séquentielle efficace, mais pas de preuves compactes pour des entrées arbitraires ni de protocole public de cohérence. C'est généralement le bon compromis pour un seul Mac exécutant un volume modéré d'actions d'agent. Ajouter un service Merkle parce que le mot apparaît dans des articles sur la transparence constitue une machinerie inutile, sauf si vous avez des moniteurs indépendants, de nombreux vérificateurs ou besoin de prouver l'appartenance à un grand journal partagé.

Le coût de l'ancrage est réel. Vous devez exploiter une autre frontière de stockage, choisir la fréquence des points de contrôle, gérer les interruptions et conserver suffisamment de métadonnées pour associer un point de contrôle à un journal local. Un point de contrôle pour chaque action crée du trafic et davantage de cas d'échec. Un point de contrôle quotidien laisse un long intervalle pendant lequel une troncature peut être difficile à révéler. Choisissez un intervalle adapté à la vitesse à laquelle les mauvaises actions deviennent coûteuses.

Pour les identifiants de déploiement en production, je préfère ancrer chaque action privilégiée terminée plutôt que débattre de l'adéquation technique d'un export quotidien. Pour les appels API en lecture seule et à faible risque, une racine périodique peut suffire.

Le chiffrement masque l'enregistrement, pas l'historique

Les journaux chiffrés protègent les détails sensibles des actions contre les lecteurs occasionnels, mais le chiffrement seul ne dit rien de la modification éventuelle des enregistrements. Les équipes construisent souvent une propriété, en décrivent deux, puis découvrent la différence pendant une enquête.

Supposons qu'une entrée de journal contienne un chemin HTTP, l'étiquette d'un identifiant d'autorisation, des métadonnées de requête et une erreur renvoyée. Le chiffrement empêche un voleur de disque d'apprendre quel point de terminaison client l'agent a contacté. Il n'empêche pas un processus local privilégié de remplacer le bloc chiffré par un autre bloc chiffré. Vous avez besoin d'un chiffrement authentifié pour chaque entrée et d'une chaîne couvrant les entrées chiffrées ou leurs représentations authentifiées.

La conception propre consiste à permettre la vérification de l'intégrité sans exposer le contenu. Le vérificateur lit la séquence d'enregistrements chiffrés, contrôle le format et les relations avec les entrées précédentes, recalcule la chaîne et indique si les octets présentés forment toujours l'historique attendu. Il n'a pas besoin que le coffre d'identifiants soit déverrouillé pour déterminer que l'entrée 1042 ne suit plus l'entrée 1041.

Cette séparation est précieuse pendant le confinement. Un enquêteur peut copier le journal, lancer la vérification et préserver le résultat avant de demander à quiconque de déverrouiller des éléments sensibles. La personne chargée de la première analyse d'un incident ne devrait pas avoir besoin d'un accès étendu aux identifiants de déploiement pour déterminer si les preuves ont été modifiées.

Le chiffrement impose aussi une décision de conservation. Si personne ne peut déchiffrer les anciennes entrées après une migration d'appareil, votre preuve d'intégrité peut rester intacte tandis que le journal perd sa valeur opérationnelle. Séparez les procédures de récupération et de conservation du format d'audit. Ne placez pas le secret de déchiffrement à côté de l'archive chiffrée en considérant le problème réglé.

Sur macOS, une protection matérielle peut réduire l'exposition des secrets locaux. La documentation de sécurité d'Apple décrit Secure Enclave comme un processeur matériel isolé dédié à la sécurité, et la documentation destinée aux développeurs précise que le matériel secret en clair ne peut pas être transféré vers le mécanisme Secure Enclave décrit, ni en sortir. Cela facilite la conception d'un coffre local, mais n'authentifie pas magiquement tous les processus du Mac.

Le journal doit tout de même identifier le processus qui a reçu l'approbation et l'action qui a franchi la passerelle. La protection matérielle sécurise une frontière. Les preuves d'audit en nécessitent plusieurs.

L'échec commence généralement avant la commande dangereuse

Un incident plausible impliquant un agent ne commence presque jamais par une commande qui semble malveillante. Il commence par une demande banale à laquelle est attachée une autorité excessive.

Imaginez qu'un agent de programmation reçoive une demande lui demandant de diagnostiquer un échec de déploiement. Il lit le dépôt, trouve un script de déploiement et ouvre un canal SSH vers un hôte de publication. La première commande est inoffensive :

systemctl status web.service

La sortie contient le chemin vers un fichier de configuration temporaire. L'agent lit ensuite ce fichier, trouve une référence à un identifiant de déploiement et exécute une seconde commande qui modifie une valeur d'environnement. La commande distante renvoie le code de sortie 0. Vingt minutes plus tard, un client signale des requêtes en échec.

Où les contrôles auraient-ils pu arrêter ou révéler cette situation ?

Premièrement, la passerelle du coffre aurait pu empêcher toute action externe tant qu'il était verrouillé. Cela ne détermine pas si la commande était judicieuse, mais empêche un agent en arrière-plan d'utiliser les identifiants après la fermeture de la frontière de sécurité par l'utilisateur.

Deuxièmement, l'autorisation de session aurait pu afficher l'identité du processus de l'agent avant sa première action. C'est là que l'autorité de signature compte. Un éditeur connu et un assistant non signé lancé depuis /tmp ne devraient pas recevoir le même traitement simplement parce qu'ils parlent tous deux MCP.

Troisièmement, une approbation obligatoire pour l'identifiant de l'hôte de publication aurait pu interrompre la seconde action. L'invite doit afficher suffisamment de contexte sur la destination et l'opération pour qu'une personne comprenne qu'il ne s'agit plus d'un diagnostic. Un bouton générique « autoriser SSH » ne répond pas à cette exigence.

Enfin, le journal doit montrer les deux commandes comme deux actions terminées distinctes au sein de la même session. Si le relevé d'incident indique seulement « l'agent a étudié l'échec du déploiement », il dissimule le moment où la session est passée de l'observation à la modification.

Je préfère une approbation à chaque utilisation pour les identifiants capables de modifier l'état de la production. C'est plus lent. Cela oblige aussi une personne à regarder le moment précis où une tâche de diagnostic devient une modification opérationnelle.

Ne demandez pas un clic pour chaque requête inoffensive. Les utilisateurs approuveront un mur d'invites identiques sans les lire, car l'interface leur apprendra exactement à le faire. Placez la friction sur les utilisations d'identifiants dont l'impact potentiel change à chaque appel.

L'identité du processus doit figurer dans l'enregistrement

Une piste d'audit qui indique « Claude Code a utilisé SSH » est trop vague pour trancher un désaccord. Vous devez savoir quel processus local a démarré la session, quelle autorité de signature le système d'exploitation a indiquée et si l'approbation couvrait cette instance du processus.

C'est une autre distinction que les équipes aplatissent : l'identité de l'application n'est pas celle du processus. Un nom de marque peut désigner un produit légitime, tandis qu'une extension compromise, un binaire copié ou un script shell utilise le même protocole depuis un contexte exécutable différent. La décision d'approbation doit être attachée au processus réel qui a demandé à agir, puis expirer à la fin de cette session.

Le journal doit conserver un identifiant de session stable et suffisamment d'informations sur la provenance du processus pour répondre plus tard aux questions suivantes :

• Le même processus a-t-il effectué la première et la dernière requête ?
• L'utilisateur a-t-il approuvé cette session avant l'appel ?
• La session a-t-elle été révoquée avant l'arrivée d'une requête ultérieure ?
• Un autre processus local a-t-il tenté de réutiliser le canal ?

Évitez d'utiliser un nom d'affichage modifiable comme principal champ d'identité. Les noms changent. Les chemins peuvent être remplacés. Une autorité de signature ou une identité équivalente de la plateforme est plus utile, car elle relie l'écran d'approbation, le journal de session et l'enquête ultérieure.

Il y a un coût. Les versions de développement légitimes, les forks locaux et les outils non signés créeront davantage de travail de vérification. Ce n'est pas un défaut du modèle d'audit. C'est le prix visible de l'accès d'un logiciel expérimental à de vrais identifiants. Décidez si ces outils doivent utiliser un identifiant distinct et peu privilégié plutôt que d'apprendre aux examinateurs à ignorer les détails d'identité inhabituels.

L'enregistrement doit également distinguer les tentatives refusées des actions terminées. Une requête SSH refusée prouve qu'un contrôle a fonctionné. Une connexion échouée prouve qu'un chemin a été tenté, mais pas qu'une exécution distante a eu lieu. Une requête terminée avec un résultat renvoyé est une preuve plus solide. Ne réduisez pas ces résultats à un booléen unique nommé success.

Un journal unique pour les sessions et les appels produit une meilleure chronologie

Les événements de session et les événements d'action doivent provenir de la même source ordonnée, même si les opérateurs les consultent pour des raisons différentes. Des fichiers de journal distincts écrits par des composants distincts finissent par diverger sous la pression.

La vue des sessions répond aux questions sur le cycle de vie de l'agent : quand une session est apparue, à quel processus elle appartenait, si un utilisateur l'a autorisée et si quelqu'un l'a révoquée. La vue des activités répond aux questions sur les actions individuelles : quelle étiquette d'identifiant a été choisie, quelle destination a été utilisée, si l'appel a été autorisé et quel résultat a été renvoyé.

Ces vues ne doivent pas être des sources indépendantes. Si une action apparaît sans sa session, ou si une session révoquée continue d'émettre des appels, l'enquêteur a besoin d'une séquence unique pour déterminer si les données sont incohérentes ou si le système se comporte mal.

C'est ici qu'un journal chiffré en écriture seule offre un avantage pratique. Les composants peuvent ajouter les informations qu'ils sont autorisés à signaler, tandis que le format du journal les empêche de parcourir facilement des entrées sans rapport. Le gain de sécurité ne vient pas du fait de rendre les journaux mystérieux. Il vient de la réduction du nombre de chemins de code capables de lire, modifier et réinterpréter les enregistrements historiques.

Sallyport produit les journaux Sessions et Activity à partir d'un même journal d'audit chiffré et chaîné par hachage, et sp audit verify vérifie cette chaîne hors ligne sur le texte chiffré sans nécessiter le déverrouillage du coffre. C'est la bonne architecture pour les preuves locales d'un agent, car le chemin de vérification reste disponible pendant le confinement.

J'exporterais tout de même des points de contrôle pour les environnements à forts enjeux. La vérification locale indique si la copie en votre possession est intègre en interne. Un point de contrôle externe aide à détecter qu'on vous a remis un historique plus ancien et plus court.

Séparez la présentation du journal de la vérité qu'il contient. Une interface pratique peut filtrer, regrouper et masquer des entrées pour l'usage quotidien. Le vérificateur sous-jacent doit fonctionner sur des octets stables et un ordre déterministe, et non sur ce que l'interface actuelle choisit d'afficher.

La vérification doit être courante, pas cérémonielle

Une commande de vérification exécutée uniquement après un incident est une fonctionnalité que personne n'a testée. Intégrez-la à la maintenance ordinaire et rendez la gestion des erreurs prévisible.

Pour une installation Sallyport, la première vérification concrète est la suivante :

sp audit verify

Exécutez-la sur une copie du journal avant une mise à niveau importante, avant d'effacer un Mac de développement et lorsque vous soupçonnez une modification inattendue de l'état local. Conservez la copie exacte du journal que vous avez vérifiée. Réexécuter la commande plus tard sur une autre copie ne prouve pas ce qui existait pendant l'incident.

La commande seule ne suffit pas. Associez-la à une petite routine opérationnelle :

1. Conservez la copie du journal et la référence de son point de contrôle avant toute remédiation.
2. Notez l'identifiant de la session concernée et la période étudiée.
3. Comparez les actions HTTP et SSH terminées avec les journaux du fournisseur distant.
4. Révoquez la session active avant de demander à l'agent d'effectuer un nettoyage.
5. Vérifiez à nouveau après l'export ou le transfert pour confirmer que les preuves copiées sont intactes.

Le troisième point est important, car l'intégrité locale et la vérité externe se complètent. Un journal valide peut montrer que la passerelle a émis POST /deployments. Le fournisseur de déploiement peut indiquer s'il a accepté, mis en file d'attente ou refusé l'opération. Le statut de sortie SSH peut signaler qu'une commande shell s'est terminée ; les journaux de services de l'hôte peuvent montrer quel processus a agi ensuite.

J'ai peu de patience pour les systèmes d'audit qui affichent uniquement les événements dans un tableau de bord. Si vous ne pouvez pas valider le journal stocké sans ce tableau de bord, vous avez rendu la réponse à l'incident dépendante de la même pile applicative que celle qui pourrait être mise en cause.

La vérification doit également échouer clairement en cas de segments manquants, de numéros de séquence invalides, de formatage chiffré incorrect ou de discordance avec l'entrée précédente. Un outil qui ignore les enregistrements défectueux pour produire une chronologie plus agréable est un destructeur de preuves aux bonnes manières.

Les enregistrements d'approbation exigent la même rigueur que ceux des actions

Un clic d'approbation fait partie de l'événement de sécurité, ce n'est pas un simple détail d'interface. Si le système enregistre uniquement qu'une action a été autorisée, vous ne pourrez pas établir plus tard si l'utilisateur a approuvé une session précise, une catégorie d'identifiants ou une invite entièrement différente.

Stockez le contexte de décision réellement présenté à la personne : l'identité du processus demandeur, la portée de l'approbation, l'étiquette de l'identifiant concerné et l'heure. Pour une décision au niveau de la session, enregistrez le début et la fin de la session, ou le moment de sa révocation. Pour une décision par utilisation, liez l'approbation à une seule action tentée afin qu'elle ne puisse pas autoriser discrètement une destination ultérieure.

Une bonne limite d'approbation implique un compromis clair. Une autorisation de session étendue réduit les interruptions et rend les boucles autonomes utilisables. Une autorisation étroite à chaque appel donne à une personne davantage d'occasions d'arrêter une mauvaise décision, mais devient épuisante si elle s'applique aux lectures courantes. Aucun réglage n'est universellement plus sûr : c'est l'effet de l'identifiant qui détermine la portée raisonnable.

Le modèle à trois contrôles suffit souvent : garder le coffre verrouillé jusqu'à son ouverture par l'utilisateur, autoriser un processus identifié pour une session et exiger une confirmation explicite à chaque utilisation de certains identifiants. Un langage de règles peut sembler plus sophistiqué, mais chaque condition devient une affirmation supplémentaire que les équipes doivent tester lors d'une mise en production. Pour une passerelle d'actions de bureau, je choisirais un petit ensemble fixe de contrôles plutôt qu'un moteur de règles que personne ne peut expliquer à 2 heures du matin.

Ce choix exclut certains flux de travail. Vous ne pouvez pas exprimer toutes les exceptions d'environnement ou les règles fondées sur l'heure dans une échelle de décision fixe. Les équipes qui gèrent un parc de serveurs et des délégations complexes peuvent avoir besoin d'un autre système. Prétendre qu'une application locale de barre des menus doit devenir un serveur d'autorisation général transforme une frontière de sécurité ciblée en système fragile.

Décidez ce que vous devez prouver avant d'accorder l'accès

La question utile n'est pas « Avons-nous des journaux ? » C'est « Quelle affirmation devrons-nous établir si cette session tourne mal ? »

Pour chaque identifiant qu'un agent peut utiliser, écrivez l'affirmation en langage courant. Par exemple : ce processus signé a reçu l'autorisation pour cette session ; cette session a appelé ce point de terminaison API ; cette commande SSH a franchi la passerelle locale ; cet identifiant était verrouillé au moment de la requête refusée ; ces enregistrements n'ont pas été modifiés depuis le point de contrôle conservé.

Testez ensuite le journal dans un scénario difficile. Supprimez ses 50 dernières lignes. Modifiez un champ de destination. Copiez-le sur un autre Mac. Verrouillez le coffre et lancez la vérification. Révoquez une session entre deux appels. Si vous ne pouvez pas dire quel contrôle doit arrêter l'événement et quel enregistrement doit le montrer, vous avez de l'observabilité, pas des preuves.

Une chaîne de hachage ne rendra pas sûr un identifiant dangereux. Le chiffrement ne prouvera pas l'exhaustivité. Une invite d'approbation ne sauvera pas un examinateur inattentif. Chaque contrôle a une fonction plus limitée.

Créez l'enregistrement là où l'action a lieu, protégez son contenu, chaînez son ordre, conservez un ancrage hors de portée de l'auteur et répétez la vérification avant de donner à un agent accès à quoi que ce soit qui puisse vous nuire. Cette séquence est moins spectaculaire qu'un immense moteur de règles. Elle est aussi beaucoup plus facile à défendre lorsque quelqu'un demande ce qui s'est réellement exécuté.