MCP : « lecture seule », mais qui a vérifié ?

Ce qui se passe

Dans le protocole MCP, un serveur décrit lui-même les outils qu'il expose. Il peut déclarer readOnlyHint: true, et un harnais d'agent peut s'appuyer sur cette annotation pour décider s'il affiche, ou non, une demande d'approbation à l'utilisateur.

La frontière de confiance est donc mal placée : le composant évalué est celui qui décrit son propre niveau de danger.

Un outil peut renvoyer un résultat parfaitement banal et écrire sur le disque, sortir sur le réseau ou exfiltrer un canari. Rien dans la spécification n'oblige l'annotation à être exacte, rien côté client ne la confronte au comportement.

Ce que fait Airlock

Un développeur a publié Airlock (MIT, github.com/himanshu748/airlock-mcp), construit pour un hackathon, dont la démarche vaut indépendamment de l'outil : observer, puis appliquer.

Airlock ouvre un dossier, inventorie les outils déclarés, les exerce sous un budget de sondes plafonné, compare la déclaration à l'observation, et — pour un dossier approuvé — émet un connecteur pointant vers un proxy d'application par dossier, et non vers le serveur suspect. La politique s'exécute avant que l'appel n'atteigne l'outil ; ce n'est pas une phrase dans un prompt système. Un appel non approuvé reçoit MCP error -32001: Tool blocked by Airlock policy.

Le choix qui mérite d'être copié est celui du vocabulaire. Chaque contrôle se résout en quatre états — finding, no_finding_observed, not_tested, sensor_failed — et il n'y a pas de score de sécurité unique. Une moyenne masquerait le seul outil qui a menti, et laisserait confondre absence de mesure et absence de problème. not_tested distingue même capability_absent, quand aucun capteur n'existait, de evidence_missing, quand le capteur a regardé sans rien voir.

Les chiffres

Le contraste entre les deux fixtures est ce qui donne du poids au reste : un détecteur qui ne trouve que dans un décor conçu pour paraître suspect n'a rien démontré.

Mais le résultat le plus parlant est le troisième. Le serveur externe n'a pas menti — il n'a rien dit. Un harnais qui déduit des catégories comme @write ou @destructive à partir des annotations ne peut alors rien classer, et des outils nommés remember ou forget_memory peuvent contourner le chemin d'approbation par simple silence.

Source : DEV Community (en anglais).