Si vous êtes RSSI, vous entendez probablement une version de cette question de la part de votre conseil d’administration : « Quelle est notre stratégie de sécurité de l’IA ? »
Et vous donnez probablement une version de cette réponse : « Nous y travaillons. La politique d’IA est encore en cours de définition. Une fois que nous saurons quels agents nous déployons, nous les sécuriserons. »
Cette réponse semblait sûre il y a six mois. Ce n’est plus le cas.
Les agents d’IA que vous prévoyez de déployer ne sont pas ceux qui vous mettent actuellement en danger. Vous devez vous méfier de ceux qui sont déjà en cours d’exécution dans votre environnement.
Résumé
- Le déficit de gouvernance de l’IA : le rapport AI at Work 2025 d’Okta a révélé que, si 91 % des entreprises déploient des agents d’IA, seulement 10 % d’entre elles disposent d’une stratégie de gestion, ce qui fait des agents à privilèges excessifs un risque immédiat.
- La faille dans la visibilité : les outils réseau et endpoints traditionnels ne peuvent pas monitorer les actions spécifiques, les propriétaires et les autorisations des agents d’IA compromis.
- L’identité comme point de contrôle : l’identité est la seule couche de sécurité capable de déterminer quel agent a fait quoi, au nom de qui et si cela était autorisé.
- Une approche unifiée : Okta for AI Agents vous permet de découvrir, d’intégrer, de protéger et de gouverner vos agents d’IA.
L’adoption de l’IA agentique par les entreprises n’est plus une solution souhaitée, mais une réalité de production. Le rapport AI at Work 2025 d’Okta a révélé qu’aujourd’hui, 91 % des entreprises utilisent déjà des agents d’IA pour automatiser les workflows complexes et stimuler la productivité. Toutefois, le même rapport met en évidence un dangereux déficit de gouvernance : alors que le déploiement est en plein essor, seulement 10 % des dirigeants déclarent avoir une stratégie ou une roadmap bien définie pour la gestion des identités non humaines, y compris les agents d’IA.
Les risques liés à la Shadow AI : gestion des effectifs invisibles
L’envie de retarder l’évaluation de l’identité ignore une vérité fondamentale : le risque ne concerne pas uniquement l’IA que vous déploierez demain, mais aussi les agents à privilèges excessifs qui s’exécutent déjà aujourd’hui.
Oubliez un instant l’idée de définir complètement votre politique d’IA. Essayez de répondre aux questions suivantes concernant votre environnement actuel :
- Où sont mes agents d’IA ?
- À quoi peuvent-ils se connecter ?
- Que peuvent-ils faire ?
La plupart des responsables de la sécurité ne peuvent répondre à aucune de ces questions avec assurance. Il ne s’agit pas d’une défailllance de votre programme de sécurité, mais d’une lacune structurelle. Les agents sont déjà là, et vos contrôles d’identité existants ne s’étendent probablement pas encore à eux.
Bien que les déploiements formels fassent l’objet de débats, les collaborateurs connectent fréquemment des outils d’IA tiers à des comptes d’entreprise via des autorisations OAuth, tels que Cursor à GitHub, Claude à Google Workspace et des outils de prise de notes de réunion basés sur l’IA à des calendriers, à un rythme que la gouvernance ne peut pas suivre.
Chaque autorisation crée une identité non humaine avec des droits délégués dans les données de l’entreprise, souvent sans propriétaire vérifié ni un périmètre d’impact clair.
La réalité de la Shadow AI
Un incident récent sur une plateforme de développement bien connue n’impliquait aucune vulnérabilité ni aucun défaut d’infrastructure, mais simplement une connexion OAuth entre le compte professionnel d’un collaborateur et un outil d’IA tiers, accordée hors du champ de vision du service IT. Lorsque cet outil d’IA a été compromis, la confiance préétablie est devenue le vecteur d’attaque : une ligne droite vers les systèmes internes, les clés API, les tokens et les variables d’environnement. Voici à quoi ressemble réellement la Shadow AI en pratique : une autorisation OAuth non approuvée et sans supervision du service IT.
La vérité qui dérange : si vous attendez que votre politique d’IA soit finalisée pour sécuriser vos agents d’IA, vous appliquerez une gouvernance à un risque déjà aggravé.
Identifiez les failles dans la sécurité de l’IA grâce à notre simulateur d’attaque en 5 minutes.
Pourquoi l’identité est la couche essentielle de la gouvernance de l’IA
Les modèles de sécurité traditionnels privilégient souvent la protection du réseau ou des endpoints. Bien que ces couches soient essentielles, elles ne permettent pas de déterminer quels agents autonomes accèdent à quoi et pour quelle raison.
- Les outils réseau examinent le trafic ; un agent d’IA agissant pour le compte d’un utilisateur ressemble à un trafic API légitime.
- Les outils endpoints examinent les processus ; un agent d’IA ressemble à un processus standard autorisé s’exécutant dans le cadre de la session d’un utilisateur légitime.
Ces deux couches sont essentielles, mais aucune ne peut répondre aux questions importantes lorsqu’un incident se produit : « Quel agent a fait cela, au nom de qui, avec quelle portée, et était-ce autorisé ? »
À l’ère agentique, l’identité est la seule couche de sécurité qui comprend l’intention et la portée. C’est pourquoi 85 % des dirigeants considèrent désormais la gestion des identités et des accès (IAM) comme l’élément le plus crucial de leur stratégie d’IA (Okta, Rapport AI at Work 2025).
L’incident ayant touché la plateforme de développement que nous avons décrit précédemment illustre bien ce point : il ne s’agissait pas d’une défaillance d’endpoint ou de réseau. D’après ce que nous avons compris, il s’agissait d’un problème d’identité, plus précisément : comment les applications tierces et les outils d’IA obtiennent un accès, ce qu’ils peuvent faire et pendant combien de temps.
C’est pourquoi nous avons créé Okta for AI Agents, une solution conçue spécifiquement pour étendre Okta Platform afin de découvrir, d’intégrer, de protéger et de gouverner vos agents d’IA dans votre environnement. Okta for AI Agents découvre et intègre les agents d’IA sur n’importe quelle plateforme, protège les connexions avec un accès sur le principe du moindre privilège, et les gère avec des vérifications des accès, des pistes d’audit complètes et la possibilité de désactiver manuellement un agent d’IA instantanément grâce à un mécanisme d’arrêt d’urgence pour empêcher les nouvelles demandes de tokens et les autorisations futures lorsqu’un agent se comporte de manière inattendue.
Quatre capacités essentielles pour une visibilité et un contrôle complets sur les agents
Lorsque l’identité est le point de contrôle pour les agents, quatre éléments deviennent possibles de manière unifiée :
- Identité d’agent de première classe : vos agents — qu’ils soient développés en interne, intégrés à un outil SaaS ou exécutés sur l’ordinateur portable d’un collaborateur — sont enregistrés en tant que mandants avec des identifiants, un propriétaire humain désigné et un cycle de vie géré. Voici ce que vous pouvez dire à votre DSI lorsqu’il vous demande : « À qui appartient cet agent, et qui est responsable en cas de problème ? »
- Attribution cryptographique : chaque action est signée cryptographiquement et porte à la fois l’identité humaine et celle de l’agent. Voici ce que vous pouvez montrer à votre auditeur lorsqu’il vous demande : « Quel agent a fait cela, et pour le compte de qui ? »
- Application du principe du moindre privilège : les tokens sont limités à un seul appel, et non à une session ou à une application. Les privilèges permanents disparaissent. Voici ce que vous pouvez répondre à votre conseil d’administration lorsqu’il vous demande : « Quelle est notre exposition si l’un de ces agents est compromis ? »
- Gouvernance intégrée : les demandes d’accès des agents et les certifications d’accès sont intégrées à la plateforme d’identité. Voici ce que vous pouvez montrer à votre auditeur lorsqu’il vous demande : « Montrez que l’accès de votre agent d’IA a été examiné par un humain au cours des 90 derniers jours. »
Mais les capacités ne comptent que si elles s’appliquent partout où vos agents s’exécutent, ce qui signifie que la stratégie relative aux agents doit être ancrée dans l’écosystème. Vos agents peuvent s’exécuter sur Salesforce Agentforce, Amazon Bedrock, ServiceNow AI, et sur toute autre plateforme que vos équipes adopteront à l’avenir. À chaque fois qu’un agent traverse un écosystème, la gouvernance de la plateforme sur laquelle il a été créé ne le suit pas. Ce qui reste, c’est la faille.
C’est précisément cette faille qu’Okta a été conçu pour combler. Okta for AI Agents est sans dépendance vis-à-vis des fournisseurs, simplifiant le courtage d’identité entre Azure, AWS et Google Cloud, afin que les mêmes politiques s’appliquent uniformément partout, sans nécessiter d’intégrations ponctuelles.
Conçu pour étendre votre fournisseur d’identité, pas pour le remplacer
La prolifération des identités constitue une préoccupation majeure pour les architectes IT, qui craignent d’ajouter un second silo d’identités pour l’IA. La gouvernance moderne de l’IA ne devrait pas exiger un remplacement intégral de votre solution existante de gestion des identités collaborateurs.
Votre fournisseur d’identité est le système d’enregistrement de votre personnel. C’est là que résident vos politiques de connexion, que l’authentification multifacteur est appliquée, que l’accès conditionnel est ajusté, et que des années de travail d’intégration ont permis à la gouvernance des identités humaines de fonctionner de manière fluide. Rien de cela ne devrait changer parce que vous ajoutez des agents à l’équation.
Okta for AI Agents est complémentaire par nature. Il s’intègre à votre fournisseur d’identité existant via des protocoles standards (OIDC, SAML), héritant de la confiance de votre fournisseur d’identité sans dupliquer les identifiants ni exiger une seconde connexion. Lorsqu’un humain invoque un agent, Okta valide l’assertion d’identité de votre fournisseur d’identité et émet un token signé cryptographiquement contenant à la fois l’humain et l’agent. Les humains restent là où ils sont. Les agents disposent d’une gouvernance conçue pour eux.
Le résultat : vous étendez la base d’identité dans laquelle vous avez déjà investi pour couvrir une nouvelle classe d’identité, sans changer de plateforme, dupliquer les annuaires ni ajouter une charge opérationnelle.
Pour en savoir plus sur l’approche d’Okta consistant à fournir une couche sans dépendance vis-à-vis des fournisseurs qui sécurise chaque connexion sans vous obliger à remplacer votre fournisseur d’identité actuel.
Premiers pas : trois questions auxquelles répondre aujourd’hui
Votre politique d’IA peut attendre, mais les agents de votre environnement ne le peuvent pas.
Commencez par ces trois questions :
Où sont mes agents d’IA ?
À quoi peuvent-ils se connecter ?
Que peuvent-ils faire ?
L’identité est la seule couche qui puisse répondre à ces trois questions et constitue le fondement sur lequel reposera votre future politique.
Découvrez la gouvernance de l’IA par vous-même. Essayez la démo interactive d’Okta for AI Agents.
Foire aux questions (FAQ)
Comment les collaborateurs introduisent-ils la Shadow AI dans un réseau d’entreprise ?
Les collaborateurs introduisent généralement la Shadow AI en accordant aux outils d’IA tiers un accès API direct aux environnements d’entreprise à l’aide des autorisations OAuth. Ces intégrations, telles que la connexion d’un assistant IA à un calendrier d’entreprise ou à un référentiel de code, se produisent de manière transparente au niveau de l’utilisateur, contournant la supervision IT traditionnelle et créant des identités non humaines non surveillées.
Pourquoi les outils de sécurité réseau et endpoints n’ont-ils aucune visibilité sur les actions des agents d’IA ?
Les outils réseau traditionnels considèrent l’activité des agents d’IA autonome comme un trafic API légitime, tandis que les outils endpoints l’interprètent comme des processus standards exécutés dans une session utilisateur autorisée. Étant donné que ces périmètres manquent de contexte d’identité au niveau de l’application, ils ne peuvent pas déterminer quel agent spécifique a initié une action, au nom de qui il a agi, ni quel est son périmètre d’impact.
Pouvez-vous sécuriser les agents d’IA avant de finaliser une politique d’IA d’entreprise formelle ?
Oui. Attendre une politique de gouvernance d’entreprise formelle laisse des vulnérabilités de sécurité actives sans correction. Les équipes sécurité peuvent réduire les risques en étendant l’architecture existante de leur fournisseur d’identité pour découvrir, autoriser et gouverner les charges de travail autonomes à l’aide de protocoles d’identité non humaine, plutôt que d’attendre l’approbation d’une politique structurelle.
L’implémentation de la sécurité des agents d’IA nécessite-t-elle un annuaire d’identités complètement distinct ?
Non. Une gouvernance efficace de l’IA doit éviter la « prolifération des identités » grâce à une intégration complémentaire avec votre fournisseur d’identité principal. En utilisant des standards de fédération ouverts comme OpenID Connect (OIDC) et SAML, des plateformes telles qu’Okta peuvent émettre des tokens délimités qui associent les identités des agents machines aux règles d’authentification humaine existantes, sans dupliquer les identifiants des utilisateurs.
Toute mention de produits, fonctions, fonctionnalités ou certifications futurs dans cet article de blog revêt un caractère purement informatif. Ces éléments ne constituent pas des engagements et ne doivent pas être considérés comme un facteur déterminant dans les décisions d’achat.
Le contenu de ce document revêt un caractère purement informatif et ne constitue pas des conseils d’ordre juridique ou commercial, de confidentialité, de sécurité ou de conformité.
Il pourrait ne pas refléter les normes de sécurité, de confidentialité et les réglementations les plus récentes. Pour obtenir de tels conseils, il vous revient de vous adresser à votre conseiller juridique ou à tout autre conseiller professionnel et de ne pas vous en remettre à ce document.
Okta ne formule aucune déclaration, garantie ou autre assurance concernant le contenu de ce document et décline toute responsabilité quant aux pertes ou dommages pouvant résulter de la mise en œuvre des recommandations fournies dans le présent document. Les informations sur les assurances contractuelles d’Okta à ses clients sont disponibles à l’adresse okta.com/agreements.
