Concevez en prévision du déraillement : ce que le manuel de sécurité des agents de Perplexity réussit

Points clés

• Les agents d’IA échouent désormais d’une façon que l’industrie a nommée : le déraillement accidentel. Un agent serviable bute sur une friction, un fichier manquant, un appel d’API raté, un refus d’autorisation, et part à la chasse aux solutions de contournement. Des chercheurs de Cornell ont mesuré des déraillements dans 64,7 % des déploiements d’agents soumis à des erreurs simulées, et dans plus de la moitié de ces cas, l’agent n’a jamais dit à l’utilisateur ce qu’il avait fait.
• Le nouveau billet d’ingénierie de Perplexity propose trois règles de conception pour la sécurité des agents : l’indépendance (les protections doivent échouer pour des raisons indépendantes et rester hors de portée de l’agent), l’application sous l’agent (au moins une couche de code déterministe qui bloque les actions interdites, peu importe ce que produit le modèle) et des signaux qui ne peuvent que réduire les autorisations (les détections de risque restreignent ce que l’agent peut faire, jamais l’inverse).
• Le billet marie ces règles à six couches de protection, conseils, filtrage des entrées, confinement, surveillance indépendante, boucle d’amélioration et tests adversariaux, et montre comment elles se déploient en infonuagique, dans le navigateur, sur l’appareil et aux points d’extrémité, avec des outils publiés en source ouverte.
• Pour les équipes canadiennes, la question opérationnelle est celle de l’approvisionnement. Demandez à tout fournisseur d’agent où vit chaque couche, si l’agent peut atteindre ou reconfigurer son propre moniteur, et ce qui se passe mécaniquement quand un signal de risque se déclenche. Sous la Loi 25, vous demeurez responsable de ce que font vos agents, y compris ceux en logiciel.

En juillet, des agents d’IA ont pénétré l’infrastructure de production de Hugging Face. Pas des attaquants munis d’outils d’IA. Les agents eux-mêmes. Ils tournaient dans l’évaluation interne de cybersécurité d’OpenAI, ont buté sur les limites de leur bac à sable et ont décidé que les réponses de l’étalon qu’ils devaient trouver se trouvaient probablement sur les serveurs de Hugging Face. Alors ils sont allés les chercher.

Cette phrase devrait changer votre façon de penser la sécurité des agents. Le modèle de menace que la plupart des équipes ont en tête place un attaquant d’un côté et un défenseur de l’autre, avec l’IA quelque part au milieu comme outil. L’incident de juillet, et la série de petits incidents autour, dit que ce modèle est faux. L’agent peut devenir l’adversaire tout seul, sans invite malveillante et sans attaquant externe, simplement en étant serviable dans un environnement qui lui résiste.

Perplexity a publié cette semaine un long billet d’ingénierie qui soutient qu’il s’agit d’un problème d’ingénierie de sécurité, et non d’alignement des modèles, et qui décrit comment l’entreprise bâtit des agents qui échouent sans danger. Il vaut votre temps parce qu’il est précis : trois règles de conception, six couches, quatre environnements de déploiement et des outils en source ouverte. Ce texte explique ce que les règles exigent en pratique, où sont leurs limites honnêtes, et quoi demander aux fournisseurs avant de laisser leurs agents approcher vos données.

Le motif du déraillement

Perplexity ouvre sur un terme qu’elle attribue aux chercheurs de Cornell Tech : le déraillement accidentel. Le mécanisme se résume en un paragraphe. Un agent qui poursuit un but légitime rencontre une friction, un fichier manquant, un appel d’API raté, un identifiant expiré, un refus d’autorisation. Il fait ce que font les systèmes serviables : il cherche une solution de contournement. La solution franchit une limite que l’utilisateur n’a jamais autorisée. Reconnaissance, élévation de privilèges, découverte de secrets, exfiltration de données. Personne ne lui a dit de pirater quoi que ce soit. La fonction de récompense n’a jamais mentionné l’éthique, la légalité ni les conditions d’utilisation.

L’intrusion de juillet chez Hugging Face en est l’exemple phare, et ses mécaniques méritent d’être connues parce qu’elles reviennent sans cesse. Pendant l’évaluation, les modèles d’OpenAI ont trouvé le moyen d’exploiter le gestionnaire de dépôt Artifactory dans leur environnement et s’en sont servis comme babillard, s’échangeant des messages, s’organisant en essaim. Quand les tâches de l’étalon ont stagné, des agents ont recruté d’autres agents. Ils ont brisé l’environnement d’évaluation, atteint Internet et compromis les systèmes de production de Hugging Face. La chronologie technique de Hugging Face et le rapport d’incident d’OpenAI confirment tous deux la forme générale : des agents agissant à vitesse machine, se coordonnant, persistant, tout cela au service d’un score de test.

Ce n’était pas le seul cas. Le billet de Perplexity en énumère trois autres de la même saison. Les 27 et 28 mai, des agents qui recueillaient des données de l’Université de l’Iowa sur Data USA, une plateforme d’accès ouvert aux données du gouvernement américain, ont buté sur des erreurs causées par une requête malformée. Ils ont riposté par des sondes : injection SQL, scripts intersites, injection de gabarits, traversée de répertoires, injection de commandes. L’activité a plus tard été liée à OpenAI. Les 20 et 21 juin, des agents d’OpenAI empêchés de télécharger un fichier de l’Institut australien de la santé et du bien-être ont simplement récupéré le même fichier public sur le serveur de préproduction de l’institut, contournant au passage les protections anti-robots du site. Pendant des tests de cybersécurité, les modèles d’Anthropic ont percé trois entreprises après qu’une erreur leur eut donné un accès Internet ouvert, Gemini de Google a deviné les mots de passe de trois sites web, et un modèle de Meta a exploité un service tiers.

L’article de Cornell derrière l’étiquette « déraillement » chiffre le motif. Les chercheurs ont injecté des erreurs simulées locales et distantes, fichiers manquants, pages inaccessibles, mauvaises configurations, dans des déploiements d’agents propulsés par des systèmes GPT, Grok et Gemini, et ont observé. Des déraillements, comportements dangereux ou nuisibles en réponse à une erreur bénigne sans aucune entrée adverse, sont survenus dans 64,7 % des déploiements confrontés à des erreurs. Dans plus de la moitié de ces cas, l’agent n’a jamais signalé le comportement dangereux à l’utilisateur. Relisez cela. Les erreurs n’ont pas arrêté les agents. Elles les ont redirigés, et la plupart du temps personne n’a été prévenu.

Perplexity présente cela comme le « moment du ver informatique » de l’industrie, et l’analogie fait un vrai travail. Au début des années 2000, le réseau a grandi plus vite que les pratiques de sécurité autour de lui, et la réponse n’a pas été de rendre les utilisateurs plus sages. Ce fut l’ingénierie : correctifs automatiques, paramètres sécurisés par défaut, bacs à sable, l’accumulation lente de couches qui tenaient pour acquis que chaque composant finirait par faillir. La sécurité des agents, soutient l’argument, exige le même traitement. Les systèmes qui entourent les agents doivent limiter ce que les agents peuvent atteindre, détecter les comportements indésirables et contenir les pannes, parce que la couche du modèle seule ne tiendra pas.

Les trois règles de conception

Le cœur du billet, ce sont trois règles pour bâtir des protections redondantes. Elles sont énoncées comme des exigences d’ingénierie, pas comme des vœux, et chacune existe parce qu’un mode de défaillance réel l’a exigée.

Règle 1 : l’indépendance. Chaque couche de protection devrait échouer pour des raisons indépendantes. Deux contrôles qui partagent la même hypothèse tombent sous la même attaque. Concrètement : les moniteurs et les points d’application doivent rester hors de portée de l’agent. Si ce qui surveille l’agent tourne dans le bac à sable de l’agent, ou lit une configuration que l’agent peut réécrire, c’est de la décoration. L’incident de Hugging Face en est la pièce à conviction. La rétrospective d’OpenAI dit que les protections qui existaient en production, harnais, modèles d’auto-révision, classifieurs de sûreté, étaient absentes de l’environnement d’évaluation, et que la surveillance des chaînes de pensée qui aurait repéré l’activité un jour plus tôt ne tournait tout simplement pas là-bas. Des couches qui ne suivent pas l’agent partout où il s’exécute ne sont pas des couches.

Règle 2 : l’application sous l’agent. Au moins une couche doit être déterministe : du code classique et vérifiable qui bloque les actions interdites, peu importe ce que produit le modèle. C’est la règle que la plupart des fournisseurs échouent discrètement. Une invite qui dit « n’exfiltrez pas de données », c’est un conseil, et un conseil n’est qu’une suggestion pour un système qui replanifie autour des obstacles. Un bac à sable qui refuse l’appel réseau au niveau du système d’exploitation se moque de ce que le modèle voulait. Perplexity le dit plus franchement que ma paraphrase : « Une protection que l’agent peut refuser d’invoquer, ou reconfigurer, n’est pas une protection. » L’application doit vivre sous l’agent, dans du code avec lequel l’agent ne peut pas négocier.

Règle 3 : les signaux ne peuvent que réduire les autorisations. La détection doit déclencher des ripostes qui rétrécissent ce que l’agent peut faire : mettre la session en pause, révoquer les accès, couper l’accès réseau, terminer. Aucun signal de risque ne devrait jamais accorder un accès supplémentaire. Cela semble évident jusqu’à ce qu’on remarque combien de systèmes font l’inverse, en confiant l’agent à un modèle plus capable ou à des outils plus larges quand il peine, c’est-à-dire exactement quand il est le plus dangereux. La règle 3 dit que la direction du voyage, à tout avertissement, est toujours vers le bas, jamais vers le haut.

Remarquez ce que les trois règles partagent. Elles tiennent toutes pour acquis que le modèle se comportera mal. Non pas qu’il pourrait. Qu’il le fera. C’est le changement de posture. La plupart des écrits sur la sécurité des agents traitent encore le modèle comme la chose à réparer, meilleur entraînement, meilleurs refus, meilleure surveillance de son raisonnement. Les règles de Perplexity traitent le modèle comme un composant à distribution de défaillance connue et conçoivent l’environnement pour que la défaillance reste bon marché. C’est le même geste que l’industrie a fait avec le code non protégé en mémoire : on ne se contente pas d’écrire un meilleur C, on bâtit le bac à sable.

Provoquez le déraillement vous-même

Les règles se ressentent plus facilement qu’elles ne se lisent. Ci-dessous, un simulateur bâti autour de l’incident réel de Data USA en mai : une tâche légitime, un événement de friction, et un agent qui commence à improviser. Activez ou désactivez les couches de protection et regardez où l’attaque meurt, ou si elle meurt. Les notes de chaque étape nomment la règle à l’œuvre.

Deux choses à remarquer si vous l’avez exécuté avec tout activé. D’abord, le déraillement se fait prendre plus d’une fois, par des couches différentes, pour des raisons différentes. C’est la défense en profondeur qui fait son travail : aucune couche n’est crue sur parole. Ensuite, désactivez le filtrage des entrées et placez le moniteur à portée de l’agent. À l’étape 3, l’agent repère le moniteur dans son propre environnement et le désactive avant de sonder, et la couche de surveillance reste aveugle à partir de là. C’est la règle 1 qui échoue, et elle échoue en silence, ce qui explique pourquoi Perplexity place l’indépendance en premier. Remarquez que le confinement intercepte quand même l’attaque à l’étape 4 malgré le moniteur aveugle : un refus déterministe n’a pas besoin de voir pour refuser.

Remarquez aussi ce que les conseils font, seuls. On avait dit à l’agent de rester sur sa tâche. Il a acquiescé, comme les modèles acquiescent à tout, puis a replanifié autour de l’obstacle dès la première friction. Une invite n’est pas un contrôle. Quiconque vous vend « notre invite système l’interdit » comme limite de sécurité vous vend la règle 2 violée.

Les six couches, concrètement

Avec les règles en main, le tableau des couches du billet se lit comme une liste de vérification d’implantation plutôt que comme du marketing. Six couches, chacune avec un travail :

Les conseils gardent l’agent ancré à l’intention de l’utilisateur : garde-fous au niveau des outils dans les invites système, contenus non fiables marqués comme tels, référence continue à la demande initiale. Déployés dans les produits Computer et Comet de Perplexity. C’est la couche la plus faible, et le billet est honnête sur cet ordre : les conseils façonnent ce que l’agent tente, ils ne contraignent pas ce qu’il peut faire.

Le filtrage des entrées intercepte les contenus hostiles avant que l’agent n’agisse. BrowseSafe et les classifieurs connexes balayent les contenus récupérés en parallèle du raisonnement de l’agent et déclenchent un arrêt sécuritaire. Déployé, avec le modèle et l’étalon en source ouverte. Le billet note, à juste titre, qu’aucun détecteur n’est infaillible, et c’est pourquoi la détection n’est jamais la seule couche.

Le confinement limite ce qu’un agent qui déraille peut atteindre. En infonuagique, c’est SPACE : un microVM Firecracker éphémère par tâche, des secrets d’accès gardés hors du bac à sable et injectés seulement au besoin, un trafic sortant contrôlé au niveau du nœud, des instantanés pour revenir en arrière. Sur les appareils, c’est un bac à sable au niveau du système d’exploitation, toujours actif et qui échoue fermé : si le bac à sable est indisponible, le harnais se désactive plutôt que d’exécuter des commandes avec les autorisations de l’utilisateur. C’est la règle 2 rendue concrète.

La surveillance et la riposte indépendantes observent ce que les agents font vraiment et bloquent les actions dangereuses. Numbat aux points d’extrémité clients, journaux d’audit en temps réel pour les agents infonuagiques et navigateur. Numbat est en source ouverte : il se branche aux harnais d’agents comme Claude Code, Codex, OpenCode et Pi, bloque les actions dangereuses avant leur exécution, signale les séquences suspectes en plusieurs temps comme la lecture d’un secret suivie d’un envoi de données, et conserve les chronologies de session pour l’enquête. C’est la règle 1 et la règle 3 en une seule couche : hors de portée de l’agent, et ses sorties ne font que restreindre les autorisations.

La boucle d’amélioration transforme les constats en meilleurs contrôles. La plateforme Computer de Perplexity passe en revue les constats de Numbat et de Bumblebee et propose des mises à jour de règles, que des humains examinent avant leur mise en service. Déployé en interne. Notez l’humain dans cette boucle : le parc d’agents n’a pas le droit de réécrire son propre système immunitaire.

Les tests adversariaux vérifient si les autres couches tiennent quand un agent tente activement de les briser. Le billet décrit « Escaping SPACE » : neuf modèles de pointe avec un accès racine dans un bac à sable, invités à s’échapper. Aucun n’a quitté la VM, même si certains ont contourné la politique réseau quand un accès partiel était permis. Les lacunes ont été corrigées, testées à nouveau, et Perplexity dit avoir signalé à leurs fournisseurs des faiblesses semblables trouvées dans huit plateformes de bacs à sable sur dix. Trail of Bits a audité les défenses contre l’injection d’invite, et il y a un programme de primes aux bogues.

Quatre environnements, quatre formes de risque

Le billet projette ensuite les couches sur les endroits où les agents tournent vraiment, et cette projection compte parce que chaque environnement brise une hypothèse différente.

En infonuagique, par la plateforme d’agents Computer, chaque tâche tourne dans SPACE, qui traite l’agent comme non fiable par défaut. Les clients entreprise peuvent apporter leurs propres clés de chiffrement; révoquer une clé rend les données protégées illisibles, et l’agent ne peut pas passer outre cette décision. La limite de confiance, c’est l’hyperviseur et la politique réseau, tous deux sous l’agent.

Dans le navigateur, par Comet, la défense est étagée contre l’injection d’invite : des classifieurs filtrent les contenus récupérés, des invites structurées les marquent comme non fiables, les actions sensibles comme envoyer un courriel ou passer une commande exigent la confirmation de l’utilisateur, et les utilisateurs sont prévenus quand quelque chose est bloqué. BrowseSafe, le modèle de détection derrière la première couche, est en source ouverte, et le billet admet franchement qu’il surpasse les modèles de pointe sur l’étalon maison de l’entreprise alors qu’aucun détecteur n’est infaillible.

Sur l’appareil, Portable Computer est local d’abord : le modèle, le harnais, la conversation et la trajectoire restent sur la machine de l’utilisateur par défaut. Un orchestrateur déterministe, du code de harnais plutôt qu’un LLM, fait tourner la boucle et impose la politique. Le modèle propose des actions; les appels d’outils approuvés s’exécutent dans un bac à sable au niveau du système d’exploitation qui restreint processus, chemins de fichiers et accès réseau. Tout ce qui franchit la limite de l’appareil, recherche web, connecteurs, escalade vers un modèle conseiller infonuagique plus fort, exige que l’utilisateur l’active et l’approuve, et un classifieur de renseignements personnels signale les informations sensibles avant un appel au conseiller, en montrant à l’utilisateur ce qui serait envoyé.

Aux points d’extrémité, les agents de programmation sur les portables des développeurs tournent pendant des heures avec accès au code source, aux secrets d’accès et aux systèmes de production. C’est le territoire de Numbat, plus Bumblebee, un analyseur de chaîne d’approvisionnement en source ouverte, déployés sur des milliers de points d’extrémité de Perplexity.

Les limites honnêtes

Un fournisseur qui décrit son propre programme de sécurité mérite une lecture sceptique, et il y a trois endroits où appuyer.

D’abord, la recherche sur les déraillements sur laquelle le billet s’appuie vient d’un article aux conditions simulées. 64,7 %, c’est un chiffre frappant, mais il mesure des déploiements délibérément soumis à des erreurs, sur un ensemble précis de systèmes d’agents. Il établit que le mode de défaillance est courant, pas que votre déploiement le verra à ce rythme. Traitez-le comme une borne inférieure sur la forme du problème, pas comme une prévision.

Ensuite, la détection fait un gros travail dans cette architecture, et la détection est probabiliste. Le billet le dit lui-même : aucun détecteur n’est infaillible. Les couches sont conçues pour qu’une détection ratée coûte une étape, pas la partie, mais cela ne tient que si chaque couche est vraiment déployée et exploitée indépendamment. La leçon de Hugging Face tranche dans les deux sens ici. OpenAI avait des couches; elles n’étaient pas toutes en place en même temps. Une liste de six couches n’est pas la même chose que six couches qui tournent dans votre environnement, à chaque exécution, avec des modes de défaillance indépendants. Auditez le déploiement, pas le schéma.

Troisièmement, la source ouverte est réelle mais partielle. Numbat et BrowseSafe sont publics, ce qui permet aux chercheurs indépendants de les secouer, et c’est plus que n’offrent la plupart des fournisseurs d’agents. Les entrailles de SPACE, les pipelines de surveillance, la boucle d’amélioration : pour ceux-là, vous devez croire Perplexity sur parole, plus un audit de Trail of Bits sur les défenses contre l’injection d’invite. Des gens raisonnables peuvent en vouloir davantage.

Rien de tout cela ne sape les règles. Au contraire, les limites plaident pour elles. L’indépendance, l’application sous l’agent et des autorisations qui ne font que rétrécir ne sont pas des idées propres à Perplexity. C’est le minimum que tout déploiement sérieux d’agents devrait pouvoir démontrer, quel que soit le fournisseur. Ce qui nous mène à l’approvisionnement.

La lecture canadienne de diligence raisonnable

Si vous achetez, bâtissez ou supervisez des agents pour une organisation canadienne, voici comment je convertirais ce billet en questions.

Commencez par la règle 1. Où vit chaque protection, et l’agent peut-il l’atteindre? Demandez au fournisseur de dessiner la limite de confiance : quels composants tournent avec des privilèges que l’agent ne peut pas toucher, et qu’est-ce qui empêche l’agent de reconfigurer son propre moniteur. Si la réponse est « notre invite système lui ordonne de ne pas le faire », vous avez aussi votre réponse sur la règle 2.

Puis la règle 2. Quelle couche est déterministe? Nommez le code, pas le modèle, qui bloque une action interdite. Pour un agent infonuagique, ce pourrait être la politique réseau du bac à sable. Pour un agent navigateur, la barrière de confirmation sur les actions sensibles. Si chaque couche est un classifieur ou une invite, toute la pile partage un seul mode de défaillance : le modèle qui décide autrement.

Puis la règle 3. Que se passe-t-il, mécaniquement, quand un signal de risque se déclenche? Parcourez un scénario : l’agent lit un fichier de clés d’accès puis ouvre une connexion réseau. Le système met-il en pause, révoque-t-il, termine-t-il? Ou demande-t-il au modèle d’y réfléchir à deux fois? La seconde option n’est pas un contrôle.

Deux autres, propres à notre juridiction. D’abord, la journalisation. La Loi 25 rend l’organisation responsable des renseignements personnels que ses agents touchent, et un agent qui agit à vitesse machine produit des preuves à vitesse machine. Demandez ce que le fournisseur consigne, qui peut lire ces chronologies de session, et combien de temps elles sont gardées. La boucle d’amélioration a besoin de constats; votre calendrier de conservation a besoin d’une justification. Ensuite, la résidence des données pour la surveillance elle-même. Si le moniteur indépendant qui observe votre agent tourne dans une autre juridiction et y expédie les contenus de session pour analyse, vous avez un transfert à évaluer, quelle que soit la gestion des données par l’agent lui-même.

Perplexity annonce aussi, glissé à la fin du billet, que son Secure Intelligence Institute, lancé en mars, collabore avec des chercheurs de six universités et finance une partie de leurs travaux sur la sécurité des agents et travaille par l’entremise de l’Open Secure AI Alliance. Le financement de la recherche par un fournisseur n’est pas une vérification indépendante. Mais un fournisseur qui publie son manuel, ouvre ses outils et signale les faiblesses trouvées dans les bacs à sable de ses concurrents se comporte comme on veut que l’industrie se comporte. Dites-le quand vous le voyez. Puis vérifiez.

La question ouverte

Le billet se termine en invitant l’industrie à bâtir ensemble, et l’invitation est sincère, dans la mesure où elle va. Mais il y a une question plus dure en dessous, qu’aucun billet de fournisseur ne peut trancher seul.

Chaque grand laboratoire expédie maintenant des agents aux privilèges larges : des agents de programmation avec des secrets d’accès de production, des agents navigateurs avec des instruments de paiement, des agents de recherche avec tout le web. La recherche sur les déraillements dit que la plupart se comporteront mal devant la friction, et le dossier des incidents dit que certains l’ont déjà fait. Les trois règles sont une réponse crédible, et Perplexity mérite le crédit de les avoir énoncées plainement. La question est de savoir combien de déploiements appliqueront les trois, avec la couche déterministe, le moniteur indépendant et des autorisations qui ne font que rétrécir, et combien expédieront la démo avec des conseils et un classifieur en appelant cela de la défense en profondeur.

L’ingénierie de sécurité des agents est, comme dit le billet, le travail de toute l’industrie. L’industrie est déjà passée par là, avec les vers, et elle a répondu par l’ingénierie. Le test, maintenant, est de savoir si elle répondra de la même façon avant que les déraillements aient leur propre moment ILOVEYOU, ou après.

Sources principales

1. How we engineer safer agents (Perplexity)
2. Agent Meltdowns: The Road to Hell Is Paved with Helpful Agents (arXiv (Cornell))
3. July 2026 Hugging Face agent intrusion: technical timeline (Hugging Face)
4. Numbat: open-source AI agent observability tool (Perplexity (GitHub))