Pourquoi les agents IA ne peuvent-ils pas encore sécuriser d’autres agents IA
L’intelligence artificielle passe rapidement de l’étape où elle génère des textes, des images ou des réponses à des questions à celle où elle devient des agents d’IA capables d’agir de manière autonome dans les environnements numériques d’une organisation.
Les agents d’IA peuvent utiliser des outils logiciels, appeler des API, accéder à des informations internes et, dans certaines configurations, modifier des données ou exécuter des actions dans les systèmes métier. Cette évolution transforme radicalement la manière dont les entreprises doivent aborder la cybersécurité.
Dans ce contexte, une idée apparemment logique apparaît : si le nombre d’agents d’IA augmente, pourquoi ne pas utiliser d’autres agents d’IA pour les surveiller et les sécuriser ?
Le problème est que cette stratégie peut introduire un nouveau niveau de complexité et peut même étendre la surface d’attaque, au lieu de la réduire.
Pourquoi l’utilisation d’agents d’IA pour la sécurité est problématique
L’un des principaux problèmes est la nature probabiliste des grands modèles linguistiques (LLM).
Un système d’IA génère des résultats basés sur des probabilités et des modèles appris. En revanche, les contrôles de sécurité critiques doivent, dans de nombreuses situations, fournir des résultats prévisibles et reproductibles.
La différence est essentielle.
Un agent d’IA peut mal interpréter une situation et considérer comme sûre une action qui ne devrait pas être autorisée. Inversement, il peut bloquer une opération légitime et importante pour l’entreprise.
Dans un scénario à haut risque, une décision erronée peut signifier la suppression de données, la modification de ressources numériques, l’accès à des informations confidentielles ou l’interruption d’un processus opérationnel.
C’est pourquoi, un modèle probabiliste ne devrait pas être le seul mécanisme définissant une frontière de sécurité déterministe.
Cela ne signifie pas que l’intelligence artificielle n’a pas un rôle important dans la cybersécurité. Au contraire. L’IA peut être extrêmement utile pour identifier des comportements inhabituels, enquêter sur des alertes et analyser des situations complexes que les règles statiques pourraient manquer.
La différence réside dans le rôle que l’IA reçoit.
Les agents d’IA qui sécurisent les agents d’IA
Un autre problème est la prolifération des agents d’IA. À mesure que les organisations déploient de plus en plus d’agents, la tentation naturelle est d’ajouter d’autres systèmes d’IA pour la surveillance, la vérification et la remédiation.
Ce modèle peut générer une prolifération difficile à contrôler des agents, des permissions, des intégrations et des mécanismes de surveillance.
Chaque agent d’IA supplémentaire peut avoir :
- ses propres permissions ;
- ses propres connexions aux API ;
- l’accès à certaines données ;
- son propre contexte ;
- des coûts de traitement ;
- une latence supplémentaire ;
- de nouveaux points à surveiller et à sécuriser.
Au lieu de simplifier l’architecture de sécurité, un réseau composé d’agents qui surveillent d’autres agents peut rendre le système plus difficile à comprendre.
De plus, lorsqu’un agent défensif interprète les actions d’un autre agent, l’équipe de sécurité doit pouvoir déterminer pourquoi chaque décision a été prise et quel contrôle a permis ou bloqué l’action.
Cette traçabilité est essentielle pour l’audit, la réponse aux incidents et la conformité.
Comment sécuriser les agents d’IA ?
Avant qu’une entreprise ne puisse contrôler les agents d’IA, elle doit savoir où ils se trouvent et ce qu’ils font. L’inventaire des agents autorisés est un point de départ, mais il n’est pas suffisant.
Dans les organisations, des agents adoptés par des employés ou des départements sans l’implication directe de l’équipe informatique centrale peuvent apparaître. Il peut également exister des fonctions d’IA intégrées dans des applications SaaS et d’autres services qui ne sont pas immédiatement perçus comme des « agents d’IA ».
Ce phénomène est souvent associé au terme shadow AI.
L’interdiction totale de ces outils n’est pas nécessairement une solution efficace. Dans certains cas, les utilisateurs peuvent continuer à les utiliser en dehors des processus de gouvernance officiels.
Une stratégie plus solide implique l’identification et la classification des agents en fonction des risques.
Par exemple, la priorité devrait être donnée aux agents d’IA qui :
- traitent des informations sensibles ;
- ont accès à des systèmes internes ;
- peuvent modifier ou supprimer des données ;
- peuvent communiquer en externe ;
- peuvent initier des transactions financières ;
- peuvent modifier des systèmes critiques.
L’identité et le principe du « moindre privilège » deviennent essentiels
Chaque agent d’IA devrait avoir une identité vérifiable, un propriétaire clair et un ensemble de permissions strictement délimité.
Le principe du « moindre privilège », l’octroi du niveau minimal d’accès nécessaire à l’exécution d’une tâche, devient encore plus important dans un écosystème d’agents autonomes.
Un agent qui n’a besoin que de consulter un profil client ne devrait pas pouvoir modifier ce profil.
De même, un agent qui a besoin d’accéder à un compte ou un ensemble de données spécifique ne devrait pas recevoir automatiquement l’accès à l’intégralité de la base de données.
Cette séparation peut limiter l’impact d’une erreur, d’une mauvaise configuration ou d’une tentative de manipulation de l’agent.
Les API et le MCP doivent être contrôlés au niveau de l’exécution
À mesure que les agents d’IA interagissent avec des outils, des API et des standards tels que le Model Context Protocol (MCP), la sécurité ne peut plus se concentrer exclusivement sur les prompts.
Le filtrage des prompts peut identifier certaines instructions suspectes, mais ne peut pas répondre seul à la question fondamentale :
Les agents d’IA ont-ils le droit d’exécuter cette action ?
La réponse doit être étayée par des contrôles d’exécution (runtime). Les organisations peuvent utiliser des listes de permissions, des restrictions sur les paramètres, une autorisation basée sur l’identité et des vérifications de politiques avant qu’un agent ne puisse appeler un outil.
Par exemple, un agent peut avoir la permission de lire les données d’un client, mais pas de les modifier. Ou il peut consulter uniquement les données associées à un identifiant spécifique, pas l’intégralité de la base de données.
Ces mécanismes réduisent la possibilité qu’une instruction malveillante ou une interaction inattendue entraîne une élévation des privilèges de l’agent.
Toutes les actions des agents d’IA ne doivent pas être traitées avec le même niveau de risque
Une erreur fréquente dans la conception de la sécurité de l’IA est de tenter de protéger toutes les interactions de la même manière. Une approche basée sur les risques est plus efficace.
Les organisations devraient commencer par les flux qui peuvent produire les plus grandes conséquences sur l’entreprise : données sensibles, communications externes, transactions financières et modifications des systèmes critiques.
Pour ces zones, des contrôles supplémentaires peuvent être mis en œuvre, notamment :
- des règles déterministes ;
- la validation des paramètres ;
- des listes de permissions ;
- des politiques d’autorisation ;
- des contrôles contre l’injection de prompts ;
- des mécanismes de prévention des pertes de données (DLP) ;
- un audit complet des actions ;
- des sauvegardes pour les systèmes accessibles aux agents ;
- des processus d’approbation humaine pour les opérations critiques.
Qu’est-ce que cela signifie pour les entreprises ?
Le message important pour les organisations n’est pas que l’IA ne peut pas être utilisée pour la sécurité. Au contraire, l’IA peut devenir un outil précieux pour les équipes de cybersécurité, mais elle ne doit pas être confondue avec un substitut universel aux contrôles déterministes.
Un modèle d’IA peut aider à prioriser les alertes, à corréler les événements et à enquêter sur des comportements complexes. Mais les décisions ayant un impact majeur doivent être encadrées par des politiques et des mécanismes techniques vérifiables.
En d’autres termes, l’architecture de sécurité devrait partir de la question :
« Qu’est-ce que l’agent est autorisé à faire ? »
et non seulement de :
« Comment pouvons-nous utiliser l’IA pour surveiller l’agent ? »
Ce changement de perspective est essentiel pour le développement d’une stratégie de sécurité de l’IA fiable.
L’avenir de la cybersécurité basée sur les agents d’IA
L’IA agentique peut apporter des avantages importants pour l’automatisation des processus d’entreprise, mais l’autonomie supplémentaire s’accompagne de responsabilités de sécurité supplémentaires.
Utiliser un agent d’IA pour sécuriser un autre agent peut sembler une solution élégante, mais cela introduit des risques lorsque les systèmes probabilistes reçoivent la responsabilité d’imposer des contrôles qui doivent être prévisibles.
Une stratégie plus robuste commence par la visibilité, l’identité, le contrôle d’accès et des politiques déterministes d’exécution (runtime). Les agents doivent être inventoriés, associés à des propriétaires et limités aux permissions strictement nécessaires.
L’IA peut compléter ces mécanismes par l’analyse et la détection, mais elle ne devrait pas être la seule ligne de défense.
Pour les organisations qui adoptent l’IA agentique en 2026, la règle de base est simple : plus un agent a d’autonomie et d’accès aux systèmes critiques, plus les contrôles de sécurité doivent être déterministes, vérifiables et faciles à auditer.
Source: computerweekly.com
