Piste d’audit d’un agent IA : prouver ce qu’il a fait
Pourriez-vous prouver dans un an ce que votre agent a payé, et qui a signé ? Pas s’il peut modifier son journal.
EN 30 SECONDES
Une piste d’audit est le registre de ce que chaque agent a fait, quand et avec quelle approbation. Une chaîne de hash vérifiée par un point de contrôle protégé rend les retouches visibles, et les tests d’attaque éprouvent les limites de l’agent.
À RETENIR · 3
- Une piste d’audit est une preuve : ce que l’agent a fait, avec quelle approbation et pourquoi, dans un journal qu’il ne peut pas réécrire.
- Une chaîne de hash ne détecte une retouche que par rapport à un point de contrôle fiable : protégez séparément les points de contrôle signés.
- Attaquez vos propres agents sur leur vrai périmètre. Un test réussi n’éprouve que la frontière qu’il vise.
Sur cette page
Pourquoi la piste d’audit doit rendre les altérations détectables
EN BREF Si un agent a déplacé de l’argent, vous devez prouver plus tard ce qu’il a fait, et il ne doit pas pouvoir réécrire cette trace.
LES MOTS À CONNAÎTRE
- Piste d’audit
- Le registre de ce que chaque agent a fait, quand et avec quelle approbation, conservé pour être vérifié plus tard.
- Hash
- Une empreinte courte des données : un caractère change, et l’empreinte aussi.
- Test d’attaque
- Attaquer exprès son propre système, comme le ferait un attaquant, pour trouver ses failles en premier.
On entend « Piste d’audit Le registre de ce que chaque agent a fait, quand et avec quelle approbation, conservé pour être vérifié plus tard. Voir le glossaire » et on imagine un fichier journal. En finance régulée, c’est plutôt une preuve : ce que l’agent a fait, avec quelle approbation et pourquoi. Je conçois en partant du principe que l’auditeur présume la mauvaise foi.
Un journal que l’agent pourrait retoucher en douce ne vaut rien devant l’auditeur. Le schéma que je propose : chaque entrée note une action et porte le Hash Une empreinte courte des données : un caractère change, et l’empreinte aussi. Voir le glossaire de la précédente.
ÉTAPE PAR ÉTAPE
Étape 1. Écrire. L’entrée 7 note une action, son approbateur et le hash de l’entrée 6.
- Écrire L’entrée 7 note une action, son approbateur et le hash de l’entrée 6.
- Retoucher Quelqu’un change le montant de l’entrée 7. Son hash change aussi.
- Rupture L’entrée 8 garde l’ancien hash de l’entrée 7 : le lien ne correspond plus.
- Vérifier Recalculée et comparée à un point de contrôle protégé, la chaîne échoue à partir de l’entrée 7.
Une chaîne de hash ne détecte une retouche que par rapport à un point de contrôle fiable. Par exemple, une copie signée d’un hash récent, rangée hors de portée de celui qui écrit.
ATTENTION
Qui peut remplacer tout le journal peut recalculer une chaîne non signée : protégez à part les points de contrôle signés, limitez l’écriture et vérifiez la chaîne par rapport à eux. Même alors, elle montre que rien n’a été modifié, pas que tout a été noté.
Une blockchain garde un historique commun, selon ses propres règles de consensus et de finalité. Mais cet historique ne dit pas pourquoi un contrôle d’éligibilité fait hors chaîne a dit oui ou non. Gardez donc la version de la règle et les preuves de chaque décision à côté de la transaction.
Sources : validation de l’intégrité des journaux signés, AWS CloudTrail.
Dans la section suivante : Alors, comment vérifier les limites avant que quiconque s’y fie ?
Attaquer en production les agents que j’ai construits
EN BREF J’ai construit des garde-fous et pratiqué le Test d’attaque Attaquer exprès son propre système, comme le ferait un attaquant, pour trouver ses failles en premier. Voir le glossaire sur des agents en production, pour trouver les failles avant qu’un attaquant ne le fasse.
Chez Ilayer, j’ai construit la plateforme d’agents d’un fonds américain de private equity immobilier. Je l’ai attaquée moi-même, avec des entrées pensées pour pousser les agents hors de leur périmètre, car « ça marchait en démo » n’est pas un argument de sécurité.
ATTENTION
Un test d’attaque réussi n’éprouve que la frontière visée par ce test. Il ne prouve pas qu’une injection inconnue ou un autre chemin d’exécution sera contenu.
Chez Integra, j’ai été CTO jusqu’à la fin de ce rôle en 2026. J’y ai déployé environ 46 agents IA pour les opérations internes. Ils sont distincts des agents en production du fonds.
Décompte approximatif, déclaré par l’auteur
Le flux d’approbation et le journal de cet épisode sont des modèles tirés de ce travail. Je n’affirme pas que le fonds les utilisait exactement ainsi.
EN CLAIR
Aucun ingénieur honnête ne peut dire « notre agent ne peut pas être injecté ». Avec le confinement, on n’a pas à vaincre l’injection, seulement à y survivre.
OBJET OBTENU
Ce que vous pouvez défendre
FAQ
Non. Ne comptez pas sur un filtre pour tout arrêter. Associez les défenses du modèle aux permissions imposées par les systèmes qu’il appelle, testez les deux et prévoyez le cas d’un agent compromis.
Il est utile, et vous devriez en utiliser un. Mais rien ne garantit qu’il arrête tout : s’il est seul avant un virement, un raté suffit. Avec le confinement, même un raté bute encore sur la signature humaine.
L’agent ne détient que les permissions de sa tâche du moment, le temps qu’elle dure. En pratique : une identité par tâche et des identifiants éphémères, pas une clé durable qu’il emporte partout.
Listez chaque chemin qui déplace de la valeur ou donne des droits. Placez ces actions derrière une approbation indépendante, qui montre au signataire le bénéficiaire, le montant et le périmètre. Même un humain peut être trompé : gardez des plafonds stricts et testez les contournements.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Pourquoi un journal que l’agent peut modifier ne prouve rien.
- Comment un point de contrôle protégé rend visible une retouche.
- Ce qu’un test d’attaque réussi montre, et ce qu’il ne montre pas.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Quelqu’un peut remplacer tout le journal, et aucun point de contrôle fiable n’est conservé hors de sa portée. La retouche se verra-t-elle ?
Non. Il peut recalculer une chaîne non signée. Seul un point de contrôle fiable hors de sa portée, comme un hash signé et protégé, la révélerait.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.