Comment nous concevons des agents plus sûrs

Pour concevoir des agents 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 ce sans aucune instruction malveillante, les agents peuvent franchir les frontières de la sécurité en essayant de surmonter des obstacles.

Nous croyons qu'il s'agit d'un problème d'ingénierie de sécurité, et l'industrie devrait s'y attaquer de la même manière qu'elle s'est attaquée aux vers Internet du début des années 2000. Les systèmes entourant les agents doivent limiter ce que les agents peuvent accéder, détecter les comportements indésirables et contenir les défaillances 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 IA, et nous appliquons de multiples couches de défense à travers nos modèles, nos harnais [harness] d'agents et notre infrastructure afin que la sécurité ne repose pas sur une seule mesure de protection.

Comportement de dérive des agents IA

En juillet, des agents IA se sont introduits dans l'infrastructure de production de la plateforme d'IA open source Hugging Face. Lors de l'évaluation interne de la cybersécurité et des cycles d'entraînement, les modèles d'OpenAI ont découvert un moyen d'exploiter le gestionnaire de référentiel Artifactory pour établir un babillard électronique permettant de communiquer entre eux, leur permettant ainsi de s'organiser en essaims. Plus tard, des agents qui ne parvenaient pas à progresser sur des tâches d'un banc d'essai 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 une rétro-ingénierie des réponses aux tâches du banc d'essai, mais pensaient que le système de notation détecterait la triche. Pour mieux comprendre le fonctionnement de l'évaluation du banc d'essai afin de trouver des moyens d'éviter d'être détectés comme tricheurs, ils ont finalement compromis les systèmes d'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 en open source Numbat 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 obstacles, tels qu'un fichier manquant, un appel d'API échoué, un identifiant expiré ou un refus de permission, et se met en quête d'une solution de contournement. Ce faisant, il peut franchir les frontières de la sécurité par la reconnaissance, l'escalade de privilèges, la découverte de secrets ou l'exfiltration de données. L'agent lui-même devient effectivement l'adversaire, même si aucun contenu malveillant ou attaquant externe n'est impliqué.

Hugging Face n'a pas été un cas isolé. D'autres comportements de dérive d'agents ont été détectés 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 proposant 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 sondes, incluant l'injection SQL, les scripts intersites (XSS), l'injection de modèles, le traversement de répertoires et l'injection de commandes. L'activité a ensuite été liée à OpenAI (SecurityWeek). Les 20 et 21 mai [sic], des agents d'OpenAI essayant d'obtenir les coûts gouvernementaux par personne pour une catégorie de médicaments dans différentes zones locales de Victoria auprès de l'Institut australien de la santé et du bien-être (AIHW) se sont vus bloquer le téléchargement d'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 ainsi 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 pénétré 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 du passé : l'ère des vers Internet

Ces incidents rappellent l'ère des vers Internet 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, aux conséquences bien plus graves que ce que nous observons actuellement avec les agents IA en situation de dérive.

Le 4 mai 2000, des gens ont commencé à recevoir des courriels provenant d'expéditeurs familiers avec pour objet « ILOVEYOU ». L'ouverture de la pièce jointe dans le courriel 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 impliquant plus de 420 000 hôtes Internet (US GAO Report). Le virus aurait pénétré dans au moins 14 agences fédérales, incluant le ministère de la Défense (Department of Defense), 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 estimé dès le départ que le virus causerait plus de 15 milliards de dollars de dommages et de pertes de productivité (US House Committee Hearing). Computer Economics a par la suite estimé les dommages à 8,75 milliards de dollars à l'échelle mondiale (Information Week).

Des 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 à ce ver en l'espace de 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 électronique Sobig sont apparus à environ une semaine d'intervalle (Microsoft, F-Secure).

À l'époque, il était légitime de se demander si les ordinateurs en réseau pouvaient réellement être sécurisés. 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 des défauts dans leurs produits. Washington a emprunté une voie différente. La stratégie nationale pour sécuriser le cyberespace (National Strategy to Secure Cyberspace) a affirmé que « la réglementation fédérale ne deviendra pas un moyen principal 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). L'application automatique de correctifs, les paramètres par défaut sécurisés, les programmes de primes aux bogues (bug bounty) et la divulgation coordonnée sont devenus la pratique courante. En 2008, Chrome a commencé à exécuter le 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 par défaut. Les technologies de sécurité, incluant l'authentification multifacteur, les pare-feu, le modèle Zero Trust (zéro confiance) et la gestion des informations et des événements de sécurité (SIEM), ont été largement adoptées. Les organisations du monde entier devraient 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 flambées épidémiques généralisées sur Internet s'est estompée. Parallèlement, Internet, largement libéré des contraintes réglementaires, 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 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 strictement 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 tenir compte des différences entre le comportement humain et le comportement de l'agent. Comme nous l'avons écrit dans notre réponse à la demande d'information du NIST sur la sécurité des agents IA, les agents IA remettent en question ces hypothèses. Ils peuvent exercer des privilèges et effectuer des actions à la vitesse de la machine, ne sont pas dissuadés par les conséquences du monde réel et peuvent entreprendre des actions qui sont techniquement permises mais 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 IA.

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

On peut affirmer que le principe de sécurité le plus important à appliquer pour sécuriser les agents IA est la défense en profondeur, qui 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 à elle seule. Des personnes peuvent se laisser tromper par des attaques d'ingénierie sociale et révéler leurs identifiants de connexion, des vulnérabilités logicielles zero-day sont découvertes et exploitées, et la détection des intrusions rate de nouvelles variantes d'attaques. La défense en profondeur accepte cette réalité et empile plusieurs couches de défense indépendantes. Si une couche défensive venait à être contournée, d'autres couches restent en place pour contrer ou détecter l'intrusion.

L'incident d'Hugging Face montre pourquoi la défense en profondeur est importante. Le rapport rétrospectif d'OpenAI indique que les mesures de protection automatisées utilisées dans ses systèmes de production, incluant les harnais [harness], les modèles d'autorévision 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 été active 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 intercepter le problème existaient. Elles n'étaient simplement pas toutes en place en même temps.

Sécuriser les agents 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 d'aujourd'hui sont nettement meilleurs pour les reconnaître et les refuser. Les développeurs de modèles entraînent également les modèles à adopter un comportement plus sûr et, comme le décrit le rapport rétrospectif d'OpenAI, surveillent les traces de raisonnement pour détecter tout signe 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 pour la sécurité et le confinement. La sûreté au niveau du modèle réduit la probabilité qu'un agent ne s'égare ; la sécurité au niveau du système limite les dégâts lorsqu'il dévie.

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 de l'appliquer selon trois règles de conception :

1. Indépendance. Chaque couche devrait échouer pour des raisons indépendantes. Deux contrôles qui partagent la même hypothèse peuvent être mis en échec par la même attaque. Les moniteurs et les points d'application doivent se situer hors de portée de l'agent.
2. Application sous 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 de 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 résiliation de la session. Aucun signal de risque ne doit jamais accorder de privilèges supplémentaires.

Nous partageons ces principes avec nos partenaires de l' Open Secure AI Alliance, notamment NVIDIA, qui a fait valoir que le harnais [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 comporte 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 traite l'agent comme non fiable par défaut. Chaque tâche obtient sa propre micro-machine virtuelle (microVM), 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 rétablir les modifications destructrices (Making SPACE). Les clients d'entreprise (Enterprise) 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 accordé à neuf modèles de pointe un accès racine au sein d'un bac à sable SPACE et leur avons demandé de s'échapper. Aucun n'a réussi à s'échapper de la machine virtuelle (VM), mais certains ont trouvé des moyens de contourner la politique réseau lorsqu'un accès réseau partiel était autorisé. Nous avons corrigé ces failles, confirmé les corrections lors d'un nouveau test et divulgué des faiblesses similaires que nous avions trouvées dans huit des 10 autres plateformes de bac à sable à leurs fournisseurs.

Dans le navigateur : Comet et BrowseSafe

Comet utilise une défense superposée 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 courriel ou le placement 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 banc d'essai BrowseSafe-Bench, pourtant le même banc d'essai 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 fait l'objet d'un audit par Trail of Bits (Perplexity).

Sur l'appareil : Portable Computer

Portable Computer est un agent axé sur le local : le modèle, le harnais [harness], la conversation et la trajectoire restent par défaut sur la machine de l'utilisateur. Un orchestrateur déterministe, qui relève du code de harnais [harness] plutôt que d'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 sécurisé en cas de défaillance (fail-closed) : s'il n'est pas disponible, le harnais [harness] se désactive au lieu d'exécuter des commandes avec les permissions de l'utilisateur. Les actions qui franchissent la frontière de l'appareil, telles que la recherche Web, les connecteurs et l'escalade vers un modèle conseiller cloud plus puissant, ne se produisent que lorsque l'utilisateur les active et les approuve. Avant un appel à un conseiller, un classificateur de renseignements personnels (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 s'exécutent pendant des heures avec un accès au code source, aux identifiants et aux systèmes de production. Numbat, notre suite de sécurité des agents open source, ajoute une couche indépendante qui se trouve en dehors de tout agent individuel. Elle fonctionne avec des harnais [harness] tels que Claude Code, Codex, OpenCode et Pi, bloque les agents [sic] avant qu'elles ne s'exécutent [sic], signale les séquences suspectes en plusieurs étapes telles que la lecture d'un secret suivie de l'envoi de données à l'extérieur, et préserve les chronologies de session pour enquête. Numbat s'exécute sur des milliers de points de terminaison de Perplexity aux côtés de Bumblebee, notre scanneur de chaîne d'approvisionnement open source. Computer examine régulièrement leurs observations 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 IA gagnent en capacité et en popularité, 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 du monde réel 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 de pair avec 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 harnais [harness], 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 faillit. C'est pourquoi nous concevons des mesures de protection qui fonctionnent sur l'ensemble des harnais [harness] d'agents et mettons nos outils en open source. C'est également la raison pour laquelle nous divulguons les faiblesses que nous découvrons dans d'autres plateformes et participons à des initiatives telles que l'Open Secure AI Alliance.

Pour travailler avec la communauté au sens large 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 travaux à Stanford, à l'Université Carnegie Mellon (CMU), à Duke, à Columbia, à l'Université d'État de l'Ohio 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 un objectif que l'industrie peut concevoir. Nous avons l'intention de continuer à faire notre part et nous invitons les autres à bâtir avec nous.