100 résultats d’évaluation de sécurité des agents IA montrent : les entreprises doivent réexaminer les limites de contrôle avant d’accélérer leur adoption

Les résultats de l’évaluation de sécurité de 100 agents IA montrent que les entreprises doivent revoir les périmètres de contrôle avant une adoption accélérée

Au cours de l’année écoulée, les investissements des entreprises dans les agents IA ont fortement augmenté, mais la recherche en sécurité alerte le marché : plus un agent est puissant, plus sa surface d’attaque est généralement grande. Selon une étude d’Adversa AI citée par SecurityWeek, l’entreprise a évalué la sécurité de 100 agents IA et les a comparés selon trois dimensions, sur la base du « AI Risk Quadrant » : la vulnérabilité à la compromission, l’impact potentiel des dommages et la robustesse des contrôles défensifs. Le constat n’est pas encourageant : parmi les 100 agents testés, seuls 11 ont été classés comme « capable well-defended » (à la fois capables et bien protégés).

L’importance de cette étude ne réside pas dans le fait de savoir si un produit donné est « sûr », mais dans le fait qu’elle met en lumière une réalité plus large pour les entreprises : l’IA agentique superpose les risques des logiciels traditionnels, les risques d’identité, les risques liés aux données et les risques d’exécution automatisée sur une même surface de contrôle. Pour les RSSI, les responsables informatiques et les architectes sécurité, cela signifie que les agents IA ne doivent pas être considérés seulement comme des fonctions de productivité, mais comme des systèmes à haute confiance et des systèmes d’automatisation à haut risque.

Conclusion clé : les capacités et la protection sont en train de s’inverser

Dans son analyse, Adversa AI introduit un concept essentiel : l’inversion puissance-protection (power-protection inversion). En termes simples, plus un agent est capable d’exécuter des tâches complexes et plus il est proche des processus métier centraux, plus il nécessite généralement des privilèges élevés, un accès plus large aux données et davantage de capacités d’actions externes ; or, ce sont précisément ces capacités qui amplifient les dégâts possibles en cas d’abus ou de détournement.

L’étude résume le problème avec la « triade mortelle » des agents IA (« lethal trifecta ») :

1. La capacité d’accéder à des données privées 2. La capacité d’être exposé à du contenu non fiable 3. La capacité d’exécuter des actions sortantes

Lorsque ces trois éléments sont réunis, l’agent devient plus vulnérable à l’injection de prompts, à la pollution du contexte, à l’abus de privilèges ou au détournement d’actions. Selon la formulation de l’étude, 98 % des systèmes testés présentaient cette structure. Cela ne signifie pas qu’ils seront nécessairement compromis, mais cela implique que les entreprises doivent, lors du déploiement, les considérer par défaut comme des automatismes à haut risque et non comme de simples applications.

Quels types d’agents présentent le plus de risques ? Les agents informatiques et les agents de codage sont les plus préoccupants

L’étude indique que les deux catégories les plus exposées sont les computer agents (agents informatiques) et les coding agents (agents de codage).

1) Agents informatiques : une fois hors de contrôle, les conséquences dépassent largement le simple « mauvais clic » sur une application

Les agents informatiques disposent généralement de la capacité d’interagir avec des environnements de bureau, des navigateurs, des interfaces système, voire avec un système d’exploitation complet.Les agents de type ordinateur disposent généralement de la capacité d’opérer dans des environnements de bureau, des navigateurs, des interfaces système, voire des systèmes d’exploitation complets. Leur vocation initiale est d’agir à la place de l’utilisateur, mais pour accomplir leurs tâches, ils nécessitent souvent des privilèges système assez larges.

Cela pose deux problèmes de niveau entreprise :

• L’attaquant peut obtenir une surface de contrôle terminale plus vaste : si cet agent est incité à exécuter des étapes malveillantes, le risque peut s’étendre d’une seule application à l’ensemble du terminal.
• Visibilité insuffisante pour l’utilisateur : des études indiquent que les humains ne voient souvent que “l’entrée de la tâche” et “la sortie du résultat”, sans voir ce que l’agent a réellement consulté entre les deux, quelles ressources il a appelées, ni quels états système il a modifiés.

Pour les entreprises, si ce type d’agent est intégré à un environnement bureautique, à des processus financiers, RH ou à des consoles d’exploitation IT, le risque ne se limite pas à un “mauvais clic” ou à une “mauvaise manipulation”, mais consiste à fusionner les privilèges du terminal, l’accès aux données et l’exécution automatique en un seul chemin susceptible d’être détourné.

2）Les agents de codage : une entrée plus directe dans la chaîne d’approvisionnement logicielle

Les risques liés aux agents de codage se situent encore plus près de la chaîne de développement et de déploiement logiciel des entreprises. L’analyse d’Adversa souligne que ces agents ne se contentent pas de générer des suggestions de code ; ils peuvent aussi accéder au shell, aux dépendances, aux jetons, aux fichiers de configuration et aux pipelines de déploiement.

Cela signifie que, lorsqu’un agent de codage est détourné, les conséquences potentielles ne se limitent pas à la génération de code non sécurisé, mais peuvent inclure :

• l’accès à des clés ou jetons de développement
• la modification des processus de build et de test
• l’introduction de dépendances à haut risque
• l’impact sur les configurations de préproduction ou de production
• l’accès à des actifs sensibles avant la revue de code

Pour les organisations qui adoptent DevOps, l’ingénierie de plateforme ou des modèles internes de low-code / “vibe coding”, l’impact de ce type d’agent est particulièrement important, car il insère le risque au cœur même de la chaîne d’approvisionnement logicielle. Les entreprises ne peuvent pas se contenter d’examiner le diff final du code ; elles doivent aussi vérifier quelles actions l’agent a exécutées, à quels secrets il a eu accès et par quelles connexions externes il est passé.

Impact pour les entreprises : il ne s’agit pas d’un simple problème ponctuel de “sécurité du modèle”, mais d’un problème de contrôle métier

Du point de vue de l’entreprise, les problèmes de sécurité liés aux agents IA affectent au moins quatre niveaux.

1）Risque opérationnel

Si l’agent dispose d’autorisations erronées ou est exploité via une injection de prompt, il peut exécuter directement de mauvaises actions, comme envoyer un mauvais e-mail, accéder à un système auquel il ne devrait pas accéder, modifier l’état d’un ticket, déclencher un flux d’automatisation, voire appeler par erreur une API externe dans un environnement intégré. Pour les entreprises qui dépendent de l’automatisation, ce type d’incident se transforme en interruption de processus, rollback manuel et retard opérationnel.

2）Risque financier

Un agent doté de privilèges élevés peut provoquer une mauvaise utilisation des ressources, une explosion des coûts cloud, une utilisation abusive de licences, ou encore introduire des coûts de correction dans les scénarios de code et de déploiement. Si l’agent participe au service client, aux processus commerciaux ou au traitement des transactions, des actions erronées peuvent également se traduire par une perte de revenus directe.

3）Risque de conformité et d’auditLorsque les AI Agent entrent en contact avec des données personnelles, des données financières, des données réglementées ou des données transfrontalières, les entreprises doivent répondre aux questions suivantes :

• Qui a autorisé l’Agent ?
• À quelles données a-t-il accédé ?
• Chacune de ses actions est-elle audit-able ?
• Est-il conforme aux exigences de moindre privilège, de minimisation des données et de traçabilité ?

Si l’entreprise ne peut pas fournir de journaux clairs, l’AI Agent deviendra une zone aveugle pour l’audit. Pour les organisations liées à la finance, à la santé, au secteur public et aux infrastructures critiques, ce point est particulièrement sensible.

4）Risques liés à la marque et à la confiance

Les utilisateurs ne se préoccupent pas du fait que l’Agent soit « théoriquement très intelligent » ; ils se soucient plutôt de savoir s’il risque de divulguer des informations, de mal exécuter des opérations ou de prendre des décisions difficiles à expliquer. Un seul échec visible peut suffire à affaiblir la confiance des clients, des partenaires et des employés internes dans le système d’automatisation. Pour les entreprises qui mènent une transformation par l’IA, cette perte de confiance ralentit souvent les déploiements ultérieurs.

Cela reflète une tendance du secteur, et non un phénomène isolé

L’aspect le plus notable de cette étude est qu’elle ne décrit pas un incident de vulnérabilité ponctuel, mais met en lumière une tendance structurelle : la vitesse de progression des capacités de l’IA dépasse celle de l’adaptation des contrôles de sécurité traditionnels aux systèmes d’automatisation.

Les conclusions d’Adversa suggèrent également un phénomène de marché : de nombreux fournisseurs mettent davantage l’accent sur les « capacités » et l’« efficacité », tout en fournissant insuffisamment d’éléments publics vérifiables sur la protection. Pour les acheteurs d’entreprise, cela signifie que l’évaluation d’un AI Agent ne doit pas se limiter à la question « que peut-il faire ? », mais doit aussi porter sur :

• Doit-il accéder à des données privées ?
• Entre-t-il en contact avec du contenu non fiable ?
• Peut-il lancer des actions sortantes ?
• Prend-il en charge des frontières de permissions vérifiables, des journaux d’audit et une approbation des actions ?
• Peut-il se dégrader en toute sécurité en cas d’échec ?

Autrement dit, la sécurité des AI Agent passe d’un « problème de modèle » à un « problème de contrôle métier et de gouvernance en temps d’exécution ».

Recommandations pour les entreprises : gouverner l’Agent comme un système d’automatisation à privilèges élevés

Au niveau de l’entreprise

• Mettre en place un système de classification de l’usage des AI Agent selon la sensibilité des données, les droits d’action et l’impact métier
• Réaliser des évaluations de risques distinctes pour le contenu externe, les systèmes internes et les capacités d’exécution automatique
• Définir des lignes rouges pour ce qui peut être automatisé et ce qui doit impérativement être confirmé par un humain

Contrôle des identités et des accès

• Imposer le principe du moindre privilège
• Utiliser une identité dédiée pour l’Agent plutôt qu’un compte humain partagé
• Introduire pour les actions à haut risque une MFA, un accès conditionnel et des approbations étape par étape
• Soumettre les actions critiques et les opérations irréversibles à une vérification supplémentaire

Contrôles techniques

• Utiliser SIEM pour centraliser l’enregistrement du comportement de l’Agent et de ses interactions avec les systèmes
• Utiliser EDR/XDR pour détecter les anomalies de terminal et de comportements interdomaines
• Imposer des restrictions sur le trafic sortant, les appels API et l’exfiltration de données
• Conserver des journaux d’audit de la chaîne d’exécution de l’Agent, et pas seulement des journaux de résultats
• Dans les environnements de développement, surveiller les shells, les dépendances, les jetons et les interactions CI/CD

Management et gouvernance

• Intégrer les AI Agent dans les plans de Incident Response
• Évaluer les risques des Agents tiers, des plugins, des serveurs MCP et des chaînes d’outils externes
• Mettre en place un processus de Third-party Risk Management
• Définir des seuils de mise en production et des mécanismes de sortie pour l’« automatisation boîte noire »
• Réexaminer régulièrement les permissions des Agents, sans les considérer comme valables indéfiniment par défaut

SecurityPost Insight

• Les tests d’Adversa AI sur 100 AI Agent rappellent aux entreprises que la sécurité des AI Agent n’est pas un sujet du futur, mais un risque réel en pleine expansion.- Utiliser SIEM pour consigner de manière centralisée le comportement de l’Agent et ses interactions avec les systèmes
• Utiliser EDR/XDR pour surveiller les terminaux et les anomalies de comportement inter-domaines
• Imposer des restrictions sur le trafic sortant, les appels API et l’exfiltration de données
• Conserver des journaux vérifiables pour les chemins d’exécution de l’Agent, et pas seulement des journaux de résultats
• Dans les scénarios de développement, surveiller le shell, les dépendances, les jetons et les interactions CI/CD

Gestion et gouvernance

• Intégrer l’AI Agent dans les plans de réponse aux incidents
• Évaluer les risques liés aux Agents tiers, aux plugins, aux serveurs MCP et aux chaînes d’outils externes
• Mettre en place un processus de gestion des risques tiers
• Fixer des seuils de mise en production et des mécanismes de sortie pour les « automatisations boîte noire »
• Réexaminer régulièrement les privilèges de l’Agent, plutôt que de les laisser valides indéfiniment

SecurityPost Insight

Les tests d’Adversa AI sur 100 AI Agents rappellent aux entreprises que la sécurité des AI Agents n’est pas un enjeu futur, mais un risque réel en pleine expansion. Le véritable défi ne réside pas seulement dans la question de savoir si le modèle peut « mal s’exprimer », mais dans le fait de savoir si, une fois doté d’un accès aux données, d’un contact avec le contenu et de capacités d’actions sortantes, il transformera une erreur en un incident de sécurité exécutable. Pour les entreprises, le plus dangereux n’est pas d’utiliser l’IA, mais de déployer des AI Agents sans limites, sans audit et sans séparation des privilèges.

Trois tendances méritent une attention particulière à l’avenir : premièrement, les Agents continueront d’entrer dans les flux de travail bureautiques, de développement, de support client et d’exploitation ; deuxièmement, les attaques par injection de prompt, l’abus de privilèges et les attaques sur la chaîne d’approvisionnement visant les Agents deviendront plus systématiques ; troisièmement, les entreprises passeront progressivement de « l’évaluation des modèles » à la « gouvernance à l’exécution » et à la « protection vérifiable ». Pour les CISO, la priorité à venir n’est pas de savoir s’il faut adopter des Agents, mais de savoir comment les adopter tout en garantissant que l’identité, les sorties, l’audit et les actions irréversibles restent maîtrisables.