Zero Trust pour les agents IA : sécuriser du code au cloud en 2026
Dev Together · Expertise IA & cybersécurité
Les agents IA ne se contentent plus de répondre à des questions. Ils lisent du code, appellent des outils, accèdent à des données métier, modifient des configurations et déclenchent des actions dans le cloud. Cette autonomie crée de nouvelles frontières de confiance : l'identité de l'agent, sa mémoire, les permissions de ses outils et la chaîne logicielle qu'il traverse. En août 2026, Microsoft a étendu son approche Zero Trust à l'IA et au DevSecOps, tandis que Google Cloud rappelait que l'accélération par l'IA ne remplace pas les fondamentaux de sécurité. Pour les entreprises, le sujet n'est donc plus seulement de déployer un agent, mais de prouver qu'il reste maîtrisé du code à la production.
Pourquoi le Zero Trust doit évoluer pour les agents IA
Le Zero Trust repose sur trois principes durables : vérifier explicitement, limiter les privilèges et supposer qu'une compromission peut survenir. Un agent IA rend leur application plus exigeante, car il peut prendre des décisions à la vitesse d'une machine et combiner plusieurs systèmes au cours d'une même tâche. Une autorisation acceptable pour un utilisateur humain peut devenir excessive lorsqu'elle est accordée en permanence à un agent capable d'enchaîner des milliers d'actions.
La nouvelle guidance Zero Trust pour l'IA et le DevSecOps de Microsoft structure justement l'évaluation autour de l'IA, des opérations de sécurité et de l'infrastructure. Elle ajoute un pilier DevSecOps couvrant les dépôts, les dépendances, les pipelines CI/CD, les artefacts et l'infrastructure as code. Le signal est important : sécuriser un agent ne consiste pas à ajouter un filtre devant le modèle, mais à contrôler tout son environnement d'exécution.
Identité, mémoire et outils : les trois frontières critiques
La première frontière est l'identité. Chaque agent doit disposer d'une identité distincte, traçable et révocable, sans partager les secrets d'un développeur ou d'un compte administrateur. Ses droits doivent être temporaires, limités à la tâche et évalués selon le contexte. Un agent chargé de résumer des incidents n'a aucune raison de pouvoir modifier une politique réseau ; un agent de déploiement ne doit pas accéder à l'ensemble des données clients.
La deuxième frontière est la mémoire. Historique de conversation, documents indexés, résultats d'outils et préférences deviennent une base de décision persistante. Il faut connaître la provenance de chaque information, appliquer les mêmes règles d'accès que sur la source, définir une durée de conservation et empêcher qu'une instruction non fiable soit réutilisée comme une règle légitime. La mémoire doit être gouvernée comme une donnée sensible, pas traitée comme un simple confort conversationnel.
La troisième frontière concerne les outils. Les serveurs MCP, APIs, navigateurs et commandes d'infrastructure augmentent fortement l'impact potentiel d'une injection de prompt ou d'une dépendance compromise. Chaque outil doit déclarer une capacité précise, valider ses entrées, limiter ses sorties et demander une approbation humaine pour les actions irréversibles. Cette approche rejoint notre travail d'architecture logicielle robuste : réduire les couplages, isoler les privilèges et rendre les décisions observables.
Étendre le DevSecOps du code jusqu'au cloud
Les assistants de développement peuvent proposer des packages, générer du code, écrire des manifestes et modifier des pipelines. Le gain de vitesse est réel, mais il amplifie aussi une mauvaise permission, une dépendance vulnérable ou une configuration trop ouverte. Une chaîne robuste combine analyse des dépendances, recherche de secrets, revue de code, signature des artefacts, séparation des environnements, politiques sur l'infrastructure as code et contrôle des droits au moment du déploiement.
Google Cloud indique que ses équipes font désormais passer les lancements de produits dans une chaîne de revue de sécurité fondée sur des agents, tout en insistant sur la nécessité de conserver les fondamentaux. Son analyse CISO d'août 2026 illustre un modèle utile : l'IA accélère la recherche de failles et la collecte de preuves, mais la politique de sécurité, la validation et la responsabilité restent explicites.
Passer d'un audit ponctuel à une sécurité contrôlée en continu
Un contrôle réalisé avant la mise en production ne couvre pas les nouvelles dépendances, les changements de permissions ou les techniques d'attaque apparues ensuite. Le NIST défend un modèle de surveillance et de mise à jour continues : des garde-fous figés ne peuvent pas résister à toutes les requêtes adversariales adaptatives. Il recommande une recherche constante de faiblesses, le renforcement régulier des protections et une résilience opérationnelle capable de limiter l'impact puis de restaurer rapidement le service.
Cette conclusion, détaillée dans la publication du NIST sur la sécurité continue des systèmes IA, soutient une pratique très concrète : intégrer des tests adversariaux aux cycles de livraison. Dans nos accompagnements en cybersécurité, des pentests automatisés par IA peuvent rechercher régulièrement des vulnérabilités sur l'application et l'infrastructure déployée. Ils complètent, sans remplacer, la revue humaine et les tests manuels ciblés sur les scénarios les plus critiques.
Une feuille de route pragmatique pour l'entreprise
Commencez par inventorier les agents, leurs modèles, leurs mémoires, leurs sources de données et tous les outils qu'ils peuvent appeler. Associez ensuite une identité technique à chaque agent, supprimez les secrets partagés et réduisez les permissions au strict nécessaire. Journalisez les décisions, les appels d'outils et les changements de privilèges avec un contexte suffisant pour reconstruire un incident. Enfin, ajoutez au pipeline des tests de sécurité reproductibles : injections de prompt, fuite de données, escalade de privilèges, dépendances compromises et erreurs de configuration cloud.
Le bon niveau de contrôle dépend de l'impact métier. Un assistant documentaire en lecture seule et un agent capable de déployer en production ne doivent pas suivre le même parcours d'approbation. Nous aidons les équipes à concevoir des solutions d'IA générative utiles et gouvernables, puis à intégrer la cybersécurité et la performance dès l'architecture. L'objectif n'est pas de ralentir l'innovation, mais de rendre possible une autonomie progressive, mesurable et réversible.