Les chercheurs de HiddenLayer contournent les garde-fous d’OpenAI, exposant une faille critique dans l’autorégulation de l’IA

Le 6 octobre 2025, OpenAI a annoncé AgentKit, un kit d’outils pour la construction, le déploiement et la gestion d’agents IA. L’un de ses composants est Guardrails – une couche de sécurité modulaire conçue pour surveiller les entrées, les sorties et les interactions d’outils des agents afin de prévenir les abus, les fuites de données ou les comportements malveillants. Guardrails peut masquer ou signaler les informations personnelles, détecter les jailbreaks et appliquer des contraintes de politique aux côtés de l’exécution de l’agent.

Alors que Guardrails est un élément nouvellement public de l’architecture d’agent d’OpenAI, les recherches de HiddenLayer révèlent une vulnérabilité plus profonde : puisque les actions de l’agent et les vérifications de sécurité utilisent une logique de modèle similaire, les attaquants peuvent créer des entrées qui sapent les deux simultanément – en effet, en brisant la couche de sécurité de l’intérieur.

Ce que HiddenLayer a découvert

La conception d’OpenAI prévoit des agents qui fonctionnent par une logique en chaîne : un utilisateur émet une demande, l’agent appelle des outils ou des ressources externes, et les réponses sont filtrées ou validées par Guardrails avant l’exécution ou la sortie. L’intention est que, quoi que fasse l’agent – qu’il génère du texte, récupère une page Web ou déclenche une fonction – Guardrails agit comme un gardien.

HiddenLayer soutient que ce gardien est structurellement défectueux lorsqu’il est construit à partir de la même classe de modèle qu’il protège. Dans leurs expériences, ils ont créé des invites qui font double emploi : ils obligent le modèle d’agent à générer du contenu qui viole la politique et manipulent le modèle juge de Guardrails pour déclarer que le contenu est “sûr”. En effet, l’invite intègre une annulation de la logique interne du juge – ses seuils de confiance, ses branches de décision – de telle sorte que le juge donne faussement son accord à la sortie malveillante. Le système produit alors du contenu interdit sans déclencher d’alerte.

Ils ont poussé l’attaque plus loin en ciblant les injections de contenu indirectes, telles que les appels de récupération d’outils. Supposons que l’agent récupère une page Web contenant des instructions malveillantes ou des invites cachées. Guardrails devrait les signaler ou les bloquer, mais la technique de HiddenLayer intègre une annulation du juge dans le contenu récupéré lui-même. Lorsque le juge le traite, il voit l’annulation et “approuve” le contenu, laissant passer l’appel de l’outil – et tout contenu malveillant qu’il retourne – sans vérification.

La leçon plus profonde est claire : lorsque votre mécanisme de sécurité est construit en utilisant la même logique et les mêmes vulnérabilités que la chose qu’il protège, une seule invite astucieuse peut briser les deux.

Pourquoi cela compte

Ce que HiddenLayer a exposé n’est pas un simple bogue – c’est une histoire de mise en garde sur la façon dont nous concevons la sécurité dans les systèmes LLM. Toute architecture qui repose sur la même classe de modèle pour la génération et l’évaluation risque des défaillances partagées sous des entrées adverses.

Cela signifie que de nombreux déploiements qui croyaient “nous avons mis en place des garde-fous, nous sommes donc en sécurité” pourraient sous-estimer le risque. Dans des cas d’utilisation non hostiles et occasionnels, leurs filtres pourraient sembler efficaces, mais dans des scénarios adverses, ils pourraient échouer silencieusement. Dans des domaines tels que les soins de santé, la finance, le gouvernement ou les systèmes critiques, de telles défaillances silencieuses pourraient entraîner des préjudices graves.

Cette recherche s’appuie également sur des méthodes d’injection de invites antérieures. La technique précédente de HiddenLayer, “Policy Puppetry“, a montré comment les attaquants peuvent déguiser des instructions nuisibles en contenu de politique. Maintenant, ils démontrent que de telles attaques masquées peuvent s’étendre à la logique de sécurité elle-même.

Implications pour les déploiements et les chercheurs

À la lumière de cette vulnérabilité, quiconque utilise ou construit des systèmes LLM agents doit repenser la stratégie de sécurité.

Premièrement : ne pas s’appuyer uniquement sur les vérifications internes basées sur le modèle. La sécurité doit être stratifiée. Cela signifie combiner des filtres basés sur des règles, des détecteurs d’anomalies, des systèmes de journalisation, une surveillance externe, une surveillance humaine et des traces d’audit. Si une couche échoue, les autres pourraient détecter la faille.

Deuxièmement : des tests d’équipe rouge adverses réguliers sont non négociables. Les modèles devraient être confrontés à des injections d’invites qui tentent de remplacer leur propre logique de garde – et non seulement du “mauvais contenu”. Les tests doivent évoluer à mesure que les attaquants inventent de nouvelles techniques.

Troisièmement : dans les secteurs réglementés ou critiques en matière de sécurité, la transparence et la vérifiabilité sont essentielles. Les déploiements ont besoin de preuves que le système peut résister à des attaques adverses, et non seulement à une fonctionnalité de base. Cela suggère que des audits tiers, une vérification formelle ou des garanties de sécurité pourraient devenir des exigences.

Quatrièmement : pour les constructeurs de modèles, corriger cette classe de vulnérabilité est difficile. Puisqu’elle est liée à la façon dont les modèles analysent et obéissent aux instructions, le simple filtrage d’une classe d’invites ne garantit pas la résistance à de nouvelles invites. Les défenses basées sur le fine-tuning ou les filtres peuvent dégrader les performances du modèle ou conduire à des courses aux armements. Une conception plus robuste peut nécessiter une séparation architecturale – la logique de garde fonctionnant dans un modèle ou un sous-système différent du modèle de génération.

Limitations et questions ouvertes

Pour clarifier : les travaux de HiddenLayer sont une preuve de concept, et non un verdict final sur chaque architecture de sécurité. Leurs attaques réussies dépendent d’une connaissance approfondie de la structure d’invite et de la logique de notation interne du modèle de garde. Dans des environnements d’invite plus restreints ou des systèmes qui aléatoirisent les défenses, l’attaque peut être plus difficile à lancer.

De plus, ils n’analysent pas pleinement la cohérence ou l’utilité des sorties malveillantes lorsqu’elles sont créées sous ces contraintes. Certaines sorties de jailbreak ou d’annulation peuvent se dégrader en qualité ou en fiabilité. Le risque est donc réel, mais contraint par l’environnement, le budget d’invite, les contraintes d’interface et l’aléatoire de la garde.

Enfin, certaines conceptions de garde-fous utilisent des classes de modèles différentes, des méthodes d’ensemble ou des évaluations aléatoires. Il n’est pas certain que chaque système de ce type soit vulnérable ; la question de savoir si cette attaque se généralise largement est une question de recherche ouverte.

Regarder vers l’avenir : l’avenir de la sécurité de l’IA

Nous semblons entrer dans une nouvelle phase : les attaques par invites non seulement contre les modèles, mais contre leurs couches de sécurité. Des techniques telles que l’hijacking de la chaîne de pensée, la subversion hiérarchique d’invite et l’annulation du juge pousseront les défenses à évoluer plus rapidement.

La voie à suivre est probablement vers une surveillance externe – des systèmes qui surveillent les sorties de l’extérieur, ne partagent pas la logique de modèle ou imposent des vérifications de sécurité via des contrôles externes. Des architectures hybrides, des méthodes formelles, la détection d’anomalies et des boucles de rétroaction humaine devront se combiner.

Les garde-fous sont un outil utile, mais les découvertes de HiddenLayer nous rappellent : ils ne peuvent pas être l’unique outil. La sécurité doit provenir de l’extérieur du système, et non seulement de l’intérieur.

La logique de del, ou imposer des vérifications de sécurité via des contrôles externes. Les architectures hybrides, les méthodes formelles, la détection d’anomalies et les boucles de rétroaction humaine devront se combiner. Les garde-fous sont un outil utile, mais les découvertes de HiddenLayer nous rappellent : ils ne peuvent pas être l’unique outil. La sécurité doit provenir de l’extérieur du système, et non seulement de l’intérieur.