L’adoption de l’IA générative dans les entreprises s’est faite à une vitesse rarement observée dans l’histoire des systèmes d’information. En moins de deux ans, des assistants conversationnels, des copilotes métier et désormais des agents autonomes sont devenus des composants à part entière des environnements IT. Cette accélération a mis en lumière une réalité souvent sous-estimée : les modèles de sécurité traditionnels ne sont pas conçus pour l’IA.
Historiquement, les architectures de sécurité reposaient sur des hypothèses relativement stables : un utilisateur humain, une application bien définie, des flux identifiables et des privilèges relativement statiques. L’IA bouleverse ces fondements. Un agent peut consommer des données, en produire, déclencher des actions et interagir avec d’autres systèmes sans intervention humaine directe. C’est précisément ce constat qui a conduit Microsoft à formaliser une approche Zero Trust étendue à l’IA, couvrant l’ensemble du cycle de vie des usages IA.
Le lien vers l’article : New tools and guidance: Announcing Zero Trust for AI | Microsoft Security Blog
L’IA introduit de nouvelles frontières de confiance
L’un des points clés soulignés dans les travaux récents de Microsoft est l’apparition de nouvelles frontières de confiance. Là où la sécurité se concentrait auparavant sur la relation utilisateur ↔ application, il faut désormais intégrer :
- la relation agent ↔ données,
- la relation modèle ↔ plugin ou connecteur,
- la relation prompt ↔ système cible.
Dans plusieurs retours d’expérience partagés par des architectes sécurité, un même schéma revient : des agents IA disposant de droits trop larges, capables d’interroger des sources sensibles, simplement parce qu’aucune politique fine n’avait été définie en amont. On commence même à parler « d’agents doubles », capables d’agir contre les intérêts de l’organisation s’ils sont mal gouvernés, une notion également mise en avant par Microsoft dans son analyse des risques liés aux agents autonomes.
Le lien vers l’article : New tools and guidance: Announcing Zero Trust for AI | Microsoft Security Blog
Appliquer Zero Trust à l’IA : continuité, pas rupture
L’approche consiste donct à étendre les principes Zero Trust existants à des objets nouveaux :
- identités non humaines (agents, workloads),
- flux dynamiques générés par des prompts,
- données intermédiaires produites par l’IA.
Les trois piliers historiques restent inchangés :
- Vérifier explicitement : l’identité et le comportement d’un agent doivent être évalués en continu.
- Appliquer le moindre privilège : un agent ne doit accéder qu’aux données strictement nécessaires à sa mission.
- Partir du principe de compromission (et assumer) : les scénarios de prompt injection, de data poisoning ou de mouvements latéraux doivent être anticipés dès la conception.
Le lien vers l’article : New tools and guidance: Announcing Zero Trust for AI | Microsoft Security Blog
Ce qui change, en revanche, c’est la manière opérationnelle d’appliquer ces principes dans des environnements IA complexes.
De la stratégie à l’exécution : un besoin fortement exprimé sur le terrain
Un retour récurrent des RSSI et responsables sécurité est la difficulté à passer du discours stratégique à des actions concrètes : les organisations savent qu’elles doivent sécuriser l’IA, mais manquent de cadres opérationnels pour prioriser et agir efficacement.
Le lien vers l’article The Microsoft Zero Trust Assessment: Helping you operationalize the hardening of your Microsoft security products | Microsoft Community Hub
C’est dans ce contexte que Microsoft a enrichi son outillage Zero Trust avec :
- un nouveau pilier IA dans le Zero Trust Workshop,
- une mise à jour des piliers Data et Network dans l’outil d’évaluation,
- une architecture de référence Zero Trust for AI, pensée comme un langage commun entre équipes sécurité, IT et métiers
Gouvernance des agents et des données : le vrai sujet
Dans la majorité des projets observés, la technologie n’est pas le principal frein. Les difficultés apparaissent plutôt sur les sujets de gouvernance :
- Qui est responsable d’un agent IA ?
- Quels jeux de données peut-il consommer ?
- Comment tracer et auditer ses actions ?
Les recommandations issues de Microsoft Learn insistent sur la nécessité de traiter les agents IA comme des workloads privilégiés, au même titre qu’un compte de service critique. Cela implique l’usage systématique de contrôles d’identité forts, de politiques d’accès conditionnel et de mécanismes de revue régulière des privilèges
Lien vers l’article : Overview – Use Zero Trust security to prepare for AI companions, including Microsoft Copilots | Microsoft Learn
On note des différences de maturité dans les organisations : il y a celles qui ont intégré l’IA dans leurs processus existants : comités de gouvernance, gestion des identités, classification des données via Microsoft Purview, et supervision centralisée, et puis il y a les autres …
Vers une observabilité accrue des systèmes IA
Un point souvent sous-estimé est celui de l’observabilité. Un système IA peut fonctionner correctement d’un point de vue technique tout en posant un risque majeur du point de vue sécurité, d’où la nécessité de corréler les signaux issus de l’identité, des données et des comportements des agents pour détecter les dérives.
On commence ainsi à évoquer une évolution des SOC, qui devront intégrer des scénarios spécifiques à l’IA : détection d’usages anormaux, analyse de prompts à risque, ou encore identification de fuites indirectes de données sensibles.
En bref : sécuriser l’IA, un chantier structurant
Zero Trust for AI ne doit pas être vu comme une simple extension marketing du Zero Trust, mais comme une adaptation nécessaire à un changement profond des usages numériques. Pour les organisations il est donc nécessaire d’aborder l’IA non pas comme un outil isolé, mais comme un nouveau type de système distribué, nécessitant des règles claires, une gouvernance forte et une exécution rigoureuse.
À l’image des projets cloud il y a quelques années, l’IA impose aujourd’hui une remise à plat des modèles de sécurité. Zero Trust offre un cadre éprouvé pour relever ce défi, à condition de l’appliquer avec le même niveau d’exigence aux agents, aux données et aux identités qu’aux utilisateurs humains.