Renforcement continu de ChatGPT Atlas contre les attaques d’injection de prompt

Le mode agent dans ChatGPT Atlas est l’une des fonctionnalités agentiques les plus polyvalentes que nous ayons publiées à ce jour. Dans ce mode, l’agent du navigateur consulte les pages Web et effectue des actions, des clics et des frappes à l’intérieur de votre navigateur, tout comme vous le feriez. Cela permet à ChatGPT de fonctionner directement sur plusieurs de vos flux de travail quotidiens en utilisant le même espace, le même contexte et les mêmes données.

À mesure que l’agent de navigateur vous aide à accomplir davantage, il devient aussi une cible de plus grande valeur pour les attaques malveillantes. C’est pourquoi la sécurité de l’IA est particulièrement importante. Bien avant le lancement de ChatGPT Atlas, nous avons continuellement renforcé et durci nos défenses contre les menaces émergentes qui ciblent spécifiquement ce nouveau paradigme d’« agent dans le navigateur ». L’injection de prompt⁠ est l’un des risques les plus importants contre lesquels nous nous défendons activement pour garantir que ChatGPT Atlas puisse opérer en toute sécurité pour votre compte. 

Dans le cadre de cet effort, nous avons récemment déployé une mise à jour de sécurité pour l’agent de navigateur d’Atlas, comprenant un nouveau modèle entraîné contre les attaques malveillantes et des mesures de protection renforcées. Cette mise à jour a été motivée par une nouvelle classe d’attaques par injection de prompt découverte grâce à notre équipe rouge automatisée interne.

Dans cet article, nous expliquons comment le risque d’injection de prompt peut survenir pour les agents Web, et nous partageons une boucle de réponse rapide que nous avons mise en place pour découvrir continuellement de nouvelles attaques et déployer rapidement des mesures d’atténuation, comme illustré par cette récente mise à jour de sécurité.

Nous considérons l’injection de prompt comme un défi de sécurité à long terme pour l’IA, et il nous faudra continuellement renforcer nos défenses contre elle (un peu comme pour les escroqueries en ligne qui évoluent constamment et ciblent les humains). Notre tout dernier cycle de réponse rapide se révèle prometteur et constitue un outil essentiel dans cette démarche : nous découvrons en interne de nouvelles stratégies d’attaque avant même qu’elles ne soient réellement déployées. Notre vision à long terme est de tirer pleinement parti (1) de notre accès en boîte blanche à nos modèles, (2) de notre compréhension approfondie de nos défenses et (3) de notre capacité de calcul afin de garder une longueur d’avance sur les attaquants externes : détecter les exploits plus tôt, expédier les atténuations plus rapidement et resserrer continuellement la boucle. Combinée à la recherche de pointe sur de nouvelles techniques pour contrer l’injection de prompt et à un investissement accru dans d’autres contrôles de sécurité, cette dynamique cumulative peut rendre les attaques de plus en plus difficiles et coûteuses, réduisant ainsi de manière significative le risque d’injection de prompt dans le monde réel. En fin de compte, notre objectif est que vous puissiez faire confiance à un agent ChatGPT et le laisser utiliser votre navigateur comme vous le feriez avec un collègue ou un ami hautement compétent et conscient des enjeux de sécurité.

Une attaque par injection de prompt cible les agents IA en insérant des instructions malveillantes dans le contenu que l’agent traite. Ces instructions sont conçues pour contourner ou rediriger le comportement de l’agent en le détournant pour qu’il suive l’intention de l’attaquant, plutôt que celle de l’utilisateur.

Pour un agent de navigateur tel que celui intégré dans ChatGPT Atlas, l’injection de prompt ajoute un nouveau vecteur de menace au-delà des risques traditionnels de sécurité Web (tels que les erreurs des utilisateurs ou les vulnérabilités logicielles). Au lieu de faire du hameçonnage sur des humains ou d’exploiter les vulnérabilités du système du navigateur, l’attaquant cible l’agent opérant à l’intérieur de ce dernier.

À titre d’exemple hypothétique, un attaquant pourrait envoyer un courriel malveillant tentant de tromper un agent afin qu’il ignore la demande de l’utilisateur et transmette plutôt des documents fiscaux sensibles à une adresse courriel contrôlée par l’attaquant. Si un utilisateur demande à l’agent de passer en revue les courriels non lus et de résumer les points clés, l’agent pourrait ingérer ce courriel malveillant au cours du flux de travail. En suivant les instructions injectées, il pourrait dévier de sa tâche et partager par erreur des renseignements sensibles.

Ceci n’est qu’un scénario possible parmi d’autres. La même généralité qui rend les agents de navigateur utiles accroît également les risques : l’agent peut rencontrer des instructions non fiables sur une surface d’interaction pratiquement illimitée : courriels et pièces jointes, invitations de calendrier, documents partagés, forums, publications sur les réseaux sociaux et pages Web arbitraires. Étant donné que l’agent peut effectuer de nombreuses actions qu’un utilisateur peut réaliser dans un navigateur, l’impact d’une attaque réussie pourrait être tout aussi vaste : transférer un courriel sensible, envoyer de l’argent, modifier ou supprimer des fichiers dans le nuage, et plus encore.

Nous avons fait des progrès dans la défense contre l’injection de prompt grâce à plusieurs couches de protection, comme nous l’avons mentionné dans un article précédent⁠. Toutefois, l’injection de prompt demeure un défi persistant pour la sécurité des agents, et nous prévoyons de continuer à y travailler pendant de nombreuses années encore.

Pour renforcer nos défenses, nous recherchons continuellement de nouvelles attaques par injection de prompt contre les systèmes d’agents en production. L’identification de ces attaques est un préalable nécessaire à la mise en place de mesures d’atténuation robustes : cela nous aide à comprendre les risques réels, à mettre en lumière les failles dans nos défenses et à élaborer des correctifs concrets.

Pour y parvenir à grande échelle, nous avons construit un attaquant automatisé basé sur un LLM et l’avons entraîné à rechercher des attaques par injection de prompt capables d’attaquer efficacement un agent de navigateur. Nous avons formé cet attaquant de bout en bout grâce à l’apprentissage par renforcement, afin qu’il apprenne de ses propres succès et échecs pour améliorer ses compétences en approche d’équipe rouge. Nous lui permettons également d’« essayer avant d’expédier », ce qui signifie que, pendant son raisonnement par chaîne de pensée, l’attaquant peut proposer une injection candidate et l’envoyer à un simulateur externe. Le simulateur effectue une exécution contrefactuelle de la façon dont l’agent victime ciblé (le défenseur) se comporterait s’il rencontrait l’injection, et renvoie une trace complète du raisonnement et des actions de l’agent victime. L’attaquant utilise cette trace comme rétroaction, itère sur l’attaque et relance la simulation, répétant cette boucle plusieurs fois avant de s’engager dans une attaque finale. Cela fournit un retour d’information contextuel plus riche à l’attaquant qu’un simple signal de réussite/échec. Cela augmente également la puissance de calcul de l’attaquant pendant la mise à l’essai. De plus, un accès privilégié aux traces de raisonnement (que nous ne divulguons pas aux utilisateurs externes) du défenseur donne à notre attaquant interne un avantage asymétrique, augmentant ainsi les chances qu’il puisse surpasser ses adversaires externes.

Pourquoi l’apprentissage par renforcement (RL)? Nous avons opté pour l’apprentissage par renforcement afin d’entraîner l’attaquant automatisé pour plusieurs raisons :

1. Optimisation des objectifs d’attaquant à long terme et de manière discontinue. Notre objectif est de rechercher des attaques par injection de prompt susceptibles de tromper l’agent en l’obligeant à exécuter des tâches malveillantes sophistiquées (p. ex., envoyer des courriels, effectuer des transactions bancaires) qui pourraient se produire dans le monde réel. Ces tâches malveillantes ont intrinsèquement un horizon lointain, nécessitant de nombreuses étapes de raisonnement et d’interaction avec l’environnement, avec des signaux de succès rares et retardés. L’apprentissage par renforcement convient bien à cette structure de récompenses rares et différées.
2. Exploiter les capacités de pointe des LLM. Nous avons entraîné directement des modèles LLM de pointe en tant qu’équipes rouges automatiques, de sorte que l’attaquant bénéficie directement des améliorations apportées au raisonnement et à la planification dans les modèles de pointe. À mesure que les modèles de base se renforcent, l’attaquant devient naturellement plus compétent également, ce qui constitue un moyen évolutif de maintenir la pression sur nos défenses à mesure que nos modèles évoluent.
3. Renforcement des ressources de calcul et simulation des attaquants adaptatifs. L’apprentissage par renforcement est bien adapté pour renforcer les calculs consacrés à la recherche d’attaques sur un grand nombre d’échantillonnages et d’étapes d’apprentissage; il reflète aussi étroitement le comportement des attaquants humains adaptatifs : essayer des stratégies de manière itérative, apprendre des résultats et renforcer les comportements réussis.
   

Notre attaquant automatisé peut découvrir de bout en bout des attaques par injection de prompt nouvelles et réalistes. Contrairement à la plupart des travaux d’équipe rouge automatisés précédents, qui faisaient apparaître des défaillances simples comme l’obtention de chaînes de sortie spécifiques ou le déclenchement involontaire d’un appel d’outil en une seule étape de la part de l’agent, notre attaquant entraîné en apprentissage par renforcement peut orienter un agent vers l’exécution de flux de travail sophistiqués et nuisibles à long terme qui se déroulent sur des dizaines (voire des centaines) d’étapes. Nous avons également observé des stratégies d’attaque inédites qui n’apparaissaient pas dans notre campagne d’approche d’équipe rouge humaine ou dans les rapports externes.

La démonstration ci-dessous présente une attaque concrète par injection de prompt découverte par notre attaquant automatisé, que nous avons ensuite utilisée pour renforcer davantage les défenses de ChatGPT Atlas. L’attaquant introduit dans la boîte de réception de l’utilisateur un courriel malveillant contenant une injection de prompt qui demande à l’agent d’envoyer une lettre de démission au Chef de la direction (PDG) de l’utilisateur. Plus tard, lorsque l’utilisateur demande à l’agent de rédiger un courriel d’absence automatique, l’agent rencontre cet dernier lors de l’exécution normale des tâches, considère le prompt injecté comme faisant autorité et le suit. Le message d’absence n’est jamais rédigé et l’agent démissionne au nom de l’utilisateur.

La nature de l’injection de prompt rend difficile l’obtention de garanties de sécurité déterministes, mais en intensifiant nos recherches automatisées en matière de sécurité ainsi que nos tests adverses, et en resserrant notre boucle de réponse rapide, nous sommes en mesure d’améliorer la robustesse et les défenses du modèle, avant même qu’une attaque ne se produise en conditions réelles. 

Nous partageons cette démonstration pour aider les utilisateurs et les chercheurs à mieux comprendre la nature de ces attaques, et comment nous nous défendons activement contre elles. Nous croyons que cela représente la limite maximale de ce que l’approche d’équipe rouge automatisée peut accomplir, et nous sommes extrêmement enthousiastes à l’idée de poursuivre nos recherches.

Notre approche d’équipe rouge automatisée alimente une boucle de réponse rapide proactive : lorsque l’attaquant automatisé découvre une nouvelle classe d’attaques réussies par injection de prompt, elle crée immédiatement une cible concrète pour améliorer nos défenses.

Entraînement par confrontation contre les attaques nouvellement découvertes. Nous entraînons continuellement des modèles d’agents mis à jour en les confrontant à notre meilleur attaquant automatisé, en priorisant les attaques où les agents cibles échouent actuellement. L’objectif est d’apprendre aux agents à ignorer les instructions malveillantes et à rester alignés sur l’intention de l’utilisateur, ce qui améliore la résistance aux nouvelles stratégies d’injection de prompt récemment découvertes. Cela permet d’« intégrer » directement la robustesse contre les attaques nouvelles et puissantes dans le point de contrôle du modèle. Par exemple, l’approche d’équipe rouge automatisée récente a directement produit un nouveau point de contrôle d’agent de navigateur entraîné de manière par confrontation, qui a déjà été déployé pour tous les utilisateurs de ChatGPT Atlas. À terme, cela nous aide à mieux protéger nos utilisateurs contre de nouveaux types d’attaques.

Utiliser les traces d’attaque pour améliorer l’ensemble plus large du système de défense. De nombreux chemins d’attaque découverts par notre équipe rouge automatisée révèlent aussi des opportunités d’amélioration en dehors du modèle lui-même, comme la surveillance, les instructions de sécurité que nous mettons dans le contexte du modèle, ou les mesures de sécurité au niveau du système. Ces résultats nous aident à améliorer l’ensemble du système de défense, pas seulement le point de contrôle de l’agent.

Répondre aux attaques actives. Cette boucle peut également aider à mieux répondre aux attaques actives en cours. En regardant notre empreinte mondiale à la recherche d’attaques potentielles, nous pouvons prendre les techniques et tactiques que nous observons chez les adversaires externes, les intégrer à cette boucle, imiter leur activité et provoquer un changement défensif sur toute notre plateforme.

En renforçant notre capacité à mobiliser les agents de l’équipe rouge et en utilisant nos modèles les plus performants pour automatiser certaines parties de ce travail, nous contribuons à rendre l’agent du navigateur Atlas plus robuste en augmentant l’échelle du cycle de découverte à correction. Cet effort de renforcement souligne une leçon bien connue en matière de sécurité : un chemin éprouvé vers une protection renforcée consiste à tester en continu les systèmes réels, à réagir aux échecs et à livrer des correctifs concrets.

Nous nous attendons à ce que les adversaires continuent de s’adapter. L’injection de prompt, tout comme les escroqueries et l’ingénierie sociale sur le Web, est peu susceptible d’être un jour entièrement « résolue ». Mais nous avons bon espoir qu’une boucle de réponse rapide proactive, hautement réactive, puisse continuer à réduire de manière significative les risques réels au fil du temps. En combinant la découverte automatisée des attaques avec l’entraînement par confrontation et les mesures de protection au niveau du système, nous pouvons identifier plus tôt de nouveaux schémas d’attaque, combler les lacunes plus rapidement et augmenter continuellement le coût de l’exploitation.

Le mode Agent dans ChatGPT Atlas est puissant, mais il élargit également la surface de menace de sécurité. Être lucide face à ce compromis fait partie de la construction responsable. Notre objectif est de rendre Atlas sensiblement plus sécurisé à chaque itération : améliorer la robustesse du modèle, renforcer le système de défense environnant et surveiller les nouveaux schémas d’abus émergents dans le monde réel.

Nous continuerons d’investir dans la recherche et le déploiement, en développant de meilleures méthodes automatisées d’équipe rouge, en déployant des mesures d’atténuation en couches, et en itérant rapidement à mesure que nous apprenons. Nous partagerons également ce que nous pouvons avec la communauté au sens large.

Alors que nous continuons à renforcer Atlas au niveau du système, les utilisateurs peuvent prendre certaines mesures pour réduire les risques lors de l’utilisation des agents. 

Limiter l’accès des utilisateurs ayant ouvert une session autant que possible. Nous continuons de recommander aux utilisateurs de profiter du mode fermeture de session⁠(s'ouvre dans une nouvelle fenêtre) lors de l’utilisation de l’agent dans Atlas, chaque fois que l’accès aux sites Web dans lesquels vous avez ouvert une session n’est pas nécessaire pour la tâche en cours, ou pour limiter l’accès aux sites spécifiques dans lesquels vous ouvrez une session pendant la tâche. 

Examinez attentivement les demandes de confirmation. Pour certaines actions importantes, comme effectuer un achat ou envoyer un courriel, les agents sont conçus pour demander votre confirmation avant d’aller de l’avant. Lorsqu’un agent vous demande de confirmer une action, prenez un moment pour vérifier que l’action est correcte et que tout renseignement partagé est approprié pour ce contexte.

Donnez des instructions explicites aux agents quand c’est possible. Évitez les prompts trop généraux comme « examine mes courriels et prends les mesure nécessaires ». Cette grande latitude facilite l’influence d’un contenu caché ou malveillant sur l’agent, même lorsque des mesures de protection sont en place. Il est plus sûr de demander à l’agent d’effectuer des tâches spécifiques et bien définies. Bien que cela n’élimine pas le risque, cela rend les attaques plus difficiles à mener.

Pour que les agents deviennent des partenaires de confiance pour les tâches quotidiennes, ils doivent être résilients face aux types de manipulation que permet le Web ouvert. Le renforcement contre les injections de prompt est un engagement à long terme et l’une de nos principales priorités. Nous communiquerons plus largement à ce sujet sous peu.