MCP a besoin d'une poignée de main de confiance : l'admission attestée des serveurs d'outils

De quoi parle-t-on ?

Le 22 mai 2026, Alfredo Metere a publié sur arXiv le papier Attested Tool-Server Admission: A Security Extension to the Model Context Protocol (2605.24248, cs.CR). Le travail naît d’un besoin opérationnel concret — permettre à l’agent Enclawed de se connecter aux serveurs MCP externes de Google (Gmail, Calendar, Drive) sans avoir à choisir entre la confiance aveugle et le refus total — et se généralise en un additif propre et rétrocompatible au protocole.

L’argument part d’une observation structurelle sur MCP tel qu’il est livré aujourd’hui : le protocole standardise comment un hôte LLM et un serveur d’outils échangent des messages, mais il n’a aucune notion native de quels serveurs un hôte peut utiliser, à quelle sensibilité, ou lesquels des outils d’un serveur sont dans le périmètre. Un hôte lit la liste d’outils auto-déclarée par un serveur et dispatche les appels. C’est exactement le modèle de confiance qu’hérite une connexion tierce non médiée, et c’est précisément le trou qui rend les déploiements accrédités essentiellement impossibles aujourd’hui.

Le papier propose trois petites additions, formulées en termes normatifs RFC 2119 de sorte qu’elles puissent être adoptées comme addendum MCP plutôt que réinventées. Il arrive deux jours après le document du NSA AISC Model Context Protocol: Security Design Considerations for AI-Driven Automation — les deux documents arrivent à la même conclusion par les deux extrémités de la pile.

Comment ça marche

mcp-attested ajoute trois vérifications en couches au handshake MCP. Un hôte non étendu qui ne connaît pas le document well-known l’ignore et se comporte exactement comme aujourd’hui : le design est strictement additif.

Mécanisme                    Où il vit                            Ce qu'il filtre
---------------------------  -----------------------------------  --------------------------
Signed clearance assertion   URI well-known du serveur            Admission du serveur
Per-server tool allowlist    Configuration de l'hôte, deny-default Dispatch outil par outil
Flavor-gated enforcement     Mode runtime de l'hôte               Warn vs. hard-deny

Attestation de clairance signée. Chaque serveur MCP publie à une URI well-known un petit document signé hors-ligne. L’hôte vérifie l’attestation contre une racine de confiance pinned avant de dispatcher tout appel. Le serveur n’est plus admis sur la seule base d’« il implémente MCP » : il est admis parce qu’une racine de confiance que l’hôte a choisi de reconnaître a vouché pour lui à un niveau de clairance donné.

Allowlist per-server deny-by-default. Admettre un serveur n’est pas synonyme de faire confiance à tous ses outils. L’hôte configure, pour chaque serveur admis, le sous-ensemble explicite des outils auxquels il acceptera de dispatcher. Tout ce qui sort de l’allowlist est refusé sans jamais atteindre l’étape de sélection d’outil du modèle — ce qui retire au modèle lui-même (couche de défense la plus lente et la plus coûteuse) la responsabilité de raisonner sur l’appel.

Mode d’enforcement à deux saveurs. Les mêmes contrôles tournent soit en saveur warning (log et passe), soit en saveur enforcing (log et refuse). Un déploiement régulé peut livrer la saveur enforcing sans recours opérationnel ; un déploiement développeur peut rester en warning le temps qu’une équipe stabilise ses allowlists. Chaque décision — admit, deny, warn — est écrite dans un journal d’audit infalsifiable, ce qui rend la décision de dispatch revuable a posteriori.

Le papier accompagne le design d’un format de fil, d’un algorithme de vérification, d’une analyse de sécurité et d’une évaluation adversariale pilotée par LLM. Une ligne de travaux séparée, MCPShield (arXiv:2602.14281) publiée en février 2026, adopte une approche complémentaire de couche cognitive — probing métadonnées avant invocation, projection isolée pendant invocation, raisonnement périodique après — et se lit le plus utilement avec ce papier, pas contre lui.

Pourquoi c’est important

Le modèle de menace MCP avec lequel l’industrie patauge depuis dix-huit mois traite l’hôte comme l’autorité de confiance et le modèle comme le gardien. Les deux choix sont faux, de façons différentes. L’hôte n’a aucune prise au niveau protocolaire sur l’identité du serveur. Et le modèle n’est pas une frontière de sécurité : c’est un prédicteur probabiliste de tokens suivants, qui peut se laisser parler d’un refus.

Les conséquences MCP-spécifiques de laisser ce trou non bouché sont désormais bien documentées. La CSI du NSA AISC du 20 mai 2026 catalogue huit classes de faiblesses, dont les serveurs de spoofing de capacités et l’enregistrement d’outils non authentifié. Les rapports publics — les findings WhatsApp MCP et GitHub MCP d’Invariant Labs, la vague de CVE MCP backend du printemps 2026 — ont montré qu’un serveur malveillant ou compromis peut transformer des dispatchs d’outils routiniers en exfiltration ou en corruption de système de fichiers. Aucun de ces incidents n’a requis un prompt astucieux ; ils ont juste requis que l’hôte croie le serveur sur parole.

Ce qui rend mcp-attested intéressant, c’est qu’il sort entièrement la décision de confiance du modèle. Le modèle n’a jamais à choisir de dispatcher vers un serveur non attesté, parce que le chemin de dispatch de l’hôte refuse avant même que la sélection d’outil du modèle ne s’exécute. C’est la même forme que la décision pré-handshake de TLS : le code applicatif n’a pas le droit de « considérer » la connexion à un serveur dont le certificat est invalide.

Le prix est un peu de travail opérationnel supplémentaire — gérer une racine de confiance pinned, maintenir des allowlists per-server, distribuer des documents de clairance signés. La thèse du papier, qui sonne juste après la récente vague de CVE MCP, est que c’est le prix d’être seulement capable d’accréditer un déploiement MCP.

Défenses

Quatre éléments à retenir du papier, même si votre stack n’adopte pas mcp-attested à la lettre.

1. Pinner une racine de confiance pour les serveurs MCP et refuser le reste. Même sans schéma de clairance formel, les runtimes d’hôte peuvent livrer une liste d’empreintes auxquelles ils accepteront de dispatcher, le reste produisant une erreur dure plutôt qu’un silence d’ignorance.
2. Faire des allowlists par serveur le défaut, pas une option. Traiter « ce serveur expose un outil que je n’ai pas énuméré » comme un bug de déploiement, pas un événement d’usage. L’ensemble des outils auxquels un hôte dispatchera réellement doit être explicite et versionné.
3. Séparer mode warning et mode enforcing, et livrer des journaux d’audit dès le premier jour. Même un hôte MCP de développement devrait écrire chaque décision d’admission et de dispatch dans un journal infalsifiable. Les incidents de production se reconstruisent depuis des logs qui n’existaient pas à l’instant T.
4. Lire ce papier avec la CSI du NSA AISC et MCPShield, pas en isolation. Les trois couvrent ensemble la couche protocole (Metere), la couche gouvernance (NSA) et la couche cognition runtime (MCPShield). Aucun n’est suffisant seul.

Statut

Élément	Référence	Date	Notes
Papier Attested tool-server admission	arXiv:2605.24248	22 mai 2026	Format de fil RFC 2119, clairance signée, allowlist, mode d’enforcement
Implémentation de référence	mcp-attested (cité dans le papier)	mai 2026	Livré dans les distributions enclawed-oss et enclaved selon §1
CSI MCP du NSA AISC	nsa.gov, U/OO/6030316-26	20 mai 2026	Huit classes de faiblesses, base défensive
MCPShield	arXiv:2602.14281	février 2026	Défense complémentaire de couche cognitive

MCP ne va pas perdre sa courbe de croissance dans les douze mois à venir. Ce qu’il peut perdre, c’est la convention selon laquelle « le serveur l’a dit » suffit à dispatcher un outil — et le papier de Metere est la première proposition concrète qui permet à un hôte de dire non avant même que le modèle ne soit consulté.