Ce que vous avez vérifié n'est pas ce qui s'exécute
Un nouvel outil a récemment attiré l'attention. Il s'interpose devant des commandes comme curl et vous montre le script avant son exécution. Il met en évidence les parties dangereuses. Cet outil est utile, mais il passe à côté du problème de fond.
Le problème n'est pas de savoir si les octets semblent malveillants. Le problème est qu'une URL peut servir un script aujourd'hui et un autre demain. Votre vérification ne s'applique qu'à un instant précis.
Les experts en systèmes appellent cela le TOCTOU. Cela signifie « time-of-check to time-of-use » (du moment de la vérification au moment de l'utilisation). Vous vérifiez un fichier, puis quelqu'un le remplace avant que vous ne l'ouvriez. Votre vérification était correcte, mais elle portait sur une chose qui n'existe plus.
Les agents d'IA augmentent considérablement ce risque. Les agents effectuent des vérifications en permanence.
- Un agent interroge une URL et considère une réponse réussie comme un signe de sécurité.
- Un agent lit un profil et traite une déclaration comme un fait.
- Un agent voit une signature et suppose que les octets exacts qu'il est sur le point d'exécuter sont ceux qui ont été signés.
Chaque vérification attache la confiance à un moment ou à un canal. L'agent agit ensuite sur un élément en aval que la vérification n'a jamais couvert.
Par exemple, un agent pourrait valider le manifeste d'un outil et mettre le résultat en cache. Si le point de terminaison change avant que l'agent n'appelle l'outil, l'agent exécute la mauvaise version. La validation a réussi, mais elle a réussi pour un manifeste que l'agent n'utilise plus.
Essayer de corriger cela en renforçant l'analyse ne fonctionne pas. Plus de règles ne font que rétrécir la fenêtre. Elles ne la ferment pas. Un producteur peut toujours servir un artefact différent dans les millisecondes qui séparent votre analyse de votre exécution.
Pour corriger cela, arrêtez de vérifier l'instant. Commencez à vérifier l'artefact.
Liez vos décisions à un objet immuable plutôt qu'à un fetch.
- N'approuvez pas une URL.
- Approuvez un hash de contenu spécifique.
- Mieux encore, approuvez un hash signé par une clé de confiance.
Cela change la question : de « ce texte est-il inquiétant ? » à « est-ce l'artefact exact pour lequel la clé s'est portée garante ? ». Si le hash ne correspond pas, vous le refusez. Il n'y a pas de débat.
Cette approche rend également la vérification portable. Un tiers peut utiliser le même hash et la même signature pour vérifier lui-même le résultat. C'est une propriété de l'objet, pas une propriété de votre après-midi.
Utilisez ces deux questions pour tester toute vérification :
- La vérification est-elle liée à l'artefact exact utilisé, ou à un instant et à une promesse ?
- Un inconnu peut-il relancer la vérification et parvenir au même verdict ?
Si la réponse à la première est un instant, la vérification a une date d'expiration. Si la réponse à la seconde est non, vous n'avez pas une vérification. Vous avez un témoignage.
La plupart des vérifications d'agents actuelles ne sont que des témoignages. « Le handshake a réussi » ou « le scan était propre » sont des affirmations vraies concernant un instant, mais elles ne sont pas liées aux octets qui s'exécutent réellement.
Les agents agissent des milliers de fois sans supervision humaine. Si vous n'ancrez pas la confiance aux artefacts, toute la chaîne hérite de la vérification la plus faible et la plus ancienne.
Vous n'avez pas besoin d'une nouvelle technologie pour corriger cela. L'adressage par contenu et les signatures numériques existent depuis des décennies. Il vous suffit de les diriger vers la bonne chose : les octets exacts qui s'exécutent, et non la requête qui les a récupérés.
Avant de faire confiance à une vérification, découvrez à quoi elle est liée. Si elle est liée à un instant, elle a déjà expiré.
Source : https://dev.to/anp2network/the-thing-you-verified-is-not-the-thing-that-runs-hnl
Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi