● Silicon.fr Télécom 📅 24/03/2026 à 16:32

Géopolitique 👤 Aziz si Mohammed *

🏷️ Tags : chine cert rag rte rust

L’adoption accélérée de l’intelligence artificielle transforme en profondeur les systèmes technologiques. Des copilotes intégrés aux outils métiers aux workflows automatisés pilotés par des agents autonomes, l’IA ne se limite plus à un simple service applicatif. Elle agit désormais comme un acteur opérationnel du SI, capable d’exécuter des actions, d’interroger des systèmes tiers et même de manipuler des données sensibles. Un défi émergent pour les architectures Zero Trust. Cette évolution fait émerger une nouvelle catégorie d’identités numériques : les identités non humaines associées aux agents IA. Clés API, comptes de service, tokens OAuth ou identités machine-to-machine deviennent les vecteurs d’interaction entre modèles, applications et infrastructures. Mais comment intégrer ces nouveaux acteurs dans les modèles de confiance existants ? Depuis plusieurs années, le paradigme Zero Trust s’impose comme une référence pour sécuriser les systèmes d’information. Son principe est simple : ne faire confiance à aucune identité par défaut et vérifier systématiquement chaque accès en fonction du contexte et du niveau de risque. Cependant, le Zero Trust a été initialement conçu pour gérer des identités humaines et des équipements utilisateurs. Or, dans un SI enrichi par l’IA, une part croissante des interactions émane d’agents automatisés. Si ces identités techniques ne sont ni inventoriées, ni gouvernées, ni surveillées avec le même niveau d’exigence que les comptes humains, l’architecture Zero Trust perd une partie de son efficacité. La sécurisation des agents IA devient ainsi un élément essentiel de toute stratégie de sécurité moderne. Les agents IA, nouvelles identités du SI Les architectures d’intelligence artificielle reposent sur de multiples mécanismes d’accès automatisés. Pour appeler un modèle, interroger une base de données, déclencher une action dans un outil métier ou récupérer des informations via une API, un agent IA doit disposer d’une identité technique. Les identités peuvent prendre la forme de clés API permettant d’accéder à des services ou bases de données, de comptes de service pour exécuter des workflows automatisés, de tokens OAuth autorisant l’accès à des applications SaaS ou d’identités machine-to-machine dans les architectures cloud natives. Ces mécanismes s’avèrent indispensables au fonctionnement des agents. Toutefois, ils introduisent aussi un changement de paradigme : les interactions avec le SI majoritairement déclenchées par des utilisateurs humains sont de plus en plus orchestrées par des processus autonomes. Un agent capable d’analyser un ticket de support, de consulter une base documentaire et de déclencher une action agit comme un utilisateur du système, souvent à une échelle et à une vitesse bien supérieures. L’angle mort du Zero Trust Le modèle Zero Trust repose sur plusieurs piliers : authentification forte, segmentation des accès, vérification continue et principe du moindre privilège. Ces mécanismes sont aujourd’hui bien maîtrisés pour les utilisateurs humains. Les identités non humaines, en revanche, restent souvent moins encadrées. Dans de nombreuses organisations, clés API et comptes de service sont créés pour répondre à un besoin projet, puis restent actifs sans supervision réelle. Ils disposent parfois de privilèges étendus afin de simplifier les intégrations techniques. Ce phénomène est amplifié par la rapidité d’expérimentation autour de l’IA. Les équipes data, innovation ou métiers déploient des agents pour automatiser des tâches, connecter des modèles ou enrichir des applications, parfois en dehors des processus de gouvernance traditionnels. Résultat : une partie du SI fonctionne avec des accès automatisés qui échappent aux contrôles habituels. Pour un attaquant, ces identités représentent une cible attractive. Contrairement aux comptes utilisateurs, elles ne sont généralement pas protégées par authentification multifactorielle et peuvent disposer d’autorisations étendues. Une clé API exposée dans un dépôt de code ou un token compromis peut ainsi ouvrir l’accès à des ressources critiques. Dans une architecture Zero Trust, ces identités hors du périmètre de contrôle créent une zone de confiance implicite. Exactement ce que ce modèle cherche à éviter. Privilèges excessifs et “Shadow Agents” : attention danger ! L’un des risques majeurs liés aux agents IA concerne la gestion des privilèges. Pour simplifier le développement, il est fréquent d’attribuer à un agent des droits excessifs : accès complet à une base de données ou permissions étendues sur plusieurs API. A l’encontre même du principe du moindre privilège. Un agent devrait disposer uniquement des droits nécessaires à sa fonction. Néanmoins, cette granularité est encore rarement appliquée. À cela s’ajoute l’émergence des “Shadow Agents”. A l’instar du Shadow IT, les agents peuvent être créés de manière informelle par des équipes métiers ou techniques pour automatiser certaines tâches. Ils utilisent souvent des identités techniques générées rapidement, sans enregistrement centralisé. Avec le temps, ces identités deviennent difficiles à tracer. Certaines subsistent alors que le projet initial a disparu, tandis que d’autres conservent des privilèges élevés injustifiés. Dans un environnement où les agents IA interagissent avec plusieurs systèmes (bases de données, SaaS ou outils internes), ces identités fantômes constituent un vecteur de risque significatif. Cartographier et gouverner les agents IA Pour sécuriser efficacement un SI automatisé, il est essentiel de rendre les identités des agents IA visibles et contrôlables. Cela implique de recenser tous les agents présents, qu’ils soient officiellement déployés par l’IT ou issus d’initiatives locales non encadrées. Chaque identité technique (clé API, compte de service, token OAuth ou identité machine-to-machine) doit être inventoriée et associée à un responsable humain afin d’assurer la traçabilité et la responsabilité. Au-delà de leur simple localisation, il est crucial de maîtriser les ressources auxquelles ces agents peuvent se connecter. Une gestion centralisée des outils, applications, API et bases de données permet d’appliquer le principe du moindre privilège à chaque interaction, de surveiller en continu les accès et de détecter immédiatement toute activité anormale. Les identités techniques doivent pouvoir être révoquées ou mises à jour rapidement pour limiter les risques liés à une exploitation abusive ou à un dysfonctionnement. Enfin, la gouvernance des agents doit couvrir l’intégralité de leur cycle de vie : création, attribution de privilèges, suivi des activités, renouvellement sécurisé des identifiants et suppression lorsqu’ils ne sont plus nécessaires. Traiter les agents IA comme des identités à part entière garantit une visibilité complète, un contrôle systématique et une intégration cohérente dans la stratégie de sécurité globale. Vers un Zero Trust réellement étendu Le principe du Zero Trust (Never Trust, Always Verify) doit s’appliquer aussi aux entités automatisées. Cela implique plusieurs évolutions dans les stratégies de sécurité pour authentifier systématiquement les identités machine-to-machine, appliquer le principe du moindre privilège aux agents IA, surveiller leurs comportements afin de détecter d’éventuels usages anormaux ou intégrer ces identités dans les politiques de segmentation et de contrôle d’accès. À mesure que les architectures d’IA se complexifient, le contrôle de ces identités devient un élément structurant de la posture de sécurité. L’intelligence artificielle ne se contente plus d’analyser ou de recommander : elle agit directement dans les systèmes d’information. Dans un SI de plus en plus automatisé, la confiance ne doit plus être vérifiée uniquement pour les utilisateurs, mais pour chaque agent capable d’agir en leur nom. *Aziz si Mohammed est Senior Manager, Solutions Engineering chez OKTA

🔗 Lire l'article original 👁️ 1 lecture