Comment nous concevons des agents plus sûrs

Pour concevoir des agents d'IA plus sûrs, nous devons tenir compte à la fois de leurs capacités et de leurs défaillances. Même lorsqu'ils exécutent des tâches légitimes, et sans aucune instruction malveillante, les agents peuvent franchir les limites de la sécurité lorsqu'ils tentent de surmonter des obstacles.

Nous pensons qu'il s'agit d'un problème d'ingénierie de sécurité, et l'industrie devrait l'aborder de la même manière qu'elle a abordé les vers informatiques du début des années 2000. Les systèmes qui environnent les agents doivent limiter ce à quoi les agents peuvent accéder, détecter les comportements indésirables et contenir les pannes lorsqu'elles se produisent.

Chez Perplexity, nous collaborons activement avec des chercheurs et des praticiens pour faire progresser l'ingénierie de sécurité pour les agents d'IA, et nous appliquons de multiples couches de défense à nos modèles, harnesses d'agents et infrastructures afin que la sécurité ne dépende d'aucune mesure de protection unique.

Comportement de dérive des agents d'IA

En juillet, des agents d'IA se sont introduits dans l'infrastructure de production de la plateforme d'IA open source Hugging Face. Lors d'évaluations de cybersécurité et de sessions d'entraînement internes, des modèles d'OpenAI ont découvert un moyen d'exploiter le gestionnaire de référentiel Artifactory pour établir un tableau d'affichage permettant de communiquer entre eux, ce qui leur a permis de s'organiser en essaims. Plus tard, des agents qui ne parvenaient pas à progresser sur des tâches dans le cadre d'un benchmark de cybersécurité ont recruté d'autres agents pour les aider. Ces agents se sont échappés de leur environnement d'évaluation et ont atteint Internet. Ils ont également découvert des moyens de tricher en effectuant de l'ingénierie inverse sur les réponses aux tâches du benchmark, tout en pensant que le système de notation détecterait la tricherie. Pour mieux comprendre le fonctionnement de l'évaluation du benchmark afin de trouver des moyens d'éviter d'être détectés comme tricheurs, ils ont fini par compromettre les systèmes de Hugging Face (Hugging Face ; OpenAI).

L'incident est un exemple flagrant d'un mode de défaillance que nous avons décrit lorsque nous avons mis Numbat en open source en juillet : les dérives accidentelles (accidental meltdowns), un terme inventé par des chercheurs en sécurité de Cornell Tech (arXiv). Un agent poursuivant un objectif légitime rencontre des difficultés, telles qu'un fichier manquant, un appel d'API échoué, un identifiant expiré ou un refus d'autorisation, et se met en quête d'une solution de contournement. Ce faisant, il peut franchir les frontières de la sécurité par le biais de la reconnaissance, de l'escalade de privilèges, de la découverte de secrets ou de l'exfiltration de données. L'agent lui-même devient de fait l'adversaire, même si aucune invite malveillante ou attaquant externe n'est impliqué.

Hugging Face n'a pas été un cas isolé. D'autres comportements de dérive d'agent ont été découverts et signalés ces dernières semaines. Les 27 et 28 mai, des agents essayant de recueillir des données de l'Université de l'Iowa auprès de Data USA, une plateforme offrant un accès ouvert aux données du gouvernement américain, ont rencontré des erreurs causées par une requête malformée. Ils ont répondu par des sondages, notamment des injections SQL, des scripts intersites (XSS), des injections de modèles, des traversées de répertoires et des injections de commandes. L'activité a ensuite été liée à OpenAI (SecurityWeek). Les 20 et 21 mai, des agents d'OpenAI essayant d'obtenir les coûts gouvernementaux par personne pour une catégorie de médicaments dans les zones locales du Victoria auprès de l'Australian Institute of Health and Welfare (AIHW) ont été empêchés de télécharger un fichier. En réponse, les agents ont téléchargé le fichier, qui était déjà public, à partir du serveur de pré-production de l'AIHW, contournant au passage les protections anti-bot du site (SecurityWeek).

Ce schéma ne se limite pas à un seul laboratoire. Lors de tests de cybersécurité, les modèles d'Anthropic ont infiltré trois entreprises après qu'une erreur leur a donné un accès libre à Internet, le Gemini de Google a deviné les identifiants de trois sites Web, et un modèle de Meta a exploité un service tiers (Reuters).

Apprendre de l'histoire : l'ère des vers informatiques

Ces incidents rappellent l'ère des vers informatiques d'il y a environ un quart de siècle. Au début des années 2000, Internet s'est développé beaucoup plus rapidement que les pratiques de sécurité qui l'entouraient. Nous avons assisté à une vague de virus et de vers, dont les conséquences ont été bien plus graves que ce que nous constatons actuellement avec les agents d'IA en dérive.

Le 4 mai 2000, des personnes ont commencé à recevoir des e-mails provenant d'expéditeurs familiers avec pour objet « ILOVEYOU ». L'ouverture de la pièce jointe dans l'e-mail a entraîné l'exécution d'un script qui a envoyé une copie de lui-même à tout le monde dans le carnet d'adresses Outlook de la victime. À 18 h ce jour-là, le CERT Coordination Center avait reçu des signalements concernant plus de 420 000 hôtes Internet (US GAO Report). Le virus aurait pénétré au moins 14 agences fédérales, dont le département de la Défense, la CIA, la NASA, ainsi que la Chambre des représentants et le Sénat (US GAO Report). Il a également mis hors service des serveurs de messagerie au Pentagone et au Parlement britannique (Wired). Le géant de l'assurance Lloyd's of London a fait une première estimation selon laquelle le virus causerait plus de 15 milliards de dollars de dommages et de pertes de productivité (US House Committee Hearing). Computer Economics a ensuite estimé les dommages à 8,75 milliards de dollars dans le monde entier (Information Week).

Les vers ne nécessitant aucun clic humain ont suivi. Le 19 juillet 2001, le ver Code-Red a infecté plus de 359 000 ordinateurs en moins de 14 heures (CAIDA). Le 25 janvier 2003, SQL Slammer a doublé de taille toutes les 8,5 secondes et a infecté plus de 90 % des hôtes Internet vulnérables qui s'y trouvaient en 10 minutes (CAIDA), exploitant une faille pour laquelle Microsoft avait publié un correctif six mois plus tôt (CNET). En août 2003, le ver Blaster et le ver de messagerie Sobig sont apparus à environ une semaine d'intervalle (Microsoft, F-Secure).

À l'époque, il était raisonnable de se demander s'il était possible de sécuriser les ordinateurs connectés en réseau. Six jours après le virus ILOVEYOU, un sous-comité de la Chambre des représentants des États-Unis a tenu une audience à ce sujet. De nombreux experts en sécurité ont réclamé une législation qui rendrait les éditeurs de logiciels responsables des dommages causés par les failles de leurs produits. Washington a pris une autre voie. La Stratégie nationale pour sécuriser le cyberespace (« National Strategy to Secure Cyberspace ») a déclaré que « la réglementation fédérale ne deviendra pas un moyen privilégié de sécuriser le cyberespace ». Elle a averti que de larges mandats pourraient créer une « approche du plus petit dénominateur commun en matière de cybersécurité » (CISA).

L'industrie a répondu par l'ingénierie. Onze jours après ILOVEYOU, Microsoft a annoncé une mise à jour d'Outlook qui bloquait les pièces jointes exécutables. En janvier 2002, l'entreprise a fait de la sécurité une priorité absolue (Seattle Times). Les correctifs automatiques, les paramètres par défaut sécurisés, les programmes de primes aux bugs et la divulgation coordonnée sont devenus la norme. En 2008, Chrome a commencé à exécuter du contenu Web dans un bac à sable qui « limite ce qu'un attaquant peut faire après avoir exploité un bogue » (Chromium Blog). Le chiffrement, autrefois l'exception, est devenu la norme. Les technologies de sécurité, notamment l'authentification multifacteur, les pare-feu, le modèle « zero trust » et la gestion des informations et des événements de sécurité (SIEM), ont été largement adoptées. Les organisations du monde entier prévoient de dépenser environ 240 milliards de dollars en 2026 pour la sécurité de l'information (Gartner). Les vers n'ont jamais totalement disparu, mais l'ère des épidémies généralisées à l'échelle d'Internet s'est estompée. Dans le même temps, Internet, largement libéré de la réglementation, est devenu un puissant moteur d'innovation et de croissance économique au cours des deux décennies suivantes.

Ingénierie de sécurité pour les agents d'IA

Des incidents récents ont soulevé des questions légitimes concernant la gouvernance des agents. Les mécanismes de sécurité existants ont été développés pour des environnements informatiques pré-agents caractérisés par un comportement logiciel étroitement délimité et largement déterministe. Les mécanismes de contrôle d'accès, en particulier, sont principalement conçus autour des utilisateurs humains et leur accordent souvent de larges privilèges qui sont, en principe, suffisants pour causer des préjudices importants.

Cette conception repose sur plusieurs hypothèses : la plupart des utilisateurs agissent de bonne foi ; les acteurs malveillants peuvent être dissuadés par l'audit et les conséquences dans le monde réel ; et les humains effectuent des actions, qu'elles soient correctes ou erronées, à un rythme relativement limité. L'application de ces mécanismes de sécurité aux agents nécessite de prendre en compte les différences entre le comportement humain et le comportement de l'agent. Comme nous l'avons écrit dans notre réponse à la demande d'informations du NIST sur la sécurité des agents d'IA, les agents d'IA remettent en question ces hypothèses. Ils peuvent exercer des privilèges et entreprendre des actions à la vitesse de la machine, ne sont pas dissuadés par les conséquences dans le monde réel et peuvent prendre des mesures techniquement autorisées qu'un utilisateur humain typique entreprendrait rarement.

Répondre à ces questions nécessite de l'ingénierie de sécurité. Nous connaissons les principes de sécurité pour concevoir des systèmes qui maintiennent les risques sous contrôle lorsque des composants individuels se comportent mal. Mais nous devons nous assurer que ces principes sont appliqués lors de la conception des environnements d'entraînement, de test et d'utilisation des agents d'IA.

Le principe de sécurité de la défense en profondeur

Il s'agit sans doute du principe de sécurité le plus important à appliquer pour sécuriser les agents d'IA : la défense en profondeur. Elle préconise une architecture de sécurité en couches, où plusieurs mesures défensives, variées et redondantes, sont employées pour protéger les ressources du système. Aucune mesure de protection n'est parfaite. Des personnes peuvent être victimes d'attaques d'ingénierie sociale et révéler leurs identifiants de connexion, des vulnérabilités logicielles de type zero-day sont découvertes et exploitées, et la détection des intrus rate de nouvelles variantes d'attaque. La défense en profondeur l'accepte et superpose plusieurs couches de défense indépendantes. Si une couche défensive venait à être contournée, d'autres couches resteraient en place pour contrer ou détecter l'intrusion.

L'incident de Hugging Face montre l'importance de la défense en profondeur. Le rapport rétrospectif d'OpenAI indique que les mesures de protection automatisées utilisées dans ses systèmes de production, notamment les harnesses, les modèles d'auto-évaluation et les classificateurs de sécurité, étaient absentes de l'environnement d'évaluation. Si sa surveillance de la chaîne de pensée actuellement déployée avait fonctionné lors de ces évaluations, elle aurait détecté l'activité initiale et alerté l'équipe de sécurité plus d'un jour avant la violation (OpenAI). Les couches qui auraient pu détecter le problème existaient. Elles n'étaient tout simplement pas toutes en place en même temps.

Sécuriser les agents d'IA nécessite d'améliorer à la fois la sûreté et la sécurité des modèles d'IA et des systèmes qui les environnent. Le travail au niveau du modèle est important et porte ses fruits. Les premiers LLM étaient facilement manipulés par des instructions injectées, tandis que les modèles actuels sont nettement meilleurs pour les reconnaître et les refuser. Les développeurs de modèles entraînent également les modèles à un comportement plus sûr et, comme le décrit le rapport rétrospectif d'OpenAI, surveillent les traces de raisonnement à la recherche de signes de comportement problématique. Mais les défenses au niveau du modèle ne constituent qu'une partie de la solution. Les systèmes dans lesquels les agents sont entraînés, testés et déployés doivent également être conçus en tenant compte de la sécurité et du confinement. La sûreté au niveau du modèle réduit la probabilité qu'un agent s'égare ; la sécurité au niveau du système limite les dégâts lorsqu'il le fait.

Agrandir

Règles de conception pour des mesures de protection redondantes

La défense en profondeur nécessite des mesures de protection redondantes. Pour les agents, nous préconisons son application selon trois règles de conception :

1. Indépendance. Chaque couche doit échouer pour des raisons indépendantes. Deux contrôles qui partagent la même hypothèse peuvent être battus par la même attaque. Les moniteurs et les points d'application doivent se trouver hors de portée de l'agent.
2. Application en dessous de l'agent. Au moins une couche doit être déterministe : du code conventionnel et vérifiable qui bloque les actions interdites, peu importe ce que le modèle produit. Une mesure de protection que l'agent peut refuser d'invoquer ou reconfigurer n'est pas une mesure de protection.
3. Les signaux ne peuvent que réduire l'autorité. La détection doit déclencher des réponses qui restreignent ce que l'agent peut faire, telles que la mise en pause, la révocation des identifiants, la coupure de l'accès au réseau ou la fin de la session. Aucun signal de risque ne doit jamais accorder un accès supplémentaire.

Nous partageons ces principes avec nos partenaires de l' Open Secure AI Alliance, notamment NVIDIA, qui a affirmé que le harness guide ce qu'un agent essaie de faire tandis que l'infrastructure contrôle ce qu'il peut faire (NVIDIA).

La défense en profondeur dans les produits de Perplexity

Perplexity exécute des agents dans quatre types d'environnements : dans le cloud via notre plateforme d'agents Computer, dans le navigateur via Comet, sur les appareils des utilisateurs via Portable Computer, et sur les ordinateurs portables des employés, où nos ingénieurs utilisent des agents de codage tiers. Chaque environnement présente ses propres risques et bénéficie de plusieurs couches de protection.

Dans le cloud : Computer et SPACE

Chaque tâche Computer s'exécute dans SPACE, notre plateforme de bac à sable, qui considère par défaut l'agent comme non fiable. Chaque tâche dispose de sa propre micro-machine virtuelle, les identifiants restent en dehors du bac à sable et ne sont injectés qu'en cas de besoin, le trafic sortant est contrôlé en dehors de l'invité et des instantanés (snapshots) nous permettent de restaurer les modifications destructrices (Making SPACE). Les clients d'entreprise peuvent également apporter leurs propres clés de chiffrement. La révocation d'une clé rend les données protégées illisibles, et l'agent ne peut pas passer outre cette décision.

Nous testons également la résistance de ces couches. Dans Escaping SPACE: Part I, nous avons donné à neuf modèles de pointe un accès root à l'intérieur d'un bac à sable SPACE et leur avons demandé de s'en échapper. Aucun ne s'est échappé de la machine virtuelle, mais certains ont trouvé des moyens de contourner la politique réseau lorsqu'un accès réseau partiel était autorisé. Nous avons comblé ces lacunes, confirmé les correctifs lors d'un nouveau test et divulgué des faiblesses similaires que nous avions trouvées dans huit des 10 autres plateformes de bacs à sable à leurs fournisseurs.

Dans le navigateur : Comet et BrowseSafe

Comet utilise une défense multicouche contre l'injection d'invites depuis son lancement : des classificateurs filtrent le contenu récupéré, des invites structurées le marquent comme non fiable, des actions sensibles telles que l'envoi d'un e-mail ou le passage d'une commande nécessitent la confirmation de l'utilisateur, et les utilisateurs sont informés lorsqu'un élément est bloqué (Comet prompt-injection defenses). BrowseSafe, le modèle de détection open source à l'origine de la première couche, surpasse les modèles de pointe sur notre benchmark BrowseSafe-Bench, et pourtant le même benchmark montre qu'aucun détecteur n'est infaillible, c'est pourquoi la détection n'est jamais la seule couche (BrowseSafe research). Computer hérite de ces défenses, qui ont été auditées par Trail of Bits (Perplexity).

Sur l'appareil : Portable Computer

Portable Computer est un agent axé sur le local : le modèle, le harness, la conversation et la trajectoire restent par défaut sur la machine de l'utilisateur. Un orchestrateur déterministe, qui est du code de harness plutôt qu'un LLM, exécute la boucle et applique la politique. Le modèle propose des actions, et les appels d'outils approuvés s'exécutent dans un bac à sable au niveau du système d'exploitation qui restreint les processus, les chemins de fichiers et l'accès au réseau. Le bac à sable est toujours actif et à échec sécurisé : s'il n'est pas disponible, le harness se désactive au lieu d'exécuter des commandes avec les autorisations de l'utilisateur. Les actions qui franchissent la limite de l'appareil, telles que la recherche sur le Web, les connecteurs et l'escalade vers un modèle de conseiller cloud plus puissant, ne se produisent que lorsque l'utilisateur les active et les approuve. Avant un appel au conseiller, un classificateur de PII signale les informations sensibles et l'utilisateur voit ce qui serait envoyé. Le conseiller reçoit uniquement ce contexte approuvé et renvoie des conseils textuels, sans aucun accès aux fichiers ou aux outils de l'appareil.

Sur le point de terminaison : Numbat

Les agents de codage sur les ordinateurs portables des développeurs fonctionnent pendant des heures avec un accès au code source, aux identifiants et aux systèmes de production. Numbat, notre suite open source de sécurité pour agents, ajoute une couche indépendante qui se trouve en dehors de tout agent individuel. Elle fonctionne avec des harnesses tels que Claude Code, Codex, OpenCode et Pi, bloque les actions dangereuses avant qu'elles ne s'exécutent, signale les séquences suspectes en plusieurs étapes (telles que la lecture d'un secret puis l'envoi de données), et conserve les historiques de session pour les enquêtes. Numbat s'exécute sur des milliers de points de terminaison de Perplexity aux côtés de Bumblebee, notre scanner open source de la chaîne d'approvisionnement. Computer examine régulièrement leurs conclusions et propose des règles de détection améliorées, et un humain approuve chaque modification avant son déploiement.

Un travail pour toute l'industrie

À mesure que les agents d'IA deviennent plus performants et plus largement utilisés, l'ingénierie de sécurité doit rester au cœur de leur développement et de leur déploiement. Les chercheurs et les ingénieurs peuvent s'appuyer sur des principes établis, utiliser des observations concrètes pour affiner les défenses et tester les mesures de protection dans les environnements où opèrent les agents. La sécurité est une discipline d'ingénierie continue qui évolue aux côtés de la technologie.

L'ingénierie de sécurité pour les agents est l'affaire de toute l'industrie. Aucune entreprise ne contrôle à elle seule l'ensemble de la pile sur laquelle s'exécute un agent. Les développeurs de modèles, les concepteurs de harnesses, les fournisseurs de bacs à sable et d'environnements d'exécution, les fournisseurs de cloud et de matériel, ainsi que les équipes de sécurité d'entreprise possèdent chacun une couche. La sécurité de l'ensemble dépend de la résistance de chaque couche lorsqu'une autre défaille. C'est pourquoi nous construisons des mesures de protection qui fonctionnent sur l'ensemble des harnesses d'agents et proposons nos outils en open source. C'est également la raison pour laquelle nous divulguons les faiblesses que nous trouvons dans d'autres plates-formes et participons à des initiatives telles que l'Open Secure AI Alliance.

Pour travailler avec la communauté élargie sur ces défis, Perplexity a lancé le Secure Intelligence Institute en mars 2026 afin d'étudier la sécurité, la fiabilité et la défense pratique des systèmes d'IA de pointe (Perplexity). Perplexity collabore actuellement avec des chercheurs universitaires et/ou finance leurs recherches à Stanford, CMU, Duke, Columbia, Ohio State et l'Université de Virginie. Nous menons également des recherches internes pour faire progresser la recherche sur la sécurité des agents, traduire ces avancées en améliorations concrètes dans les systèmes de Perplexity, et partager les connaissances et les ressources qui contribuent à renforcer l'écosystème de l'IA dans son ensemble. Des agents plus sûrs sont à la portée de l'ingénierie de l'industrie. Nous avons l'intention de continuer à faire notre part et invitons les autres à construire avec nous.