Contexte et enjeux
L’article souligne que l’informatique d’entreprise repose depuis longtemps sur des chaînes de confiance : fournisseurs cloud, éditeurs logiciels, systèmes d’identité et administrateurs sont supposés agir conformément à leurs spécifications. Les agents d’intelligence artificielle autonomes bouleversent ce modèle en pouvant récupérer des informations, prendre des décisions, invoker des outils externes, collaborer avec d’autres agents et exécuter des actions au nom de l’entreprise. Cette délégation accrue crée le besoin d’une méthode permettant de vérifier que chaque action découlant d’un agent correspond à l’intention initiale.
Architecture de confiance vs vérifiable
Le texte distingue deux concepts. La confiance traditionnelle s’appuie sur des contrôles d’accès, des politiques et des journaux d’événements qui indiquent qui a été autorisé et quelles API ont été appelées. Cependant, ces journaux ne capturent pas la chaîne complète d’instructions, d’entrées, de décisions et d’actions qui conduit à un résultat. En revanche, le modèle de computing vérifiable exige que le système produise une preuve indépendante liant l’instruction initiale, les données consultées, les outils invoqués et le résultat final. Cette preuve doit être consultable sans se reposer sur la bonne volonté du fournisseur ou du logiciel.
Mécanismes d’audit et preuves cryptographiques
Pour chaque action à fort impact (paiement, modification de code en production, accès à des données régulées), l’article recommande de définir un niveau d’audit incluant : l’instruction ou l’autorisation reçue, les sources d’information exploitées, les outils ou services externes appelés, les décisions prises, les résultats obtenus, ainsi que les identités des utilisateurs ou systèmes initiateurs. La persistance de ces éléments doit traverser les frontières système afin d’éviter les « trous » d’audit où la chaîne se couperait au niveau d’une application. Le texte propose d’utiliser des signatures cryptographiques et des hashes pour garantir l’intégrité de chaque enregistrement et permettre à un auditeur externe de valider que le contenu n’a pas été altéré. Un identifiant unique et traçable doit relier chaque requête initiale aux délégations subséquentes, aux appels d’API et aux approbations humaines éventuelles.
Limites et perspectives
L’article ne fournit pas de métriques précises sur le volume de données d’audit nécessaire ni sur les performances impactées par la génération de preuves cryptographiques. Il reconnaît que la mise en œuvre doit concilier confidentialité, minimisation des données et exigences réglementaires. De plus, la confiance dans les plateformes tierces reste un point critique : les organisations doivent exiger des fournisseurs qu’ils livrent des preuves vérifiables compatibles avec leurs propres exigences d’audit. Enfin, le texte indique que les pratiques de sécurité classiques (gestion d’identité, protection des points de terminaison, surveillance) restent indispensables, mais qu’elles doivent être intégrées dans un cadre plus large où la vérifiabilité constitue le socle de la confiance.
