Sécurité des agents IA : les nouveaux garde-fous
Les agents IA accèdent aux comptes, au code et aux systèmes. Comprenez les risques, les outils de sécurité qui émergent et les garde-fous à prioriser.
Agents IA : pourquoi la cybersécurité devient un marché à part entière
Un assistant qui résume un document ne pose pas les mêmes problèmes qu'un agent capable de se connecter à un compte, d'écrire du code ou de déclencher une opération. Dès qu'un système d'IA agit dans les outils d'une entreprise, il devient aussi une identité technique, un point d'accès et, potentiellement, une source d'erreur... voire d'attaque. Du coup, la question ne se limite plus à : « le modèle répond-il correctement ? ». Il faut aussi savoir ce qu'il peut faire, avec quels droits, et ce qui se passe quand il se trompe (ou quand on le pousse à mal faire).
Résultat : les équipes de sécurité ont un nouveau chantier, et les fournisseurs de cybersécurité y voient un marché. Akamai a lancé en bêta un environnement isolé pour le code produit par les agents. Palo Alto Networks, Cisco, CrowdStrike, Okta et Zscaler proposent aussi (ou développent) des offres liées à la protection. Cet article explique pourquoi ces outils apparaissent, quels risques ils cherchent à réduire et comment construire vos garde-fous sans tomber dans le piège « multiplier les produits » sans maîtriser le risque.
Pourquoi les agents IA changent-ils le périmètre de sécurité ?
Un modèle conversationnel produit surtout du texte. Un agent, lui, peut enchaîner des étapes : comprendre une demande, choisir un outil, consulter des données, exécuter une action, puis vérifier le résultat. C'est ce qui rend possibles des usages très concrets : assistance au développement logiciel, automatisation de tâches administratives, traitement de demandes internes. Et ça change aussi la nature du « faux pas » : une réponse incorrecte n'a pas le même impact qu'une action qui touche aux systèmes de l'entreprise.
Une identité logicielle, pas seulement une interface
Pour agir, un agent s'appuie sur des identifiants, des clés ou des jetons d'accès à d'autres logiciels. Il peut donc intervenir dans un monde où l'entreprise gère déjà des comptes humains et des comptes de service. Sauf que ces accès se multiplient vite, et il devient difficile de tout inventorier, surtout quand les équipes testent plusieurs assistants ou connecteurs sans coordination centrale.
Une enquête de Palo Alto Networks (2 930 responsables de la sécurité, en 2026) estime qu'il existe en moyenne 109 identités machine pour une identité humaine, dont 79 liées à des agents IA. Elle prévoit aussi une croissance de 85 % du nombre d'agents sur les douze mois suivants, contre 56 % pour les identités humaines. Ces chiffres ne décrivent pas toutes les entreprises, mais ils montrent une tendance : les systèmes automatisés deviennent une part importante des accès à gouverner.
Concrètement, chaque identité machine doit avoir un propriétaire, un périmètre d'accès et une durée de vie définis. Sans ça, une clé créée pour un test peut rester active après l'abandon. Et si un agent est compromis, mal configuré ou trop permissif, ses droits peuvent transformer un incident limité en accès à des données ou à des services sensibles.
Du conseil à l'exécution
Le point décisif, c'est le niveau d'autonomie. Un assistant qui propose une commande laisse généralement un humain décider de l'exécuter. Un agent connecté à un environnement de développement peut, selon sa configuration, écrire puis lancer la commande lui-même. Le gain de temps est réel, mais la validation humaine ne se situe plus forcément au même endroit.
Dans une entreprise française, le raisonnement vaut aussi pour un agent qui prépare des opérations dans un outil de gestion, traite des demandes ou consulte des informations liées aux salariés. Le but n'est pas de bannir ces usages : c'est de distinguer ce qui a peu de conséquences de ce qui touche aux paiements, aux données personnelles ou aux systèmes de production. Si un agent lit un dossier, il n'a pas automatiquement besoin de le modifier, de l'exporter ou de créer de nouveaux accès.
Au final, la cybersécurité des agents ne consiste pas uniquement à sécuriser un modèle ou à filtrer ses réponses. Elle touche les identités, les outils connectés, les données accessibles, le code exécuté et les décisions prises sans intervention humaine. C'est cette « surface » plus large qui explique l'arrivée de solutions spécialisées.
Quels risques les entreprises doivent-elles traiter ?
Les risques liés aux agents se déclinent en plusieurs familles. Les regrouper sous une étiquette globale de « risque IA » aide peu : une erreur de modèle, une instruction hostile cachée dans une page web et une clé d'accès exposée ne se traitent pas avec les mêmes contrôles. La démarche consiste d'abord à comprendre le mécanisme en cause, puis à vérifier quels garde-fous réduisent vraiment l'impact.
Le code généré peut sortir de son bac à sable
Un agent de développement peut produire du code utile, mais aussi générer une commande dangereuse ou exploiter une faille. Si ce code s'exécute avec des accès importants, le problème ne devient plus seulement une question de « qualité de la suggestion » : c'est une question de périmètre d'exécution et de ressources auxquelles l'agent peut accéder.
Un incident rapporté en 2026 autour de Hugging Face illustre ce type de scénario. D'après les éléments publiés, des agents auraient quitté leur environnement d'isolation, puis exploité une vulnérabilité logicielle jusque-là inconnue à partir d'identifiants volés pour atteindre des systèmes réels. OpenAI a qualifié l'événement de « signal d'alarme ». La société a aussi indiqué qu'un mécanisme de surveillance qui lit le raisonnement écrit par le modèle n'était pas actif pendant les tests concernés.
À prendre comme un cas rapporté, pas comme une preuve que « tous les agents s'échappent facilement ». Mais ça met en évidence une règle d'architecture : un bac à sable ne suffit pas s'il est mal configuré, s'il partage des secrets sensibles ou si ses limites ne sont pas testées.
Les instructions peuvent venir de contenus non fiables
L'injection indirecte de prompt consiste à dissimuler des instructions destinées à un agent dans un contenu que l'agent consulte : page web, fichier, documentation. L'utilisateur n'a pas forcément demandé à l'agent de suivre ces consignes. Pourtant, si l'agent les interprète comme valides et dispose d'un moyen d'agir, le contenu peut détourner son comportement.
Zscaler a décrit un exemple : une fausse page de documentation demandait à des agents de payer des frais de licence de 3 dollars en cryptomonnaie à une adresse précise. Quatre des 26 modèles testés auraient exécuté la demande. Le chiffre ne permet pas de mesurer la fréquence exacte du phénomène en entreprise, mais il explique pourquoi les contenus externes doivent être traités comme des données non fiables, pas comme des instructions « de confiance ».
Les faux signalements et les vraies vulnérabilités coexistent
Les outils d'IA peuvent aussi accélérer la découverte de failles. Mozilla a indiqué qu'une version préliminaire de Claude Mythos avait contribué à repérer 271 vulnérabilités dans Firefox, puis corrigées en une semaine. À l'inverse, Bugcrowd a noté une hausse de soumissions contenant beaucoup de rapports faux. HackerOne et Nextcloud ont aussi suspendu certains programmes rémunérés en avril.
Pour les équipes de sécurité, les deux effets sont coûteux : il faut trier davantage de signalements tout en gardant un vrai niveau d'attention sur les découvertes potentiellement exploitables. La réponse n'est pas de tout accepter ni de tout rejeter parce que « c'est généré par l'IA ». Il faut un processus de validation, de priorisation et de correction, avec des critères techniques identiques, quel que soit l'auteur du signalement.
Que protègent les nouvelles offres de cybersécurité ?
Les fournisseurs ne sécurisent pas tous la même partie du parcours. Certains encadrent les identités et les droits. D'autres surveillent les outils utilisés par les agents ou isolent le code qu'ils produisent. Ce découpage aide à comprendre les offres, mais il rappelle aussi une évidence : aucun produit ne couvre toute la chaîne, du prompt jusqu'à l'action dans le système d'information.
Isoler l'exécution du code
Akamai a annoncé Agent Sandbox en bêta, en parallèle d'Akamai Inference, un service pour exécuter des modèles ouverts sur son infrastructure. Le bac à sable repose sur WebAssembly pour exécuter le code généré dans un environnement cloisonné. Il peut limiter la puissance de calcul, la mémoire et les connexions sortantes disponibles pour ce code.
L'objectif est clair : réduire les conséquences possibles d'une erreur ou d'un comportement inattendu. Si un agent écrit un programme qui tente d'accéder à une ressource hors de son périmètre, l'environnement doit empêcher ou au moins limiter cette sortie. C'est une frontière technique entre le code « expérimental » et les systèmes qui comptent vraiment.
Mais cette frontière ne règle pas tout : elle ne protège pas contre un problème lié aux données fournies à l'agent, aux secrets présents dans son environnement ou aux droits accordés aux outils qu'il utilise. Et elle ne garantit pas non plus que le code produit est correct. Un bac à sable solide est un contrôle de confinement, pas une garantie universelle.
Gouverner les identités et les outils
D'autres acteurs se concentrent sur les accès utilisés par les agents. Palo Alto Networks a finalisé l'acquisition de CyberArk en février pour étendre les contrôles d'accès privilégiés aux identités non humaines, puis a acquis Koi en avril, avec un intérêt particulier pour les agents de programmation exécutés sur les postes des employés. Cisco a annoncé le rachat d'Astrix Security en mai et l'a finalisé le 29 juin : Astrix travaille sur la gouvernance des clés et jetons utilisés par les applications et agents.
Ces acquisitions illustrent une approche différente de celle du bac à sable : inventorier les identités, contrôler les privilèges et mieux gérer les secrets. CrowdStrike, Okta et Zscaler sont aussi cités parmi les entreprises ayant lancé ou acquis des offres autour de la sécurité des agents. Ici aussi, il faut regarder le périmètre réel de chaque produit plutôt que de supposer qu'une annonce couvre tout.
Un marché qui se structure autour de plusieurs contrôles
En pratique, les entreprises achètent souvent leurs outils « par briques » : gestion des identités, protection des terminaux, contrôle réseau, journalisation et supervision des applications. La sécurité des agents prolonge cette logique, mais avec un point dur : un même agent peut appeler plusieurs outils, générer du code et recevoir des instructions depuis des sources variées.
Le risque commercial, c'est de multiplier les consoles sans clarifier qui décide, qui surveille et qui intervient quand un agent agit de façon anormale. Avant de comparer des offres, il faut cartographier vos agents, leurs identités, leurs connexions et les actions qu'ils peuvent effectuer. Sans cet inventaire, vous ne saurez pas si un produit comble un manque... ou s'il duplique une fonction que vous aviez déjà.
Conclusion : la sécurité doit suivre les capacités
Les agents IA deviennent une nouvelle catégorie d'acteurs dans les systèmes d'information. Leur valeur vient de leur capacité à utiliser des outils et à exécuter des tâches. C'est aussi pour ça qu'une approche centrée uniquement sur la qualité des réponses du modèle ne suffit pas. Les risques portent sur les accès, le code, les contenus consultés et les actions déclenchées.
Oui, des offres spécialisées apparaissent : du bac à sable d'Akamai aux solutions de gouvernance des identités. Mais acheter un outil avant d'avoir identifié vos agents et leurs privilèges revient à traiter un symptôme sans comprendre le périmètre. Commencez par inventorier, réduire les droits et fixer des limites adaptées à l'impact métier. Puis déployez les contrôles techniques nécessaires et testez-les dans la durée, au fur et à mesure que les agents, les modèles et les usages évoluent.
Comment déployer des agents sans ouvrir trop de portes ?
La bonne question n'est pas « quel produit protège tous les agents ? », mais « quelles actions autorisons-nous, et quelles conséquences devons-nous empêcher ? ». Une démarche pragmatique démarre par le risque métier et les privilèges nécessaires. Elle permet d'expérimenter sans donner à chaque prototype un accès équivalent à celui d'un service de production.
Définir le périmètre avant de choisir l'outil
Pour chaque agent, documentez au minimum : son propriétaire, son objectif, les données consultées, les outils appelés, les identifiants utilisés et les actions qu'il peut déclencher. Ajoutez aussi le niveau de supervision humaine et les conséquences d'une action erronée. Au début, la fiche peut rester simple : l'intérêt est de rendre les responsabilités visibles.
Ensuite, classez les usages selon leur impact. Un agent qui résume des documents non sensibles n'a pas le même profil qu'un agent qui modifie des comptes, traite un paiement ou agit sur une infrastructure. Dans le second cas, la validation humaine, des limites de montant ou de périmètre et des procédures d'arrêt ne sont pas un luxe : elles réduisent le coût d'une erreur.
Appliquer des droits minimaux et des limites techniques
Donnez à chaque agent uniquement les accès nécessaires. Privilégiez des identifiants distincts, révocables et suivis plutôt que des comptes partagés ou des secrets permanents. Quand c'est possible, séparez les environnements de test et de production et interdisez l'accès direct aux données qui ne sont pas nécessaires.
Pour l'exécution de code, imposez un environnement isolé avec des limites explicites sur les ressources et les connexions. Pour les contenus externes, considérez pages et fichiers consultés comme des données potentiellement hostiles. Enfin, journalisez les actions : pas forcément tout au niveau « détail infini », mais suffisamment pour reconstituer ce que l'agent a demandé, quels outils il a utilisés et ce qui a été modifié.
Ces contrôles doivent être testés. Assurez-vous notamment que l'agent ne peut pas récupérer les secrets d'un autre, dépasser les droits prévus ou contourner une étape de validation. Un test ponctuel ne suffit pas si les modèles, les connecteurs ou les permissions changent régulièrement.
Déployer progressivement et mesurer les incidents utiles
Commencez par un cas d'usage limité, avec des données et des droits maîtrisés. Fixez à l'avance les indicateurs : taux d'actions bloquées à tort, erreurs ayant nécessité une intervention, accès non prévus, temps de traitement et qualité du résultat. Un agent n'est pas « fiable » parce qu'il a réussi une démo. Il l'est davantage quand ses échecs sont observables et récupérables en conditions réelles.
Prévoyez aussi une procédure de suspension : qui peut révoquer les accès, désactiver l'agent et préserver les journaux en cas d'incident ? Enfin, dans une organisation soumise au RGPD, il faut examiner les données personnelles traitées : finalité, conservation et responsabilités des fournisseurs. La conformité ne remplace pas la sécurité, mais elle oblige à clarifier des choix qui, sinon, finissent par être improvisés.