Un worker IA doit vérifier un serveur de projet ou déclencher une action approuvée. Il lui faut des outils et des droits adaptés. Un fichier contenant tous les jetons API et clés SSH privées dans le dossier du projet rend ce fonctionnement commode, mais augmente les conséquences possibles d’une erreur ou d’une entrée manipulée.
Un intermédiaire MCP contrôlé peut représenter précisément le périmètre d’action autorisé. L’agent demande une action définie ; le serveur vérifie identité, projet et autorisation. Lorsque le processus le permet, un service backend limité utilise les identifiants nécessaires sans les renvoyer au modèle.
MCP fournit des outils, pas des droits automatiquement sûrs
Le Model Context Protocol décrit comment les clients utilisent les outils et autres capacités d’un serveur. L’application doit décider de façon fiable si un utilisateur peut réaliser une action donnée sur un objet précis. Un client authentifié n’est pas automatiquement autorisé pour chaque projet ou outil.
Pour les connexions HTTP protégées, MCP décrit un parcours d’autorisation fondé sur OAuth. La spécification actuelle le distingue des connexions STDIO locales. La protection adaptée dépend du transport réel. Une clé quelconque dans un paramètre d’URL ou un jeton permanent partagé n’équivalent pas à une gestion différenciée des droits.
Un exemple concret : le projet A reste le projet A
Un worker doit interroger l’état d’un service convenu dans le projet A. Un outil dédié accepte un identifiant d’objet vérifié et ne renvoie que le résultat nécessaire. Il ne propose ni shell libre ni export général de tous les secrets.
Chaque appel est contrôlé côté serveur selon utilisateur, projet, outil et action. Même un identifiant de projet modifié par le client ne doit pas permettre l’accès au projet B. Les cibles sont résolues à partir d’associations approuvées ; une adresse quelconque fournie par le modèle ne constitue pas une autorisation suffisante. Les limites entre locataires font partie du contrôle.
Vérifier les jetons pour le bon destinataire
Sur un serveur MCP HTTP protégé, un jeton d’accès doit être émis pour le destinataire prévu et vérifié par celui-ci. Audience, portée autorisée et validité sont liées. Une durée courte limite la fenêtre d’utilisation d’un jeton volé ; elle ne remplace ni les contrôles d’objets côté serveur ni le processus de révocation.
La documentation de sécurité MCP interdit le transfert de jetons non vérifié : un serveur ne doit pas accepter des jetons destinés à d’autres ressources comme sa propre preuve d’autorisation puis les transmettre inchangés aux API suivantes. La connexion du client MCP et les droits auprès du système cible sont des relations de confiance distinctes. Une transition mal définie peut détourner un intermédiaire privilégié au profit d’un tiers ; c’est le problème du confused deputy.
Utiliser les secrets dans le backend prévu
Un backend de gestion des secrets peut fournir les identifiants selon les responsabilités et la finalité. Le service exécutant ne reçoit que les droits nécessaires. L’interface d’administration gère validations, associations et révocations ; elle ne devient pas un catalogue de mots de passe lisible par tous les workers connectés.
Un outil limité peut lire une valeur d’état ou effectuer une opération expressément autorisée et renvoyer un résultat expurgé. Les données brutes du backend de secrets ne doivent pas se retrouver incidemment dans les sorties d’outils, erreurs, traces ou prompts. Si un client précis doit techniquement recevoir un secret, cette divulgation est explicitement évaluée et limitée en portée, durée et destinataire. Une garantie générale d’absence de divulgation serait alors fausse.
| Point de contrôle | Limite souhaitée | Test concret |
|---|---|---|
| Utilisateur et projet | Chaque action reste dans le périmètre de projet autorisé. | Changer l’identifiant de projet : refuser l’accès non autorisé. |
| Outil et paramètres | Seules les actions et cibles prévues sont accessibles. | Refuser une adresse libre ou l’identifiant d’un objet étranger. |
| Jeton et backend | Destinataire et parcours d’autorisation sont sans ambiguïté. | Tester audience incorrecte, expiration et révocation. |
| Secrets et résultats | Seuls les résultats nécessaires quittent le backend. | Contrôler sorties d’outils, erreurs et journaux pour détecter les valeurs brutes. |
| Validation et exploitation | Les changements lourds de conséquences ont une approbation ciblée. | Tester lien à la cible, durée, limites et gestion des pannes. |
Un contenu tiers ne peut pas accorder une autorisation
Un ticket, un site ou un dépôt peut contenir du texte destiné à orienter l’agent vers d’autres actions. Descriptions et résultats d’outils peuvent aussi être manipulés. Ces contenus sont des données, pas une preuve d’autorisation. Un prompt tel que « utilise seulement le projet A » aide à décrire la tâche mais ne remplace pas une limite de projet techniquement imposée.
Des outils étroits, des paramètres vérifiés, des systèmes cibles limités et des contrôles de droits indépendants réduisent l’effet d’une injection de prompt. Les validations supplémentaires dépendent de l’action : une lecture d’état demande un autre parcours qu’un changement aux conséquences importantes. L’approbation est liée à la cible précise et à la modification prévue.
Prévoir journalisation et révocation
Pour une exploitation traçable, on consigne identité utilisateur ou de service, projet, outil, décision, moment et résultat. Les valeurs secrètes en sont exclues. Conservation, accès aux journaux et niveau de détail sont convenus selon l’environnement. Un unique journal de succès ne remplace pas la vérification de ce qui s’est réellement produit sur la cible.
Limites de débit, délais et périmètre backend restreint réduisent encore les conséquences d’appels inattendus. Lors de la révocation, on traite séparément nouveaux appels, justificatifs déjà émis et actions en cours. Une panne du service MCP ou de secrets exige un parcours défini de gestion d’erreur et de reprise.
Commencer par un petit pilote
Un pilote adapté commence par un projet et quelques outils en lecture seule. On vérifie identifiants d’objets permis et interdits, droits manquants, justificatifs expirés, résultats manipulés et panne d’un backend. Les écritures clairement limitées ne sont évaluées qu’ensuite. Le périmètre dépend du risque et de l’exploitation existante.
DAXS accompagne architecture, intégration et définition d’un périmètre d’outils vérifiable. La page consacrée à MCP et aux interfaces, le billet sur les accès SSH gérés et la présentation de la sécurité IA approfondissent ces liens. Vous pouvez discuter d’une intégration IA propre à un projet.
Questions fréquentes
Un serveur MCP peut-il cacher tous les identifiants au modèle ?
Avec des actions serveur bien conçues, le modèle peut recevoir uniquement un résultat expurgé. Il faut vérifier si cela est possible pour chaque opération nécessaire. Transmettre techniquement un secret au client change l’évaluation du risque.
Un long jeton secret suffit-il à protéger l’accès ?
Non. Il faut aussi vérifier destinataire, portée, validité, attribution à l’utilisateur et au projet, ainsi que l’action concrète. Un jeton unique doté de droits étendus ne fournit pas cette séparation à lui seul.
Comment débuter un pilote avec plusieurs projets ?
On définit et teste d’abord les actions autorisées pour un projet. On teste ensuite un second projet, y compris avec des références croisées explicitement interdites. Seule une séparation réellement appliquée fonde les tâches suivantes.
Sources : MCP : autorisation, version du 28.07.2026 (lien externe) · MCP : limites de confiance et transfert de jetons (lien externe) · OWASP : autorisation par appel et objet (lien externe) · OWASP : gérer les secrets (lien externe) · OWASP : limiter les injections de prompt (lien externe)
Les fonctions et le périmètre d’exploitation concrets sont convenus selon l’environnement.
