Chaque appel de modèle d’un agent d’IA inclut un menu répertoriant tous les outils qu’il ou elle pourrait utiliser. Même celles qu’elle ne touchera jamais.
C’est vrai que l’agent se connecte à Google Workspace, à Slack ou à un serveur MCP interne auquel une centaine d’outils ont été ajoutés au fil des années. Chaque outil exposé par un serveur MCP est rendu dans l’invite du modèle sous forme de schéma, de nom, de description et de paramètres, et cela se produit à chaque tour. Vous devez payer pour que le modèle puisse raisonner sur cet outil, qu’il l’utilise effectivement ou non.
Nous appelons cela la taxe sur les outils. Et cela est resté invisible pour la plupart des équipes IA, car cela n’apparaît ni comme un appel rejeté ni comme un incident de sécurité. Cela apparaît comme une facture de tokens plus difficile à expliquer qu’elle ne devrait l’être.
Les agents d’IA sont aussi performants que les systèmes auxquels ils sont connectés.
Les serveurs MCP sont l’un des moyens à la croissance la plus rapide permettant aux entreprises de connecter des agents aux outils et aux données. Cette croissance a engendré une pression au sein des équipes IT : « tout doit être connecté à tout ». Les équipes déploient davantage de serveurs MCP, trop rapidement pour pouvoir les gérer efficacement, ce qui entraîne à la fois une exposition aux risques de sécurité et un problème de coûts.
Plus d’outils exposés par serveur signifie que davantage de tokens sont consommés par décision d’agent, rien que pour la sélection des outils, avant même que le moindre travail effectif ne soit réalisé. Un seul serveur MCP populaire peut compter des milliers d’utilisateurs actifs, et chacun d’eux paie le coût lié aux outils à chaque étape. Le problème du nombre d’outils et celui du nombre d’utilisateurs se cumulent.
Rejeter a posteriori un appel d’outil non autorisé ne permet pas de récupérer ces tokens. Elles étaient déjà utilisées lors de la phase de prompt, avant même que le modèle n’essaie quoi que ce soit. Et lorsqu’un agent utilise un outil auquel il ne devrait pas avoir accès, revenir en arrière devient un projet à part entière : une personne doit s’en apercevoir, enquêter, puis révoquer l’accès. Les tokens restent dépensés quoi qu’il arrive.
Définir le périmètre en amont signifie qu’il n’y a rien à récupérer par la suite.
Le plan directeur d’Okta pose une version plus précise de la question « à quoi peuvent-ils se connecter ? »
Le plan d’action pour l’entreprise agentique sécurisée demande à chaque organisation utilisant des agents d’IA de répondre à trois questions : où se trouvent mes agents, à quoi peuvent-ils se connecter et que peuvent-ils faire ?
Cette fonctionnalité découle directement de la deuxième question, à un niveau de détail plus fin que celui auquel la plupart des équipes pensent à vérifier. « À quoi peuvent-ils se connecter » ne fait pas seulement référence aux serveurs MCP qu’un agent peut atteindre, mais aussi aux outils spécifiques que cet agent est autorisé à utiliser pour un utilisateur donné.
Le principe du moindre privilège signifie qu’un agent ne doit jamais avoir connaissance de ressources, de bases de données ou d’outils pour lesquels il n’a pas reçu d’autorisation explicite. Éliminer les outils non autorisés pour sécuriser l’entreprise réduit également la surcharge liée aux outils.
Fonctionnement
Okta définit la liste des outils au moment où un agent se connecte à un serveur MCP. Dans le tableau de bord Okta, un administrateur configure les outils auxquels une identité donnée est autorisée à accéder. Okta renvoie alors uniquement l’ensemble filtré, plutôt que tout ce que le serveur expose.
Une liste plus courte est injectée dans le prompt de l’agent à chaque itération, ce qui implique une consommation de tokens réduite à chaque étape, avant même que l’agent n’initie un appel. Les outils non autorisés ne figurent pas dans la liste visible par le modèle, et le périmètre est vérifié à nouveau à l’exécution avant l’appel de tout outil.
Ce que cela représente
Limiter la liste des outils à ceux auxquels l’identité de l’agent est réellement autorisée à accéder permet d’éliminer la majeure partie du catalogue avant même qu’il n’atteigne le modèle. Dans des modélisations internes couvrant un éventail réaliste de niveaux d’autorisation, certains scénarios réduisent le nombre d’outils visibles de plus de 90 %. Le coût lié au schéma des outils, c’est-à-dire la part de la facture associée à la description des outils dans le prompt, diminue dans des proportions similaires.*
Pourquoi il s’agit d’un problème d’identité et d’autorisation, et non d’un problème de passerelle
Les passerelles plafonnent les dépenses par clé, équipe ou groupe, au niveau de détail le plus fin que leurs données permettent. C'est une véritable fonctionnalité, et pour le routage et la limitation du débit, c'est le bon niveau pour en avoir la maîtrise. Mais plafonner les dépenses a posteriori fait presque automatiquement de la personne responsable de la passerelle une sorte de police des jetons : il faut fixer les limites, les défendre lorsque des équipes contestent, et répondre lorsque des utilisateurs se retrouvent bloqués en pleine tâche. Ce n’est pas une défaillance de la passerelle. C’est ce qui se produit lorsque le seul levier dont vous disposez est un plafond de dépenses, et non une définition du périmètre.
Les gateways mesurent ce qui s’est déjà produit : tokens entrants, tokens sortants, dollars dépensés. Elles peuvent limiter les dégâts lorsque la décision devient coûteuse. Ils ne peuvent pas empêcher la décision d’être coûteuse à l’origine, car les informations au niveau du groupe ne leur permettent pas de savoir à quoi un agent spécifique, ou la personne derrière cet agent, a réellement le droit d’accéder.
La couche d’identités le peut. Avec des droits attribués par utilisateur et par agent plutôt que par appartenance à un groupe, Okta filtre une liste d’outils avec une précision à laquelle les gateways n’ont pas accès. La passerelle mesure ce qui passe. La couche d’identités réduit ce qu’il reste à mesurer, ce qui limite d’autant la surveillance nécessaire.
Le contrôle des coûts pour les agents s’effectue de manière optimale à l’aide d’outils de gouvernance des identités qui offrent un contrôle plus granulaire, et une plus grande précision, sans perturber les processus de l’entreprise. L’approche d’Okta est une solution élégante pour y parvenir, car elle exploite les mêmes données d’habilitation qui régissent la sécurité, et non une couche de mesure distincte dépourvue de cette visibilité, explique Paul Webber, analyste principal du secteur cybersécurité chez Software Analyst Cyber Research.
L’essentiel
Le coût n’est qu’un aspect de cette question. Supprimer des outils et une identité qui n’est pas autorisée à les utiliser élimine également ce que cette identité pourrait faire en cas de compromission. La même définition du périmètre qui permet de garder l’invite concise limite également l’ampleur des conséquences en cas d’incident.
Le principe du moindre privilège appliqué au MCP réduit à la fois le nombre de tokens qu’un modèle doit prendre en compte et les dégâts qu’un attaquant pourrait causer avec les outils restants.
Hagan ne s'arrête pas là. Consultez notre simulateur d’IA pour exécuter des scénarios d’attaque réels, évaluer votre couverture, mettre en évidence les lacunes en matière de sécurité et comprendre dans quelle mesure les différents contrôles permettent de réduire les risques et l’impact d’éventuelles compromissions.
*Méthodologie. Les chiffres de réduction présentés dans cette publication proviennent de modélisations internes d’Okta, réalisées uniquement à partir des données produits d’Okta et de la documentation publique des fournisseurs. Aucune donnée client n’a été utilisée. Nous avons modélisé un seul client MCP ayant accès à un catalogue d’outils d’entreprise, puis comparé le nombre d’outils visibles pour le modèle avant et après la limitation basée sur l’identité. La réduction du nombre d’outils est calculée comme un moins le ratio des outils dans le périmètre sur les outils hors périmètre. Pour estimer l’exposition par périmètre, nous avons associé les outils Okta MCP Server aux scopes OAuth qui les activent, défini des segments d’utilisateurs et d’utilisatrices représentatifs (support en lecture seule, opérateur support, administrateur d’application, administrateur de la marque et des e-mails, et super administrateur), puis pondéré chaque segment selon une part estimée du trafic mensuel. Le coût des tokens du schéma d’outil évolue de façon presque linéaire avec le nombre d’outils, car chaque outil ajoute un nom, une description et un schéma de paramètres à l’invite à chaque itération. Ainsi, toute réduction en pourcentage du coût du schéma correspond étroitement à une réduction en pourcentage du nombre d’outils. Les montants absolus en tokens et en dollars dépendent de la taille moyenne du schéma, du volume de requêtes et de la tarification du modèle, des éléments qui varient selon le déploiement. C’est pourquoi cette publication indique les réductions en pourcentage plutôt qu’en dollars. Les résultats réels varient selon votre catalogue d’outils, la répartition des autorisations et le modèle choisi.
