Chapitre 12 — Durcissement du protocole et défenses

Douzième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où chaque menace du chapitre précédent reçoit une défense, où aucune des défenses n'est une balle d'argent, et où leur composition est la seule chose qui produit une posture vraiment déployable.

Pourquoi ce chapitre existe

Le protocole ne devient pas sûr en étant déployé. Il devient sûr en étant déployé à l'intérieur d'une pile qui compense les hypothèses que le protocole nu fait. Le Chapitre 11 a catalogué les menaces ; ce chapitre parcourt les défenses à profondeur d'ingénierie. L'attestation cryptographique des capacités ferme les classes de découverte et d'escalade de capacités. La discipline des scopes OAuth 2.1 avec tokens délégués à l'utilisateur ferme les classes Deputy et Passthrough. Les durées de vie de session bornées ferment la classe Hijack. Le sandboxing contient les compromissions que la prévention manque. L'approbation human-in-the-loop attrape les opérations destructives que le reste de la pile devrait automatiser pour être utile. Chaque défense laisse un risque résiduel ; la composition est ce qui rend les résiduels assez petits pour être défendus en pratique.

12.1 AttestMCP : attestation cryptographique des capacités

La première défense adresse un problème qui traverse presque toutes les menaces : l'hôte n'a pas de moyen de vérifier que le serveur auquel il parle est ce qu'il prétend être. AttestMCP — aussi appelé MCPSec ou manifestes de capacités signés — ajoute une couche d'attestation cryptographique au-dessus de la structure de messages du protocole. Un éditeur détient une clé de signature longue durée enregistrée auprès d'un répertoire ou d'un journal de transparence. Le manifeste complet des capacités est haché et signé à la sortie. L'hôte vérifie la signature à initialize contre la clé de l'éditeur en fichier, et admet le serveur, le met en quarantaine, ou refuse la connexion.

Les bénéfices sont réels. Les typosquats ne peuvent pas produire une signature valide de l'éditeur légitime. L'escalade de capacités via les notifications list_changed devient détectable parce qu'un nouveau manifeste exige une nouvelle signature. Une politique à grain fin — « faire confiance aux serveurs publiés par GitHub pour les dépôts mais pas pour les e-mails » — devient applicable parce que l'identité de l'éditeur est désormais vérifiable plutôt qu'affirmée. Les coûts sont réels aussi : les éditeurs doivent exploiter une infrastructure de signature, les journaux de transparence ont besoin d'un opérateur digne de confiance, et la couche de politique de l'hôte doit comprendre la révocation. Le cadrage honnête : AttestMCP est une ingénierie substantielle, pas une case à cocher. Et il y a une lacune à nommer : le manifeste signe ce que le serveur dit de lui-même, pas ce qu'il fait à l'exécution. Une déclaration signée d'un outil bénin peut quand même livrer une implémentation qui exfiltre. L'attestation est nécessaire mais insuffisante, raison d'être du reste du chapitre.

12.2 Scopes OAuth 2.1 et durées de vie de session bornées

Le second cluster resserre le modèle de credentials et de session. Les flux d'OAuth 2.1 sont mûrs ; l'ingénierie consiste à les utiliser correctement. La première discipline est les scopes étroits — ne demander que ce dont la surface d'outils déclarée a besoin. Plus le scope est serré, plus le rayon d'explosion est petit. La discipline est plus dure qu'il n'y paraît parce que les services en amont définissent souvent les scopes grossièrement et que le chemin étroit est fastidieux ; les scopes larges marchent du premier coup et donnent l'impression d'avancer. Le coût des scopes étroits est payé par l'ingénieur ; le coût des scopes larges est payé par l'utilisateur quand quelque chose tourne mal.

La défense contre le Confused Deputy que la seule discipline des scopes ne fournit pas, ce sont les tokens délégués à l'utilisateur. Là où l'amont le soutient, chaque utilisateur complète son propre flux OAuth, et le serveur agit sur le token de l'utilisateur plutôt que sur sa propre identité de service. Le Deputy disparaît parce que le serveur n'agit plus de sa propre autorité. Le Token Passthrough a un remède différent : ne pas faire passer les tokens. Le serveur détient ses propres credentials, établis au moment de l'enregistrement, et la frontière entre hôte et serveur ne porte jamais de token. Les durées de vie de session bornées adressent le hijack : minutes pour les opérations à haut risque, heures pour les routinières, avec une identité de workflow durable superposée pour qu'une tâche de plusieurs heures puisse renouveler ses sessions de transport sans redemander à l'utilisateur toutes les quinze minutes. La liaison de capacités par session et la reconfirmation des capacités au renouvellement de session complètent la discipline — les deux sont du travail de gestion d'état que l'hôte doit faire explicitement, et beaucoup d'implémentations ne l'ont pas fait.

12.3 Sandboxing et isolation à l'exécution

Le troisième cluster reconnaît que toutes les menaces ne peuvent pas être prévenues et qu'une posture défendable doit contenir les dégâts quand la prévention échoue. Le sandboxing de processus pour les serveurs locaux — seccomp sur Linux, App Sandbox sur macOS, AppContainer sur Windows, gVisor pour une isolation plus forte — refuse par défaut l'accès au système de fichiers, au réseau et aux processus, et n'accorde que les accès spécifiques dont le serveur a besoin. Un serveur compromis qui tenterait de lire un fichier de mots de passe ou d'exfiltrer vers un endpoint attaquant verrait l'opération refusée au niveau OS, non parce que le code du serveur s'en abstient mais parce que le sandbox s'y oppose. Les politiques réseau pour les serveurs distants — mTLS, endpoints en liste autorisée, filtrage egress — rétrécissent la surface qu'un serveur distant compromis peut atteindre. L'isolation de contenu à l'intérieur de l'hôte traite le contenu retourné avec une suspicion appropriée avant qu'il n'atterrisse dans le contexte du modèle : marqueurs « non fiable », assainissement HTML, refus de suivre les URL incorporées. Le sandboxing d'appels d'outils par des politiques sensibles aux capacités laisse l'hôte examiner les arguments d'appel et décider d'autoriser, refuser ou escalader vers une approbation utilisateur. Un risque spécifique à nommer est l'exfiltration par canal latéral à travers des outils légitimes — un modèle malveillant encodant des credentials dans une requête de recherche — que la couche de politique attrape en inspectant les arguments plutôt que les endpoints. L'isolation de la chaîne logistique ferme la boucle : le hash du binaire est vérifié à l'installation et à la mise à jour contre une valeur signée dans le journal de transparence, pour qu'un binaire altéré ne puisse pas s'exécuter même si le manifeste vérifie.

12.4 Portes d'approbation human-in-the-loop

Le quatrième cluster reconnaît que certaines opérations ne devraient jamais être automatisées. Les appels destructifs, irréversibles ou à fort impact — envoyer de l'argent, supprimer des fichiers, modifier la production — méritent une décision humaine explicite au moment où ils arrivent. Le mécanisme, c'est la porte HITL, et l'ingénierie consiste à la rendre efficace sans rendre le système inutilisable. Catégoriser par réversibilité : les opérations en lecture seule procèdent automatiquement ; celles qui changent l'état franchissent une porte. Présenter de manière signifiante : un modal qui dit « Autoriser l'exécution de l'outil ? » est un tampon en caoutchouc ; une porte utile montre l'outil, les arguments complets, la conséquence en langage clair, et la provenance. Évitez la fatigue d'approbation par approbation contextuelle par lot, où un utilisateur qui initie « envoyer les factures aux clients du trimestre dernier » approuve le lot une fois plutôt que chaque e-mail vingt fois. Routez les opérations à fort enjeu en out-of-band — token matériel, second appareil, authentification renforcée empruntée à l'industrie financière. Gardez les opérations visibles, auditables et annulables. Les appels pilotés par sampling passent par les mêmes portes que les appels initiés par l'agent ; le canal latéral de l'inférence initiée par le serveur n'a pas le droit de se terminer en effet de bord sans que l'utilisateur ne le remarque.

Ce que prépare le Chapitre 12

La moitié sécurité du tableau d'ingénierie est maintenant complète. L'autre moitié — frameworks, patrons de déploiement, caractéristiques de performance, et tests qui confirment que le système fonctionne en production — est ce que les chapitres restants prennent en charge. Le Chapitre 13 ouvre cet arc en parcourant les frameworks et les intégrations cloud qui se sont installés en 2025 et 2026 : Strands avec Amazon Bedrock, les patrons de couche d'état AWS, le Microsoft Agent Framework, LangChain et Semantic Kernel. Les frameworks comptent parce que personne ne construit du MCP de production à partir du protocole brut, et les choix parmi eux façonnent la posture d'ingénierie et de sécurité d'une manière que la seule couche protocolaire ne détermine pas.

Prochaine étape — Chapitre 13 : Frameworks et intégration cloud. Strands avec Bedrock, la couche d'état AWS, l'Agent Framework de Microsoft, LangChain, Semantic Kernel, et les trois patrons d'intégration de production sur lesquels les équipes convergent indépendamment.