La sécurité des agents IA d’Okta s’attaque à la confusion des entreprises

Okta a identifié un adversaire inhabituel dans sa stratégie de sécurité des agents IA : la confusion des clients, plutôt qu’un autre fournisseur de sécurité. Le président et directeur des opérations Eric Kelleher l’a affirmé lors de la conférence Goldman Sachs Communacopia + Technology, le 9 septembre 2026.

Cet argument reflète un marché où les entreprises veulent des logiciels autonomes, mais peinent à définir ce qui doit être sécurisé. Un agent peut résumer des e-mails, mettre à jour une fiche commerciale, approuver un remboursement ou gérer tout un flux de travail financier. Chaque rôle engendre des autorisations, des risques et des exigences de responsabilité différents.

Okta veut faire de l’identité la couche organisatrice de ce désordre. Son cadre pose trois questions : où se trouvent les agents, à quoi peuvent-ils se connecter et que peuvent-ils faire ? Microsoft poursuit des objectifs similaires avec Entra Agent ID et Agent 365, ce qui rend la distribution en entreprise aussi importante que la conception de la sécurité.

Cette concurrence modifie la portée du message d’Okta. La confusion peut ouvrir un marché à un fournisseur d’identité indépendant, mais elle peut aussi ralentir les achats et favoriser les plateformes intégrées. Okta doit transformer un discours de sécurité urgent en déploiements reproductibles, en adoption mesurable et en normes que les clients peuvent utiliser chez plusieurs fournisseurs.

La sécurité des agents IA d’Okta commence par trois questions

La démarche immédiate d’Okta consiste à ramener un vaste problème de sécurité à la découverte des agents, au contrôle des connexions et à l’autorisation.

Lors de la conférence de septembre, Kelleher a décrit des clients sollicitant l’aide d’Okta après avoir découvert des rapports alarmants sur les agents autonomes. Ces acheteurs comprennent que les agents introduisent des risques, mais ils manquent souvent d’un modèle commun pour les évaluer.

La réponse d’Okta est son Blueprint for the Secure Agentic Enterprise. L’entreprise a présenté ce cadre en mars et a rendu Okta for AI Agents généralement disponible le 30 avril 2026. Le produit étend les contrôles d’identité familiers aux logiciels autonomes et semi-autonomes.

La première question, « Où sont mes agents ? », concerne l’inventaire et la propriété. Les employés peuvent activer des outils sans processus de déploiement formel, tandis que les développeurs peuvent créer des agents sur de nombreuses plateformes cloud. Les équipes de sécurité ne peuvent pas gouverner un agent qu’elles ne peuvent pas identifier.

La capacité Agent Discovery d’Okta est conçue pour révéler ces déploiements cachés. Selon les détails d’agent discovery de l’entreprise, elle détecte l’activité de consentement OAuth et identifie les connexions impliquant des plateformes d’agents non approuvées.

Le consentement OAuth accorde à une application l’autorisation d’accéder à un autre service sans recevoir le mot de passe de l’utilisateur. Cette commodité devient risquée lorsqu’un employé autorise un agent inconnu à lire des e-mails, des fichiers, des calendriers ou des dossiers clients.

Okta affirme que les signaux du navigateur peuvent révéler l’application cliente, la ressource connectée et les périmètres d’autorisation demandés. Les administrateurs peuvent alors enregistrer l’agent, lui attribuer un responsable humain et appliquer des politiques de base.

La deuxième question, « À quoi les agents peuvent-ils se connecter ? », déplace l’attention de l’inventaire vers les voies d’accès. Un agent peut interagir avec des applications, des API, des bases de données, des outils ou des serveurs Model Context Protocol. MCP est une interface standard qui permet aux systèmes d’IA d’accéder à des outils externes et à des informations.

Le blueprint d’Okta comprend une passerelle destinée à servir d’intermédiaire pour ces connexions, la gestion sécurisée des identifiants et la gestion des accès aux API. Ces contrôles visent à remplacer les identifiants larges et persistants par des décisions plus restreintes fondées sur l’identité, le contexte et le risque.

La troisième question, « Que peuvent faire les agents ? », touche à la couche la plus difficile. Savoir qu’un agent peut entrer dans un système ne révèle pas s’il peut lire, écrire, transférer, approuver ou supprimer des informations.

Okta propose de journaliser les appels d’outils individuels et les décisions d’autorisation. L’entreprise promeut également Universal Logout comme interrupteur d’arrêt qui révoque les jetons d’accès d’un agent dans les systèmes connectés.

Ce cadrage est important, car un agent n’est pas simplement un autre compte employé. Il peut exécuter rapidement de nombreuses actions, combiner des informations provenant de plusieurs systèmes et modifier son comportement lorsque le contexte environnant évolue.

Il diffère aussi d’un compte de service traditionnel, qui exécute généralement une tâche automatisée prévisible. Un agent IA peut sélectionner des outils, générer des plans intermédiaires et agir via des autorisations déléguées par un utilisateur.

Les trois questions d’Okta créent donc une structure d’achat utile. Elles ne prouvent pas que chaque contrôle sous-jacent fonctionne sur chaque plateforme d’agents. Elles donnent aux responsables de la sécurité un vocabulaire commun pour déterminer ce qui doit être testé.

Ce vocabulaire est le fondement de la stratégie de l’entreprise. Okta veut que les entreprises considèrent la sécurité des agents comme une extension de la gouvernance des identités, et non comme une catégorie isolée de surveillance de l’IA.

La confusion crée à la fois de la demande et des délais

La même incertitude qui amène les clients vers Okta peut aussi allonger les évaluations et empêcher la sécurité des agents de devenir une activité prévisible.

Kelleher a qualifié la confusion de principal concurrent actuel de l’entreprise dans l’identité agentique. Les acheteurs sont confrontés à des affirmations concurrentes de la part de fournisseurs de sécurité, de fournisseurs cloud, de développeurs d’IA et de plateformes de gouvernance. De nombreux produits utilisent un langage similaire tout en protégeant des couches différentes.

Un fournisseur peut analyser les prompts à la recherche d’instructions malveillantes. Un autre peut découvrir des identités machine ou des identifiants exposés. Un troisième peut contrôler le trafic réseau, tandis qu’un fournisseur d’identité détermine quel agent peut accéder à une application précise.

Ces fonctions peuvent se compléter, mais les entreprises doivent encore établir les responsabilités. L’équipe de sécurité peut contrôler les politiques d’accès, tandis que les développeurs sont propriétaires de l’agent et les unités opérationnelles définissent les actions acceptables.

Les achats deviennent plus difficiles lorsqu’une organisation ne peut pas répondre à des questions élémentaires sur son déploiement. Une entreprise peut savoir que ses employés utilisent des assistants IA sans savoir lesquels disposent d’autorisations d’application durables.

Les définitions d’agent restent également incohérentes. Certains systèmes sont des interfaces conversationnelles qui recommandent des actions. D’autres exécutent des flux de travail après approbation humaine, tandis que les agents autonomes peuvent agir sans examiner chaque étape.

Cette ambiguïté affecte la tarification et la mesure des produits. Kelleher a déclaré qu’Okta facture actuellement son offre agentique comme un supplément à la tarification par utilisateur. Il a reconnu que ce modèle n’est pas parfait pour l’architecture des agents, mais l’a décrit comme facile à acheter pour les clients.

La plupart des premières transactions sont des accords d’un an, selon ses propos lors de la conférence. Okta s’attend à ce que les deux parties obtiennent de meilleures informations sur l’utilisation des agents et les coûts d’exploitation avant les renouvellements.

Cette approche réduit les frictions immédiates à l’achat. Elle montre aussi à quel point le marché reste précoce. Une catégorie de sécurité mature possède généralement des unités plus claires, telles que les utilisateurs, les appareils, les charges de travail, les transactions ou le volume de données protégées.

L’activité des agents peut recouper toutes ces unités. Un employé peut utiliser plusieurs agents, tandis qu’un agent peut créer des travailleurs temporaires ou effectuer des milliers d’appels d’outils. Un modèle par utilisateur peut finir par ne plus correspondre à la charge de travail sécurisée.

L’avantage d’Okta réside dans sa relation existante avec les équipes d’identité des entreprises. Kelleher a déclaré que plus de 20 000 entreprises font déjà confiance à Okta pour les identités humaines et non humaines. Cette base installée offre un accès direct aux discussions sur la sécurité.

Toutefois, la confiance n’élimine pas le travail de mise en œuvre. Les clients doivent découvrir les agents, classifier leurs finalités, identifier les responsables, réduire les autorisations excessives et connecter les applications pertinentes aux points d’application des contrôles.

Les responsables de la sécurité doivent également décider quelles actions exigent une approbation humaine. Un agent de synthèse et un agent de devis-à-encaissement ne devraient pas recevoir des contrôles identiques, même s’ils utilisent la même plateforme d’identité.

Le second peut toucher aux prix, aux contrats, aux systèmes de facturation et aux registres de revenus. Une erreur pourrait devenir un incident financier ou de conformité plutôt qu’une réponse simplement gênante.

Cette distinction ne transforme la confusion en opportunité produit que lorsqu’Okta peut guider le déploiement. Un blueprint aide les clients à poser de meilleures questions, mais des modèles opérationnels et des intégrations doivent fournir les réponses.

Cette exigence met sous pression les activités commerciales et de services professionnels d’Okta. Les acheteurs s’attendront à ce que l’entreprise traduise un cadre d’identité abstrait en contrôles pour des flux de travail concrets.

Les développeurs font face à un défi connexe. Ils ont besoin de modèles d’accès sécurisés qui n’exigent pas de reconstruire chaque agent pour le système d’identité de chaque client. C’est pourquoi la stratégie de normes d’Okta se trouve au cœur de son argument produit.

Cross App Access est la tentative d’Okta pour une couche de contrôle ouverte

Okta parie qu’une norme ouverte d’autorisation peut rendre l’accès des agents portable tout en préservant les fournisseurs d’identité comme principaux responsables de l’application des politiques.

Cross App Access, ou XAA, est la méthode proposée par Okta pour connecter les agents aux applications via une autorisation standardisée. Elle étend des concepts d’OAuth et fonctionne avec MCP, qui fournit une méthode commune permettant aux agents de découvrir et d’appeler des outils.

La distinction est importante. MCP peut décrire un outil disponible et prendre en charge l’interaction, mais les entreprises doivent encore décider si un agent particulier peut l’utiliser. XAA est conçu pour transmettre le contexte d’identité et d’autorisation dans cette connexion.

Kelleher a déclaré qu’Okta proposait Cross App Access comme une norme ouverte plutôt que comme un format propriétaire d’Okta. Il a également déclaré qu’elle avait été acceptée comme extension de MCP et suscitait un large intérêt dans le secteur.

Okta a rendu Agent SSO généralement disponible en août 2026. Agent SSO permet à un administrateur d’enregistrer un agent comme principal de charge de travail, c’est-à-dire une identité non humaine gérée indépendamment.

Lorsqu’un agent pris en charge se connecte à une application, Okta peut le placer dans Universal Directory aux côtés d’autres identités gouvernées. Les administrateurs peuvent alors consulter la propriété, les connexions et les politiques applicables via les processus d’identité existants.

Cette approche tente de résoudre une faiblesse récurrente des déploiements d’agents. De nombreux premiers agents empruntent le jeton d’accès d’un utilisateur ou s’appuient sur un identifiant statique stocké dans un flux de travail.

L’accès emprunté peut rendre l’attribution peu claire. Si un agent modifie un enregistrement en utilisant l’identité d’un employé, un journal d’audit peut ne pas distinguer l’action du logiciel de l’action humaine directe.

Les identifiants statiques créent un autre problème. Ils peuvent rester actifs plus longtemps que nécessaire et apparaître dans des fichiers de configuration, des journaux ou des environnements de développement. Un secret exposé peut donner à un attaquant un accès persistant.

Une identité d’agent dédiée sépare l’acteur de son sponsor. Le responsable métier reste comptable, mais le système de sécurité peut appliquer des politiques différentes à l’agent et à la personne.

Cette séparation favorise le principe du moindre privilège, qui limite une identité à l’accès minimal nécessaire à sa tâche assignée. Elle peut aussi permettre des jetons de plus courte durée et une désactivation plus claire lorsqu’un agent est retiré.

Okta affirme qu’Auth0 for AI Agents peut aider les développeurs à créer des agents qui fonctionnent avec XAA. Ces agents peuvent stocker des identifiants auprès de différents fournisseurs d’identité, plutôt que d’exiger un environnement réservé à Okta.

L’ouverture renforce l’argument d’Okta auprès des clients préoccupés par l’enfermement propriétaire. Une entreprise peut utiliser dans le même environnement des agents de Microsoft, Google, Salesforce, d’équipes de développement internes et de fournisseurs plus petits.

Une couche d’autorisation portable permettrait à ces agents de rencontrer des décisions d’accès cohérentes. Elle pourrait également réduire le travail d’intégration sur mesure pour les développeurs vendant à des entreprises dotées de systèmes d’identité différents.

Pourtant, la publication d’une norme ne crée pas automatiquement l’interopérabilité. Les applications doivent l’implémenter, les frameworks d’agents doivent transmettre le contexte requis et les fournisseurs d’identité doivent interpréter les requêtes de manière cohérente.

Les équipes de sécurité doivent également faire confiance aux métadonnées utilisées dans chaque décision. Un agent peut posséder une identité valide tout en recevant des instructions manipulées ou en sélectionnant une action dangereuse.

L’identité répond à la question de savoir qui ou quoi demande l’accès. Elle ne détermine pas de manière autonome si un plan généré est exact, éthique ou aligné sur l’intention commerciale.

Le mécanisme d’Okta est donc important, mais limité. XAA peut rendre l’autorisation plus explicite et plus auditable. Il ne peut pas remplacer les garde-fous des modèles, la gouvernance des données, les contrôles réseau ou la validation au niveau des applications.

L’entreprise y gagne si XAA devient une norme de connexion neutre. Elle subit davantage de pression si les plateformes d’agents maintiennent l’application des identités au sein de leurs propres plans de contrôle intégrés.

Cette pression est déjà visible dans la pile croissante d’identités d’agents de Microsoft.

Microsoft transforme la sécurité des identités en bataille de distribution

Le principal défi concurrentiel d’Okta réside dans la capacité de Microsoft à regrouper l’identité des agents avec les applications, les services cloud et les outils d’administration que les entreprises utilisent déjà.

Microsoft Entra Agent ID est devenu généralement disponible en avril 2026. Il fournit des structures d’identité, des contrôles d’authentification, d’autorisation, de gouvernance et de sécurité conçus pour les agents d’IA.

Son argument fondamental ressemble étroitement à celui d’Okta. Les agents doivent avoir des propriétaires identifiables, des cycles de vie gérés, un accès limité et une activité auditable. Microsoft prend également en charge OAuth, MCP et les protocoles agent-à-agent.

La différence tient à la distribution. Microsoft contrôle un vaste ensemble d’applications métier, de services pour développeurs, d’infrastructures cloud, de plateformes de données et de produits de sécurité.

Agent 365 sert de catalogue unifié et de couche de gestion de l’entreprise. Entra fournit la base d’identité qui le sous-tend, selon la documentation sur l’identité des agents de Microsoft.

Microsoft peut connecter une identité d’agent à l’Accès conditionnel, à Identity Protection, à Microsoft Graph et à son environnement de gouvernance plus large. Les clients qui opèrent déjà au sein de cette pile peuvent préférer une expérience administrative consolidée.

Un exemple pratique apparaît dans l’intégration Dataverse de Microsoft. Un agent de développement commercial peut recevoir une identité dédiée et un rôle limité pour lire les prospects, enregistrer les actions de prospection et mettre à jour les enregistrements éligibles.

Les administrateurs peuvent exclure des tables non liées ou des champs sensibles. Les actions restent attribuables à l’agent au lieu d’apparaître sous un compte partagé d’employé ou d’application.

Ce scénario démontre le risque stratégique pour Okta. Microsoft n’a pas besoin de vendre l’identité des agents comme une catégorie distincte lorsqu’il peut intégrer la gouvernance dans l’application où le travail se déroule.

La réponse d’Okta est l’indépendance. Sa valeur augmente lorsqu’une entreprise utilise plusieurs clouds, créateurs d’agents et écosystèmes logiciels. Une couche d’identité neutre peut offrir une politique cohérente au-delà de ces frontières.

Kelleher a souligné que l’identité agentique combine des caractéristiques d’identité humaine et non humaine. Okta gère déjà les deux catégories, ce qui lui donne de l’expérience en gouvernance du cycle de vie, accès aux applications et signaux de sécurité.

Son catalogue d’intégrations donne également à l’entreprise un point de départ important. Okta a déclaré en mars que son réseau comptait plus de 8 200 intégrations, avec une prise en charge des agents impliquant Boomi, DataRobot et Google Vertex AI.

Cette ampleur ne compte que si les intégrations offrent une application significative des règles. Une entrée de catalogue qui enregistre un agent diffère d’une entrée qui autorise des appels d’outils individuels et permet une révocation rapide.

Microsoft fait face au même test au sein de son écosystème. Une identité centralisée peut décrire des autorisations, mais les applications doivent appliquer correctement ces autorisations au cours de flux de travail rapides et à plusieurs étapes.

D’autres fournisseurs de sécurité ajoutent une couche de concurrence supplémentaire. Les entreprises spécialisées dans l’accès privilégié peuvent gérer des identifiants sensibles, tandis que les fournisseurs de sécurité des terminaux et du cloud peuvent analyser les comportements autour d’un agent.

Les spécialistes de la sécurité de l’IA peuvent se concentrer sur l’injection de prompts, la sélection dangereuse d’outils, la fuite de données et le comportement des modèles. Ces menaces ne disparaissent pas après qu’un agent a reçu une identité dédiée.

L’architecture d’entreprise probable comprendra plusieurs couches de contrôle. La question disputée est de savoir quelle plateforme deviendra le lieu central pour la propriété, les politiques et les enquêtes.

Okta souhaite que cette place soit occupée par le tissu de sécurité des identités. Microsoft souhaite qu’Agent 365 et Entra fournissent un plan de contrôle unifié, en particulier dans les applications Microsoft.

Les clients jugeront ces affirmations à travers des environnements mixtes. Une plateforme qui ne gouverne que ses agents natifs laissera les équipes de sécurité avec des inventaires et des politiques fragmentés.

L’indépendance d’Okta apporte une réponse crédible à la fragmentation. La profondeur d’intégration de Microsoft apporte une réponse crédible à la complexité opérationnelle.

C’est le principal affrontement de l’article : une couche d’identité neutre face à un plan de contrôle intégré pour les applications et le cloud. La confusion aide Okta à entamer la conversation, mais l’interopérabilité déterminera qui la contrôle.

Les contrôles d’identité ne peuvent pas juger l’intention d’un agent

Okta peut restreindre ce à quoi un agent est autorisé à accéder, mais des identifiants valides ne garantissent pas un raisonnement sûr ni une action correcte.

Un agent peut s’authentifier avec succès et rester dans un périmètre d’autorisation approuvé tout en causant des dommages. Il peut mal interpréter une demande, suivre une instruction malveillante ou combiner des actions autorisées pour aboutir à un résultat non intentionnel.

L’injection de prompts illustre cet écart. Un attaquant peut placer des instructions dissimulées ou trompeuses dans du contenu qu’un agent lit. L’agent peut traiter ces instructions comme faisant partie de sa tâche.

Les contrôles d’identité peuvent limiter le rayon d’impact qui en résulte. Ils ne peuvent pas toujours reconnaître que le processus de décision de l’agent a été manipulé.

La même limite s’applique à une planification incorrecte. Un agent financier autorisé pourrait sélectionner le mauvais compte, dupliquer une action ou appliquer une règle d’approbation à la mauvaise transaction.

Un interrupteur d’arrêt devient utile après la détection d’un comportement suspect. Toutefois, des agents autonomes peuvent exécuter de nombreuses actions avant qu’un humain reconnaisse le schéma et révoque l’accès.

L’autorisation à l’exécution cherche à réduire cette fenêtre. Au lieu d’accorder un accès permanent étendu, un système évalue les requêtes individuelles en fonction de l’identité, du contexte, du risque et de l’action envisagée.

La qualité de cette évaluation dépend d’un contexte fiable. Les politiques doivent distinguer les variations ordinaires des comportements dangereux sans bloquer les flux de travail légitimes.

Les organisations ont également besoin de journaux fiables. L’enregistrement des appels d’outils d’un agent aide les enquêteurs à reconstituer les événements, mais les journaux doivent relier l’agent, le sponsor humain, l’instruction, la décision d’autorisation et la modification résultante.

Un enregistrement qui ne montre qu’un appel API réussi offre une responsabilité limitée. Les équipes de sécurité doivent savoir pourquoi l’agent a appelé l’API et quelles données ont façonné sa décision.

Les fonctionnalités de journal système et de gouvernance d’Okta couvrent certaines parties de cette chaîne. L’entreprise affirme que les appels d’outils, les tentatives d’accès et les décisions d’autorisation peuvent être transmis aux systèmes de gestion des informations et des événements de sécurité.

Ces capacités restent des affirmations de l’entreprise jusqu’à ce que les clients les testent sur divers frameworks d’agents et applications. L’annonce d’Okta elle-même avertit également que des fonctionnalités non publiées peuvent arriver tardivement ou ne jamais arriver.

Les preuves indépendantes restent limitées, car les déploiements d’agents en entreprise sont récents. Les travaux universitaires ont commencé à examiner la gestion des identités pour les systèmes agentiques, mais les benchmarks de production sont encore en développement.

Une préoccupation supplémentaire concerne la qualité de la propriété. Désigner un sponsor humain crée une responsabilité sur le papier, mais cette personne doit comprendre les données, les autorisations, les dépendances et les conditions de retrait de l’agent.

La propriété peut devenir cérémonielle lorsque les organisations déploient des agents plus vite que les responsables ne peuvent les examiner. Les certifications d’accès risquent alors de devenir une autre file d’approbation manquant de contexte.

La prolifération des agents aggrave le problème. Un agent principal peut créer des sous-agents temporaires pour la recherche, l’analyse ou l’exécution. La politique de sécurité doit déterminer si ces identités temporaires héritent des autorisations.

Un héritage étendu est facile à administrer, mais accroît l’exposition. Exiger une approbation distincte pour chaque agent de courte durée peut compromettre la rapidité qui rend les flux de travail agentiques attrayants.

C’est le compromis central de la sécurité des agents d’IA d’Okta. Les entreprises veulent que les agents opèrent rapidement entre les systèmes, tandis que les équipes de sécurité ont besoin que chaque action reste limitée, attribuable et réversible.

Trop peu de contrôle crée un risque inacceptable. Trop de friction transforme un flux de travail autonome en une lente série d’approbations humaines.

Les déploiements les plus solides commenceront par des tâches restreintes et des limites de données explicites. Un agent de support peut classer les tickets avant de recevoir l’autorisation d’émettre des crédits ou de modifier les dossiers clients.

Les équipes devraient tester les scénarios d’échec, et pas seulement les démonstrations réussies. Elles ont besoin de preuves montrant comment le système gère une propriété expirée, des entrées manipulées, des autorisations excessives et des services d’application indisponibles.

Une base de connaissances consultable peut aider les équipes à documenter les propriétaires, les politiques et les décisions liées aux incidents. Elle ne remplace pas le contrôle d’accès, mais elle préserve le contexte dont les examinateurs ont besoin.

La stratégie d’Okta devient plus convaincante lorsque les clients peuvent relier les décisions d’identité à des privilèges réduits et à un confinement plus rapide des incidents. Les annonces de produits seules ne peuvent pas établir ce résultat.

Trois signaux montreront si l’offensive d’Okta fonctionne

L’adoption des normes, l’expansion des clients et l’application des règles entre plateformes détermineront si Okta transforme la confusion en une catégorie durable de sécurité des identités.

Le premier signal est l’adoption de Cross App Access au-delà des propres produits d’Okta. Les développeurs d’agents, les fournisseurs d’applications et les fournisseurs d’identité concurrents doivent implémenter le protocole pour qu’il devienne une infrastructure significative.

Okta a déclaré lors de la conférence de septembre que des annonces plus larges approchaient. Le détail important ne sera pas le nombre de partenaires nommés. Les acheteurs devraient examiner quelles actions ces intégrations peuvent réellement autoriser.

La prise en charge de l’enregistrement fournit un inventaire. La prise en charge d’une autorisation limitée et contextuelle fournit le contrôle. La prise en charge d’une révocation rapide fournit le confinement lorsqu’un agent s’écarte de son rôle prévu.

Un ensemble croissant d’intégrations opérationnelles renforcerait l’argument d’Okta en faveur d’une plateforme neutre. Une adoption limitée laisserait XAA comme une fonctionnalité utile dans l’environnement Okta plutôt que comme une couche de contrôle sectorielle.

Le deuxième signal est la forme des renouvellements et expansions clients. Kelleher a déclaré que la plupart des premières transactions agentiques utilisent des contrats d’un an, donnant aux clients et à Okta le temps de comprendre l’utilisation.

Ces renouvellements révéleront si les entreprises vont au-delà de l’évaluation. Les acheteurs devraient rechercher des déploiements qui gouvernent des agents de production sur plusieurs processus métier, et non des démonstrations isolées.

L’expansion vers des plateformes d’agents supplémentaires soutiendrait l’affirmation selon laquelle l’identité offre un plan de contrôle commun. Une croissance liée uniquement à des projets expérimentaux suggérerait que la confusion reste un obstacle commercial.

La tarification fournira un autre indice. La hausse par utilisateur d’Okta simplifie les achats initiaux, mais le volume et l’activité des agents ne suivent pas nécessairement le nombre d’employés.

Le modèle pourrait évoluer vers des agents protégés, des connexions, des transactions ou des événements d’autorisation. Chaque changement révélera ce que les clients valorisent et quels coûts opérationnels comptent le plus.

Un modèle stable et compréhensible aiderait la catégorie à gagner en maturité. Une tarification complexe à l’usage pourrait réintroduire l’incertitude que le modèle d’Okta vise à éliminer.

Le troisième signal est la réaction concurrentielle de Microsoft et d’autres fournisseurs d’identité. Le modèle Agent 365 de Microsoft associe déjà un inventaire unifié à une identité et une gouvernance appuyées par Entra.

Si Microsoft étend une gouvernance simple aux agents tiers, l’argument d’indépendance d’Okta sera directement mis à l’épreuve. Si Microsoft reste surtout performant dans son propre environnement, Okta disposera d’une marge de manœuvre dans les entreprises hétérogènes.

Les clients devraient comparer l’application des politiques entre Microsoft 365, Google Workspace, Salesforce, les plateformes cloud et les applications personnalisées. Le gagnant devra offrir davantage qu’une liste centrale d’agents.

Il devra préserver l’identité des agents au-delà des frontières entre applications, appliquer le principe du moindre privilège, rendre la responsabilité visible et révoquer les accès de manière cohérente. Il devra également fournir des éléments de preuve utilisables par les équipes de sécurité lors d’enquêtes et d’audits.

La prise en charge, par les concurrents, de normes communes validerait la thèse plus large d’Okta, même si elle réduisait la différenciation des produits. Des approches propriétaires feraient de l’identité des agents une nouvelle frontière entre plateformes.

Le message d’Okta lors de la conférence mérite l’attention, car il évite de présenter la sécurité des agents IA comme une simple fonction de détection. L’entreprise articule le problème autour de la responsabilité et de l’accès tout au long du cycle de vie d’un agent.

Cette approche correspond au défi opérationnel. Une entreprise doit savoir qui a créé un agent, pourquoi il existe, quelles ressources il peut atteindre et comment l’arrêter.

Toutefois, l’identité n’est qu’un plan de contrôle parmi plusieurs. Les protections des modèles, la validation des applications, la surveillance réseau, la gouvernance des données et la supervision humaine restent nécessaires.

Les acheteurs de solutions de sécurité devraient donc considérer le modèle d’Okta comme un cadre de test. Ils peuvent demander à chaque fournisseur de démontrer la découverte, l’autorisation, la responsabilité, la journalisation et la révocation au sein d’un flux de travail réel.

La meilleure preuve viendra d’un déploiement de production volontairement limité. Les équipes peuvent commencer par un agent qui lit des informations restreintes et propose des actions soumises à l’approbation humaine.

Elles peuvent ensuite mesurer les demandes d’autorisations excessives, les refus de politiques, le temps d’enquête et la précision du déclassement. Ces résultats en disent davantage qu’une démonstration autonome soignée.

La sécurité des agents IA d’Okta repose en définitive sur le pari que les entreprises ne géreront pas les logiciels autonomes au moyen d’identifiants dispersés et de contrôles isolés. Le marché évolue vers des identités dédiées, une responsabilité explicite et une autorisation continue.

La question non résolue est de savoir qui fournira cette couche dans des environnements mixtes. Surveillez d’abord les intégrations XAA, ensuite les renouvellements en production, puis la portée de Microsoft auprès des tiers.

Si Okta progresse sur ces trois fronts, la confusion se transformera en une opportunité durable pour l’identité. Si l’adoption reste fragmentée, les plateformes intégrées conserveront leur avantage.

Pour les équipes d’entreprise, la prochaine étape est pratique : sélectionnez un agent, cartographiez chaque connexion et documentez chaque action autorisée. Demandez-vous ensuite si votre système d’identité actuel peut voir, restreindre, auditer et révoquer cet agent sans travail personnalisé.