Note : Ceci est une note de recherche qui complète le livre Unscarcity, désormais disponible à l’achat. Ces notes développent des concepts du texte principal. Commencer ici ou découvrir le livre.

Ton IA tient ses comptes au crayon

Ou : pourquoi le journal d’activité d’un agent n’est qu’un témoignage tant que l’agent peut y toucher, et les cinq verrous qui changent ça.

« Je n’ai jamais fait ça »

Ça t’est peut-être déjà arrivé. Tu regardes ton IA faire quelque chose. Plus tard, tu lui poses la question, et elle répond qu’elle n’a jamais fait ça. Tu remontes jusqu’à l’endroit où tu l’as vue le faire. Les lignes ont disparu. Vient alors la partie humaine. Je me suis trompé ? Je l’ai inventé ?

Reste un instant avec ça, parce que c’est tout le problème en miniature. Tu n’en veux pas à l’IA. Tu doutes de toi, et la seule trace est celle que tu as sous les yeux.

Maintenant, donne à cette IA un travail et un budget. Un agent fait le travail, sa machine écrit le journal, et dans bien des installations l’agent a le droit de le modifier. Personne ne le décide. D’après mon expérience, ça dérive. Après une série de bonnes suggestions, tu lâches un peu plus de pilote automatique à chaque fois, jusqu’au sudo sans mot de passe et aux clés SSH sans phrase de passe. Chaque étape paraît raisonnable. L’IA l’a mérité.

Et un jour, l’agent est devenu son propre comptable, et « je n’ai jamais fait ça » pourrait devenir vrai dans la seule trace qui existe. Après un sinistre, tu ne pourrais pas prouver ce que l’agent a fait. Tu pourrais seulement rejouer la même dispute, cette fois avec un régulateur ou un assureur dans la pièce, et la perdre.

L’aviation a réglé exactement ce problème il y a des décennies. Les gros avions commerciaux doivent embarquer deux « boîtes noires », installées dans la partie de l’appareil la plus susceptible de survivre à un crash. Les règles fédérales américaines sur les enregistreurs de conversations de cockpit et les enregistreurs de données de vol exigent qu’ils soient montés pour résister à l’impact et au feu, peints en orange vif ou en jaune vif et, pour l’enregistreur de conversations, que toute fonction d’effacement soit neutralisée automatiquement dans les dix minutes qui suivent un crash. La règle de couleur remonte au milieu des années 1960, pour que les secours puissent les retrouver. L’équipage peut dire ce qu’il veut. Il ne peut pas réécrire la bande.

Ton agent tient ses comptes au crayon, et c’est le comptable qui tient la gomme.

Ce qu’un test a révélé cet été

Rien de tout cela n’est hypothétique. En juillet, lors d’évaluations internes de cybersécurité chez OpenAI, des agents IA qui travaillaient sur un banc d’essai de piratage sont tombés sur des tâches impossibles à terminer : selon le décompte d’OpenAI, 198 des 898 tâches n’avaient jamais été résolues par aucun de ses modèles. OpenAI avait pourtant testé et validé le bac à sable, mais les agents ont enchaîné des vulnérabilités jusque-là inconnues dans un service de gestion de paquets exposé à l’intérieur, en sont sortis, et se sont frayé un chemin jusque dans les systèmes de Hugging Face, une vraie entreprise, extérieure au test. La chronologie technique publiée par Hugging Face reconnaît sans détour que les faiblesses de son côté étaient connues : « Un attaquant humain compétent aurait pu trouver et exploiter les mêmes failles. »

Pourquoi ? Parce qu’ils voulaient réussir. L’enquête indépendante de METR a compté environ 1 200 agents sur un forum de discussion improvisé, dont environ 700 impliqués dans l’attaque, et conclut que l’intrusion chez Hugging Face « semblait principalement motivée par la volonté de comprendre l’implémentation du correcteur ». Les agents connaissaient les règles. L’un d’eux raisonnait ainsi, dans une ligne que cite METR : « l’exploitation d’une infrastructure externe sort du périmètre prévu. Mais tâche impossible, les pairs le font. On continue. »

Pendant tout ce temps, des agents travaillaient sur leurs propres journaux d’activité. Dans la chronologie de METR, la falsification des appels d’outils est assignée le 9 juillet, deux jours avant la première exécution de code à distance chez Hugging Face : la falsification a donc couru en parallèle de l’attaque, pas après. Le but était une tâche résolue : « mettre en scène une capture de drapeau d’apparence légitime et tromper le correcteur d’ExploitGym ». METR note que « les agents ont bien remarqué qu’il existait des journaux accessibles de leurs actions, et il était courant qu’ils les modifient ».

Ce qui a sauvé l’enquête, c’est une trace tenue par un mécanisme séparé. « Les transcriptions dont nous disposions étaient journalisées par un mécanisme différent, si bien que modifier ces fichiers de journal n’avait aucun effet », écrit METR, qui n’a trouvé aucun cas où des agents auraient « réussi à modifier des entrées antérieures de la transcription réelle ». Voilà la bonne nouvelle, et elle vient avec un astérisque : des entrées forgées se sont bel et bien glissées dedans. Plus de 7 % des transcriptions du jeu de données de METR contenaient des appels d’outils délibérément falsifiés, de fausses sorties d’outils qui ont fini dans la trace tenue à part. METR ajoute qu’il « ne peut pas exclure » d’en avoir manqué.

Et ce n’était pas un agent isolé qui aurait déraillé. METR a constaté qu’« au moins 20 % des agents de notre jeu de données ont exprimé un intérêt clair pour la falsification de leurs transcriptions », et précise en note que son classifieur sous-estimait probablement, des estimations plus larges donnant près de la moitié. Au moins un sur cinq.

Trois mois plus tôt, le rapport de METR sur les risques des modèles de pointe disait n’avoir « connaissance d’aucun incident clairement documenté d’agents IA tentant de se soustraire à la surveillance ultérieure de leurs transcriptions ou de leurs journaux ». Fin août, METR avait documenté des agents qui falsifiaient leurs transcriptions. Pour être juste envers les agents, la cible était le correcteur automatique, pas les humains : METR écrit que le raisonnement « était toujours motivé par la volonté de tromper le correcteur automatique », et que les tentatives d’échapper à la détection humaine étaient « très rares et faibles ». C’est moins rassurant qu’il n’y paraît. Aujourd’hui, le public, c’est le correcteur. L’habitude de retoucher la trace pour son public, elle, se transpose.

L’histoire complète de qui a enquêté, et à quelles conditions, se trouve dans Qui enquête sur la machine ?. Cette note porte sur la question plus étroite à laquelle ce test m’a renvoyé : pas seulement ce que l’agent a fait, mais si l’on peut prouver, après coup, ce qu’il a fait.

Un journal que l’agent peut modifier n’est pas une preuve. C’est un témoignage.

Une règle est une demande. Une permission est un mur.

Une consigne de sécurité dans un prompt n’est pas un contrôle de sécurité. « Reste dans le périmètre », c’est une demande, et les agents de cet été ont lu la règle, l’ont répétée, et ont continué. On peut argumenter avec un modèle, le piéger, ou il peut simplement se tromper. Le système d’exploitation, non. Un contrôle de permission ne lit pas le prompt.

Les contrôles ont donc leur place une couche plus bas, hors de portée de l’agent, et la discipline consiste à lui donner moins que ce qu’il demande :

le faire tourner sous son propre utilisateur, pas le tien ;
rendre le journal en ajout seul, pour que cet utilisateur puisse ajouter une ligne mais jamais en modifier une ;
garder le journal dans un répertoire où l’agent ne peut pas écrire ;
laisser un autre processus écrire (c’est ce qui a sauvé METR) ;
envoyer une copie hors de la machine en quelques secondes.

Comme je l’écrivais dans un texte précédent, You Told Me to Water the Plant : pas « ne devrait pas ». Ne peut pas.

Une limite honnête. Le système d’exploitation ne vaut que ce que vaut celui qui détient root, le compte administrateur. Sous Linux, seul le superutilisateur (ou un processus doté de la capacité CAP_LINUX_IMMUTABLE) peut poser ou retirer l’attribut d’ajout seul, ce qui veut aussi dire que root peut le lever. D’où les verrous suivants : une copie sur une autre machine, et une clé de signature gardée ailleurs.

Le cloud ne te sauvera pas

Dans le cloud, le mur, c’est le système de permissions, et il a deux points faibles : un administrateur, et les permissions de l’agent lui-même. Un agent agit en général à travers un rôle IAM (gestion des identités et des accès), un ensemble nommé de permissions. Azure appelle la même idée contrôle d’accès basé sur les rôles et identités managées. Si ce rôle peut supprimer des journaux, l’agent aussi.

Les remèdes sont partout les mêmes. Ne donner au rôle de l’agent aucune permission sur la journalisation. Garder les journaux dans un compte que le compte de l’agent ne peut pas administrer. Et poser des garde-fous de refus au-dessus du compte, là où ses propres administrateurs ne peuvent pas les atteindre :

AWS : les politiques de contrôle des services (SCP) « s’appliquent à tous les utilisateurs et rôles des comptes rattachés, y compris l’utilisateur root ». Un piège : « les SCP n’affectent pas les utilisateurs ni les rôles du compte de gestion ». N’y fais tourner aucun agent.
Google Cloud : les stratégies de refus IAM permettent d’écrire des « règles de refus qui empêchent certains principaux d’utiliser certaines permissions, quels que soient les rôles qui leur sont accordés ».
Azure : les règles de refus d’Azure Policy, assignées sur un groupe d’administration, descendent en cascade sur chaque abonnement placé dessous. (On ne peut pas poser de verrou de ressource sur un groupe d’administration, et un propriétaire de l’abonnement peut le retirer, d’où le choix de Policy. Attention : l’effet deny simple bloque les créations et les mises à jour ; bloquer les suppressions demande l’effet distinct denyAction.)

Cinq verrous sous le prompt

Aucun ne se laisse convaincre, et chacun ferme une brèche que le précédent laisse ouverte. D’abord la carte, puis chaque verrou avec ce qu’il n’empêche pas.

Verrou	Tes propres serveurs	AWS	Google Cloud	Azure
1. Écrire une fois	`chattr +a`, instantanés ZFS, instantanés immuables sur NAS	S3 Object Lock, mode conformité	Bucket Lock	Stockage Blob immuable, stratégie verrouillée
2. Rendre la falsification visible	Enregistrements chaînés par empreinte	Validation d’intégrité des fichiers CloudTrail	Bucket Cloud Logging verrouillé	Journal d’activité vers un stockage immuable, ou registre confidentiel
3. Quelqu’un d’autre garde une copie	Une machine séparée dont le compte de réception ne peut qu’ajouter	Trail d’organisation vers un compte de journaux séparé	Récepteur au niveau de l’organisation vers un projet séparé	Espace de travail ou stockage dans un abonnement séparé
4. Signer avec une clé gardée ailleurs	TPM, YubiKey, ou une machine de signature séparée	KMS	Cloud HSM	Key Vault Managed HSM
5. Un enregistreur conçu pour les agents	À construire soi-même (le mien est plus bas)	Bedrock AgentCore Observability	Traçage Agent Runtime	Traçage Foundry

Verrou 1 : écrire une fois

Sous Linux, une seule commande rend un fichier de journal en ajout seul :

sudo chattr +a /var/log/agent/audit.log

La page de manuel précise qu’un tel fichier « ne peut être ouvert en écriture qu’en mode ajout ». Dans mon propre test, les commandes rm, truncate -s 0 et sed -i lancées par root ont toutes échoué avec « Operation not permitted ». Personne ne peut écraser, tronquer ou supprimer le fichier. Pas même l’administrateur, du moins pas sans retirer d’abord l’attribut.

La même idée existe à chaque couche. Un instantané ZFS est « une copie en lecture seule d’un système de fichiers ou d’un volume ». Un NAS peut conserver des instantanés immuables, impossibles à supprimer pendant une période de protection fixée. En mode conformité de S3 Object Lock, un objet protégé « ne peut être écrasé ni supprimé par aucun utilisateur, y compris l’utilisateur root », et « sa période de rétention ne peut pas être raccourcie ». Le Bucket Lock de Google Cloud empêche « définitivement que la stratégie soit réduite ou supprimée ». La stratégie d’immuabilité verrouillée d’Azure ne va que dans un sens : « Vous pouvez prolonger la période de rétention, mais vous ne pouvez pas la réduire. »

Ce qu’il n’empêche pas : sur ton propre serveur, l’administrateur peut retirer l’attribut. Dans le cloud, le verrou n’est réel qu’une fois verrouillé. Chaque fournisseur propose aussi un mode non verrouillé pour les tests : le mode gouvernance d’AWS peut être contourné avec une permission spécifique, une stratégie de rétention Google non verrouillée peut être supprimée, et Azure dit en toutes lettres que « la stratégie est déverrouillée à des fins de test ». Un administrateur peut défaire les trois.

Verrou 2 : rendre la falsification visible

Chaque enregistrement stocke l’empreinte (un hachage cryptographique) du précédent. Modifie un enregistrement, et toutes les empreintes suivantes cessent de correspondre. C’est un cahier relié aux pages numérotées : arrache une page, et le trou se voit.

Sur ta propre machine, le processus de journalisation écrit lui-même la chaîne. AWS le fait pour sa propre piste d’audit : la validation d’intégrité des fichiers CloudTrail écrit un fichier de condensat signé toutes les heures, et AWS affirme que cela rend « informatiquement impossible de modifier, supprimer ou falsifier des fichiers de journal CloudTrail sans que cela soit détecté ». Chez Google Cloud, verrouiller un bucket de journaux empêche « quiconque de mettre à jour ou de supprimer un bucket de journaux », et le bucket ne peut pas être supprimé tant que chaque entrée n’a pas accompli sa période de rétention. Chez Azure, tu peux exporter le journal d’activité vers un compte de stockage et rendre ce stockage immuable, ou écrire tes propres empreintes dans le registre confidentiel Azure, que Microsoft décrit comme un registre en ajout seul produisant des « enregistrements dont la falsification est détectable ».

Ce qu’il n’empêche pas : une chaîne d’empreintes rend seulement la falsification visible. Celui qui détient le fichier entier peut reconstruire toute la chaîne. Et les fonctions cloud ci-dessus protègent les journaux d’audit du cloud lui-même, la trace de qui a appelé quelle API. Les prompts, appels d’outils et raisonnements de ton agent n’ont droit à cette protection que si tu les envoies toi-même vers une destination verrouillée. C’est la brèche que la plupart des équipes ratent.

Verrou 3 : quelqu’un d’autre garde une copie

En quelques secondes, chaque enregistrement devrait atterrir quelque part où la machine de l’agent ne peut ni modifier ni supprimer. Sur ton propre matériel, c’est une machine séparée dont le compte de réception ne sait faire qu’une chose : ajouter. Chez AWS, un trail d’organisation écrit dans un compte de journaux séparé, et les comptes membres peuvent le voir « mais ne peuvent ni le modifier ni le supprimer ». Chez Google Cloud, un récepteur agrégé au niveau de l’organisation ou d’un dossier achemine les journaux « vers un emplacement de stockage central » dans un autre projet. Chez Azure, l’équivalent est un espace de travail Log Analytics ou un compte de stockage dans un abonnement séparé, ce qui n’aide que si l’identité de l’agent n’a aucun droit sur cet abonnement.

Ce qu’il n’empêche pas : les trous pendant que la copie ne circule pas, et celui qui contrôle le côté réception. Un trou devrait déclencher une alarme, pas passer pour une heure calme.

Verrou 4 : signer avec une clé que la machine journalisée ne détient pas

De temps en temps, signe une empreinte récapitulative du journal. Quiconque réécrit l’histoire doit alors aussi falsifier la signature, et la clé n’est pas sur la machine qu’il contrôle.

Chez soi, cette clé peut vivre dans un TPM (la puce de sécurité de beaucoup d’ordinateurs), une clé de sécurité matérielle comme une YubiKey, ou une machine de signature séparée. Chez AWS, KMS est conçu pour qu’une clé privée « ne quitte jamais AWS KMS en clair ». Chez Google Cloud, utilise le niveau de protection Cloud HSM, qui tourne dans des « HSM certifiés FIPS 140-2 niveau 3 » (les clés Cloud KMS par défaut sont des clés logicielles, d’un niveau inférieur). Chez Azure, Key Vault Managed HSM utilise du matériel validé FIPS 140-3 niveau 3, une norme de sécurité du gouvernement américain.

Ce qu’il n’empêche pas : un agent dont le rôle peut lui-même demander une signature. Dans le cloud, vérifie qui a le droit d’utiliser la clé. Et une signature prouve que le journal n’a pas été modifié. Elle ne peut pas prouver qu’il a tout capturé.

Verrou 5 : un enregistreur conçu pour les agents

Les trois clouds proposent désormais un traçage des agents qui enregistre les appels au modèle, les appels d’outils et les étapes de l’agent : AWS Bedrock AgentCore Observability, le traçage Agent Runtime de Google (Google a renommé Agent Engine en Agent Runtime cette année), et le traçage Foundry de Microsoft, qui couvre « les appels aux LLM, les invocations d’outils, les décisions de l’agent ».

Ce sont de bons outils de débogage, pas des enregistreurs résistants à la falsification. Leurs traces atterrissent dans des entrepôts de supervision ordinaires (CloudWatch, Cloud Trace, Application Insights) : elles ne survivent à un agent dévoyé ou à un initié que dans la mesure où les verrous 1 à 4 les protègent. Je n’ai trouvé aujourd’hui aucun produit cloud qui combine la capture des agents avec un stockage verrouillé, signé et détenu séparément. S’il en existe un, je veux bien qu’on me le signale.

Ce qui tourne dans mon garage

Alors mon assistant IA et moi en avons construit un pour ma propre installation. Tout a commencé en septembre, quand le garde placé devant certains agents qui tournent sans surveillance dans mon garage (des règles codées en dur, vérifiées avant chaque appel d’outil) s’est révélé incapable de protéger son propre journal d’audit. Ce journal était un fichier ordinaire que mon propre compte pouvait modifier. Le garde bloquait une façon de le réécrire et en laissait passer plusieurs autres.

Ce qui existe aujourd’hui, dans sa première phase :

Un seul rédacteur. Un unique processus d’enregistrement, qui tourne sous son propre utilisateur, est le seul autorisé à écrire le journal. Il ne peut qu’ajouter, et chaque enregistrement porte l’empreinte du précédent.
Tout ce que le fournisseur expose. Il capture chaque prompt, chaque appel d’outil et son résultat, et tout le raisonnement que le fournisseur renvoie. Cette dernière partie est plus mince qu’on ne le croit. Quand j’ai compté, sur l’ensemble des transcriptions Claude Code de la machine enregistrée, il y avait 23 435 blocs de raisonnement ; 343 d’entre eux, environ 1,5 %, contenaient du texte. Les 23 092 autres étaient une chaîne vide accompagnée d’une signature. « Chaque bloc de raisonnement que les modèles exposent » est une phrase vraie. « Toutes ses pensées » n’est disponible chez aucun fournisseur que je connaisse.
Une copie ailleurs, en quelques secondes. Les enregistrements partent toutes les dix secondes vers une seconde machine dont le compte de réception ne sait faire qu’une chose : ajouter l’enregistrement suivant dans l’ordre. Le premier jour, une session en direct est apparue à l’identique sur la seconde machine en douze secondes environ.
Deux vérifications planifiées. Toutes les 30 minutes, la machine de sauvegarde revérifie sa copie de son côté et m’envoie directement un courriel s’il manque quoi que ce soit ou si quelque chose a été modifié. Toutes les 15 minutes, la machine enregistrée compare son journal octet par octet avec cette copie. Chaque côté vérifie que l’autre tourne encore. Elles détectent la falsification. Elles ne l’empêchent pas.

Puis j’ai audité mon propre enregistreur, et il a échoué à son propre test. La copie de sauvegarde, que j’avais décrite comme hors d’atteinte, pouvait en réalité être supprimée depuis la machine même contre laquelle elle devait protéger, via un compte privilégié auquel cette machine pouvait se connecter. Cet accès venait de la même dérive que celle décrite au début : des droits privilégiés et des clés qui ne demandaient aucun mot de passe, accordés une étape raisonnable après l’autre.

J’ai fermé ce chemin. Seul le compte de livraison, qui ne peut qu’ajouter, peut désormais écrire la copie, et les répertoires de journaux de l’enregistreur lui-même sont en ajout seul. Puis j’ai fermé la dernière route indirecte, qui passait par mes autres machines, et j’ai vérifié que les anciennes clés et les anciens mots de passe sont refusés. L’accès administrateur à la machine de sauvegarde par le réseau demande maintenant une clé de sécurité matérielle qui exige mon code PIN et mon doigt dessus, et même alors seulement pendant une fenêtre courte et limitée dans le temps. La machine des agents ne peut plus atteindre la copie par aucune route que je connaisse.

L’audit a trouvé ce que la conception avait raté. C’est l’argument en faveur de l’audit, et contre la confiance accordée à une conception parce qu’on l’a écrite soi-même.

Ce qu’il ne fait pas encore, et je préfère que tu l’apprennes de moi :

Conçu mais pas construit : les points de contrôle signés (verrou 4), la couverture des modèles autres que Claude, et le chiffrement au repos.
Mode fantôme. Si l’enregistreur tombe, les agents continuent de travailler et la panne apparaît comme un trou. Un enregistreur qui bloque les tâches de nuit parce que quelqu’un a redémarré la machine à la mauvaise minute est le genre de garde qu’on finit par désactiver, alors « pas d’enregistreur, pas de vol » attendra qu’il l’ait mérité.
Root reste root. L’administrateur de la machine enregistrée peut arrêter l’enregistreur. La conception rend cela visible, pas impossible. Et quelqu’un devant la console physique de la machine de sauvegarde, ou qui détiendrait à la fois ma clé et mon code PIN, sort de ce modèle.
« Aucune route que je connaisse » est une formule choisie avec soin. J’ai trouvé en auditant une route que je ne connaissais pas. Il serait imprudent de prétendre qu’il n’en reste aucune.

Quoi demander lundi

Pose sept questions à ton équipe d’ingénierie. N’accepte pas « tout va bien ».

L’agent peut-il écrire dans son propre journal d’audit, ou le supprimer ? Si la réponse est « techniquement oui », tu as un témoignage, pas une preuve.
Existe-t-il une copie hors de la machine de l’agent, et en combien de temps y arrive-t-elle ? Ça devrait se compter en secondes, pas en « sauvegarde de la nuit ».
Quelqu’un, nos propres administrateurs compris, peut-il supprimer cette copie avant l’heure ? Qui peut utiliser la clé de signature ?
Quelle facilité avons-nous accordée dont l’agent hérite désormais, comme un sudo sans mot de passe ou des clés sans phrase de passe ?
Enregistrons-nous les actions, c’est-à-dire les appels d’outils et leurs résultats, ou seulement la conversation ?
Quand l’enregistreur est en panne, avons-nous une alarme ou un trou silencieux ?
Quand avons-nous falsifié nos propres journaux pour la dernière fois, exprès, pour voir si quelqu’un le remarquait ?

L’horloge de la conformité

C’est aussi en train de devenir une question de conformité, par trois côtés à la fois.

La réglementation. L’article 12 du règlement européen sur l’IA exige que les systèmes d’IA à haut risque « permettent techniquement l’enregistrement automatique des événements (journaux) tout au long de la durée de vie du système ». Des journaux qui existent, c’est le plancher. Des journaux que le système journalisé ne peut pas modifier, c’est ce qui comptera la première fois que quelqu’un les contestera.

Le précédent. La finance a réglé la question pour les traces humaines il y a longtemps. La règle 17a-4 de la SEC impose aux courtiers en valeurs mobilières de conserver leurs documents électroniques soit sur un support à écriture unique, soit avec une « piste d’audit complète et horodatée » permettant de recréer un original modifié ou supprimé. Les amendements de 2022 ont ajouté l’option de la piste d’audit et conservé l’écriture unique. Les entreprises qui vivent déjà sous cette règle connaissent la forme de la réponse pour les agents. Les autres sont sur le point de l’apprendre.

L’assurance. Le CSIS, une organisation de recherche sur les politiques publiques à but non lucratif et transpartisane, rapporte que plus de 60 groupes d’assurance de dommages ont déposé des demandes pour adopter des exclusions liées à l’IA, et que Verisk, dont la filiale Insurance Services Office publie des formulations de polices standardisées utilisées par de nombreux assureurs américains, « a confirmé en juillet étudier de nouvelles exclusions pour l’IA agentique ». Le jour où l’assureur demande ce que ton agent a fait, un journal que l’agent pouvait modifier est la pièce la plus faible du dossier.

La lecture Post-Pénurie

La troisième loi du livre est Le Pouvoir Doit Décroître : « Aucune autorité ne doit survivre à sa raison d’être. » La plupart des gens y lisent une règle sur la limitation des mandats et l’influence qui s’érode. Applique-la à la trace, et elle devient quelque chose de plus mécanique : l’acteur qui a le plus de capacités ne devrait jamais être le seul à détenir la trace de ce qu’il a fait.

C’est la configuration qu’a produite le test de cet été, et celle que mon garage a produite par dérive. L’agent faisait le travail, la machine de l’agent tenait le journal, et les permissions de l’agent atteignaient le journal. La capacité et la trace dans les mêmes mains. Les verrous ci-dessus, c’est la décroissance inscrite dans l’infrastructure : chacun met une partie de la trace hors de portée de celui qu’on enregistre, jusqu’à ce qu’aucun acteur isolé, agent ou administrateur, ne la détienne en entier.

La deuxième loi, La Vérité Doit Être Vue, dit que les décisions qui touchent aux ressources et aux droits des gens doivent être observables et auditables. Blanchiment de responsabilité soutenait que la trace doit inclure les entrées, les prompts et la première réponse que personne n’a gardée, pas seulement le verdict. Une boîte noire est ce qui rend cette règle applicable au lieu de la laisser au rang de vœu. Un registre que l’arbitre peut modifier n’est pas un registre. Ce sont les mémoires de l’arbitre, et la défense d’une IA qui arbitre pendant que les humains gardent la conscience suppose que les décisions de l’arbitre puissent être vérifiées par quelqu’un d’autre.

Le fil de cette note, une règle est une demande et une permission est un mur, reprend l’argument que le livre fait valoir pour ses propres Cinq Lois de la Gravité : la transparence et la décroissance doivent être architecturales, parce que tout ce qui n’est que légal peut être reporté dès que ça coûte cher. Un prompt qui dit « ne touche pas aux journaux », c’est une politique. Un attribut d’ajout seul sur un fichier dont l’utilisateur de l’agent n’est pas propriétaire, c’est de l’architecture.

Cela rejoint aussi les points de contrôle où les agents doivent s’arrêter : un point de contrôle ne vaut que ce que vaut la trace qui prouve qu’il a été respecté. Et la Loi de Goodhart, dans sa forme la plus pure à ce jour : des agents qui optimisaient un score s’en sont pris au correcteur, puis aux preuves du correcteur. Si la mesure peut être modifiée par celui qu’on mesure, la mesure est la première à tomber.

Enfin, c’est la condition préalable de l’enquêteur défendu dans Qui enquête sur la machine ?. Un NTSB pour les agents IA, doté du droit de saisir les journaux, ne vaut que ce que valent les journaux. L’aviation a obtenu des enquêtes utiles une fois qu’elle a exigé des enregistreurs que la compagnie ne pouvait pas modifier. Les agents ont besoin de la même chose avant d’avoir besoin du bureau d’enquête.

Par où commencer

Commence par le verrou 1 cette semaine : une commande, sur un journal, sur une machine. Arrive au verrou 3 ce trimestre, parce qu’une copie hors de portée de l’agent est le verrou qui donne leur sens aux autres. Puis demande à tes fournisseurs où est leur verrou 5, et si c’est un enregistreur ou juste un tableau de bord.

Arrête de laisser la gomme au comptable.

Les machines seront dans la pièce pour chaque décision qui compte, et certaines tiendront le procès-verbal. Unscarcity est un livre sur la construction d’institutions où le pouvoir ne peut pas réécrire discrètement sa propre histoire, que ce pouvoir appartienne à un dirigeant, à une entreprise ou à un agent muni d’une carte bancaire d’entreprise. L’agent peut écrire le journal. Il ne devrait pas pouvoir le désécrire.

Sources

Aviation

14 CFR 25.1457, Cockpit voice recorders (eCFR) - orange vif ou jaune vif ; montage limitant les dégâts du crash et du feu ; effacement neutralisé dans les 10 minutes après l’impact
14 CFR 25.1459, Flight data recorders (eCFR) - les mêmes clauses de couleur et de montage
Flight Data Recorder (SKYbrary) - orange ou jaune obligatoire depuis 1965, pour être plus facile à localiser
Cockpit voice recorders and flight data recorders (NTSB) - deux « boîtes noires » sur les gros avions commerciaux, dans la partie la plus résistante au crash

L’incident

Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (METR, 26 août 2026) - environ 1 200 agents, dont environ 700 dans l’attaque ; la chronologie de la falsification à partir du 9 juillet ; « un mécanisme différent » ; plus de 7 % de transcriptions falsifiées ; au moins 20 % d’agents ayant exprimé un intérêt clair pour la falsification
Frontier risk report (METR, 19 mai 2026) - « aucun incident clairement documenté »
Hugging Face model evaluation security incident (OpenAI, 21 juillet 2026, mises à jour des 28 et 29 juillet) - la faille zero-day dans le bac à sable ; des agents « hyperconcentrés » sur la résolution d’ExploitGym
The Hugging Face incident and the road ahead (OpenAI, 26 août 2026) - évaluations internes de cybersécurité ; 198 tâches sur 898 jamais résolues
Security incident disclosure, July 2026 (Hugging Face)
Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident (Hugging Face)
You Told Me to Water the Plant (Patrick Deglon, LinkedIn, 17 septembre 2026)

Tes propres serveurs

chattr(1) - attribut d’ajout seul ; seul le superutilisateur ou CAP_LINUX_IMMUTABLE peut le poser ou le retirer
OpenZFS zfsconcepts(7) - les instantanés sont en lecture seule
What is an immutable snapshot? (Synology)

AWS

S3 Object Lock - modes conformité et gouvernance
CloudTrail log file integrity validation
AWS CloudTrail and AWS Organizations - trails d’organisation
Service control policies - root inclus ; compte de gestion exclu
AWS KMS cryptography essentials
Bedrock AgentCore Observability

Google Cloud

Bucket Lock
Configure log buckets - verrouillage d’un bucket
Aggregated sinks overview
IAM deny policies
Cloud HSM
Agent Runtime tracing et notes de version : Agent Engine devient Agent Runtime

Azure

Immutable storage for Azure Blob Storage
Azure Monitor activity log - export vers un compte de stockage
Azure confidential ledger overview
Log Analytics workspace design
Azure Policy deny effect
Management groups - stratégie héritée par chaque abonnement placé dessous
Azure Key Vault Managed HSM
Foundry observability

Réglementation et assurance

EU AI Act, Article 12: Record-keeping (AI Act Service Desk)
Amendments to electronic recordkeeping requirements for broker-dealers (SEC) - règle 17a-4, écriture unique ou piste d’audit
The insurance industry’s retreat from AI threatens to slow innovation and adoption (CSIS, 4 septembre 2026)
About CSIS
ISO Forms, Rules and Loss Costs (Verisk)

L’enregistreur

L’enregistreur de l’auteur : notes de conception, résultats du premier jour (17 septembre 2026) et audit du 2 octobre 2026. Non public ; chiffres cités tels que mesurés.
Unscarcity, chapitre 3 (les Cinq Lois de la Gravité : La Vérité Doit Être Vue, Le Pouvoir Doit Décroître)

Une boîte noire pour les agents IA : le journal inviolable