Le 24 août 2026, Okta a rendu Agent SSO généralement disponible, offrant aux agents IA des identités de première classe dans Universal Directory et remplaçant les clés API statiques par des jetons à durée limitée et gouvernés par des politiques. C'est l'infrastructure de sécurité agent la plus utile livrée cette année, incluse dans les plans SSO de base d'Okta sans coût supplémentaire, et les équipes de sécurité devraient l'activer. Cela implique aussi une condition préalable que la plupart des entreprises ne peuvent pas encore remplir : un agent doit être enregistré avant que son identité puisse le gouverner.
Cette condition préalable est là où les actualités de la semaine entrent en collision avec les données du mois. Le Enterprise AI Usage Risk Report 2026 d'Akamai a révélé que 47,11 % des conversations IA en entreprise ont lieu via des identités personnelles plutôt que des comptes d'entreprise. Ces conversations n'atteignent jamais un fournisseur d'identité. Ce ne sont pas des agents en attente de jetons, ce sont des employés avec des onglets de navigateur. Deux plans de contrôle différents sont impliqués, et cette semaine un seul a évolué.
L’identité des agents a enfin une norme digne d’être adoptée
Le cœur de la sortie d’Okta est la norme sous-jacente. Agent SSO est construit sur Cross App Access, un protocole neutre étendant OAuth et intégré comme extension officielle Enterprise-Managed Authorization pour le Model Context Protocol. Un agent est enregistré dans Universal Directory, les administrateurs appliquent les politiques d’accès déjà utilisées pour les employés, et l’agent reçoit des jetons à durée limitée lorsqu’il doit agir au nom d’un utilisateur. Ric Smith, président des produits et technologies chez Okta, a bien résumé le problème : accorder l’accès aux agents « ne devrait pas nécessiter de sacrifier la sécurité ou la visibilité. »
Le modèle d’identifiants remplacé mérite les critiques qu’il reçoit. Les clés API statiques sont durables, surdimensionnées, copiées dans des fichiers de configuration et variables CI, partagées entre services, et pratiquement invisibles aux workflows de révocation. Les remplacer par des jetons à durée limitée liés à une identité nommée réduit vraiment la portée des dégâts. Les recherches d’Okta montrent que seulement 34 % des organisations appliquent les mêmes contrôles de sécurité aux agents IA qu’aux travailleurs humains, donc la base améliorée est faible. Que le protocole soit ouvert importe plus que le produit : cela garantit que le contrôle survit à un changement de fournisseur d’identité.
Que gouverne réellement Okta Agent SSO ?
Agent SSO gouverne les connexions agent-application prises en charge pour les agents implémentant Cross App Access. Il enregistre ces agents dans Universal Directory d’Okta, applique les mêmes politiques d’accès que pour les employés, et délivre des jetons à durée limitée pour agir au nom d’un utilisateur spécifique. Remplacer les clés API statiques est sa fonction la plus précieuse. Ce qu’il ne fait pas est tout aussi important. Agent SSO n’est pas un mécanisme de découverte : un agent devient visible après enregistrement ou connexion, donc ce n’est pas un inventaire de tous les processus autonomes dans votre environnement. Il ne couvre pas les agents sans support Cross App Access, les connexions agent-agent, ni l’application en temps réel des actions d’un agent une fois autorisé. La découverte, les revues de certification, les workflows d’approbation et la désactivation relèvent de l’abonnement séparé Okta for AI Agents. Okta est explicite sur cette séparation, et les acheteurs doivent en prendre bonne note.
Cross App Access est-il la même chose que MCP ?
Non, mais ils sont désormais formellement connectés. Le Model Context Protocol est la norme ouverte définissant comment une application IA se connecte aux outils et sources de données. Il définit la structure technique, pas le modèle d’autorisation, ce qui explique pourquoi les premières implémentations MCP utilisaient des clés API statiques et des jetons personnels à longue durée de vie. Cross App Access étend OAuth pour répondre à la question d’autorisation : quel agent, agissant pour quel utilisateur, peut accéder à quelle ressource, et pour combien de temps. Il a été intégré comme extension officielle Enterprise-Managed Authorization pour MCP, ce qui signifie que les deux sont conçus pour être utilisés ensemble et non en concurrence. Pour les équipes de sécurité, la lecture pratique est simple : si votre organisation déploie des serveurs MCP, Cross App Access est le mécanisme qui vous permet de ne plus leur fournir de justificatifs statiques. Il est neutre vis-à-vis des fournisseurs, donc son adoption ne vous enferme pas chez un seul fournisseur d’identité.
La gouvernance des identités commence à l’enregistrement. La découverte en assure le remplissage.
Chaque contrôle basé sur l’identité hérite de l’exhaustivité de l’inventaire sous-jacent. Vous ne pouvez pas émettre un jeton à courte durée de vie à un agent que vous n’avez jamais vu, appliquer une politique à une connexion qui ne la demande jamais, ou révoquer un accès qui ne vous a jamais été accordé. Ce n’est pas un défaut de l’Agent SSO. C’est une propriété structurelle que le single sign-on a toujours eue.
Le précédent est le shadow SaaS. Les entreprises ont largement adopté le SSO la dernière décennie et se sont retrouvées avec des centaines d'applications non fédérées, car le SSO gouverne les applications fédérées, pas celles auxquelles une équipe s'abonne avec une carte d'entreprise. Shadow IA est le même échec, mais beaucoup plus rapide, avec une barrière d'entrée plus basse et sans aucune étape d'approvisionnement. Google Cloud a fait un point similaire le même jour, décrivant les agents comme « les insiders ultimes » et rapportant que 79 % des responsables technologiques citent la sécurité, la gouvernance ou les opérations comme leur principal obstacle à la montée en charge de l'IA.
Pourquoi l’identité agent ne résout-elle pas le shadow IA ?
Parce que la plupart du shadow IA n’est pas un agent. C’est une personne. Lorsqu’un employé ouvre un compte personnel ChatGPT dans un onglet de navigateur et y colle une liste de clients, il n’y a pas d’agent à enregistrer, pas de jeton à émettre et pas de demande de connexion à évaluer par un fournisseur d’identité. La télémétrie d’Akamai place 47,11 % des conversations IA en entreprise exactement dans cette catégorie. Les contrôles d’identité agissent au moment où quelque chose demande l’accès à un système que vous possédez. Le shadow IA fait généralement l’inverse : il extrait des données d’un système auquel l’employé est déjà légitimement connecté, et les envoie ailleurs, hors de votre contrôle. La décision d’autorisation a déjà été validée. L’identité agent comble une faille réelle et sérieuse pour les acteurs machines, mais elle opère un niveau au-dessus de l’endroit où la plupart des pertes de données IA en entreprise se produisent réellement.
Près de la moitié de l’utilisation de l’IA en entreprise n’atteint jamais le plan d’identité
Le rapport d’Akamai repose sur la télémétrie d’usage réel plutôt que sur des réponses à des enquêtes, ce qui rend ses chiffres plus fiables que les statistiques habituelles d’adoption. En plus du chiffre de 47,11 %, il a constaté que plus de 14 % des conversations IA en entreprise impliquaient des abonnements personnels « freemium » liés à des adresses email professionnelles. Cette combinaison est le pire des deux mondes : elle porte le domaine de l’organisation, donc elle semble gouvernée dans un tableau, tandis que le compte, ses conditions de conservation des données et ses contrôles d’accès sont entièrement hors du contrôle de l’organisation.
L'exposition est aussi concentrée. Akamai a constaté que les 5 % d'utilisateurs les plus actifs génèrent au moins 144 conversations chacun, dépassant souvent 18 requêtes par conversation, tandis que la moitié des effectifs s'engage à peine. Ou comme l'a expliqué clairement Eshed, VP Sécurité Entreprise chez Akamai :
L’IA n’est plus seulement un booster de productivité ; c’est un collègue collaboratif avec un accès direct aux joyaux de la couronne de l’entreprise.
La concentration est une bonne nouvelle opérationnelle. Cela signifie que l’intervention la plus efficace est un programme ciblé visant quelques centaines de personnes, et non une campagne à l’échelle de l’organisation qui prend un an et agace tout le monde.
La couche des extensions de navigateur est le logiciel le moins gouverné que vous installez
Akamai a constaté que près de 75 % des extensions IA pour navigateur demandent des permissions élevées ou critiques, et que 16,3 % contiennent des CVE connus. Les extensions s’exécutent dans la session authentifiée. Elles peuvent lire le contenu rendu de votre CRM, de votre client mail et de votre système de tickets après que le single sign-on a réussi, c’est précisément le moment où une décision d’identité est terminée et cesse de protéger quoi que ce soit.
Les trois techniques d'attaque natives IA nommées par Akamai pour 2026 opèrent à ce niveau. Le vibe hacking manipule les fichiers d'instruction locaux pour qu'un assistant de codage produise un résultat non sécurisé ou prenne une action non autorisée. Le CursorJacking récolte des clés API via une extension malveillante. Le CometJacking utilise une injection de requête indirecte pour exfiltrer des données via un navigateur IA. Aucune de ces attaques n'est contrée par un meilleur jeton, car dans chaque cas l'autorisation était légitime et l'abus est survenu après.
Gouvernez deux plans, pas un seul
Le modèle pratique est celui de deux plans avec des contrôles différents. Le premier est le plan d’identité machine : agents qui se connectent aux systèmes, gouvernés par l’enregistrement, des jetons à courte durée de vie et le principe du moindre privilège. Agent SSO est désormais une bonne réponse ici et doit être adopté. Le second est la couche d’interaction : ce que les personnes et agents envoient réellement, requêtes, texte collé, fichiers téléchargés, trafic d’extensions, indépendamment de l’identité attachée, s’il y en a une. Rien sur le plan d’identité n’inspecte le contenu, et c’est dans le contenu que se produit la perte de données.
- Construisez un inventaire observé de l’utilisation de l’IA, pas un inventaire basé sur des enquêtes. La découverte doit s’exécuter dans le navigateur et sur le poste de travail, car les sessions à identité personnelle ne passent jamais par votre fournisseur d’identité.
- Activez Agent SSO pour chaque agent qui supporte Cross App Access. Il est inclus dans les plans Okta SSO de base, donc le seul coût réel est le temps de configuration.
- Commencez par les 5 % d’utilisateurs les plus actifs. La concentration signifie qu’un programme ciblé couvre la majeure partie de l’exposition pour une fraction de l’effort.
- Traitez les extensions IA de navigateur comme des logiciels privilégiés : inventairez-les, examinez les permissions demandées, et utilisez une liste blanche plutôt qu’une liste noire.
- Inspectez la couche d’interaction avec un DLP contextuel qui lit le contenu des requêtes et des téléchargements, pas seulement les points de terminaison, emails et partages de fichiers.
- Fermez la voie des emails professionnels sur abonnements personnels. Cela semble gouverné, mais ne l’est pas.
Comment découvrir une utilisation de l’IA sans identité d’entreprise ?
Vous l’observez là où elle se produit, c’est-à-dire dans le navigateur et sur le poste de travail. Les sessions authentifiées avec des identifiants personnels n’apparaissent jamais dans les journaux du fournisseur d’identité, donc un inventaire basé sur l’IdP est structurellement aveugle à celles-ci. Trois signaux fonctionnent réellement : la télémétrie du navigateur qui voit quelles applications IA un employé ouvre et ce qu’il soumet ; l’inspection du trafic vers les fournisseurs IA sur le poste de travail, y compris les applications natives qui contournent complètement le navigateur ; et l’analyse des sorties réseau comparée à un catalogue maintenu des domaines de services IA. Le catalogue est la partie sous-estimée par les équipes. Akamai décrit une longue traîne d’applications non gérées fonctionnant sous la poignée de plateformes que les équipes de sécurité surveillent réellement, donc un contrôle qui reconnaît seulement les vingt principaux fournisseurs recrée simplement le manque de visibilité à plus petite échelle. La découverte doit aussi être continue, car le marché des outils IA évolue assez vite pour qu’un audit ponctuel soit obsolète en un trimestre.
Que doit faire un RSSI dans les 30 premiers jours ?
Commencez par la mesure, pas la politique. La plupart des politiques d’usage acceptable de l’IA échouent car elles sont écrites contre un usage imaginé plutôt que réel. Passez les deux premières semaines à établir un inventaire observé : quelles applications IA sont utilisées, par qui, via des identités professionnelles ou personnelles, et quelles catégories de données sont soumises. Ensuite, agissez sur la concentration, car Akamai a constaté que les 5 % d’utilisateurs les plus actifs génèrent au moins 144 conversations chacun. En parallèle, deux changements coûtent presque rien : activez Agent SSO pour chaque agent supportant Cross App Access, puisqu’il est inclus dans les plans Okta SSO de base, et auditez les extensions IA de navigateur comme logiciels privilégiés, étant donné que près de 75 % demandent des permissions élevées ou critiques. Ce n’est qu’ensuite que vous devriez rédiger ou réviser la politique, car à ce stade vous gouvernerez ce que les gens font réellement.
Agent SSO est un vrai progrès et la norme ouverte qui le sous-tend est le bon pari à long terme. Mais il gouverne les agents que vous avez enregistrés, et les données de cette semaine montrent que près de la moitié de l’utilisation IA en entreprise ne s’enregistre nulle part. Le plan d’identité a progressé. La couche d’interaction non.
Comment Aona comble la faille de la couche d’interaction
Aona est une plateforme Workforce AI Security conçue pour la zone inaccessible à l'identité. Elle découvre l'utilisation de l'IA sur plus de 10 000 outils depuis le navigateur et le poste de travail, y compris les sessions de comptes personnels qui ne passent jamais par votre fournisseur d'identité, vous montre qui sont les utilisateurs à fort volume, et applique une protection des données en temps réel sur ce qui est réellement envoyé, avec une rédaction des fichiers DOCX, Excel et PDF. Découvrez comment Aona détecte et gouverne le Shadow IA.
