Okta affirme que les listes d’outils MCP (Model Context Protocol) axées sur l’identité peuvent réduire les coûts des jetons d’agent IA.
Chaque appel de modèle effectué par un agent IA peut inclure des schémas, des noms, des descriptions et des paramètres pour chaque outil exposé par un serveur MCP. Okta appelle l’invite qui en résulte la « taxe sur les outils » : les jetons consommés en tant que modèle prennent en compte les outils, y compris ceux qu’il n’appellera jamais.
L’entreprise fait valoir que ce coût apparaît avant qu’un agent ne tente d’appeler l’outil. Un rejet ultérieur d’une requête non autorisée ne peut donc pas récupérer les jetons d’invite déjà consommés. Le contrôle proposé par Okta filtre la liste des outils avant qu’elle n’atteigne le modèle, en utilisant les autorisations attribuées à l’identité d’un agent et à l’utilisateur qui lui est associé.
La modélisation interne d’Okta a révélé que certains scénarios d’autorisation réduisaient le nombre d’outils visibles de plus de 90 %. La société a déclaré que les coûts des schémas d’outils avaient diminué à peu près dans la même proportion, bien qu’elle n’ait pas fourni de chiffres absolus en termes de jetons ou de dollars.
Les schémas de l’outil MCP créent une surcharge d’invite à chaque tour
Les serveurs MCP sont devenus un moyen de connecter les agents IA aux outils et aux données. Okta cite comme exemples les connexions à Google Workspace, Slack et aux serveurs MCP internes. Un serveur MCP peut exposer un grand nombre d’outils et le modèle reçoit à chaque tour une représentation de chaque outil disponible dans son invite.
Cette représentation comprend un schéma. Il comprend également le nom de l’outil, sa description et ses paramètres.
Okta affirme que le coût augmente lorsqu’un serveur MCP largement utilisé expose de nombreux outils. Chaque utilisateur actif subit la surcharge d’invite chaque fois que son agent effectue un appel de modèle. L’entreprise considère cela à la fois comme un problème de nombre d’outils et de nombre d’utilisateurs.
La question a également une dimension de contrôle d’accès. Un agent qui voit des outils en dehors de sa portée d’autorisation peut tenter de les utiliser. Un contrôle qui rejette l’appel au moment de l’exécution peut bloquer l’exécution, même si le modèle a déjà reçu la définition de l’outil et utilisé des jetons pour la traiter.
Okta filtre les outils avant la création de l’invite de l’agent
Okta positionne cette fonctionnalité dans son « modèle pour l’entreprise agentique sécurisée », qui demande aux organisations d’identifier leurs agents, leurs connexions autorisées et leurs actions autorisées.
Son approche réduit la question de connexion de l’accès à l’ensemble d’un serveur MCP à l’accès à des outils individuels sur ce serveur. Un administrateur configure les outils qu’une identité particulière peut utiliser dans le tableau de bord Okta. Okta renvoie ensuite l’ensemble d’outils ciblé au lieu du catalogue complet du serveur.
L’agent reçoit cette liste plus courte dans son invite à chaque tour. Okta indique qu’il vérifie à nouveau la portée au moment de l’exécution avant l’exécution d’un appel d’outil.
Cette conception applique le moindre privilège au niveau de l’outil. L’entreprise affirme qu’un agent ne doit pas avoir connaissance de ressources, de bases de données ou d’outils qu’il n’a pas été expressément autorisé à utiliser. La suppression des outils indisponibles de l’invite supprime également leur coût de schéma de l’appel de modèle.
Okta ne décrit pas de déploiement client en direct dans la publication. Les preuves de la réduction alléguée proviennent d’une modélisation interne utilisant les données des produits Okta et la documentation publique du fournisseur, sans aucune donnée client.
Le modèle interne utilisait les portées OAuth et les rôles représentatifs
Okta a modélisé un client MCP unique avec accès à un catalogue d’outils d’entreprise. Il a comparé le nombre d’outils visibles par le modèle avant et après la portée basée sur l’identité.
Pour estimer l’exposition, la société a mappé les outils du serveur Okta MCP aux étendues OAuth qui les déverrouillent. Il a ensuite défini des segments d’utilisateurs représentatifs. Il s’agissait notamment des utilisateurs en lecture seule et des opérateurs du service d’assistance.
Les autres segments étaient les administrateurs d’applications, les administrateurs de marque et de messagerie, ainsi que les super-administrateurs. Okta a pondéré chaque segment en fonction d’une part supposée du trafic mensuel.
L’entreprise a calculé la réduction du nombre d’outils comme étant égale à un moins le rapport entre les outils ciblés et les outils non ciblés. Il indique que certains scénarios suppriment plus de 90 % des outils visibles. Son article indique que le coût du jeton de schéma d’outil suit le nombre d’outils de manière presque linéaire, car chaque outil fournit son nom, sa description et son schéma de paramètres à chaque invite.
Okta indique que les résultats réels varient en fonction du catalogue d’outils, de la distribution des autorisations et du modèle sélectionné. La taille moyenne du schéma, le volume des demandes et la tarification du modèle affectent également les coûts absolus en jetons et en dollars.
Okta oppose les droits d’identité aux contrôles des dépenses de passerelle
Le message distingue la portée basée sur l’identité des contrôles de passerelle. Okta indique que les passerelles peuvent limiter les dépenses par clé, équipe ou groupe, et prendre en charge le routage et la limitation des tarifs.
Une passerelle peut mesurer les jetons entrant et sortant d’un système, ainsi que les dollars dépensés. Okta affirme que ces contrôles peuvent limiter les coûts une fois qu’une décision modèle devient coûteuse.
Les droits d’identité fournissent une contribution différente. Okta indique que les droits par utilisateur et par agent peuvent déterminer les outils disponibles pour un agent spécifique ou la personne derrière cet agent, plutôt que d’appliquer les informations d’accès au niveau du groupe.
Paul Webber, analyste principal du secteur de la cybersécurité chez Software Analyst Cyber Research, a déclaré : « Le contrôle des coûts pour les agents est mieux assuré en utilisant des outils de gouvernance des identités qui offrent un contrôle et une précision plus granulaires sans perturber les processus métier.
« L’approche d’Okta est une manière élégante d’y parvenir car elle exploite les mêmes données d’autorisation qui régissent la sécurité, et non une couche de mesure distincte sans ces informations.
Le compte d’Okta présente la passerelle comme un contrôle de ce qui la traverse. La couche d’identité filtre l’ensemble d’outils disponibles avant que ces outils ne doivent être mesurés.
La visibilité des outils affecte également l’exposition aux attaques MCP
Le message associe le même mécanisme à l’exposition à la sécurité. Okta affirme que la suppression des outils de la vue d’une identité non autorisée supprime également les actions que l’identité pourrait entreprendre si elle était compromise.
Le contrôle de portée proposé opère sur deux points. La première se produit lorsque la liste d’outils est assemblée pour l’invite de l’agent. La seconde se produit lorsque l’agent tente d’exécuter un appel d’outil.
Okta décrit le résultat comme un rayon d’explosion plus petit pour une identité compromise. Les outils exposés restants déterminent l’ensemble des actions disponibles pour cette identité. Dans le modèle de l’entreprise, l’invite contient uniquement les outils associés aux étendues OAuth autorisées de l’identité.
Pour les organisations évaluant l’accès au MCP, l’inventaire des outils et la cartographie des droits sont les principaux intrants opérationnels. La méthodologie d’Okta mappe les outils du serveur MCP aux étendues OAuth qui les déverrouillent, puis compare le catalogue d’outils complet avec le catalogue étendu visible pour chaque segment d’utilisateurs représentatif.
Okta est un sponsor clé de cette année Salon européen de l’IA et du Big Data qui s’est tenu à Amsterdam les 19 et 20 octobre 2026.
