L’IA défensive a aussi besoin de contrôles d’accès

Yves Wattel, VP Sales Europe du Sud et Europe Centrale chez Delinea partage son analyse et ses conseils.

L’agent de sécurité devient une partie de la surface d’attaque

Les équipes de sécurité déploient de plus en plus d’agents IA pour trier les alertes, prioriser les vulnérabilités ou enquêter sur les activités suspectes. La logique est claire, plus les attaques deviennent automatiques et le volume de signaux à évaluer important, plus la défense doit elle aussi gagner en rapidité. Cependant, cela redéfinit le paysage de la sécurité. Un agent qui se contente d’évaluer une alerte reste un simple outil d’analyse. En revanche, dès qu’il ouvre un ticket ou isole un processus, il commence à interagir avec l’environnement informatique. Pour ce faire, il a besoin d’accéder aux environnements cloud, aux systèmes de ticketing ou aux outils d’administration.

L’agent IA fait ainsi partie de la défense, mais rejoint également la surface d’attaque. Il traite des informations provenant de sources variées, utilise des interfaces privilégiées et peut amorcer des modifications en très peu de temps. Son rôle défensif ne le dispense pas d’être contrôlé. Au contraire, c’est précisément parce qu’il est déployé pour protéger qu’on lui accorde souvent des privilèges étendus.

Une IA défensive n’est pas automatiquement digne de confiance

Le risque ne vient pas d’un agent de sécurité qui agirait intentionnellement de façon malveillante. Il survient lorsque l’agent rencontre des informations inexactes, incomplètes ou manipulées et y répond en utilisant des droits privilégiés. Ce qui provoquerait une simple erreur d’appréciation sur un outil purement analytique peut déclencher une modification directe de l’environnement de production dès lors que l’agent a la capacité d’agir.

Le problème ne vient pas nécessairement du modèle ou d’un manque de protection à la connexion. Il apparaît lorsqu’une autorisation est trop large et reste valide dans un nouveau contexte. Cela devient particulièrement critique lorsque les agents sont autorisés à effectuer des modifications en production ou à modifier des identifiants. Les contrôles de sécurité ne doivent donc pas seulement évaluer qui obtient l’accès, mais aussi limiter ce que l’agent est autorisé à faire avec cet accès.

Yves Wattel, VP Sales Europe du Sud et Europe Centrale chez Delinea

Un rôle n’est pas un chèque en blanc

Les contrôles d’accès traditionnels prennent leur décision principale au moment de la connexion. Une fois l’utilisateur authentifié, l’autorisation reste souvent active pendant une durée définie. Pour des administrateurs humains, cela peut fonctionner à condition d’appliquer des contrôles complémentaires. En revanche, les agents fonctionnent à très grande vitesse et peuvent cibler de nombreux systèmes en très peu de temps. Une autorisation pertinente au début d’une session peut devenir inappropriée quelques minutes plus tard, par exemple parce que le niveau de risque a changé, de nouvelles informations sont apparues ou l’agent s’aventure dans une zone non couverte par sa mission initiale.

Ce n’est pas parce que l’agent fait partie de la défense que ses autorisations doivent devenir un chèque en blanc. Il a besoin d’un accès pour une tâche clairement définie, et non d’un accès permanent à l’ensemble d’un environnement. S’il doit corriger une vulnérabilité, il ne doit pouvoir accéder qu’aux seules ressources nécessaires à cette fin. Une fois la tâche accomplie, cette autorisation doit expirer.

Des autorisations éphémères plutôt qu’un accès permanent

Un accès privilégié permanent subsiste même en l’absence de tâche légitime. Si un agent est induit en erreur, ce niveau d’accès reste immédiatement exploitable. Des autorisations temporaires, basées sur la tâche à accomplir, constituent une approche bien plus raisonnable. L’agent ne reçoit un accès à une ressource définie que pour la durée d’une étape de travail précise. L’autorisation est ensuite révoquée automatiquement.

Cela ne signifie pas que chaque action de routine doit être approuvée manuellement. Un agent peut collecter des informations, enrichir des alertes ou préparer des recommandations de correctifs. En revanche, s’il doit récupérer des données sensibles ou attribuer des autorisations, des conditions supplémentaires ou une décision humaine restent indispensables.

Cela permet de conserver une automatisation rapide là où elle s’impose, tout en la ralentissant là où les conséquences d’une erreur seraient trop lourdes.

Avant de déployer un agent en production, les responsables doivent impérativement définir quatre points 

• Quelles actions l’agent est-il autorisé à exécuter, et lesquelles doivent rester sous la responsabilité d’un humain ?
• Quelle identité utilise-t-il, et qui en porte la responsabilité ?
• Quelles autorisations s’appliquent uniquement pendant la durée d’une tâche, et quand sont-elles révoquées ?
• Quels signaux déclenchent une réévaluation, une escalade ou un arrêt immédiat ?

La défense a besoin de ses propres garde-fous

Les organisations qui déploient l’IA pour leur défense ne doivent pas la traiter comme une exception de confiance. Un agent de sécurité reste une identité non humaine privilégiée. Il nécessite une mission clairement définie, des autorisations limitées dans le temps et des contrôles capables d’intervenir avant qu’une mauvaise recommandation ne se transforme en un changement lourd de conséquences.

C’est ainsi que l’agent restera un véritable outil de cyberdéfense au lieu de menacer le système.