Concevoir des agents IA pour résister aux attaques par injection d’invite

Les agents d’IA sont de plus en plus capables de naviguer sur le web, de récupérer des informations et d’effectuer des actions pour le compte de l’utilisateur. Ces capacités sont utiles, mais elles créent aussi de nouvelles possibilités pour les attaquants de tenter de manipuler le système.

Ces attaques sont souvent décrites comme attaque par injection d’invite⁠ : des instructions placées dans du contenu externe dans le but de faire faire au modèle quelque chose que l'utilisateur n'a pas demandé. D’après notre expérience, les versions les plus efficaces de ces attaques dans le monde réel ressemblent de plus en plus à de l’ingénierie sociale plutôt qu’à de simples contournements d'invite.

Cette évolution est importante. Si le problème ne consiste pas seulement à identifier une chaîne malveillante, mais à résister à un contenu trompeur ou manipulateur dans son contexte, alors la défense ne peut pas reposer uniquement sur le filtrage des entrées. Cela nécessite aussi de concevoir le système de manière à limiter l’impact d’une manipulation, même si certaines attaques réussissent.

Les premières attaques de type « attaque par injection d’invite » pouvaient être aussi simples que modifier un article Wikipédia pour y inclure des instructions directes destinées aux agents d’IA qui le consultaient ; sans expérience à l’entraînement dans un environnement adversarial de ce type, les modèles d’IA suivaient souvent ces instructions sans les remettre en question¹. Alors que les modèles sont devenus plus performants, ils sont aussi devenus moins vulnérables à ce type de suggestion, et nous avons observé que les attaques de type injection d’invite ont évolué en intégrant des éléments d’ingénierie sociale :

Dans l’écosystème plus large de la sécurité de l’IA, il est devenu courant de recommander des techniques comme les « pare-feu pour l’IA », dans lesquelles un intermédiaire entre l’agent d’IA et le monde extérieur tente de classer les entrées entre attaques par injection d’invite malveillantes et entrées normales, mais ces attaques pleinement élaborées ne sont généralement pas détectées par de tels systèmes. Pour ces systèmes, détecter une entrée malveillante revient au même problème très difficile que serait de détecter un mensonge ou une information trompeuse, et souvent sans le contexte nécessaire.

Alors que les attaques par injection d’invite en conditions réelles gagnaient en complexité, nous avons constaté que les techniques offensives les plus efficaces s'appuyaient sur des manœuvres d'ingénierie sociale. Plutôt que de considérer ces attaques par injection d’invite intégrant de l’ingénierie sociale comme une catégorie de problème distincte ou entièrement nouvelle, nous avons commencé à les analyser à travers le même prisme que celui utilisé pour gérer les risques d’ingénierie sociale chez les humains dans d’autres domaines. Dans ces systèmes, l’objectif ne consiste pas seulement à identifier parfaitement les entrées malveillantes, mais à concevoir des agents et des systèmes de manière à limiter l’impact d’une manipulation, même si elle réussit. De tels systèmes se révèlent efficaces pour atténuer à la fois les attaques par injection d’invite et l’ingénierie sociale.

De cette manière, on peut imaginer l’agent d’IA comme évoluant dans un système à trois acteurs similaire à celui d’un agent du service client : l’agent agit pour le compte de son employeur, mais il est en permanence exposé à des entrées externes susceptibles de tenter de le tromper. L’agent du support client, humain ou IA, doit voir ses capacités limitées afin de réduire les risques potentiels liés à l’évolution dans un tel environnement malveillant.

Imaginez une situation dans laquelle un humain gère un système de support client et peut accorder des cartes-cadeaux et des remboursements pour des désagréments subis par le client, comme des retards de livraison, des dommages dus à un dysfonctionnement, etc. Il s’agit d’un problème multipartite dans lequel l’entreprise doit avoir confiance dans le fait que l’agent accorde des remboursements pour les bonnes raisons, tandis que l’agent interagit également avec des tiers susceptibles de tenter de le tromper, voire de le placer sous pression.

Dans le monde réel, l'agent reçoit un ensemble de règles à suivre, mais on s'attend à ce que, dans l'environnement adversarial dans lequel il évolue, il soit induit en erreur. Par exemple, un client peut envoyer un message affirmant que son remboursement n’a jamais été effectué, ou menacer de causer un préjudice s’il n’obtient pas de remboursement. Les systèmes déterministes avec lesquels l’agent interagit limitent le montant des remboursements pouvant être accordés à un client, signalent les courriels d’hameçonnage potentiels et offrent d’autres mécanismes d’atténuation afin de limiter l’impact de la compromission d’un agent individuel.

Cet état d’esprit a guidé la mise en place d’un ensemble robuste de contre-mesures que nous avons déployées afin de respecter les exigences de sécurité de nos utilisateurs.

Dans ChatGPT, nous combinons ce modèle d’ingénierie sociale avec des approches plus traditionnelles d’ingénierie de sécurité, comme l’analyse source-puits.

Dans ChatGPT, nous combinons ce modèle d’ingénierie sociale avec des approches plus traditionnelles d’ingénierie de sécurité, comme l’analyse source-puits. Pour les systèmes agentifs, cela signifie souvent combiner un contenu externe non fiable avec une action telle que transmettre des informations à un tiers, suivre un lien ou interagir avec un outil.

Notre objectif est de préserver une attente de sécurité fondamentale pour les utilisateurs : des actions potentiellement dangereuses, ou la transmission d’informations potentiellement sensibles, ne doivent pas se produire en silence ni sans garde-fous appropriés.

Les attaques que nous observons le plus souvent contre ChatGPT consistent à tenter de convaincre l'assistant qu'il doit extraire des informations secrètes d'une conversation et les transmettre à un tiers malveillant. Dans la plupart des cas que nous avons observés, ces attaques échouent, car notre entraînement à la sécurité pousse l’agent à refuser. Dans les cas où l’agent est convaincu, nous avons développé une stratégie d’atténuation appelée Safe Url, conçue pour détecter lorsque des informations apprises par l’assistant au cours de la conversation seraient transmises à un tiers. Dans ces rares cas, nous affichons soit à l’utilisateur les informations qui seraient transmises et lui demandons de confirmer, soit nous bloquons la transmission et demandons à l’agent d’essayer une autre manière de poursuivre la requête de l’utilisateur.

Ce même mécanisme s'applique aux navigations et aux signets dans Atlas⁠; ainsi qu'aux recherches et aux navigations dans Recherche approfondie⁠. ChatGPT Canvas⁠ et ChatGPT Apps⁠ adoptent une approche similaire, permettant à l'agent de créer et d'utiliser des applications fonctionnelles—celles-ci s'exécutent dans un bac à sable capable de détecter des communications inattendues et de demander le consentement de l'utilisateur⁠(s'ouvre dans une nouvelle fenêtre).

Vous pouvez en savoir plus sur Safe Url et consulter un article décrivant sa structure dans le billet de blogue dédié Protéger vos données lorsqu’un agent d’IA clique sur un lien⁠.

Une interaction sûre avec le monde extérieur hostile est nécessaire pour des agents entièrement autonomes. Lors de l’intégration d’un modèle d’IA dans un système applicatif, nous recommandons de se demander quels contrôles un agent humain devrait avoir dans une situation similaire et de les mettre en place. Nous nous attendons à ce qu'un modèle d'IA doté d'une intelligence maximale soit en mesure de résister à l'ingénierie sociale mieux qu'un agent humain, mais cela n'est pas toujours réalisable ni rentable selon l'application.

Nous continuons d’explorer les implications de l’ingénierie sociale visant les modèles d’IA ainsi que les moyens de s’en défendre, et d’intégrer nos conclusions à la fois dans nos architectures de sécurité applicative et dans l’entraînement de nos modèles d’IA.