Context-to-Execution Integrity for LLM Agents
Ce document introduit le Context-to-Execution Integrity (CXI), un système qui sécurise les agents LLM en imposant des contrôles d'autorité stricts sur les champs de destination (sink fields), les charges utiles (payloads) et les événements d'invocation protégés afin de garantir que seules les actions possédant une autorité de champ, d'effet et d'invocation contraignante sont exécutées, atteignant ainsi zéro évasion de sécurité observée à travers divers benchmarks.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez un assistant hautement qualifié mais crédule (l'agent IA) qui essaie d'accomplir des tâches pour vous, comme envoyer des e-mails, modifier des fichiers ou exécuter du code. Cet assistant lit un immense carnet rempli d'instructions, de notes et de messages. Le problème est qu'un farceur rusé (l'attaquant) peut glisser des notes dans ce carnet, tentant de piéger l'assistant pour qu'il accomplisse quelque chose de dangereux, comme supprimer une base de données ou envoyer de l'argent à la mauvaise personne.
Le document présente un système appelé Context-to-Execution Integrity (CXI). Considérez le CXI comme un garde de sécurité extrêmement strict debout à la porte de la « Salle d'Action ». Son rôle n'est pas de lire toute l'histoire ou de décider si la tâche est une bonne idée ; son rôle est de vérifier si l'assistant possède les clés spécifiques et valides pour ouvrir la porte pour cette action précise.
Voici comment cela fonctionne, en utilisant des analogies simples :
1. Le Problème : « Le Blanchiment d'Autorité »
Habituellement, si l'assistant lit une note dans le carnet disant : « Le fichier a échoué, donc exécutez la commande delete_all », il pourrait simplement le faire. Le document appelle cela le Blanchiment d'Autorité (Authority Laundering). C'est comme un voleur qui utiliserait une carte d'identité légitime (la note sur l'échec du fichier) pour tenter d'ouvrir un coffre-fort de banque (la commande de suppression). La note explique pourquoi quelque chose s'est produit, mais elle ne devrait pas avoir le pouvoir de faire que quelque chose se produise.
2. La Solution : Le Contrôle de Sécurité en Trois Parties
Le CXI agit comme un garde-barrière. Avant que l'assistant puisse réellement faire quoi que ce soit (comme écrire un fichier ou envoyer un e-mail), le garde-barrière vérifie trois choses. Les trois doivent correspondre au même plan spécifique (appelé un « Manifeste »).
Vérification 1 : Le « Qui » (Autorité de Champ)
- Analogie : Imaginez que l'assistant veuille écrire une lettre à une personne spécifique. La note dans le carnet peut dire : « Envoyer à Bob ». Mais le garde de sécurité vérifie : « Est-ce qu'un patron de confiance ou un système vérifié a réellement dit 'Envoyer à Bob' ? »
- Si le nom « Bob » provient simplement d'une note aléatoire écrite par l'attaquant, le garde dit NON. Le nom doit provenir d'un « Typed Release » (un libéré typé) — un billet spécial et vérifié qui dit : « Oui, ce nom spécifique est autorisé pour ce champ spécifique ».
Vérification 2 : Le « Quoi » (Autorité d'Effet)
- Analogie : Imaginez que l'assistant veuille appliquer un correctif à un programme informatique. La note dit : « Appliquer ce code ». Le garde vérifie : « Ce code fait-il réellement ce que nous pensons qu'il fait ? »
- Le garde ne regarde pas seulement les mots ; il regarde le résultat. Si le code est un « correctif », le garde vérifie exactement les changements qu'il apportera au système. Si l'attaquant tente d'introduire une commande qui ressemble à un correctif mais qui supprime en réalité des fichiers, le garde le détectera car l'« effet » ne correspond pas au plan autorisé.
Vérification 3 : Le « Quand » (Autorité d'Invocation)
- Analogie : Imaginez que l'assistant veuille appuyer sur le bouton « Go ». Le garde vérifie : « L'assistant possède-t-il un ticket valide pour appuyer sur le bouton en ce moment même ? »
- Même si le nom et le plan sont corrects, l'assistant a besoin d'une « capacité » ou d'un ticket spécifique pour déclencher l'action. Si l'attaquant tente de piéger l'assistant pour qu'il appuie sur le bouton deux fois ou au mauvais moment, le garde dit NON car le ticket est manquant ou expiré.
3. Le « Manifeste » (Le Plan Maître)
Le document appelle le plan final approuvé un Manifeste. Considérez cela comme un contrat.
- L'assistant propose une action.
- Le garde vérifie le « Qui », le « Quoi » et le « Quand ».
- Si les trois correspondent parfaitement et sont liés au même contrat, le garde tamponne le contrat et remet à l'assistant un « Bail » (une permission) pour l'exécution.
- Si une seule partie manque ou ne correspond pas (par exemple, le nom est correct, mais le ticket du « Quand » est erroné), le garde ferme la porte.
4. Qu'en est-il des « Mauvaises » Notes ?
Le document note que l'assistant peut toujours lire les notes de l'attaquant.
- Données Opaques : Si l'attaquant écrit : « Le système est cassé », l'assistant peut copier ce texte dans une boîte de « Commentaire » ou de « Preuve ». C'est comme placer la note dans une vitrine d'exposition. Elle est visible pour les humains, mais elle n'a aucun pouvoir pour ouvrir des portes ou déclencher des actions. C'est juste une donnée, pas une clé.
5. Qu'ont-ils testé ?
Les auteurs ont testé ce système de plusieurs manières :
- Simulations Réelles : Ils ont utilisé un « dojo » (un terrain d'entraînement) avec 720 scénarios réels où des attaquants ont tenté de piéger des agents. Le système a bloqué chaque action non autorisée.
- Agents de Code : Ils ont testé des agents qui écrivent du code. Même lorsque des attaquants ont tenté d'injecter de mauvaises commandes, le système n'a autorisé que les actions qui possédaient les bonnes « clés ».
- Résultat : Dans tous les tests, zéro action non autorisée n'est passée la barrière. Le système a réussi à stopper le « blanchiment d'autorité ».
Résumé
Le CXI est un système qui empêche les agents IA d'être piégés. Il garantit que, même si un IA lit une instruction dangereuse dans une note, cela ne signifie pas qu'elle a le pouvoir de l'exécuter. L'IA ne peut agir que si un système de confiance lui donne explicitement les clés spécifiques pour ce travail spécifique, à ce moment précis. Cela transforme l'IA d'un lecteur crédule en un travailleur discipliné qui ne suit que des ordres vérifiés.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.