La frontière de confiance
Le modèle peut proposer un appel d’outil. Le code applicatif déterministe doit authentifier l’appelant, autoriser précisément l’opération et sa cible, valider les arguments, contrôler l’exécution et consigner l’effet de bord qui en résulte.
Un serveur MCP doit exposer des capacités métier soigneusement sélectionnées, telles que get_incident_context ou restart_approved_service, et non des primitives génériques comme des requêtes HTTP sans restriction, l’exécution d’un shell ou du SQL arbitraire.
Couches de sécurité requises
Propagez une identité attribuable — utilisateur délégué ou charge de travail — à travers chaque invocation d’outil.
Accordez une autorisation propre à chaque capacité plutôt que d’hériter de l’ensemble des accès applicatifs de l’appelant.
Rejetez les champs inconnus, les identifiants invalides, les plages dangereuses et les entrées surdimensionnées avant l’exécution de la logique métier.
Évaluez le sujet, l’action, la ressource et l’environnement indépendamment du raisonnement produit par le modèle.
Plafonnez la taille des réponses, classifiez les champs et expurgez les secrets avant que la sortie de l’outil n’entre dans le contexte du modèle.
Consignez l’appel normalisé, la décision de politique, l’identité de l’exécuteur et le résultat effectif.
Un flux d’invocation défendable
- L’agent sélectionne un outil nommé dans un manifeste explicitement autorisé.
- La passerelle associe la requête à un utilisateur authentifié ou à une identité de charge de travail.
- Une validation stricte du schéma normalise les arguments et rejette ceux qui sont malformés.
- Un service de politique autorise l’action exacte sur la cible exacte.
- Un exécuteur déterministe réalise l’opération avec des identifiants aux privilèges strictement limités.
- La réponse est bornée, classifiée et expurgée avant d’être renvoyée au modèle.
- L’intégralité de la décision et de son résultat est inscrite dans la piste d’audit.
Séparation des responsabilités
Le modèle ne doit pas détenir l’identifiant qui exécute sa proposition, et l’exécuteur ne doit pas déduire une autorisation d’un raisonnement en langage naturel.
Menaces et contrôles correspondants
| Menace | Contrôle | Vérification |
|---|---|---|
| Action privilégiée provoquée par injection d’instructions | Décision de politique indépendante et liste d’opérations autorisées | Les tests adversariaux sur les contenus récupérés ne peuvent pas élargir le périmètre |
| SSRF via un outil de récupération générique | Connecteurs propres au domaine et listes de destinations autorisées | Les destinations privées, link-local ou non approuvées sont refusées par défaut |
| Accès intertenant | Identité liée au tenant et contrôles imposés par le stockage | Tests d’autorisation négatifs aux couches outil et stockage |
| Fuite de secrets dans les résultats d’outils | Classification des champs, expurgation et plafonnement des résultats | Les secrets canaris n’entrent jamais dans le contexte du modèle |
| Rejeu d’une requête destructive | Autorisation de courte durée, nonce et clé d’idempotence | Les requêtes répétées ne dupliquent pas les effets de bord |
Liste de contrôle pour la revue d’architecture
- Chaque outil peut-il être rattaché à une capacité métier et à un responsable identifié ?
- Les opérations d’écriture se distinguent-elles des lectures, tant dans la politique que dans la télémétrie ?
- Un document récupéré peut-il modifier l’autorisation, ou seulement influencer la proposition ?
- Les identifiants de service sont-ils inaccessibles à l’environnement d’exécution du modèle ?
- Les enquêteurs peuvent-ils reconstituer, plusieurs mois plus tard, les arguments exacts et les effets de bord ?
- Le système refuse-t-il l’opération par défaut lorsque les dépendances d’identité, de politique ou d’audit sont indisponibles ?
Périmètre d’attribution et éléments probants
Cette note d’architecture, publiée à titre de source primaire, repose sur la pratique déclarée de Salah Awad en matière de conception de surfaces d’outils MCP et de systèmes de défense en profondeur. Elle ne prétend ni que MCP fournit à lui seul ces contrôles, ni qu’une mise en œuvre confidentielle particulière a fait l’objet d’une certification indépendante.