Les entreprises russes passent à une sécurité systématique des agents d'IA plutôt qu'à des contrôles ponctuels

La sécurité des agents d'IA ne peut plus se régler en examinant à la main chaque nouvel outil : les LLM et les agents de code ont accès au code, au shell, à git, au réseau et aux secrets, il faut donc les traiter comme des services ordinaires dotés de droits très étendus. Lorsque ces systèmes s'intègrent au développement, aux tests et à l'exploitation, la question n'est pas de savoir si on peut leur faire confiance, mais quelles restrictions, quelles politiques et quelle observabilité l'entreprise a mises en place autour d'eux.

En deux ou trois ans, les entreprises russes ont cessé de voir l'IA générative comme une expérience curieuse et ont commencé à l'intégrer dans leurs processus quotidiens. Il ne s'agit plus seulement de chats de support ou de brouillons de textes : les modèles aident les développeurs, participent aux revues de code, génèrent du code d'infrastructure, travaillent sur la configuration et deviennent de plus en plus souvent une brique de vrais produits. Les recommandations internationales vont dans le même sens : le NIST propose de considérer l'IA générative comme un élément d'infrastructure critique, tandis que l'ENISA examine séparément son rôle dans le DevSecOps et l'automatisation de l'ingénierie.

La logique est simple : dès qu'un modèle accède à des données, à des outils et à la possibilité d'exécuter des actions, il cesse d'être une simple interface et devient un nœud opérationnel du système.

Le profil de menaces change en conséquence. Aux problèmes classiques, comme les erreurs d'autorisation et les injections, s'ajoutent les risques décrits par l'OWASP Top 10 for LLM Applications : prompt injection, traitement non sécurisé de la réponse du modèle, fuites de secrets via le contexte, droits excessifs des agents et conception non sécurisée des plugins ou tools.

L'étude de plusieurs agents d'IA a fait apparaître un schéma récurrent : presque tous ont accès au shell via des commandes locales, Docker ou SSH, beaucoup savent travailler directement avec git, créer des branches et des commits, et la configuration comporte souvent des modes dangereux du type bypassPermissions. Dans ce cadre, une seule injection réussie ou une seule réponse du modèle traitée de façon non sécurisée suffit pour que l'agent exécute une commande arbitraire, extraie des jetons et des clés, modifie discrètement le code ou se mette à parcourir les services internes et la chaîne CI/CD.

Le problème, c'est que la vérification manuelle de chaque nouvel agent passe mal à l'échelle. Même si l'éditeur de l'outil a déjà ajouté un sandbox par défaut, un module de gestion des secrets, le masquage des données sensibles dans les journaux et une documentation de lancement sécurisé, l'équipe de sécurité doit encore évaluer presque de zéro dans quelle mesure ces réglages sont fiables.

C'est pourquoi l'auteur propose de retirer le mot IA de la discussion et de voir l'agent comme un service en boîte noire aux droits étendus. Si ce service peut lire et modifier des fichiers, lancer des commandes, appeler des API externes et pousser du code, il faut l'évaluer à travers les domaines habituels : qui déclenche exactement les actions, quels droits l'agent reçoit, où il s'exécute, à quels répertoires, réseaux et outils il accède, ce qui est journalisé et en combien de temps l'équipe repérera une anomalie.

De là découle un profil de protection très concret. Premièrement, des règles claires d'autorisation et de moindre privilège : quel dépôt l'agent voit, s'il peut écrire ou seulement lire, s'il a le droit de lancer des tests, des migrations ou des commandes shell. Deuxièmement, l'isolation : un conteneur, un runner dédié ou un environnement spécifique aux mounts strictement limités, sans accès superflu à docker.

sock, à l'API Kubernetes ni aux secrets de production. Troisièmement, un contrôle réseau avec des listes blanches de domaines et une politique claire pour les requêtes externes. Enfin, l'analyse statique du code et des configurations, les tests dynamiques en laboratoire avec des fichiers honeypot et de faux secrets, ainsi que l'audit et les alertes en cas de comportement atypique de l'agent sont indispensables.

Cette approche n'interdit pas l'adoption de l'IA : elle fait d'un outil à la mode et peu prévisible un composant maîtrisable de l'infrastructure d'ingénierie.

Concrètement : la sécurité ne doit pas freiner l'adoption des agents de code, mais on ne doit pas non plus leur faire confiance par défaut. Si l'on établit à l'avance, avec les équipes de développement, un profil unique d'exigences, si l'on teste les risques typiques dans un environnement isolé et si l'on fixe les politiques d'accès, l'arrivée d'un nouvel outil d'IA cessera de se transformer à chaque fois en expertise urgente et coûteuse. Pour l'entreprise, cela signifie adopter plus vite une automatisation utile, sans risque superflu pour le code, les secrets et l'infrastructure interne.