Comment appliquer le principe de sécurisation dès la conception lors du déploiement d’agents d’IA ?
- Kaspersky Team
Kaspersky Team
- 12 Nov 2026
12 Nov 2026
Les systèmes d’IA sont beaucoup plus difficiles à protéger que les systèmes informatiques traditionnels, que ce soit contre les erreurs des opérateurs, contre les interventions malveillantes, ou tout simplement contre les comportements instables. Il existe deux raisons principales à cela. Premièrement, les réponses de l’IA sont probabilistes : une même requête peut donc produire des réponses différentes à chaque exécution. Deuxièmement, les modèles LLM actuels ne savent pas distinguer de manière fiable les commandes des données. Malgré les problèmes de sécurité avérés des systèmes d’IA que nous avons abordés à de nombreuses reprises, il est impossible d’ignorer les bénéfices économiques potentiels liés à leur adoption. C’est pourquoi de nombreuses entreprises ne se contentent plus de simples assistants IA et se tournent désormais vers des agents d’IA. Ces agents effectuent des tâches de manière autonome et ont directement accès aux mêmes outils que les humains, qu’il s’agisse de consulter des bases de données ou de modifier les paramètres des processus de production. Dans leur nouvelle étude, nos experts examinent comment définir clairement et réduire au minimum les risques qui en découlent afin de limiter au maximum les problèmes potentiels. Cette approche reprend et adapte les principes de cyberimmunité et de sécurisation dès la conception.
Les principes fondamentaux de la sécurisation dès la conception
Tous les principes de cette discipline s’appliquent de manière universelle à la conception de n’importe quel système informatique, y compris les agents d’IA. Ce qui diffère, c’est le degré d’adaptation et de remaniement dont chaque principe a besoin pour s’appliquer aux scénarios d’IA.
- La sécurité est un facteur à part entière et important dès la phase de conception. Les objectifs et les hypothèses en matière de sécurité sont définis dès le départ et respectés à chaque étape du développement. Pour les agents d’IA, ces hypothèses doivent inclure trois points clés : (i) le modèle de langage est considéré comme non fiable, (ii) les données externes, quelle que soit leur nature, sont considérées comme potentiellement malveillantes, et (iii) les actions irréversibles ne peuvent pas être exécutées de manière autonome sans une approbation humaine obligatoire.
- Le système est conçu en partant du principe qu’il sera attaqué.
- La base informatique de confiance et la surface d’attaque sont réduites au minimum. Les agents ne disposent que des outils dont ils ont réellement besoin, d’autorisations limitées, et d’un minimum d’informations contextuelles. L’application de la stratégie de sécurité est entièrement gérée par des modules déterministes, à savoir le moniteur de la stratégie, l’environnement d’exécution de l’agent et les mécanismes d’isolation (sandboxes).
- Le principe du moindre privilège s’applique. Chaque agent dispose de ses propres identifiants et droits d’accès (identité), limités au strict minimum nécessaire à l’exécution de sa tâche. Si un agent a temporairement besoin de droits d’accès étendus, il ne les obtient qu’après approbation externe, et uniquement pour la durée exacte de la tâche qui les requiert.
- Les modules sont isolés. Dans les systèmes à base d’agents, il s’agit de l’un des problèmes d’architecture les plus complexes, qui se pose à plusieurs niveaux. L’environnement d’exécution de l’agent doit fonctionner dans un environnement isolé (sandbox ou machine virtuelle), et les agents doivent être aussi isolés que possible les uns des autres. Le traitement des données dans les contextes fiables est également séparé de celui effectué dans les contextes non fiables. Par exemple, un agent lit une demande d’extraction et rédige une ébauche de code, tandis qu’un autre agent examine ce travail sans jamais voir le texte potentiellement malveillant de la demande.
- Le refus par défaut est la règle. Les stratégies de sécurité suivent la règle suivante : tout ce qui n’est pas explicitement autorisé est interdit. Cela inclut les appels d’outils, les interactions entre les agents et le trafic réseau.
- Une défense en profondeur est mise en place. Différentes mesures doivent fonctionner simultanément et se renforcer mutuellement. Les défenses probabilistes, comme les garde-fous d’IA (un « pare-feu » pour les modèles de langage) ou l’alignement (la capacité du modèle à distinguer ce qui est acceptable de ce qui ne l’est pas), ne peuvent offrir aucune garantie formelle en matière de sécurité. Néanmoins, elles renforcent la sécurité globale du système et constituent une source précieuse de données télémétriques.
- La chaîne d’approvisionnement est protégée. Certains agents peuvent installer de manière autonome des compétences, des bibliothèques et d’autres modules logiciels, de sorte que ces capacités doivent être strictement encadrées. Bloquez complètement ces capacités, ou limitez-les à une liste fermée et préapprouvée de versions spécifiques de modules particuliers. Les systèmes reposant sur des LLM dans le cloud sont exposés à un risque supplémentaire, à savoir les mises à jour des modèles. Un jour, une même requête API pourrait être traitée par un modèle de langage différent, présentant des propriétés de sécurité différentes.
Les pièges de la sécurité en matière d’IA
Les principes généraux de la sécurisation dès la conception sont bien connus et semblent simples sur le papier. Cependant, leur application aux systèmes d’IA est délicate, car les agents sont incroyablement flexibles. Par exemple, une équipe de sécurité pourrait penser qu’un agent installé sur l’ordinateur d’un développeur s’exécute dans un sandbox et ne peut rien modifier en dehors de celui-ci. Or, un pirate informatique, voire l’agent lui-même, peut trouver des dizaines de moyens de contourner cette protection apparemment fiable, par exemple en exécutant des commandes par le biais d’un serveur MCP local non soumis aux restrictions du sandbox, ou encore en reconfigurant un autre agent d’IA installé sur le système. Pour compliquer encore les choses, l’éventail des vecteurs d’attaque est immense, allant de champs arbitraires dans la configuration de l’agent à des chaînes de texte d’apparence anodine dans un fichier de compétences.
La fatigue de l’utilisateur constitue également un problème sérieux que les concepteurs sous-estiment souvent. Un agent très actif peut générer des dizaines de demandes par minute, invitant l’utilisateur à valider des actions potentiellement dangereuses. En moins d’une heure, la personne clique sur Approuver de façon machinale, sans même lire ce qu’elle approuve. C’est pourquoi il est important d’ajuster soigneusement la fréquence à laquelle ces demandes apparaissent, ainsi que la manière dont elles sont formulées. Personne ne lira une description de demande trop longue. À l’inverse, une description trop courte peut omettre les détails essentiels dont l’utilisateur a besoin pour prendre la bonne décision.
Les vulnérabilités des agents et des outils associés constituent un problème urgent, aggravé par la rapidité avec laquelle ces catégories de logiciels évoluent et reçoivent des mises à jour. Des plateformes et applications de référence dans le secteur (comme LangGraph, MS Semantic Kernel et Claude Code) ont vu leurs vulnérabilités critiques être corrigées à plusieurs reprises. Les architectes devraient toujours envisager de remplacer un framework volumineux et polyvalent par un système compact et épuré, doté uniquement des fonctionnalités dont un agent particulier a réellement besoin.
De plus, la mise en œuvre rigoureuse de mesures de sécurité standard et éprouvées dans les outils disponibles permet de réduire considérablement les dégâts si un agent est attaqué ou se comporte de manière inattendue. Une liste d’autorisation stricte des domaines auxquels l’outil de récupération Web peut accéder à la demande de l’agent en constitue un exemple. Cependant, les concepteurs prennent rarement en compte les problèmes cachés et la charge de travail supplémentaire liés à la gestion de cette liste. Celle-ci devient donc progressivement obsolète et crée des failles que les pirates informatiques peuvent exploiter. L’exemple le plus frappant est l’attaque EchoLeak. Microsoft 365 Copilot disposait d’une liste d’autorisation correctement mise en œuvre et relativement efficace pour l’accès à des sites externes, mais des pirates informatiques ont réussi à la contourner en exploitant une fonctionnalité d’un outil secondaire, ainsi que le domaine MS Teams.
Conseils pratiques destinés aux architectes et aux équipes de sécurité
Les architectes de systèmes d’IA et les responsables des équipes d’ingénierie et de sécurité doivent intégrer la sécurité des agents dès la phase de conception. Ils doivent s’appuyer principalement sur des mécanismes vérifiables et déterministes, en isolant les modules, en contrôlant les interactions et en réduisant au minimum la base informatique de confiance.
Les principales décisions architecturales consistent notamment à définir le degré d’autonomie acceptable pour les agents, à limiter l’accès aux données confidentielles et aux combinaisons de capacités dangereuses, et à utiliser des sandboxes, des rôles distincts pour les différents modèles et des passerelles de contrôle d’accès. Les restrictions ajoutées après coup réduisent les risques, mais ne remplacent pas une architecture sécurisée.
Sur les plans organisationnel et opérationnel, les entreprises doivent tenir un inventaire de leurs agents, coordonner les efforts des équipes chargées de la sécurité et du déploiement, protéger les environnements de conteneurs, gérer la chaîne d’approvisionnement (AIBOM) et intégrer une défense multicouche.
L’observabilité mérite une attention particulière. Pour les systèmes d’IA, cela doit inclure la journalisation des requêtes, des réponses et du raisonnement du LLM, ainsi que des données télémétriques détaillées provenant des hôtes et des environnements cloud sur lesquels l’agent s’exécute.
Le plus difficile dans la conception d’agents est de trouver le juste équilibre entre sécurité, performances et utilité. Pour découvrir comment trouver cet équilibre grâce à une modélisation des menaces et à des objectifs de sécurité clairement définis, consultez
Conseils
Neuf raisons de configurer un VPN sur votre routeur
Tirez le meilleur parti de votre VPN en matière de vitesse, de fiabilité et de confort d’utilisation en le configurant sur votre routeur. Voici un aperçu des avantages concrets que peuvent offrir différents scénarios de configuration VPN pour l’ensemble de votre réseau domestique.
