Sécuriser l’IA Agentique : 5 Pratiques Que Toute Équipe de Sécurité Devrait Adopter Dès Maintenant

La semaine dernière, nous avons examiné pourquoi l’injection indirecte de commandes (indirect prompt injection) est devenue l’un des risques les plus urgents pour les équipes de sécurité en 2026, classée par l’OWASP comme le risque numéro un pour les applications LLM et d’intelligence artificielle générative, et déjà liée à des incidents confirmés d’exfiltration de données, de paiements non autorisés et même d’exécution de code à distance. La question naturelle qui suit est de savoir quoi faire concrètement.

La bonne nouvelle, c’est qu’il ne s’agit pas d’un problème insoluble. C’est un problème nouveau, qui exige un état d’esprit différent de celui de la sécurité applicative traditionnelle, mais un ensemble croissant de recommandations concrètes émane d’organisations comme l’OWASP et OpenAI sur la manière de concevoir et d’exploiter des agents d’IA capables de résister à une attaque. Voici cinq pratiques qu’il vaut la peine de mettre en place dès maintenant.

1. Cartographiez le rayon d’impact de chaque agent avant sa mise en production

Le chercheur Simon Willison a décrit un schéma qu’il appelle la « trifecta létale », et il constitue un cadre utile pour toute équipe de sécurité évaluant des agents d’IA. Un agent devient véritablement dangereux lorsqu’il combine trois éléments à la fois : l’accès à des données privées, l’exposition à du contenu externe non fiable, comme des courriels ou des pages web, et la capacité de communiquer vers l’extérieur, que ce soit en envoyant des données, en appelant une API ou en affichant un lien. Chacun de ces éléments pris isolément reste gérable. Réunis, ils signifient qu’un attaquant capable d’insérer des instructions dans le contenu que votre agent lit pourrait repartir avec tout ce que cet agent peut voir.

Avant de mettre un agent en production, posez-vous une question simple : possède-t-il ces trois capacités à la fois ? Si c’est le cas, traitez-le comme un système à haut risque nécessitant les contrôles décrits ci-dessous, et non comme une application standard qui reçoit une revue de routine avant d’être déployée.

2. Appliquez le principe du moindre privilège à ce que les agents peuvent réellement faire

Attribuez aux agents des identifiants limités à leur périmètre plutôt qu’un accès étendu aux systèmes qu’ils touchent, et imposez de véritables limites aux actions à fort impact comme les paiements, les suppressions et l’exécution de code. Pensez-y comme vous le feriez pour un nouvel employé. Un représentant du service client humain dispose généralement d’un plafond de remboursement et doit obtenir une validation au-delà. Vos agents d’IA méritent la même rigueur. Si un agent n’a pas besoin de pouvoir supprimer des enregistrements ou déplacer des fonds, il ne devrait tout simplement pas en avoir la capacité.

3. Tenez le contenu non fiable à l’écart du canal d’instructions

Une part importante des attaques par injection de commandes observées dans le monde réel fonctionne parce qu’il n’existe aucune frontière claire entre ce qu’un système a reçu comme instruction et ce qu’il lit par ailleurs en l’exécutant. Concevez vos prompts de façon à ce que le contenu externe (pages web, documents, courriels, journaux d’activité) soit clairement séparé des instructions au niveau du système, et ajoutez le filtrage des entrées et des sorties comme une couche supplémentaire, non comme votre seule ligne de défense. Le filtrage repère les schémas connus. La séparation structurelle est ce qui vous protège contre ceux que personne n’a encore vus.

4. Exigez une validation humaine pour les actions privilégiées ou irréversibles

Toute action ayant de réelles conséquences financières, opérationnelles ou de perte de données doit passer par une validation humaine avant son exécution. Il ne s’agit pas de ralentir vos équipes sur tous les fronts. Il s’agit d’être précis sur les actions pouvant s’exécuter de manière autonome et celles qui méritent un second regard, la même distinction que vous appliqueriez déjà à une demande de virement bancaire ou à une modification d’une base de données de production.

5. Testez en continu, et traitez le modèle comme un utilisateur non fiable

C’est la pratique que la plupart des organisations n’ont pas encore mise en place, et c’est celle qui compte le plus. Les analyses de vulnérabilités standards et les revues de code ne détecteront pas l’injection de commandes, car la faille réside dans la façon dont le système traite le contenu, et non dans une portion de code dotée d’une signature connue. C’est précisément pour cette raison que l’injection de commandes peut occuper la première place des préoccupations des experts en sécurité tout en apparaissant beaucoup plus rarement dans les registres traditionnels d’incidents et de vulnérabilités : les outils que la plupart des programmes utilisent déjà n’ont jamais été conçus pour la détecter.

La seule façon fiable de savoir si vos agents résistent réellement est de les tester comme le ferait un attaquant, en traitant le modèle lui-même comme une partie non fiable et en examinant les intégrations d’outils, les permissions et l’accès aux données qui le sous-tendent, et pas seulement les réponses du modèle prises isolément. C’est exactement là que les tests d’intrusion spécialisés en IA et LLM font toute la différence. Les tests de sécurité pour l’IA générative et les LLM d’Orenda sont conçus précisément autour de ce modèle de menace, en évaluant comment un agent se comporte face à un contenu manipulé et où ses permissions et intégrations d’outils pourraient être détournées. Associés à des exercices de red team et à une gestion continue des vulnérabilités, ils vous apportent une réponse réelle, fondée sur des preuves plutôt que sur des suppositions, à la question que tout RSSI déployant des agents d’IA devrait se poser : si quelqu’un tentait cela contre nous aujourd’hui, est-ce que cela fonctionnerait ?

L’essentiel à retenir

Aucune de ces cinq pratiques n’exige de ralentir vos initiatives en matière d’IA. Elles exigent que vous les construisiez avec la même rigueur que celle que vous appliquez déjà à vos réseaux, vos applications et vos environnements cloud : savoir ce que vous exposez, limiter ce qui peut mal tourner, et tester régulièrement face à de véritables techniques d’attaque plutôt que de supposer que tout va bien simplement parce que rien ne s’est encore produit.