1. L’empreinte de baseline
Au premier contact la passerelle calcule un hash canonique de l’ensemble d’outils annoncé du serveur et le stocke comme baseline approuvé :- Le hash couvre le nom, la description et le schéma JSON d’entrée de chaque outil — exactement la surface qu’un rug pull altérerait (un outil gagnant un argument d’exfiltration, ou une description militarisée pour l’injection de prompt fait basculer le hash).
- Il est indépendant de l’ordre : un serveur réordonnant sa liste d’outils, ou réordonnant les clés à l’intérieur d’un schéma, ne ressemble pas à un changement. Seul un véritable changement de définition déplace le hash.
2. Le cycle de vie du statut de schéma
Chaque serveur enregistré porte unschema_status. Les états et comment ils
affectent le fait que les outils du serveur soient servis :
| Statut | Signification | Outils servis ? |
|---|---|---|
| (non baseliné) | Première utilisation — aucun baseline enregistré encore. | Posture de découverte : Oui (trust-on-first-use — le schéma courant est capturé comme baseline). Posture stricte : Non — voir pending ci-dessous. |
verified | Le schéma en direct correspond au baseline approuvé. | Oui |
changed | Dérive détectée — le schéma en direct diffère du baseline. | Non — échoue fermé |
pending | Un serveur non baseliné sous une posture stricte (pas de trust-on-first-use) — en attente d’approbation. | Non — échoue fermé |
quarantined | Un admin a retenu le serveur. | Non — échoue fermé |
Les trois états fermés —
changed, pending, quarantined — empêchent tous
les outils du serveur d’être servis à travers la passerelle. verified sert
toujours ; un serveur non baseliné ne sert que sous la posture de découverte
(trust-on-first-use) et est retenu en pending sous la posture stricte. La
dérive ne passe jamais silencieusement.3. Ce qui se passe en cas de dérive
Quand une re-vérification constate que le schéma en direct ne correspond plus au baseline :Le statut bascule en changed
Le
schema_status du serveur devient changed et l’horodatage de la dérive
est enregistré.Les outils cessent d'être servis
La passerelle échoue fermé : les outils de ce serveur sont retirés de la
surface MCP unifiée, de sorte qu’un agent ne peut pas appeler les définitions
modifiées.
La console le fait remonter
La dérive apparaît pour revue afin qu’un admin puisse comparer le nouvel
ensemble d’outils à celui approuvé.
4. Ré-approuver un serveur ayant dérivé
Le re-baselining est un seul appel (ou l’action console) :verified. (Mettre un
serveur en quarantaine est une action distincte, pour quand vous décidez que
le changement est hostile — approve_schema ne fait que re-baseliner vers
verified.) L’action est écrite dans la piste d’audit.
5. Où cela s’inscrit
La détection de dérive de schéma est la moitié couche-schéma de la défense contre le rug pull ; l’autre moitié est l’évaluation par appel sur la surfacemcp (chaque tools/call est vérifié contre votre politique au dispatch).
Ensemble elles couvrent à la fois « les définitions ont changé » et « cet appel
précis est dangereux ».
Défense contre le rug pull
L’image complète du rug pull — baseline de schéma plus évaluation par appel.
Aperçu de la sécurité MCP
La passerelle MCP, les skills, et les credentials.
Empoisonnement d'outils MCP
La menace contre laquelle cette machine à états défend.
Événements d'audit MCP
Surveiller les changements de schéma et les décisions de la passerelle.