Okta révolutionne la gestion des coûts IA avec le protocole MCP

Okta innove avec le protocole MCP pour réduire les coûts des agents IA

Okta, un acteur majeur dans la gestion des identités, a récemment mis en avant une solution innovante pour réduire les coûts associés aux agents d'intelligence artificielle (IA). En utilisant le protocole de contexte de modèle (MCP), Okta propose de diminuer les coûts des jetons consommés par les agents IA. Chaque appel de modèle effectué par un agent IA inclut divers éléments tels que des schémas, des noms, des descriptions et des paramètres pour chaque outil exposé par un serveur MCP. Cette surcharge, que l'entreprise appelle la "taxe d'outil", représente les jetons utilisés lorsque le modèle considère des outils, même ceux qu'il n'utilisera jamais.

Okta explique que ces coûts apparaissent avant même qu'un agent ne tente d'appeler un outil. Ainsi, même si une demande est rejetée par la suite, les jetons de prompt déjà consommés ne peuvent être récupérés. Pour pallier ce problème, Okta propose un contrôle qui filtre la liste des outils avant qu'elle n'atteigne le modèle, en se basant sur les autorisations assignées à l'identité de l'agent et à l'utilisateur associé.

Réduction significative des outils visibles grâce à la modélisation interne

Dans ses analyses internes, Okta a observé que certains scénarios d'autorisation permettaient de réduire la visibilité des outils de plus de 90%. Bien que l'entreprise n'ait pas fourni de chiffres absolus en termes de jetons ou de coûts en dollars, elle a noté que les coûts des schémas d'outils diminuaient dans des proportions similaires.

Le surcoût des prompts lié aux schémas d'outils MCP

Les serveurs MCP sont devenus essentiels pour connecter les agents IA à divers outils et données. Okta cite des exemples de connexions à Google Workspace, Slack, et à des serveurs MCP internes. Un serveur MCP peut exposer un grand nombre d'outils, et chaque outil disponible est représenté dans le prompt à chaque tour.

Cette représentation inclut un schéma, le nom de l'outil, sa description et ses paramètres. Selon Okta, le coût s'accumule lorsque de nombreux outils sont exposés par un serveur MCP très utilisé. Chaque utilisateur actif subit ce surcoût de prompt chaque fois que son agent effectue un appel de modèle, posant un problème à la fois en termes de nombre d'outils et d'utilisateurs.

Le problème est également lié au contrôle d'accès. Un agent qui voit des outils en dehors de son champ d'autorisation peut tenter de les utiliser. Même si un contrôle rejette l'exécution, le modèle a déjà reçu la définition de l'outil et utilisé des jetons pour la traiter.

Filtrage des outils avant la construction du prompt

Okta positionne cette capacité dans son "plan pour l'entreprise agentique sécurisée", qui demande aux organisations d'identifier leurs agents, leurs connexions autorisées et leurs actions autorisées.

L'approche d'Okta réduit la question de connexion de l'accès à un serveur MCP entier à 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 alors l'ensemble d'outils ciblé au lieu du catalogue complet du serveur.

L'agent reçoit cette liste plus courte dans son prompt à chaque tour. Okta affirme qu'elle vérifie à nouveau le champ d'application à l'exécution avant qu'un appel d'outil ne soit exécuté.

Ce design applique un accès au moindre privilège au niveau des outils. L'entreprise déclare qu'un agent ne devrait pas être conscient des ressources, bases de données ou outils qu'il n'a pas été expressément autorisé à utiliser. La suppression des outils non disponibles du prompt élimine également leur coût de schéma de l'appel du modèle.

Okta ne décrit pas de déploiement client en direct dans le post. Ses preuves pour la réduction revendiquée proviennent de modélisations internes utilisant des données de produits Okta et de la documentation publique des fournisseurs, sans données clients utilisées.

Modélisation interne et rôles représentatifs

Okta a modélisé un seul client MCP avec accès à un catalogue d'outils d'entreprise. Elle a comparé le nombre d'outils visibles pour le modèle avant et après le ciblage basé sur l'identité.

Pour estimer l'exposition ciblée, l'entreprise a cartographié les outils du serveur Okta MCP aux portées OAuth qui les déverrouillent. Elle a ensuite défini des segments d'utilisateurs représentatifs, y compris des utilisateurs en lecture seule du service d'assistance et des opérateurs du service d'assistance.

D'autres segments comprenaient des administrateurs d'applications, des administrateurs de marque et d'e-mail, et des 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 un moins le ratio des outils ciblés par rapport aux outils non ciblés. Elle a déclaré que certains scénarios éliminaient plus de 90% des outils visibles. Son post indique que le coût en jetons des schémas d'outils suit le nombre d'outils presque de manière linéaire, car chaque outil contribue son nom, sa description et son schéma de paramètres à chaque prompt.

Okta affirme 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 des schémas, le volume des demandes et les prix des modèles affectent également les coûts absolus en jetons et en dollars.

Comparaison entre droits d'identité et contrôles de passerelle

Le post distingue le ciblage basé sur l'identité des contrôles de passerelle. Okta affirme que les passerelles peuvent limiter les dépenses par clé, équipe ou groupe, et peuvent prendre en charge le routage et la limitation du taux.

Une passerelle peut mesurer les jetons entrant et sortant d'un système, ainsi que les dollars dépensés. Okta indique que ces contrôles peuvent limiter les coûts après qu'une décision de modèle soit devenue coûteuse.

Les droits d'identité fournissent une entrée différente. Okta affirme 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 des informations d'accès au niveau du groupe.

Le compte d'Okta présente la passerelle comme un contrôle pour ce qui passe à travers elle. La couche d'identité filtre l'ensemble d'outils disponibles avant que ces outils n'aient besoin d'être mesurés.

Impact sur la sécurité et l'exposition aux attaques MCP

Le post lie 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 cette identité pourrait entreprendre si elle était compromise.

Le contrôle de portée proposé fonctionne à deux points. Le premier se produit lors de l'assemblage de la liste des outils pour le prompt de l'agent. Le second 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 restants exposés déterminent l'ensemble des actions disponibles pour cette identité. Dans le modèle de l'entreprise, le prompt ne contient que des outils associés aux portées OAuth autorisées de l'identité.

Pour les organisations évaluant l'accès MCP, l'inventaire des outils et la cartographie des droits sont les principales entrées opérationnelles. La méthodologie d'Okta cartographie les outils du serveur MCP aux portées OAuth qui les déverrouillent, puis compare le catalogue complet d'outils avec le catalogue ciblé visible pour chaque segment d'utilisateur représentatif.