Le secteur de l'intelligence artificielle connaît un débat intense sur les mécanismes de gouvernance des modèles avancés et leur évaluation avant déploiement. Cependant, ces grands débats ignorent souvent le code informatique réel qui détermine si un agent d'IA est autorisé à exécuter des actions sensibles telles que l'envoi d'e-mails, la modification de clés de chiffrement, la fusion de branches logicielles ou le transfert de fonds. Ces décisions ne sont pas prises par les grands laboratoires ni par les textes réglementaires, mais par de simples fonctions logicielles qui renvoient une valeur vrai ou faux.
Les tests de résistance effectués sur un protocole open source de vérification des actions des agents, appelé "PIC", ont montré que les problèmes ne découlent pas nécessairement d'une défaillance du chiffrement, mais de l'acceptation par le protocole de formats multiples, apparemment valides mais sujets à des interprétations divergentes. Par exemple, le schéma structurel peut accepter des codes de hachage en majuscules ou en minuscules, tandis que l'interprète les traite de manières conduisant à des résultats différents d'un système à l'autre, sans pour autant enfreindre les spécifications standard annoncées.
Limites des schémas JSON dans la validation des données
Les schémas JSON jouent un rôle essentiel mais limité dans la validation de la structure des données ; ils s'assurent de la présence des champs requis, de la validité de leurs types de valeurs et de leur conformité aux règles générales. Cependant, le schéma est incapable d'imposer des règles relationnelles complexes, comme garantir qu'une référence spécifique à des preuves pointe vers un élément unique au sein d'un tableau de sources sans répétition ni ambiguïté.
Les différences dans l'exécution des opérations de recherche ou de correspondance d'identifiants entre les différents langages de programmation conduisent à ce que l'on appelle la divergence des analyseurs, un type ancien de vulnérabilité apparu précédemment dans des protocoles comme HTTP et JWT, où deux composants lisent les mêmes entrées de deux manières différentes. Dans les protocoles d'agents modernes, ces nuances conduisent à l'acceptation d'actions dans un service donné alors qu'elles sont refusées par un autre service utilisant la même politique et les mêmes spécifications.
Impact des opérations de normalisation sur la sécurité du protocole
Les développeurs ont tendance à normaliser les entrées pour éviter de rejeter des données récupérables, comme la suppression des espaces excédentaires, la conversion des caractères en minuscules ou la correction des remplissages Base64. Cependant, ces pratiques constituent un risque réel aux frontières de l'authentification. Par exemple, si l'interprète normalise le nom d'un outil ou supprime les espaces avant de le comparer avec une liste blanche, le système pourrait exécuter une action non approuvée par la partie signataire, ou manipuler les autorisations d'exécution à l'insu des développeurs.
De plus, se fier aux champs envoyés par l'agent lui-même pour confirmer la fiabilité de sa source ouvre la porte au problème du mandataire confus sous forme numérique. La confiance doit être dérivée exclusivement à l'intérieur des limites de l'application de la loi et de la vérification, par la validation des signatures numériques et leur correspondance avec des clés cryptographiques auxquelles l'opérateur fait directement confiance, indépendamment des déclarations contenues dans la charge utile de la requête.
Structure à trois couches et vecteurs de correspondance d'exécution
Pour éviter ces vulnérabilités, une structure séparant clairement trois couches successives est nécessaire :
- Validation du schéma : pour rejeter les structures corrompues et les représentations non conformes au réseau.
- Validation sémantique : pour résoudre les références, vérifier les corrélations et dériver la confiance réelle.
- Évaluation des politiques : pour prendre la décision finale concernant l'autorisation ou le blocage de l'exécution de l'action.
Il ne suffit pas de s'en tenir aux notes documentaires ; des outils de test de conformité d'exécution clairs sont nécessaires, incluant des entrées précises, des résultats attendus et des codes d'erreur stables pour traiter les cas ambigus. Ces vecteurs garantissent l'uniformité du comportement à travers toutes les implémentations et empêchent la sécurité de dépendre de configurations par défaut divergentes dans les différents ponts logiciels.