Les agents IA passent rapidement des démos de recherche aux applications d'entreprise réelles, connectant les grands modèles de langage (LLM) aux données et services de l'entreprise. Une approche courante consiste à utiliser des outils ou des plugins pour permettre à un LLM de récupérer du contexte ou d'effectuer des actions – mais certains les considèrent comme de simples « appels API glorifiés ». En réalité, l'intégration sécurisée de l'IA avec les systèmes métier est bien plus complexe. C'est là qu'intervient le Model Context Protocol (MCP), et pourquoi une architecture proxy robuste avec identité OpenID Connect (OIDC) est cruciale pour les déploiements à l'échelle de l'entreprise.
\n\ngraph TB\n User[Utilisateur] --> |interagit avec| AIAgent[Agent IA]\n AIAgent --> |requêtes MCP| Proxy[Passerelle API/Proxy]\n Proxy --> |authentifie via| OIDC[Fournisseur d'identité/OIDC]\n Proxy --> |route vers| Tools[Outils/Serveurs MCP]\n Tools --> |accède à| Backend[Systèmes Backend]\n \n subgraph \"Périmètre de sécurité\"\n Proxy\n OIDC\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,OIDC security;\nLe diagramme ci-dessus illustre l'architecture de haut niveau d'une implémentation MCP sécurisée. Au cœur de cette architecture se trouve une passerelle API/Proxy comme point de contrôle de sécurité central entre les agents IA et les outils MCP. Le proxy fonctionne en conjonction avec un fournisseur d'identité supportant OIDC pour créer un périmètre de sécurité qui applique l'authentification, l'autorisation et les contrôles d'accès. Cela garantit que toutes les requêtes MCP des agents IA sont correctement authentifiées et autorisées avant d'atteindre les outils MCP réels, qui à leur tour accèdent à divers systèmes backend.
\n\nMCP est un standard ouvert (initialement introduit par Anthropic) qui fournit un moyen cohérent pour les assistants IA d'interagir avec des sources de données et des outils externes. Au lieu d'intégrations sur mesure pour chaque système, MCP agit comme un connecteur universel, permettant aux modèles IA de récupérer du contexte ou d'exécuter des tâches via une interface JSON-RPC standardisée. Fait important, MCP a été conçu avec la sécurité à l'esprit – rien n'est exposé à l'IA par défaut, et elle n'obtient accès qu'à ce que vous autorisez explicitement. En pratique, cependant, garantir ce principe de « liste d'autorisation » à travers de nombreux outils et utilisateurs nécessite une infrastructure soignée. Une passerelle API (proxy) de qualité production peut servir de gardien entre les agents IA (clients MCP) et les outils ou sources de données (serveurs MCP), appliquant les règles d'authentification, d'autorisation et de routage.
\n\nAvant de plonger dans la solution, une note rapide sur Envoy : il existe des propositions actives pour utiliser Envoy Proxy comme implémentation de référence d'une passerelle MCP. Le routage L7 riche d'Envoy et son extensibilité en font un candidat solide, et il pourrait bientôt inclure un support MCP de première classe. Cela dit, le modèle que nous discutons ici est agnostique du proxy – tout proxy inverse HTTP moderne ou passerelle API (Envoy, NGINX, HAProxy, Kong, etc.) offrant des capacités similaires peut être utilisé. L'objectif est de décrire une architecture sécurisée pour MCP, plutôt que les spécificités de la configuration d'Envoy.
\n\nÀ première vue, utiliser un outil IA via MCP pourrait sembler aussi simple qu'appeler une API web. Dans une démo basique, un agent LLM pourrait interroger un endpoint REST, obtenir du JSON, et c'est tout. Mais dans un scénario d'entreprise réel, beaucoup plus se passe en coulisses :
\n\ngraph LR\n subgraph \"Appel API simple\"\n A[Client] -->|Requête| B[API]\n B -->|Réponse| A\n end\n \n subgraph \"Réalité MCP d'entreprise\"\n C[Utilisateur] -->|Interagit| D[Agent IA]\n D -->|Requête MCP avec identité| E[Passerelle API]\n E -->|Valider le jeton| F[Fournisseur d'identité]\n E -->|Router la requête| G[Registre d'outils]\n E -->|Requête autorisée| H[Outil MCP]\n H -->|Requête avec contexte utilisateur| I[Système Backend]\n I -->|Données| H\n H -->|Réponse| E\n E -->|Réponse filtrée| D\n D -->|Résultat| C\n \n J[Surveillance de sécurité] -..->|Audit| E\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class E,F,G,J security;\nCe diagramme contraste un simple appel API avec la réalité complexe des implémentations MCP d'entreprise. Dans le cas simple, un client fait une requête directe à une API et reçoit une réponse. Cependant, dans la réalité MCP d'entreprise, le flux est beaucoup plus complexe :
\n\nTout au long de ce processus, les systèmes de surveillance de sécurité auditent les interactions au niveau de la passerelle. Ce flux complet garantit que l'identité de l'utilisateur, les permissions et les politiques de sécurité sont appliquées à chaque étape, bien au-delà de ce qu'un simple appel API impliquerait.
\n\nEn bref, une entreprise doit traiter les intégrations d'outils IA avec la même rigueur que toute intégration de service de production – sinon plus. Une couche de passerelle appropriée aide à répondre à ces préoccupations en agissant comme un point de contrôle central. Au lieu de coder en dur la confiance dans chaque agent IA ou outil, le proxy impose des politiques de sécurité à l'échelle de l'organisation. Cette approche nous fait passer au-delà de la mentalité « juste appeler une API » vers un modèle structuré où chaque appel MCP est authentifié, autorisé, surveillé et audité.
\n\nExaminons quelques défis de sécurité spécifiques qui surviennent lors du déploiement de MCP à grande échelle, et pourquoi ils importent :
\n\ngraph TD\n A[Empoisonnement du contexte] --> |atténué par| B[Filtrage de contenu]\n A --> |atténué par| C[Vérification d'outil]\n \n D[Propagation d'identité] --> |résolu avec| E[Auth basée sur jetons]\n D --> |résolu avec| F[Chaînes de délégation]\n \n G[Provisionnement dynamique d'outils] --> |géré par| H[Registre d'outils]\n G --> |géré par| I[Workflows d'approbation]\n G --> |géré par| J[Suivi de versions]\n \n K[Changements MCP distants] --> |contrôlé par| L[Gouvernance du proxy]\n \n subgraph \"Contrôles de sécurité du proxy\"\n B\n C\n E\n F\n H\n I\n J\n L\n end\n \n classDef challenge fill:#f66,stroke:#333,stroke-width:2px;\n classDef solution fill:#6f6,stroke:#333,stroke-width:2px;\n \n class A,D,G,K challenge;\n class B,C,E,F,H,I,J,L solution;\nCe diagramme cartographie les défis de sécurité clés dans les workflows MCP (en rouge) vers leurs solutions correspondantes (en vert) qui peuvent être implémentées dans les contrôles de sécurité du proxy. Le diagramme illustre comment :
\n\nEn implémentant ces contrôles dans la couche proxy, les organisations peuvent aborder ces défis de sécurité de manière centralisée et cohérente plutôt que d'essayer de les résoudre individuellement pour chaque outil ou agent.
\n\nsequenceDiagram\n participant User as Utilisateur\n participant AIAgent as Agent IA\n participant Proxy as Passerelle API\n participant IdP as Fournisseur d'identité\n participant Tool as Outil MCP\n participant Backend as Système Backend\n \n User->>IdP: 1. Authentifier (nom d'utilisateur/mot de passe)\n IdP->>User: 2. Émettre jeton OIDC\n User->>AIAgent: 3. Interagir avec l'IA (jeton attaché)\n AIAgent->>Proxy: 4. Requête MCP avec jeton\n Proxy->>IdP: 5. Valider le jeton\n IdP->>Proxy: 6. Jeton valide, contient claims/scopes\n \n alt Jeton valide avec permissions requises\n Proxy->>Tool: 7. Transmettre requête avec contexte utilisateur\n Tool->>Backend: 8. Requête avec auth déléguée\n Backend->>Tool: 9. Retourner données (filtrées par permissions utilisateur)\n Tool->>Proxy: 10. Retourner résultat\n Proxy->>AIAgent: 11. Retourner réponse autorisée\n AIAgent->>User: 12. Présenter résultat\n else Jeton invalide ou permissions insuffisantes\n Proxy->>AIAgent: 7. Rejeter requête (401/403)\n AIAgent->>User: 8. Signaler accès refusé\n end\nCe diagramme de séquence illustre le flux d'authentification et d'autorisation dans un système MCP utilisant OIDC. Le processus commence avec l'utilisateur s'authentifiant auprès d'un fournisseur d'identité et recevant un jeton OIDC. Ce jeton est ensuite attaché aux interactions de l'utilisateur avec l'agent IA. Quand l'agent fait une requête MCP, il inclut ce jeton, que la passerelle API valide avec le fournisseur d'identité.
\n\nSi le jeton est valide et contient les permissions nécessaires (claims/scopes), la requête est transmise à l'outil MCP approprié avec le contexte de l'utilisateur. L'outil peut alors interroger les systèmes backend en utilisant l'authentification déléguée, garantissant que les données retournées sont filtrées selon les permissions de l'utilisateur. Le résultat remonte à travers le système vers l'utilisateur.
\n\nSi le jeton est invalide ou manque de permissions suffisantes, la requête est rejetée au niveau de la passerelle avec un code d'erreur approprié (401 Non autorisé ou 403 Interdit), et l'agent IA signale ce refus d'accès à l'utilisateur.
\n\nCe flux garantit que l'identité et les permissions de l'utilisateur sont appliquées de manière cohérente tout au long de la chaîne d'interaction, empêchant l'accès non autorisé à des données ou opérations sensibles.
\n\nsequenceDiagram\n participant Admin as Administrateur\n participant Registry as Registre d'outils\n participant Proxy as Passerelle API\n participant Tool as Nouvel outil MCP\n participant AIAgent as Agent IA\n \n Admin->>Tool: 1. Développer nouvel outil MCP\n Admin->>Registry: 2. Enregistrer outil (métadonnées, endpoints, exigences auth)\n Registry->>Registry: 3. Valider configuration outil\n Registry->>Proxy: 4. Mettre à jour configuration routage\n \n Note over Registry,Proxy: L'outil est maintenant enregistré mais pas encore approuvé\n \n Admin->>Registry: 5. Approuver outil pour groupes d'utilisateurs spécifiques\n Registry->>Proxy: 6. Mettre à jour politiques d'accès\n \n Note over AIAgent,Proxy: L'outil est maintenant disponible aux utilisateurs autorisés\n \n AIAgent->>Proxy: 7. Découvrir outils disponibles\n Proxy->>AIAgent: 8. Retourner outils approuvés pour l'utilisateur\n AIAgent->>Proxy: 9. Appeler nouvel outil\n Proxy->>Tool: 10. Router requête si autorisé\nCe diagramme de séquence illustre le workflow d'enregistrement et d'approbation d'outils dans un environnement MCP sécurisé. Le processus commence avec un administrateur développant un nouvel outil MCP et l'enregistrant dans le registre d'outils, fournissant métadonnées, endpoints et exigences d'authentification. Le registre valide la configuration de l'outil et met à jour la configuration de routage dans la passerelle API.
\n\nÀ ce stade, l'outil est enregistré mais pas encore approuvé pour utilisation. L'administrateur doit explicitement approuver l'outil pour des groupes d'utilisateurs spécifiques, ce qui déclenche une mise à jour des politiques d'accès dans la passerelle API. Ce n'est qu'alors que l'outil devient disponible aux utilisateurs autorisés.
\n\nQuand un agent IA découvre les outils disponibles via le proxy, il ne reçoit que des informations sur les outils qui ont été approuvés pour l'utilisateur actuel. Quand l'agent appelle le nouvel outil, le proxy route la requête vers l'outil seulement si l'utilisateur est autorisé à y accéder.
\n\nCe workflow garantit que les nouveaux outils subissent une vérification et une approbation appropriées avant de pouvoir être utilisés, et que l'accès est restreint aux seuls utilisateurs autorisés. Il centralise également le processus de gouvernance des outils, facilitant la gestion du cycle de vie des outils MCP de manière sécurisée.
\n\nEn reconnaissant ces défis, les ingénieurs et architectes de sécurité peuvent concevoir des défenses avant que les problèmes ne surviennent. Nous examinons ensuite comment un proxy conscient de l'identité peut fournir ces défenses de manière propre et centralisée.
\n\nUne conception éprouvée dans les architectures cloud consiste à placer un proxy inverse (souvent appelé passerelle API) devant vos services. Les systèmes IA basés sur MCP ne font pas exception. En introduisant un proxy intelligent entre les agents IA (clients) et les serveurs MCP (outils/backends), nous créons un entonnoir contrôlé par lequel tout le trafic d'outils IA passe. Ce proxy peut opérer à la couche 7 (couche application), ce qui signifie qu'il comprend HTTP et même les charges utiles JSON, permettant un contrôle fin. Ci-dessous, nous décrivons les rôles clés qu'un tel proxy joue dans la sécurisation de MCP :
\n\ngraph TB\n subgraph \"Côté client\"\n User[Utilisateur]\n AIAgent[Agent IA]\n User -->|interagit| AIAgent\n end\n \n subgraph \"Couche de sécurité\"\n Proxy[Passerelle API/Proxy]\n Auth[Authentification]\n RBAC[Autorisation/RBAC]\n Registry[Registre d'outils]\n Audit[Journalisation d'audit]\n \n Proxy -->|utilise| Auth\n Proxy -->|applique| RBAC\n Proxy -->|consulte| Registry\n Proxy -->|génère| Audit\n end\n \n subgraph \"Outils MCP\"\n Tool1[Recherche de documents]\n Tool2[Requête base de données]\n Tool3[Opérations fichiers]\n Tool4[API externe]\n end\n \n subgraph \"Systèmes Backend\"\n DB[(Bases de données)]\n Storage[Stockage fichiers]\n APIs[APIs internes]\n External[Services externes]\n end\n \n AIAgent -->|requêtes MCP| Proxy\n Proxy -->|route vers| Tool1\n Proxy -->|route vers| Tool2\n Proxy -->|route vers| Tool3\n Proxy -->|route vers| Tool4\n \n Tool1 -->|lit| DB\n Tool1 -->|lit| Storage\n Tool2 -->|interroge| DB\n Tool3 -->|gère| Storage\n Tool4 -->|appelle| APIs\n Tool4 -->|appelle| External\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,Auth,RBAC,Registry,Audit security;\nCe diagramme fournit une vue détaillée du pattern de proxy conscient de l'identité pour MCP. L'architecture est divisée en quatre couches principales :
\n\nToutes les requêtes MCP des agents IA doivent passer par le proxy, qui authentifie les requêtes, applique les politiques RBAC, consulte le registre d'outils pour déterminer le routage, et génère des journaux d'audit. Le proxy route ensuite les requêtes autorisées vers les outils MCP appropriés, qui à leur tour interagissent avec les systèmes backend.
\n\nCette architecture de sécurité centralisée garantit l'application cohérente des politiques de sécurité à travers toutes les interactions MCP, indépendamment des outils utilisés ou des systèmes backend accédés.
\n\nContrairement à un simple appel API sans état, les sessions MCP peuvent être de longue durée et impliquer du streaming (Server-Sent Events pour la sortie, etc.). Le proxy devrait s'assurer que toutes les requêtes et réponses appartenant à une session ou conversation donnée sont gérées de manière cohérente. Cela signifie souvent implémenter l'affinité de session – si plusieurs instances d'un serveur MCP sont en cours d'exécution, le proxy routera le trafic d'une session donnée vers la même instance à chaque fois. Cela évite les problèmes où, par exemple, l'état de l'outil A (cache en mémoire, fenêtre de contexte, etc.) est perdu parce que la requête 2 est allée vers une instance différente de la requête 1. Les proxies modernes peuvent faire de l'équilibrage de charge conscient de session en utilisant des en-têtes HTTP ou des routes (par exemple, mapper un ID de session ou un ID client dans l'URL vers un backend particulier). De plus, le proxy peut gérer les connexions SSE avec élégance, de sorte que les réponses en streaming ne soient pas accidentellement cassées par des intermédiaires réseau. Si une session doit être reprise ou transférée, la passerelle peut coordonner cela (comme proposé dans les fonctionnalités Envoy à venir pour MCP). En bref, le proxy garantit la fiabilité et la cohérence pour les interactions avec état de MCP, ce qui est crucial pour l'expérience utilisateur et pour maintenir un contexte correct.
\n\nsequenceDiagram\n participant User as Utilisateur\n participant AIAgent as Agent IA\n participant Proxy as Passerelle API\n participant Instance1 as Instance outil 1\n participant Instance2 as Instance outil 2\n \n User->>AIAgent: Démarrer conversation\n AIAgent->>Proxy: Requête MCP 1 (session=abc123)\n \n Note over Proxy: Routage par affinité de session\n \n Proxy->>Instance1: Router vers instance 1\n Instance1->>Proxy: Réponse avec état\n Proxy->>AIAgent: Retourner réponse\n \n User->>AIAgent: Continuer conversation\n AIAgent->>Proxy: Requête MCP 2 (session=abc123)\n \n Note over Proxy: Même ID de session route vers même instance\n \n Proxy->>Instance1: Router vers instance 1 (préserve l'état)\n Instance1->>Proxy: Réponse avec état mis à jour\n Proxy->>AIAgent: Retourner réponse\n \n Note over User,Instance2: Sans affinité de session, la requête pourrait aller vers instance 2 et perdre l'état\nCe diagramme de séquence illustre comment l'affinité de session fonctionne dans un environnement MCP. Quand un utilisateur démarre une conversation avec un agent IA, l'agent fait une requête MCP à la passerelle API avec un identifiant de session (dans ce cas, \"abc123\"). La passerelle utilise cet ID de session pour router la requête vers une instance d'outil spécifique (Instance 1).
\n\nQuand l'utilisateur continue la conversation, l'agent fait une autre requête MCP avec le même ID de session. Parce que la passerelle implémente l'affinité de session, elle route cette requête vers la même instance (Instance 1), qui préserve l'état de l'interaction précédente. Cela garantit une expérience cohérente et cohérente pour l'utilisateur.
\n\nSans affinité de session, la deuxième requête pourrait être routée vers une instance différente (Instance 2), qui n'aurait pas les informations d'état de la première requête. Cela résulterait en une expérience cassée, car l'outil n'aurait pas le contexte de l'interaction précédente.
\n\nL'affinité de session est particulièrement importante pour MCP car de nombreuses interactions IA sont avec état et dépendantes du contexte. La capacité du proxy à maintenir cette cohérence de session est un avantage clé par rapport aux approches d'intégration API plus simples.
\n\nChaque requête atteignant la passerelle MCP devrait porter un jeton d'identité valide – typiquement un JSON Web Token (JWT) émis par un fournisseur d'identité via OIDC (OpenID Connect). En exigeant des JWT, le proxy décharge l'authentification des outils eux-mêmes et garantit que seuls les appels authentifiés et autorisés passent. En pratique, cela signifie que l'agent IA (ou la session de l'utilisateur avec l'agent) doit obtenir un jeton OIDC (par exemple, un jeton ID ou un jeton d'accès) et l'attacher à chaque requête MCP (souvent dans un en-tête HTTP comme Authorization: Bearer <token>). Le proxy vérifie ce jeton, vérifie la signature et les claims (émetteur, audience, expiration, etc.), et rejette toute requête qui n'est pas correctement authentifiée. De cette façon, vos serveurs MCP ne voient jamais un appel anonyme – ils font confiance à la passerelle pour avoir vérifié l'identité.
sequenceDiagram\n participant User as Utilisateur\n participant App as Application IA\n participant IdP as Fournisseur d'identité\n participant Proxy as Passerelle API\n participant Tool as Outil MCP\n \n User->>App: Accéder à l'application IA\n App->>IdP: Rediriger vers connexion\n User->>IdP: S'authentifier\n IdP->>App: Code d'autorisation\n App->>IdP: Échanger code contre jetons\n IdP->>App: Jeton ID + jeton d'accès\n \n Note over App: Stocker jetons de manière sécurisée\n \n User->>App: Requête utilisant outil IA\n App->>Proxy: Requête MCP avec jeton d'accès\n \n Proxy->>Proxy: Valider jeton (signature, expiration, audience)\n Proxy->>Proxy: Extraire identité et permissions utilisateur\n \n alt Jeton valide\n Proxy->>Tool: Transmettre requête avec contexte utilisateur\n Tool->>Proxy: Réponse\n Proxy->>App: Retourner réponse\n App->>User: Afficher résultat\n else Jeton invalide\n Proxy->>App: 401 Non autorisé\n App->>User: Session expirée, veuillez vous reconnecter\n end\n \n Note over App,Proxy: Le rafraîchissement du jeton se fait en arrière-plan\n App->>IdP: Rafraîchir jeton quand nécessaire\n IdP->>App: Nouveau jeton d'accès\nCe diagramme de séquence illustre le flux d'authentification OIDC dans un environnement MCP. Le processus commence quand un utilisateur accède à l'application IA, qui redirige vers le fournisseur d'identité pour l'authentification. Après que l'utilisateur s'authentifie, le fournisseur d'identité émet un code d'autorisation, que l'application échange contre des jetons ID et d'accès.
\n\nL'application stocke ces jetons de manière sécurisée et utilise le jeton d'accès lors de requêtes MCP via l'agent IA. Quand le proxy reçoit une requête, il valide le jeton en vérifiant la signature, l'expiration, l'audience et d'autres claims. Il extrait également l'identité et les permissions de l'utilisateur du jeton.
\n\nSi le jeton est valide, le proxy transmet la requête à l'outil MCP approprié avec le contexte de l'utilisateur. L'outil traite la requête et retourne une réponse, qui remonte à travers le proxy vers l'application et finalement vers l'utilisateur.
\n\nSi le jeton est invalide (expiré, altéré, etc.), le proxy retourne une réponse 401 Non autorisé, et l'application invite l'utilisateur à se reconnecter.
\n\nEn arrière-plan, l'application peut utiliser un jeton de rafraîchissement pour obtenir de nouveaux jetons d'accès quand nécessaire, sans exiger que l'utilisateur se ré-authentifie. Cela garantit une expérience utilisateur fluide tout en maintenant la sécurité.
\n\nCette intégration OIDC fournit un mécanisme d'authentification robuste largement adopté dans les environnements d'entreprise et s'intègre bien avec les systèmes de gestion d'identité existants.
\n\nAlors que la discussion ci-dessus se concentre sur l'authentification de l'utilisateur humain, un déploiement MCP de qualité production doit également identifier deux acteurs supplémentaires :
\n\nNotre article compagnon \"Proposition OpenID Connect pour Agents (OIDC-A) 1.0\" ({{ site.baseurl }}/2025/04/28/oidc-a-proposal/) étend OIDC Core 1.0 avec un ensemble riche de claims pour l'identité d'agent, l'attestation et les chaînes de délégation. En pratique, cela signifie :
\n\nagent_type, agent_model, agent_instance_id, delegator_sub, delegation_chain, etc.). Ce jeton voyage aux côtés du jeton d'accès de l'utilisateur dans chaque requête MCP.agent_capabilities, agent_trust_level, agent_attestation).L'adoption d'OIDC-A apporte plusieurs avantages :
\n\nemail:draft à invoquer l'outil Mail).agent_attestation) permet à la passerelle de vérifier l'intégrité et la provenance des agents et des outils avant de router le trafic vers eux.Pour le reste de cet article, chaque fois que nous faisons référence à un \"jeton\" validé par la passerelle, supposez que cela englobe maintenant le jeton de l'utilisateur, le jeton OIDC-A de l'agent, et (optionnellement) le jeton d'outil/ressource – tous évalués dans une seule étape de décision de politique.
\n\nCe pattern est déjà largement utilisé dans la sécurité API : \"une passerelle API peut implémenter de manière sécurisée et cohérente l'authentification... sans alourdir les applications elles-mêmes.\" Dans notre contexte, le proxy MCP pourrait s'intégrer avec votre SSO d'entreprise (Azure AD, Okta, etc.) via OIDC pour gérer les flux de connexion utilisateur et la validation de jetons. De nombreuses passerelles supportent OIDC nativement, initiant des redirections pour la connexion utilisateur si nécessaire et stockant ensuite le jeton résultant dans un cookie pour la continuité de session. Dans un scénario d'agent sans tête (où l'IA appelle des outils serveur à serveur), le jeton pourrait être provisionné hors bande (par exemple, l'utilisateur s'est connecté à l'application IA, donc l'application injecte le jeton pour que l'agent l'utilise). Dans tous les cas, la passerelle applique que pas de jeton = pas d'accès. Elle peut également mapper les claims de jeton aux rôles ou scopes pour implémenter l'autorisation (par exemple, seuls les utilisateurs avec un scope \"HR_read\" peuvent utiliser l'outil \"Base de données RH\"). Cela s'aligne parfaitement avec l'objectif de conception de MCP de connexions sécurisées – combiner MCP avec OIDC et OIDC-A vous donne un canal authentifié de bout en bout pour l'utilisation d'outils.
\n\nsequenceDiagram\n participant User as Utilisateur\n participant Agent as Agent LLM (OIDC-A)\n participant Proxy as Passerelle API\n participant Tool as Outil MCP (OIDC-A)\n participant Backend as Système Backend\n\n User->>Agent: 1. Interagir (chat, formulaire, etc.)\n Agent->>Proxy: 2. Requête MCP\\nBearer jeton utilisateur + jeton OIDC-A agent\n Proxy->>Proxy: 3. Valider jeton utilisateur (OIDC) & jeton agent (OIDC-A)\n Proxy-->>Tool: 4. Transmettre requête plus *jeton ressource* optionnel pour l'outil\n Tool->>Backend: 5. Requête/action utilisant auth déléguée\n Backend-->>Tool: 6. Données / résultat\n Tool-->>Proxy: 7. Réponse (peut inclure attestation)\n Proxy-->>Agent: 8. Réponse autorisée\n Agent-->>User: 9. Présenter résultat\nUn avantage puissant du proxy est qu'il peut prendre des décisions de routage basées non seulement sur les URL, mais sur les métadonnées dans les requêtes. Avec MCP, les requêtes et réponses sont au format JSON-RPC, qui inclut des champs comme le nom de méthode de l'outil, les paramètres, et même les annotations d'outil. Un proxy conscient de l'identité peut être configuré pour inspecter ces détails et appliquer des règles de politique. Par exemple, vous pourriez configurer des règles telles que :
\n\ngraph TD\n subgraph \"Requête MCP\"\n Request[Requête JSON-RPC]\n Method[Méthode outil]\n Params[Paramètres]\n User[Identité utilisateur]\n end\n \n subgraph \"Moteur de politiques\"\n Rules[Règles de politique]\n RBAC[Accès basé sur rôles]\n Audit[Journalisation d'audit]\n Transform[Transformation de réponse]\n end\n \n Request --> Method\n Request --> Params\n Request --> User\n \n Method --> Rules\n Params --> Rules\n User --> RBAC\n \n Rules --> Decision{Autoriser/Refuser}\n RBAC --> Decision\n \n Decision -->|Autoriser| Forward[Transmettre à l'outil]\n Decision -->|Refuser| Reject[Rejeter requête]\n \n Forward --> Audit\n Reject --> Audit\n \n Forward --> Tool[Outil MCP]\n Tool --> Response[Réponse outil]\n Response --> Transform\n Transform --> Filtered[Réponse filtrée]\n \n classDef request fill:#bbf,stroke:#333,stroke-width:1px;\n classDef policy fill:#fbf,stroke:#333,stroke-width:1px;\n classDef action fill:#bfb,stroke:#333,stroke-width:1px;\n \n class Request,Method,Params,User request;\n class Rules,RBAC,Audit,Transform policy;\n class Decision,Forward,Reject,Filtered action;\nCe diagramme illustre comment le filtrage de métadonnées d'outils et l'application de politiques fonctionnent dans un proxy MCP. Le processus commence avec une requête MCP au format JSON-RPC, qui contient la méthode d'outil, les paramètres et les informations d'identité utilisateur. Ces composants sont extraits et alimentés dans le moteur de politiques.
\n\nLe moteur de politiques se compose de règles de politique, de contrôle d'accès basé sur les rôles (RBAC), de journalisation d'audit et de composants de transformation de réponse. La méthode d'outil et les paramètres sont évalués par rapport aux règles de politique, tandis que l'identité utilisateur est vérifiée par rapport aux permissions RBAC.
\n\nSur la base de ces évaluations, le moteur de politiques prend une décision autoriser/refuser. Si la requête est autorisée, elle est transmise à l'outil MCP ; si refusée, elle est rejetée. Dans les deux cas, l'action est journalisée à des fins d'audit.
\n\nQuand une requête est autorisée et traitée par l'outil, la réponse peut passer par une étape de transformation avant d'être retournée au client. Cette transformation peut filtrer ou modifier la réponse selon les politiques de sécurité, comme supprimer des informations sensibles que l'utilisateur ne devrait pas voir.
\n\nCette application de politique fine au niveau des métadonnées permet des contrôles de sécurité sophistiqués qui vont bien au-delà du simple routage basé sur URL. Par exemple :
\n\ndelete_file et que l'utilisateur n'est pas dans le groupe IT Admin, refuser la requête.\"execute_sql que les jours de semaine entre 9h et 17h, et journaliser toutes les requêtes.\"C'est analogue à un pare-feu d'application web (WAF) ou une passerelle API effectuant du filtrage de contenu, mais adapté à l'utilisation d'outils IA. Dans la proposition Envoy MCP, cela correspond à l'analyse des messages MCP et à l'utilisation de filtres RBAC sur eux. Le proxy comprend essentiellement l'intention de chaque appel d'outil et peut le contrôler de manière appropriée. Il peut également redacter ou transformer les données si nécessaire – par exemple, supprimer certains champs d'une réponse que l'utilisateur ne devrait pas voir, ou masquer des informations personnellement identifiables. En centralisant cela dans la passerelle, vous évitez d'avoir à implémenter des vérifications dans chaque service d'outil (qui pourraient être incohérentes ou oubliées). L'audit est un autre avantage : le proxy peut journaliser chaque invocation d'outil avec l'identité utilisateur et les paramètres, alimentant les systèmes SIEM pour la surveillance. De cette façon, si une IA fait un jour quelque chose qu'elle ne devrait pas, vous avez une trace claire de quel appel d'outil était impliqué et qui l'a déclenché. En somme, le filtrage basé sur les métadonnées transforme le proxy en un point d'application de politique intelligent, ajoutant une couche de sécurité au-dessus des capacités de base de MCP.
\n\nLes entreprises font constamment évoluer leurs services – nouvelles versions, tests A/B, déploiements staging vs production, etc. Le proxy peut grandement simplifier la façon dont les agents IA gèrent ces changements. Au lieu que l'IA ait besoin de savoir quelle version d'un outil appeler, la passerelle peut implémenter un routage conscient de version. Par exemple, l'endpoint MCP pour un outil \"Recherche de documents\" pourrait rester le même pour l'agent, mais le proxy pourrait router 90% des requêtes vers v1 du service et 10% vers une nouvelle v2 (pour un déploiement canari). Ou router les utilisateurs internes vers une instance \"beta\" tandis que les utilisateurs externes vont vers stable. Cela se fait en faisant correspondre les attributs de requête ou en utilisant des règles de routage qui incluent l'audience utilisateur et les identifiants d'outil.
\n\ngraph TB\n AIAgent[Agent IA] -->|Requête MCP| Proxy[Passerelle API]\n \n Proxy -->|\"90% trafic\"| V1[Outil v1]\n Proxy -->|\"10% trafic\"| V2[Outil v2 - Canari]\n \n Proxy -->|\"Utilisateurs internes\"| Beta[Version Beta]\n Proxy -->|\"Utilisateurs externes\"| Stable[Version Stable]\n \n Proxy -->|\"Petites requêtes\"| Standard[Instance standard]\n Proxy -->|\"Grandes requêtes\"| HighMem[Instance haute mémoire]\n \n Proxy -->|\"Utilisateurs US\"| US[Région US]\n Proxy -->|\"Utilisateurs EU\"| EU[Région EU]\n \n classDef proxy fill:#f96,stroke:#333,stroke-width:2px;\n classDef version fill:#bbf,stroke:#333,stroke-width:1px;\n classDef audience fill:#bfb,stroke:#333,stroke-width:1px;\n classDef size fill:#fbf,stroke:#333,stroke-width:1px;\n classDef region fill:#ff9,stroke:#333,stroke-width:1px;\n \n class Proxy proxy;\n class V1,V2 version;\n class Beta,Stable audience;\n class Standard,HighMem size;\n class US,EU region;\nCe diagramme illustre les diverses stratégies de routage qu'une passerelle API peut implémenter pour les requêtes MCP. La passerelle peut router le trafic selon plusieurs facteurs :
\n\nL'agent IA n'a pas besoin d'être conscient de ces décisions de routage ; il fait simplement des requêtes au nom logique de l'outil, et la passerelle gère la complexité du routage vers le backend approprié. Cette abstraction simplifie l'implémentation de l'agent tout en fournissant de puissantes capacités opérationnelles.
\n\nDe même, le routage peut considérer le contexte – par exemple, diriger les requêtes vers le serveur régional le plus proche pour une latence plus faible si la localisation de l'utilisateur est connue, ou choisir un backend différent selon la taille de la requête (peut-être une instance spéciale haute mémoire pour de très gros fichiers). Tout cela est configurable au niveau du proxy. L'agent IA appelle simplement le nom logique de l'outil, et la passerelle se charge de trouver le bon backend. Cela facilite non seulement les opérations (vous pouvez mettre à niveau les outils backend sans casser l'interface de l'IA), mais ajoute également à la sécurité. Vous pourriez isoler certaines versions pour les tests, ou vous assurer que les outils expérimentaux ne sont accessibles que sous certaines conditions. En contrôlant le flux de trafic, le proxy aide à maintenir un principe de moindre privilège à l'échelle macro – l'IA n'atteint que les backends qu'elle est censée atteindre, via des routes appropriées au contexte actuel.
\n\nMaintenant que nous avons couvert les patterns de sécurité clés, examinons une approche pratique pour implémenter la sécurité MCP avec un proxy conscient de l'identité. Cette section décrit les étapes pour configurer un environnement MCP sécurisé, en se concentrant sur les points d'intégration entre les composants.
\n\ngraph TB\n subgraph ImplementationSteps[\"Étapes d'implémentation\"]\n Step1[1. Configurer fournisseur d'identité]\n Step2[2. Configurer passerelle API]\n Step3[3. Implémenter registre d'outils]\n Step4[4. Définir politiques de sécurité]\n Step5[5. Intégrer agents IA]\n Step6[6. Surveiller et auditer]\n \n Step1 --> Step2\n Step2 --> Step3\n Step3 --> Step4\n Step4 --> Step5\n Step5 --> Step6\n end\n \n classDef step fill:#beb,stroke:#333,stroke-width:1px\n class Step1,Step2,Step3,Step4,Step5,Step6 step\nCe diagramme décrit les six étapes clés de l'implémentation de la sécurité MCP avec un proxy. Le processus suit une progression logique :
\n\nChaque étape s'appuie sur les précédentes, créant une implémentation de sécurité complète. Les sections suivantes exploreront chaque étape en détail.
\n\nLa première étape consiste à configurer votre fournisseur d'identité (IdP) pour supporter les flux OIDC nécessaires à la sécurité MCP. Cela implique typiquement :
\n\nL'IdP sera responsable de l'authentification des utilisateurs et de l'émission des jetons qui seront utilisés pour sécuriser les requêtes MCP. Il est important de configurer les scopes et claims appropriés pour s'assurer que les jetons contiennent les informations nécessaires aux décisions d'autorisation.
\n\nEnsuite, vous devrez configurer votre passerelle API pour agir comme proxy MCP. Cela implique :
\n\nsequenceDiagram\n participant Admin as Administrateur\n participant Gateway as Passerelle API\n participant IdP as Fournisseur d'identité\n \n Admin->>Gateway: 1. Configurer intégration OIDC\n Gateway->>IdP: 2. Récupérer document de découverte OIDC\n IdP->>Gateway: 3. Retourner endpoints et clés\n \n Admin->>Gateway: 4. Configurer règles de routage MCP\n Admin->>Gateway: 5. Configurer politiques de sécurité\n \n Note over Gateway: Passerelle prête à valider jetons et router trafic MCP\nCe diagramme de séquence illustre le processus de configuration d'une passerelle API pour la sécurité MCP. Le processus commence avec un administrateur configurant l'intégration OIDC dans la passerelle. La passerelle récupère ensuite le document de découverte OIDC du fournisseur d'identité, qui retourne les endpoints et clés nécessaires pour la validation de jetons.
\n\nEnsuite, l'administrateur configure les règles de routage MCP, définissant comment les requêtes doivent être dirigées vers différents outils MCP selon divers critères. L'administrateur configure également les politiques de sécurité, spécifiant qui peut accéder à quels outils et sous quelles conditions.
\n\nUne fois ces configurations terminées, la passerelle est prête à valider les jetons et router le trafic MCP selon les règles et politiques définies. Cette configuration établit la passerelle comme point de contrôle de sécurité central pour toutes les interactions MCP.
\n\nLes étapes de configuration incluent :
\n\nLa passerelle sera responsable de valider les jetons, d'appliquer les politiques de sécurité et de router les requêtes MCP vers les backends appropriés. Il est important de s'assurer que la passerelle est correctement configurée pour gérer le format JSON-RPC de MCP et pour extraire les informations nécessaires aux décisions de politique.
\n\nUn registre d'outils est essentiel pour gérer le cycle de vie des outils MCP dans votre environnement. Cela implique :
\n\nLe registre d'outils sera responsable de maintenir la liste des outils disponibles, leurs endpoints et leurs exigences d'accès. Il fournira également les informations nécessaires à la passerelle API pour le routage et l'application de politiques.
\n\ngraph TB\n subgraph \"Registre d'outils\"\n DB[(Base de données outils)]\n API[API registre]\n UI[Interface admin]\n \n UI -->|Gérer outils| API\n API -->|Opérations CRUD| DB\n end\n \n subgraph \"Points d'intégration\"\n Gateway[Passerelle API]\n Agents[Agents IA]\n \n API -->|Configurations outils| Gateway\n API -->|Outils disponibles| Agents\n end\n \n subgraph \"Cycle de vie outil\"\n Register[Enregistrer]\n Approve[Approuver]\n Deploy[Déployer]\n Monitor[Surveiller]\n Retire[Retirer]\n \n Register --> Approve\n Approve --> Deploy\n Deploy --> Monitor\n Monitor --> Retire\n end\n \n classDef registry fill:#bbf,stroke:#333,stroke-width:1px;\n classDef integration fill:#fbf,stroke:#333,stroke-width:1px;\n classDef lifecycle fill:#bfb,stroke:#333,stroke-width:1px;\n \n class DB,API,UI registry;\n class Gateway,Agents integration;\n class Register,Approve,Deploy,Monitor,Retire lifecycle;\nCe diagramme illustre les composants et le cycle de vie d'un registre d'outils dans un environnement MCP. Le registre d'outils se compose de trois composants principaux :
\n\nLe registre d'outils s'intègre avec deux systèmes clés :
\n\nLe diagramme montre également le cycle de vie d'un outil MCP :
\n\nCette approche complète de la gestion des outils garantit que tous les outils MCP sont correctement vérifiés, déployés et surveillés tout au long de leur cycle de vie, réduisant les risques de sécurité et les problèmes opérationnels.
\n\nLes politiques de sécurité sont les règles qui régissent l'accès aux outils MCP. Cela implique :
\n\nLes politiques de sécurité seront appliquées par la passerelle API selon l'identité de l'utilisateur et l'outil accédé. Il est important de s'assurer que les politiques sont complètes et alignées avec les exigences de sécurité de votre organisation.
\n\nEnfin, vous devrez intégrer vos agents IA avec l'environnement MCP sécurisé. Cela implique :
\n\nLes agents IA seront responsables d'obtenir les jetons nécessaires et de les inclure dans les requêtes MCP. Ils devront également gérer les erreurs d'authentification et d'autorisation avec élégance, fournissant un retour approprié aux utilisateurs.
\n\nsequenceDiagram\n participant User as Utilisateur\n participant Agent as Agent IA\n participant App as Application\n participant IdP as Fournisseur d'identité\n participant Gateway as Passerelle API\n participant Tool as Outil MCP\n \n User->>App: Accéder à l'application IA\n App->>IdP: Authentifier utilisateur\n IdP->>App: Émettre jetons\n \n User->>Agent: Requête utilisant capacités IA\n Agent->>App: Demander jeton pour MCP\n App->>Agent: Fournir jeton\n \n Agent->>Gateway: Requête MCP avec jeton\n Gateway->>Gateway: Valider jeton & appliquer politiques\n Gateway->>Tool: Transmettre requête autorisée\n Tool->>Gateway: Réponse\n Gateway->>Agent: Retourner réponse\n Agent->>User: Présenter résultat\n \n Note over App,Gateway: Cycle de rafraîchissement de jeton\n App->>IdP: Rafraîchir jeton quand nécessaire\n IdP->>App: Nouveau jeton d'accès\nCe diagramme de séquence illustre l'intégration des agents IA avec un environnement MCP sécurisé. Le processus commence quand un utilisateur accède à l'application IA, qui authentifie l'utilisateur avec le fournisseur d'identité et reçoit des jetons.
\n\nQuand l'utilisateur fait une requête nécessitant des capacités IA, l'agent IA demande un jeton à l'application, qui le fournit. L'agent inclut ensuite ce jeton dans sa requête MCP à la passerelle API.
\n\nLa passerelle valide le jeton et applique les politiques de sécurité pour déterminer si la requête doit être autorisée. Si autorisée, la requête est transmise à l'outil MCP approprié, qui la traite et retourne une réponse. Cette réponse remonte à travers la passerelle vers l'agent et finalement vers l'utilisateur.
\n\nEn arrière-plan, l'application gère les cycles de rafraîchissement de jetons, demandant de nouveaux jetons d'accès au fournisseur d'identité quand nécessaire. Cela garantit une opération continue sans exiger que l'utilisateur se ré-authentifie fréquemment.
\n\nCette approche d'intégration garantit que les agents IA opèrent dans le cadre de sécurité établi par l'architecture proxy, avec toutes les requêtes correctement authentifiées et autorisées.
\n\nEn implémentant une architecture MCP sécurisée avec un proxy conscient de l'identité, vous allez bien au-delà des « appels API glorifiés » vers une intégration robuste de qualité entreprise entre les agents IA et vos systèmes métier. Cette approche aborde les défis de sécurité clés des déploiements MCP, incluant :
\n\nL'architecture basée sur proxy fournit un point de contrôle centralisé pour appliquer les politiques de sécurité, gérer l'accès aux outils et surveiller l'activité des agents IA. Elle simplifie également les opérations en abstrayant la complexité des services backend et en fournissant une interface cohérente pour les agents IA.
\n\nAlors que MCP continue d'évoluer et de gagner en adoption, les patterns de sécurité décrits dans cet article deviendront de plus en plus importants pour les déploiements d'entreprise. En implémentant ces patterns maintenant, vous pouvez vous assurer que votre infrastructure d'agents IA est sécurisée, évolutive et prête pour l'avenir.
\n\ngraph LR\n A[Appels API glorifiés] -->|Évolution| B[Architecture MCP sécurisée]\n \n subgraph \"Avantages clés\"\n C[Sécurité centralisée]\n D[Propagation d'identité]\n E[Application de politiques]\n F[Audit & conformité]\n G[Simplicité opérationnelle]\n end\n \n B --> C\n B --> D\n B --> E\n B --> F\n B --> G\n \n classDef benefit fill:#bfb,stroke:#333,stroke-width:1px;\n class C,D,E,F,G benefit;\nCe diagramme final résume l'évolution des « appels API glorifiés » vers une architecture MCP sécurisée, mettant en évidence les avantages clés de cette approche :
\n\nEn adoptant cette architecture, les organisations peuvent déployer en toute confiance des agents IA dans des environnements d'entreprise, sachant que leurs interactions MCP sont sécurisées, auditables et gérables à grande échelle. Cela représente une avancée significative au-delà de la vision simpliste des outils IA comme de simples appels API, reconnaissant les exigences de sécurité complexes des systèmes IA de production.
", "source_hash": "sha256:2e298f37ca328b0eb320a81887dd3640aeb212ad3bf1d820c547bb98ab9e3b19", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T03:19:29.693958+00:00" }