La vague de l’IA agentique s’accélère rapidement. Ce qui a commencé comme des chatbots équipés d’outils simples évolue maintenant vers des travailleurs numériques autonomes qui sont profondément intégrés dans les flux de travail de l’entreprise.
Au fur et à mesure que ces déploiements arrivent à maturité, une lacune critique en matière de sécurité devient de plus en plus évidente.
De nombreuses architectures d’agents actuelles reposent encore sur ce que l’on peut décrire comme un modèle de clé divine, dans lequel des informations d’identification générales et durables regroupent l’identité de l’utilisateur, l’autorisation et l’accès aux outils en un seul secret partagé.
Cette approche n’est pas sûre.
Pour les entreprises qui souhaitent rendre les agents opérationnels à grande échelle, il est nécessaire de passer à une délégation d’identité et à des mécanismes de mise en œuvre tenant compte de l’intelligence artificielle.
Vous trouverez ci-dessous un examen approfondi du problème réel et de ce qu’implique une solution de niveau de production.
1. Le vrai risque : des identifiants d’agents trop privilégiés
Dans les premiers déploiements d’agents, tels que les outils de type LangChain, les serveurs MCP personnalisés et les passerelles d’outils internes, l’authentification est souvent gérée à l’aide d’identifiants de service statiques :
- clés API à longue durée de vie
- comptes de services partagés
- les informations d’identification du client OAuth au sens large
- ou des identités de charge de travail grossières
Pour clarifier, MCP lui-même ne nécessite pas de clés statiques. Le protocole prend en charge les modèles OAuth et d’identité déléguée. Toutefois, dans le monde réel, de nombreux agents utilisent encore des identifiants surdimensionnés et non liés à l’utilisateur pour communiquer avec des serveurs MCP individuels.
C’est la source du risque.
Le problème de l’identité partagée (attribution entre utilisateurs)
Considérons un scénario dans lequel :
- 50 employés utilisent un seul agent marketing
- l’agent appelle GitHub à l’aide d’un identifiant de service
Dans cette configuration, les journaux de GitHub indiqueraient simplement : Agent_Service_Account a supprimé le repo X.
Ce qui manque :
- l’homme qui a initié l’action
- si l’utilisateur a été autorisé
- si l’action était attendue
Du point de vue de l’audit et de la criminalistique, l’attribution est perdue. Il ne s’agit pas d’un défaut de MCP, mais plutôt d’une lacune dans la propagation de l’identité présente dans de nombreux déploiements d’agents.
Le problème des autorisations trop larges (portée transversale)
Prenons l’exemple d’un serveur MCP qui expose plusieurs outils :
- lire_fichier
- liste_fichiers
- supprimer_fichier
Si l’agent s’authentifie à l’aide d’un justificatif d’identité unique et à large portée, toute injection d’invite réussie ou tout comportement erroné de l’agent pourrait potentiellement invoquer des outils à plus haut risque. Bien que MCP permette aux serveurs d’appliquer l’autorisation par outil, de nombreux services MCP sont aujourd’hui principalement axés sur la fonctionnalité des outils et ne sont pas conçus pour servir de points d’application de la politique d’entreprise complète.
Cela crée une lacune architecturale importante.
2. La réalité architecturale : Les serveurs MCP ne sont pas des passerelles ZTNA
Dans la plupart des entreprises, les applications internes ne sont pas censées mettre en œuvre elles-mêmes une logique complète d’authentification, d’autorisation et de politique de risque. Au lieu de cela, cette responsabilité est généralement centralisée dans une couche d’accès au réseau sans confiance (ZTNA) qui se trouve devant les applications de l’entreprise.
Les services MCP doivent être considérés de la même manière.
Dans la pratique, de nombreux serveurs MCP :
- se concentrer sur l’exécution de l’outil
- confiance en amont de l’identité
- mettre en œuvre une authentification grossière ou au niveau du service
- manque de modèles profonds de politique des utilisateurs/groupes
- n’effectuez pas d’échange de jetons
- ne sont pas conçues pour prendre des décisions rapides en matière de risque
Attendre de chaque serveur MCP qu’il joue le rôle d’un moteur d’application Zero Trust complet n’est ni réaliste ni évolutif.
3. Pourquoi le ZTNA est le point de contrôle naturel
ZTNA joue déjà un rôle bien établi dans la sécurité des entreprises :
- fronting des applications internes
- centralisation de l’authentification
- l’application des politiques d’accès
- fournir un plan de contrôle unique
- réduire la charge des équipes chargées des applications
En appliquant ce modèle aux services MCP, les organisations disposent d’une approche unifiée pour protéger à la fois les applications traditionnelles et l’accès aux outils pilotés par l’IA.
Une façon cohérente de protéger à la fois les applications traditionnelles et l’accès aux outils pilotés par l’IA.
Cependant, l’IA introduit une nouvelle exigence pour les solutions ZTNA.
4. Le ZTNA traditionnel ne tient pas compte du comportement de l’IA
Les solutions ZTNA traditionnelles fondent leurs décisions sur des facteurs tels que
- l’identité de l’utilisateur
- posture du dispositif
- contexte du réseau
- identité de l’application
La circulation de l’IA agentique ajoute de nouvelles dimensions au risque, comme par exemple :
- l’outil MCP invoqué
- quels sont les arguments transmis
- si la demande a été générée par une invite
- si l’action présente un risque élevé
- si l’utilisateur est autorisé à utiliser cet outil spécifique
Les solutions ZTNA traditionnelles ne peuvent pas voir ou appliquer les contrôles à cette couche. Pour faire face en toute sécurité aux services MCP, ZTNA doit être conscient du protocole MCP et de l’intelligence artificielle.
Il ne s’agit pas de remplacer ZTNA, mais de le faire évoluer.
ZTNA compatible avec MCP : l’évolution nécessaire
Le ZTNA traditionnel reste la porte d’entrée architecturale correcte pour les applications d’entreprise, y compris les services MCP. La centralisation du contrôle d’accès en dehors de l’application s’est avérée évolutive, vérifiable et efficace sur le plan opérationnel.
Cependant, les flux de travail pilotés par des agents introduisent deux nouvelles exigences pour lesquelles le ZTNA classique n’a pas été conçu :
l’identité déléguée au niveau de l’utilisateur pour l’exécution de l’outil
visibilité au niveau du protocole de l’activité de l’outil MCP
Le respect de ces exigences ne remplace pas ZTNA, il le fait évoluer.
Une couche ZTNA tenant compte des MCP étend le modèle traditionnel de confiance zéro dans deux dimensions essentielles : la délégation d’identité et l’autorisation tenant compte du protocole.
Identité déléguée : Pourquoi l’échange de jetons est nécessaire
Lorsqu’un agent d’intelligence artificielle invoque un outil MCP, le service en aval doit être en mesure de répondre à une question fondamentale :
Au nom de quel être humain cette action est-elle effectuée ?
Transmettre un jeton d’utilisateur large et à longue durée de vie directement à chaque service MCP n’est ni sûr ni évolutif. Cela crée une propagation excessive de la confiance et augmente le rayon d’action en cas d’utilisation abusive d’un jeton.
Au lieu de cela, les architectures modernes de confiance zéro utilisent l’identité déléguée.
Dans ce modèle :
- l’utilisateur s’authentifie auprès de l’IdP de l’entreprise
- l’agent propage l’identité de l’utilisateur
- la couche d’application ZTNA valide l’utilisateur
- la couche d’exécution procède à l’échange de jetons
- un titre de créance de courte durée et de portée limitée est créé pour le service MCP spécifique
Cette approche garantit que les services en aval ne reçoivent que l’autorité minimale requise pour l’opération demandée.
L’échange de jetons par délégation permet également aux entreprises de :
- mettre en œuvre des contrôles cohérents de la durée de vie
- normaliser les publics
- réduire le rayon d’action du jeton
- et maintenir l’attribution complète à l’utilisateur
Mais l’identité seule ne suffit pas.
Pourquoi la sensibilisation au protocole MCP est-elle importante ?
Même avec une identité parfaite, le ZTNA traditionnel manque encore de visibilité sur ce que fait réellement l’agent.
Du point de vue du réseau, le trafic MCP apparaît souvent comme du HTTPS standard. Sans connaissance du protocole, la couche d’application ne peut pas voir :
- l’outil MCP invoqué
- quels sont les arguments transmis
- si l’action présente un risque élevé
- si l’utilisateur est autorisé à utiliser cet outil spécifique
C’est le principal angle mort.
Une couche ZTNA sensible aux MCP comprend une analyse approfondie du protocole qui permet d’extraire des données :
- nom de l’outil
- arguments de l’outil
- contexte de la session
- réclamations des utilisateurs
Ces signaux permettent de mettre en place des politiques d’autorisation fines et sensibles à l’IA, qui vont bien au-delà des simples décisions d’accès aux applications.
Ce n’est qu’une fois que la délégation d’identité et l’inspection au niveau MCP sont en place qu’une véritable application du principe de moindre privilège peut être réalisée pour les flux de travail agentiques.
Détail critique de mise en œuvre : Les agents doivent propager l’identité de l’utilisateur
Pour que l’identité déléguée fonctionne de bout en bout, le moteur d’exécution de l’agent doit propager activement les informations relatives à l’identité de l’utilisateur. Dans de nombreux déploiements actuels, l’utilisateur est authentifié en amont (par exemple, à l’aide de ZTNA et d’OIDC), mais les appels d’outils en aval sont toujours effectués à l’aide d’informations d’identification de service statiques. Dans ce cas, l’attribution de l’utilisateur est perdue et les contrôles du moindre privilège sont interrompus.
Pour permettre la confiance zéro en matière d’IA, l’agent ou le cadre d’agent doit s’assurer que les demandes de MCP ou d’outils sortants comportent un justificatif d’identité vérifiable et lié à l’utilisateur vers AI>Secure. Cette capacité n’est pas automatique dans la plupart des cadres d’agents et nécessite généralement une configuration explicite et, dans certains cas, des modifications mineures du code.
Modèle de production recommandé : Collecteurs à double identité
Dans les déploiements d’AI>Secure en production, les demandes comprennent généralement deux identités vérifiables de manière indépendante :
Identité de l’agent :
Autorisation : Bearer
Identité de l’utilisateur :
X-AI-User-Assertion :
Délégué en amont :
Autorisation : Bearer
Les deux jetons sont validés indépendamment par AI>Secure avant toute évaluation de la politique.
Ce qui change dans l’agent (minimal)
La plupart des cadres d’agents ne nécessitent que des modifications mineures pour prendre en charge ce modèle :
- pointez le point d’extrémité MCP sur AI>Secure
- continuer à envoyer le JWT de l’agent existant
- ajouter un en-tête sortant contenant le JWT de l’utilisateur
Les cadres modernes comme OpenClaw prennent généralement en charge les en-têtes sortants personnalisés, ce qui facilite la transition. Aucune modification du protocole MCP n’est nécessaire.
Comment AI>Secure applique le principe du moindre privilège
Lorsqu’une demande parvient à AI>Secure, les étapes suivantes se déroulent :
- L’identité de l’agent est validée
- L’identité de l’utilisateur est validée
- Le trafic MCP est analysé
- La politique à grain fin est évaluée
- AI>Secure procède à un échange de jetons
- Un jeton délégué de courte durée est envoyé en amont.
Avant de transmettre la demande, AI>Secure supprime les informations d’identification originales et les injecte :
Autorisation : Bearer
Cela garantit que le serveur MCP ne reçoit qu’une identité correctement délimitée.
Avec quoi AI>Secure doit-il être configuré ?
Authentification en amont par serveur MCP
Pour chaque serveur MCP, AI>Secure est configuré avec la méthode d’authentification en amont appropriée :
- Porteur OAuth
- Clé API
- mTLS
- autres méthodes soutenues
Politiques d’autorisation à granularité fine
Les politiques AI>Secure sont capables d’assurer la mise en œuvre :
- outil permettant/refusant les règles
- inspection des arguments
- contrôle des utilisateurs/groupes
- conditions fondées sur le risque
Configuration du courtier en identité
Le courtier en identité AI>Secure s’occupe des tâches suivantes :
- validation des jetons d’utilisateur entrants
- vérification de l’émetteur et du public
- Réalisation d’un échange de jetons OAuth
- la frappe de jetons délégués à courte durée de vie
- les jetons de cadrage vers le service MCP cible
- l’application des limites de durée de vie
- la transformation éventuelle des revendications
Grâce à ces mécanismes, les serveurs MCP ne reçoivent que des informations d’identification de moindre privilège et ne sont pas tenus de mettre en œuvre eux-mêmes une logique d’identité complexe.
Le bilan
Le problème n’est pas une faille dans le protocole MCP. Le problème principal est que de nombreux déploiements d’agents anciens (ou même actuels) s’appuient sur des informations d’identification qui sont surprivilégiées et qui ne sont pas correctement attribuées. Ces identifiants accordent des permissions excessives et ne permettent pas d’identifier clairement l’utilisateur ou l’agent qui a effectué une action spécifique. En conséquence, les services MCP doivent appliquer des contrôles de sécurité et des politiques d’accès pour lesquels ils n’ont jamais été conçus, ce qui fait peser une charge excessive sur leurs implémentations.
En plaçant une couche ZTNA consciente de l’IA devant les services MCP, les entreprises peuvent :
- centraliser le contrôle d’accès
- préserver l’attribution des utilisateurs
- appliquer le moindre privilège par outil
- éviter de surcharger les implémentations de services MCP
Les organisations qui adaptent leur architecture de confiance zéro à l’ère de l’IA seront les mieux placées pour faire évoluer en toute sécurité leurs employés numériques. À l’ère des agents autonomes, la confiance zéro doit s’étendre au-delà des personnes autorisées à se connecter – à ce que l’IA est réellement autorisée à faire.