Retour d'expérience · Deep Dive
Un retour d'expérience issu de VamiGRC
Un serveur MCP sécurisé tient toute décision qui compte à l'écart de l'agent IA. En construisant le serveur MCP qui relie des assistants IA comme Claude à VamiGRC, nous avons appris qu'une confirmation dans le chat n'est pas un contrôle de sécurité : un agent manipulé peut y répondre lui-même. Ce retour d'expérience montre comment nous avons déplacé l'identité, les validations, l'autonomie et les frontières entre locataires vers le backend, comment nous avons testé chacun de ces éléments et où se situent encore les limites.
Depuis la révision de juin 2025 de la spécification MCP, un serveur MCP protégé est un resource server OAuth 2.1. La pratique est à la traîne, et une plateforme GRC fait monter les enjeux.
8,5 %
des plus de 5 200 serveurs MCP open source examinés en octobre 2025 utilisaient OAuth.
State of MCP Server Security 2025: Research Report (octobre 2025) (ouvre un site externe)
Specification, Revision 2025-06-18: Authorization (juin 2025) (ouvre un site externe)
L'agent lit les risques, les incidents et les données fournisseurs, et il peut les modifier. Une modification erronée n'est pas qu'un simple bug : elle peut fausser les preuves sur lesquelles s'appuie un auditeur.
Comment un agent IA peut-il travailler avec des données de conformité sans devenir le point le plus faible de la plateforme ?
Nous avons modélisé trois attaquants, avec STRIDE pour la classe de faille et l'OWASP MCP Top 10 comme catalogue de risques. Sélectionnez un attaquant pour voir quels contrôles le limitent, quels tests négatifs s'y rapportent et ce qui subsiste.
Ce qui subsiste : Dans une session détournée, l'agent peut encore confirmer au niveau L2 dans le chat, et il peut saisir lui-même la référence de suppression. C'est pourquoi les suppressions et les décisions exigent une validation dans l'application. L'injection de prompt elle-même ne peut pas être entièrement empêchée.
Ce qui subsiste : Ce que l'API publique et les limites de l'organisation autorisent reste possible : une session détournée peut encore confirmer au niveau L2 dans le chat les modifications autres que les suppressions et les décisions, et le retour arrière n'est que partiel.
Le fil conducteur : un agent manipulé ne s'introduit pas par effraction. Il utilise des autorisations qu'il détient légitimement. Chaque contrôle doit donc se situer là où l'agent ne peut pas l'atteindre.
L'agent ne détient jamais de jeton que le backend accepterait comme une session utilisateur normale. La chaîne de connexion en quatre étapes :
L'assistant découvre le serveur d'autorisation à partir des Protected Resource Metadata du serveur MCP (RFC 9728).
L'utilisateur se connecte directement à VamiGRC et voit un écran de consentement : quel assistant, lecture seule ou lecture et modification, quel locataire.
L'assistant reçoit un access token valable quelques minutes et non quelques jours, lié au serveur MCP en tant qu'audience, ainsi qu'un refresh token qui change à chaque utilisation.
Le backend n'accepte ce jeton que comme un jeton d'API restreint : uniquement l'API publique, jamais de fonctions d'administration, et jamais plus que le rôle propre de l'utilisateur.
Notre conception précédente échangeait, auprès d'un fournisseur d'identité externe, la connexion de l'utilisateur contre un jeton pour le backend. Cela fonctionnait, mais les sessions de longue durée et l'échange de jetons faisaient mauvais ménage : après une période d'inactivité, les utilisateurs voyaient s'afficher « connexion expirée ». Faire de VamiGRC le serveur d'autorisation a éliminé cette catégorie de problèmes.
Un seul scope manquant, offline_access, a fait échouer un client IA majeur avant même qu'il n'affiche une page de connexion.
Références : RFC 9728: OAuth 2.0 Protected Resource Metadata (avril 2025) (ouvre un site externe) · RFC 8707: Resource Indicators for OAuth 2.0 (février 2020) (ouvre un site externe) · RFC 9700: Best Current Practice for OAuth 2.0 Security (janvier 2025) (ouvre un site externe) · The OAuth 2.1 Authorization Framework (Internet-Draft) (ouvre un site externe)
Notre première version demandait à l'utilisateur de confirmer chaque modification dans la conversation. Cela semblait sûr, mais la confirmation se faisait dans le canal même que contrôle l'attaquant.
Le contrôle se situe dans le canal de l'attaquant.
L'agent ne peut pas falsifier ces couches. Les suppressions et les décisions exigent en plus une validation dans l'application.
Chaque écriture est un appel en deux étapes. La première renvoie un aperçu et le stocke sur le serveur ; seule sa confirmation déclenche l'écriture. Si l'enregistrement a changé entre-temps, la confirmation est refusée.
À l'étape de confirmation, le serveur MCP signe la requête exacte. Le backend rejette toute écriture qui en est dépourvue : un access token volé, utilisé directement contre l'API, ne peut donc pas écrire.
Un simple « oui » ne supprime rien. L'utilisateur doit saisir la référence de l'enregistrement, et l'aperçu énumère tout ce qui est lié à cet enregistrement. Les enregistrements archivables sont archivés plutôt qu'effacés.
Toutes les actions ne méritent pas la même confiance. Chaque route d'écriture de l'API publique relève d'une classe d'actions, et l'organisation fixe pour chaque classe le niveau d'autonomie maximal, selon les niveaux L0 à L3 de VamiGRC.
L0
L'agent n'a pas le droit d'agir.
Dans le serveur MCPRefus assorti d'une raison claire ; la personne agit dans VamiGRC.
L1
L'agent prépare, la personne agit.
Dans le serveur MCPUn brouillon que la personne vérifie et enregistre.
L2
L'agent agit après la validation d'un humain.
Dans le serveur MCPAperçu et confirmation, ou validation dans l'application pour les suppressions et les décisions.
L3
L'agent agit seul, tout est consigné.
Dans le serveur MCPUniquement pour les classes à faible risque, comme les notes.
L'organisation fixe le maximum, et chaque personne ne peut que le restreindre pour ses propres assistants. C'est toujours le réglage le plus strict qui s'applique.
Les suppressions et les décisions ne sont jamais autonomes, et les décisions signées, comme les approbations, ne passent jamais par le chat.
Une route sans classe est considérée comme bloquée. Un test échoue dès qu'une nouvelle route d'écriture n'a pas de classe.
Choisissez une classe d'actions, le maximum de l'organisation et la limite personnelle. Le calculateur applique les trois règles.
Niveau effectif
L2Exécuté par l'IA avec validation obligatoire
Aperçu et confirmation, ou validation dans l'application pour les suppressions et les décisions.
Limité par le maximum de l'organisation.
Modèle simplifié fondé sur ce retour d'expérience ; il ne reproduit pas la configuration du produit.
Les consultants travaillent pour plusieurs clients : une même personne a donc souvent accès à plusieurs locataires. Le serveur MCP suit le locataire que la personne a sélectionné dans l'application VamiGRC ; il le vérifie à chaque appel, sans mise en cache. Ce confort crée un nouveau risque.
L'aperçu enregistre son locataire et sa société, et la réponse les indique.
Le serveur MCP suit ce changement dès l'appel suivant.
La confirmation est refusée avant que quoi que ce soit ne soit envoyé.
Le serveur refuse plutôt que de se rabattre silencieusement sur un autre locataire.
Chaque test tente de mettre en échec un contrôle ; il est exécuté de bout en bout, avec un vrai backend et un vrai client MCP, et pas seulement sous forme de tests unitaires.
| Test | Attendu | Résultat |
|---|---|---|
| Code d'autorisation utilisé deux fois | Refusé, et la connexion qu'il a créée est fermée | Réussi |
| Ancien refresh token réutilisé après rotation | Refusé, et toute la connexion est fermée | Réussi |
| Simple « oui » sur un aperçu de suppression | Rien n'est supprimé, la référence est demandée | Réussi |
| Locataire changé entre l'aperçu et la confirmation | Confirmation refusée, rien n'est écrit | Réussi |
| Plusieurs changements de locataire d'affilée | La connexion suit chaque changement | Réussi |
| Suppression par ID dans une autre société | Introuvable, l'enregistrement est conservé | Réussi |
| Écriture sans preuve de confirmation | Refusée | Réussi |
| Limite personnelle plus stricte que celle de l'organisation | La limite la plus stricte s'applique | Réussi |
C'est en testant les contrôles comme le ferait un attaquant, et pas seulement les fonctionnalités, que nous les avons découverts.
Cinq enseignements transposables à d'autres serveurs MCP, et cinq limites, exposées en toute transparence.
Dix questions tirées de ce retour d'expérience. Plus vous répondez souvent « Oui », moins votre sécurité dépend de ce que fait l'agent.
Réponses : 0/10
Le résultat donne une orientation ; il ne constitue pas une preuve d'audit. Vos réponses ne sont pas transmises.
Voici comment nous mettons les contrôles en correspondance avec les catalogues de risques. Les deux catalogues sont jeunes, et cette correspondance évoluera avec eux.
MCP01
OWASP MCP Top 10 (v0.1, Beta) (ouvre un site externe)
Pas de token passthrough, des jetons à courte durée de vie liés à leur audience, des refresh tokens en rotation avec détection de réutilisation, un accès limité à l'API publique.
MCP10
OWASP MCP Top 10 (v0.1, Beta) (ouvre un site externe)
Les réponses indiquent le locataire et la société, les données issues des enregistrements sont marquées comme non fiables, et l'agent ne voit que ce que le rôle de la personne autorise.
LLM06:2025
OWASP Top 10 for LLM Applications 2025 (ouvre un site externe)
Niveaux d'autonomie par classe d'actions, plafonds stricts et validation dans l'application pour les suppressions et les décisions.
L'OWASP MCP Top 10 est une bêta, et l'Agent Control Standard en est à la version 0.1.0. Les dix risques MCP dans notre Deep Dive
Le retour d'expérience préparé pour les décideurs : modèle de menaces, identité sans token passthrough, validations dans le backend, niveaux d'autonomie et gouvernance, liaison au locataire et piste d'audit, tests négatifs, questions aux fournisseurs et plan à 30-60-90 jours.
Nous examinons les serveurs MCP et les intégrations d'agents de la manière décrite dans ce retour d'expérience : avec un modèle de menaces, des contrôles en dehors de l'agent et des tests négatifs.
Spécifications, normes et études sur lesquelles s'appuie ce retour d'expérience.
Réponses courtes
Parce qu'elle passe par le canal même que contrôle un attaquant. Un agent manipulé par injection de prompt peut répondre lui-même « oui » à la question, et quiconque détient un access token volé contourne entièrement le chat. Plus efficaces sont les contrôles que l'agent ne peut pas falsifier : des aperçus imposés par le serveur, une preuve de confirmation liée à la requête exacte et, pour les suppressions et les décisions, une validation dans l'application.
Depuis la révision de juin 2025, un serveur MCP protégé est un resource server OAuth 2.1. La spécification exige la découverte des métadonnées via les Protected Resource Metadata (RFC 9728), PKCE et des jetons émis pour le serveur MCP en tant qu'audience ; le token passthrough est interdit. Le retour d'expérience montre ce qu'il faut en plus dès qu'un agent est autorisé à écrire.
Ils définissent ce qu'un agent peut faire seul : L0 manuel, L1 assisté par l'IA, L2 exécuté par l'IA avec validation obligatoire, L3 entièrement autonome et intégralement audité. Dans le serveur MCP de VamiGRC, l'organisation fixe le niveau maximal par classe d'actions, chaque personne ne peut que le restreindre, et une route sans classe est bloquée. Les suppressions et les décisions ne sont jamais autonomes.
Non. Le texte issu des enregistrements est marqué comme non fiable, mais un modèle peut tout de même le suivre. Les contrôles limitent ce qu'un agent manipulé peut faire, mais n'empêchent pas la manipulation elle-même. C'est pourquoi les suppressions et les décisions exigent une validation dans l'application.
Avec, pour chaque contrôle, un test négatif qui tente délibérément de le mettre en échec : échanger deux fois un code d'autorisation, réutiliser un ancien refresh token, changer de locataire entre l'aperçu et la confirmation, écrire sans preuve de confirmation, supprimer par ID dans une autre société. De bout en bout, avec un vrai backend et un vrai client MCP, et pas seulement dans des tests unitaires.
Tous deux en sont à leurs débuts : l'OWASP MCP Top 10 est une bêta en version 0.1, et l'Agent Control Standard en est à la version 0.1.0. Nous faisons correspondre nos contrôles aux risques Token Mismanagement & Secret Exposure, Context Injection & Over-Sharing et Excessive Agency, et ajusterons cette correspondance à mesure que les standards mûriront.
Nous examinons les serveurs MCP et les intégrations d'agents comme le ferait un attaquant, et montrons quelles décisions restent à la portée de l'agent.
