Renforcement continu de ChatGPT Atlas contre les attaques par injection de prompt

Le mode Agent dans ChatGPT Atlas est l'une des fonctionnalités d'agent les plus polyvalentes que nous ayons lancé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 bon nombre de vos flux de travail quotidiens en utilisant le même espace, le même contexte et les mêmes données.

Alors que l'agent du navigateur vous aide à être plus productif, il devient également une cible de plus grande valeur pour les attaques malveillantes. Cela rend la sécurité de l'IA particulièrement importante. Bien avant le lancement de ChatGPT Atlas, nous avons continuellement renforcé 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 significatifs contre lesquels nous nous défendons activement pour garantir que ChatGPT Atlas puisse fonctionner en toute sécurité pour vous. 

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, incluant un modèle nouvellement entraîné de manière antagoniste 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 interne de red teaming automatisé.

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étecter en permanence les nouvelles attaques et proposer 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 nous devrons continuellement renforcer nos défenses contre elle (à l'instar des escroqueries en ligne en constante évolution qui ciblent les humains). Notre dernier cycle de réponse rapide s'avère très prometteur en tant qu'outil essentiel dans cette démarche : nous identifions de nouvelles stratégies d'attaque en interne avant qu'elles n'apparaissent dans la nature. 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 pour garder une longueur d'avance sur les pirates externes, en identifiant les failles plus tôt, en déployant les mesures d'atténuation plus rapidement et en renforçant continuellement le processus. Associé à la recherche de pointe sur les nouvelles techniques permettant de lutter contre les injections de prompt et à l'augmentation des investissements dans d'autres contrôles de sécurité, ce cycle combiné peut rendre les attaques de plus en plus difficiles et coûteuses, réduisant ainsi considérablement le risque réel d'injection de prompt. En fin de compte, notre objectif est que vous puissiez faire confiance à un agent ChatGPT pour utiliser votre navigateur comme vous le feriez avec un collègue ou un ami hautement compétent et sensibilisé à la sécurité.

Une attaque par injection de prompt cible les agents IA en insérant des instructions malveillantes dans le contenu traité par l'agent. Ces instructions sont conçues pour outrepasser ou rediriger le comportement de l'agent, le détournant pour suivre l'intention d'un pirate plutôt que celle de l'utilisateur.

Pour un agent navigateur tel que celui intégré à ChatGPT Atlas, l'injection de requêtes ajoute un nouveau vecteur de menace qui s'ajoute aux risques traditionnels liés à la sécurité Web (tels que les erreurs utilisateur ou les vulnérabilités logicielles). Au lieu de tenter de phishing ou d'exploiter les vulnérabilités du système du navigateur, le pirate cible l'agent qui y opère.

À titre d'exemple hypothétique, un pirate pourrait envoyer un e-mail malveillant pour tenter de tromper un agent afin qu'il ignore la demande de l'utilisateur et transfère plutôt des documents fiscaux sensibles à une adresse e-mail contrôlée par le pirate. Si un utilisateur demande à l'agent de passer en revue les e-mails non lus et de résumer les points clés, l'agent pourrait ingérer cet e-mail malveillant au cours du flux de travail. Si le système suit les instructions injectées, il peut s'écarter de sa tâche et partager à tort des informations sensibles.

Ceci est juste un scénario spécifique. La même généralité qui rend les agents de navigation utiles élargit également les risques : l'agent peut rencontrer des instructions non fiables sur une surface pratiquement illimitée : e-mails et pièces jointes, invitations calendaires, documents partagés, forums, publications sur les médias sociaux et pages web arbitraires. Étant donné que l'agent peut effectuer bon nombre des actions qu'un utilisateur peut effectuer dans un navigateur, l'impact d'une attaque réussie peut être tout aussi important : transfert d'un e-mail confidentiel, envoi d'argent, modification ou suppression de fichiers dans le cloud, etc.

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 précédent article⁠. Cependant, l'injection de prompt demeure un défi persistant pour la sécurité des agents, et nous prévoyons de continuer à nous pencher dessus pendant des années à venir.

Pour renforcer nos défenses, nous avons continuellement recherché de nouvelles attaques par injection de prompts contre les systèmes d'agents en production. Identifier ces attaques est un préalable nécessaire à la mise en place de mesures de mitigation efficaces : cela nous aide à comprendre les risques réels, à identifier les lacunes de nos défenses et à élaborer des correctifs concrets.

Pour réaliser cela à grande échelle, nous avons développé un attaquant automatisé basé sur un LLM et l'avons entraîné à détecter des attaques par injection de prompt pouvant attaquer avec succès un agent de navigateur. Nous avons entraîné ce pirate de bout en bout avec l'apprentissage par renforcement, afin qu'il tire des leçons de ses succès et échecs pour perfectionner ses compétences en red teaming. Nous permettons également de « tester avant l'envoi », ce qui signifie que, pendant son raisonnement, l'attaquant peut proposer une injection candidate et l'envoyer à un simulateur externe. Le simulateur effectue un déploiement contrefactuel pour déterminer comment l'agent victime ciblé (le défenseur) réagirait face à l'injection, et fournit une trace complète du raisonnement et des actions de l'agent victime. Le pirate utilise cette trace comme commentaires, 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 offre au pirate des commentaires plus riches en contexte qu'un simple signal de réussite ou d'échec. Il augmente également la puissance de calcul de du pirate pendant l'inférence. De plus, l'accès privilégié aux trames de raisonnement (que nous ne divulguons pas aux utilisateurs externes) du défenseur confère à notre attaquant interne un avantage asymétrique, augmentant ainsi ses chances de surpasser les adversaires externes.

Pourquoi l'apprentissage par renforcement (RL) ? Nous avons choisi l'apprentissage par renforcement pour entraîner le pirate automatisé pour plusieurs raisons :

1. Optimisation des objectifs à long terme et non continus des pirates. Notre objectif est de rechercher des attaques par injection de prompt susceptibles d'inciter l'agent à exécuter des tâches adversaires sophistiquées (par exemple, envoyer des e-mails, effectuer des transactions bancaires) qui pourraient se produire dans le monde réel. Ces tâches adverses sont intrinsèquement à long terme, nécessitant de nombreuses étapes de raisonnement et d'interaction avec l'environnement, avec des signaux de réussite rares et retardés. L'apprentissage par renforcement convient bien à cette structure de récompense rare et différée.
2. Exploiter les capacités de pointe des LLM. Nous avons entraîné des LLM de pointe directement en tant qu'auto-red-teamers, ce qui permet au pirate de bénéficier directement des améliorations en matière de raisonnement et de planification dans les modèles de pointe. À mesure que les modèles de base se renforcent, le pirate 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. Mise à l'échelle des capacités de calcul et imitation des pirates qui s'adaptent. L'apprentissage par renforcement est particulièrement adapté à la mise à l'échelle des calculs nécessaires à la recherche d'attaques sur un grand nombre d'échantillonnages et d'étapes d'apprentissage. Il reflète également fidèlement le comportement des attaquants humains adaptatifs : essayer des stratégies de manière itérative, tirer des enseignements des résultats et renforcer les comportements efficaces.
   

Notre pirate automatisé est capable de détecter de nouvelles attaques réalistes par injection de prompt de bout en bout. Contrairement à la plupart des précédents travaux automatisés de red teaming, qui mettaient en évidence des défaillances simples telles que l'obtention de chaînes de sortie spécifiques ou le déclenchement d'un appel d'outil à une seule étape non intentionnel de la part de l'agent, notre pirate entraîné par RL peut amener un agent à exécuter des workflows sophistiqués et nuisibles à long terme qui se déroulent en plusieurs dizaines (voire centaines) d'étapes. Nous avons également observé de nouvelles stratégies d'attaque qui n'apparaissaient pas dans notre campagne de red teaming humaine ni dans les rapports externes.

La démonstration ci-dessous présente une exploitation concrète par injection de prompt découverte par notre pirate automatisé, que nous avons ensuite utilisée pour renforcer davantage les défenses de ChatGPT Atlas. Le pirate envoie à la boîte de réception de l'utilisateur un e-mail malveillant contenant une injection de prompt qui ordonne à l'agent d'envoyer une lettre de démission au PDG de l'utilisateur. Plus tard, lorsque l'utilisateur demande à l'agent de rédiger un message pour répondre en cas d'absence du bureau, l'agent tombe sur cet e-mail lors de l'exécution normale de sa tâche, traite l'injection comme faisant autorité et la suit. Le message d'absence n'est jamais rédigé et l'agent démissionne à la place de l'utilisateur.

La nature même de l'injection de prompt rend difficile toute garantie de sécurité déterministe. Cependant, en développant nos recherches automatisées en matière de sécurité, nos tests adversaires et en renforçant 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 dans la réalité. 

Nous partageons cette démonstration afin d'aider les utilisateurs et les chercheurs à mieux comprendre la nature de ces attaques et la manière dont nous nous défendons activement contre elles. ous estimons que cela représente la limite de ce que le red teaming automatisé peut accomplir, et nous sommes très enthousiastes à l'idée de poursuivre nos recherches.

Notre red teaming automatisé alimente une boucle de réponse rapide proactive : lorsque le pirate automatisé découvre une nouvelle classe d'attaques réussies par injection de prompt, il créér immédiatement une cible concrète pour améliorer nos défenses.

Entraînement en situation réelle contre les attaques récemment identifiées. Nous entraînons continuellement des modèles d'agents mis à jour contre notre meilleur pirate automatisé, en donnant la priorité aux attaques où les agents cibles échouent actuellement. L'objectif est d'apprendre aux agents à ignorer les instructions adverses et à rester alignés avec l'intention de l'utilisateur, ce qui améliore la résistance aux nouvelles stratégies d'injection de prompts découvertes. Cela renforce directement la robustesse du modèle face à de nouvelles attaques de grande ampleur. Par exemple, une récente opération automatisée de red teaming a directement produit un nouveau point de contrôle d'agent navigateur entraîné pour la détection des attaques, qui a déjà été déployé auprès de tous les utilisateurs de ChatGPT Atlas. Cela contribue en fin de compte à mieux protéger nos utilisateurs contre les nouveaux types d'attaques.

Utilisation des informations sur les attaques pour améliorer l'ensemble des mesures de défense. De nombreuses voies d'attaque découvertes par nos red teamers automatisés révèlent également des possibilités d'amélioration en dehors du modèle lui-même, par exemple au niveau de la surveillance, des consignes de sécurité que nous intégrons dans le contexte du modèle ou des mesures de protection au niveau du système. Ces conclusions nous aident à améliorer l'ensemble des mesures de défense, et 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. Lorsque nous examinons notre empreinte mondiale à la recherche d'attaques potentielles, nous pouvons utiliser les techniques et les tactiques observées chez nos adversaires externes, les intégrer dans cette boucle, imiter leurs activités et apporter des changements défensifs à l'ensemble de notre plateforme.

Renforcer notre capacité à former des agents red team et utiliser nos modèles les plus performants pour automatiser certaines parties de ce travail contribue à rendre l'agent de navigation Atlas plus robuste en optimisant le cycle de détection et de correction. Cet effort de renforcement renforce une leçon bien connue en matière de sécurité : un moyen éprouvé d'obtenir une protection plus efficace consiste à tester en permanence les systèmes réels, à réagir aux défaillances et à fournir des corrections concrètes.

Nous nous attendons à ce que les pirates 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 restons optimistes qu'une boucle de réponse rapide, proactive et très réactive pourra continuer à réduire de manière significative le risque dans le monde réel au fil du temps. En combinant la détection automatisée des attaques avec un entraînement adaptatif et des protections au niveau du système, nous pouvons identifier plus rapidement les nouveaux modèles d'attaque, combler plus rapidement les failles et augmenter continuellement le coût de l'exploitation.

Le mode agent dans ChatGPT Atlas est très performant, mais il augmente également les risques liés à la sécurité. Il est essentiel d'être conscient de ce compromis pour développer de manière responsable. Notre objectif est de renforcer considérablement la sécurité d'Atlas à chaque itération : en améliorant la robustesse du modèle, en renforçant la pile de défense environnante et en surveillant les nouveaux modèles abusifs émergents.

Nous continuerons d'investir dans la recherche et le déploiement, en développant de meilleures méthodes automatisées de red teaming, en déployant des mesures de réduction des risques en couches, et en itérant rapidement à mesure que nous apprenons. Nous partagerons également nos connaissances avec la communauté au sens large.

Tout en continuant à renforcer Atlas au niveau du système, les utilisateurs peuvent prendre certaines mesures pour réduire les risques liés à l'utilisation d'agents. 

Limitez l'accès aux utilisateurs se connectant lorsque c'est possible. Nous continuons à recommander aux utilisateurs de tirer parti du mode déconnecté⁠(ouverture dans une nouvelle fenêtre) lorsqu'ils utilisent Agent dans Atlas, chaque fois que l'accès aux sites web auxquels ils sont connectés n'est pas nécessaire pour la tâche à accomplir, ou pour limiter l'accès à des sites spécifiques auxquels ils se connectent pendant la tâche. 

Veuillez examiner attentivement les demandes de confirmation. Pour certaines actions importantes, telles que finaliser un achat ou envoyer un e-mail, les agents sont conçus pour demander votre confirmation avant de procéder. Lorsqu'un agent vous demande de confirmer une action, prenez un moment pour vérifier que l'action est correcte et que toute information partagée est appropriée pour ce contexte.

Donnez des instructions explicites aux agents lorsque cela est possible. Veuillez éviter les prompts trop vagues comme « examiner mes e-mail et prendre les mesures nécessaires ». Une grande latitude facilite l'influence de contenus cachés ou malveillants 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 fiables dans les tâches quotidiennes, ils doivent être capables de résister aux manipulations rendues possibles par le web ouvert. Le renforcement contre les injections de prompt est un engagement à long terme et l'une de nos principales priorités. Nous vous en dirons bientôt plus.