L’injection rapide n’est pas une hypothèse : des garde-fous pour les agents d’IA dotés d’outils

La démo que tout le monde connaît : un agent lit une page Web contenant des instructions cachées et l'agent commence à les suivre à la place des vôtres. Cela ressemble à un discours de conférence sur la sécurité, mais la version que j'ai utilisée en pratique était beaucoup plus ennuyeuse : un document partagé avec une ligne de texte blanc et un agent qui a consciencieusement transmis le contenu à une adresse qu'il n'aurait jamais dû contacter.

Ce qui est inconfortable, c’est qu’aucune incitation minutieuse ne résout ce problème. Si votre agent lit un texte écrit par quelqu'un d'autre, ce texte est saisi et un modèle ne peut pas distinguer de manière fiable les instructions des données. Dire au modèle d'ignorer les instructions contenues dans les documents ressemble à une solution ; il s'agit d'une suggestion, et les suggestions perdent face aux invites qui ressemblent à la véritable tâche.

Les garde-corps doivent donc vivre en dehors du modèle. Trois choses sur lesquelles j'insiste maintenant : l'agent obtient l'accès à l'outil le plus restreint possible, chaque action consécutive nécessite une étape qu'un humain peut interrompre, et il existe un journal qui enregistre ce que l'agent a fait dans un langage simple que je pourrai lire plus tard. L'ensemble d'autorisations constitue la limite de sécurité réelle ; l'invite est une suggestion adressée à l'agent et non à l'attaquant.

Concrètement : un outil capable d'envoyer des e-mails ne devrait pouvoir envoyer qu'à des adresses déjà présentes sur le compte, et seulement après qu'un humain ait confirmé la liste des destinataires. Un outil capable d'exécuter des commandes shell doit s'exécuter dans un bac à sable sans informations d'identification, car dès que votre agent dispose de vos clés de production, l'attaquant en dispose également. La lecture seule est la meilleure valeur par défaut, et l'accès en écriture est ce que vous gagnez plutôt que ce que vous accordez.

L’autre moitié traite les données comme des données. Tout ce que l'agent lit en dehors de votre organisation (pages Web, e-mails entrants, documents partagés, voire fichiers PDF provenant de clients) est traité comme une entrée non fiable, de la même manière que vous traiteriez l'e-mail d'un inconnu vous demandant de transférer le contrat. L’agent doit le résumer, le citer et vous le transmettre – ne jamais y obéir.

Rien de tout cela ne garantit la sécurité des agents dans l’abstrait. Cela les rend suffisamment en sécurité pour se lancer dans une tâche où le pire résultat est une course inutile au lieu d'un virement bancaire. Je commence désormais chaque automatisation par cette phrase, car si le pire des cas est inacceptable, le choix de l'outil n'est pas le problème que vous devriez résoudre.

Questions fréquemment posées :

Q : L’injection rapide peut-elle être corrigée avec une meilleure invite ?

R : Non. Il peut être réduit, mais pas éliminé, car le modèle ne peut pas séparer de manière fiable les instructions du contenu qu'il a été demandé de lire. La solution fiable consiste à limiter ce que l’agent peut faire, sans lui demander d’être prudent.

Q : Quel est le garde-corps le plus important à ajouter en premier ?

R : Supprimez l'accès en écriture à tout ce qui se trouve en dehors de la tâche. La plupart des incidents d'agent deviennent inoffensifs dès que l'agent ne peut pas envoyer, supprimer ou dépenser sans confirmation humaine. Les agents en lecture seule sont sécurisés par défaut.

Q : En ai-je besoin si j'utilise uniquement des agents sur mes propres fichiers ?

R : Le risque réside dans tout ce que l’agent lit, pas seulement dans ce qu’il écrit. Un document d'un collègue ou d'un client peut contenir les mêmes instructions, et votre agent les traite de la même manière qu'il traite vos notes.