Ce qui est prouvé, et ce qui ne l’est pas.
Une affirmation de sécurité qu’on ne peut pas réfuter n’est pas une affirmation, c’est de la publicité. Cette page déclare le niveau de preuve de chaque profil avec les mots mêmes qu’emploie le plan interne, pour qu’un lecteur extérieur puisse le confronter à ce qui est publié.
Les quatre niveaux
Chaque lot de travail se clôt en déclarant l’un d’eux, à côté de PASS, FAIL ou SKIP et des dénominateurs. Il n’y a pas de cinquième niveau ni de milieu confortable.
conceptionSpécifié et relu. Rien n’a été exécuté. Décrire comment quelque chose fonctionnerait ne vaut jamais un PASS.
simuléExécuté contre des fixtures, le fournisseur et les approbations étant identifiés comme des fixtures. Ce n’est pas une intégration et ce n’est jamais décrit comme telle.
intégration réelleExécuté contre un fournisseur réel, dans un compte autorisé, pour le profil exact testé — et pour lui seul.
non évaluéAucune sonde n’a tourné. C’est la valeur par défaut, pas un oubli, et cela ne compte jamais comme réussi.
Prouvé aujourd’hui
Les règles ci-dessus existent pour garder cette liste honnête, pas pour ne pas en avoir. Chaque point est une propriété du code, vérifiable sans nous le demander.
Une autorisation se consomme une seule fois
L’usage unique est un littéral au niveau du type dans le schéma du grant, et toute autre valeur est rejetée à la validation. Ce n’est pas un compteur que quelqu’un a pensé à décrémenter.
Les receipts se vérifient sans réseau
Il n’y a aucun appel réseau sur tout le chemin de vérification. Un receipt contrôlé dans cinq ans ne dépend ni de notre disponibilité ni d’un registre mutable.
Un adaptateur ne peut pas redéfinir ce qui a été accordé
Le client du fournisseur reçoit l’effet et une clé d’idempotence. Il ne reçoit jamais le grant ni l’autorité, il n’a donc rien à élargir.
Une mutation n’est jamais rejouée à l’aveugle
La réconciliation est le seul second appel à un fournisseur. Si la réconciliation elle-même échoue, le résultat est consigné comme indéterminé plutôt que supposé.
Le cloud ne peut pas élargir le plafond local
Le contrôle de politique locale est deny-only et fixe le tenant, la passerelle, le fournisseur, l’empreinte de l’adaptateur, l’autorité, les versions de politique acceptées, les règles de ressources et les limites monétaires. Il exige qu’une politique locale signée soit installée, faute de quoi le mode production refuse de démarrer.
Deux d’entre elles dépendent du déploiement : le plafond local exige une politique signée installée — en bac à sable sans politique il n’y a pas de plafond — et l’isolation des identifiants dépend du connecteur et du mode de déploiement choisis.
Les règles qui la rendent réfutable
- SKIP et non évalué ne comptent jamais comme un PASS.
- Une route sans sonde reste non évaluée. Elle n’hérite pas de la couverture d’une autre route.
- Le manifeste de couverture est une affirmation que le harnais de test doit pouvoir réfuter : si un contournement obtient un effet, la couverture déclarée devient contredite et la barrière échoue, même là où le fichier dit protégé.
- L’applicabilité est fixée avant que le runtime existe. Rien ne peut être marqué non applicable après avoir échoué.
- Tester un connecteur avec MFA ou quorum ne crédite pas un profil délégué à plusieurs étapes. Chaque affirmation nomme la chaîne et les versions qu’elle a testées.
- Les fixtures d’approbation ne sont ni un vrai MFA ni un vrai quorum, et une approbation simulée n’est jamais présentée comme humaine.
Ce qu’établit un receipt
Un Action Receipt prouve ce qui est passé par un Guardian enrôlé et le résultat que ce Guardian a pu établir. Un dépassement de délai est réconcilié en relisant chez le fournisseur, jamais rejoué à l’aveugle, et un résultat ambigu reste indéterminé au lieu d’être arrondi en succès.
Menaces nommées
Celles que nous atténuons, avec les brèches encore ouvertes.
Empoisonnement d’outils
Un hôte altère les descriptions d’outils pour que le modèle les appelle avec des arguments manipulés. Le catalogue d’outils fait autorité côté serveur — le serveur sert une liste figée et n’accepte aucune définition d’outil venant du client — et une liste d’autorisation limite ce qu’un client donné peut invoquer. Brèche ouverte : le manifeste servi n’est pas encore signé, son intégrité repose donc sur le transport.
Hôte ou client hostile
Le processus qui orchestre l’agent est lui-même hostile. Les scopes et la liste d’outils autorisés bornent les dégâts, chaque appel est audité et les clés se révoquent immédiatement. Brèche ouverte : une clé d’API est une credential au porteur, un hôte hostile qui en détient une agit donc comme le tenant jusqu’à révocation. Des jetons délégués de courte durée existent pour resserrer cela.
Injection de prompt via le contenu analysé
Un message tente d’injecter des instructions à travers le contenu analysé. Le guard classe et analyse ; il n’exécute pas ce qu’il lit, et la réponse porte des faits extraits plutôt que des instructions. Un effet hors contrat est refusé, qu’un détecteur ait vu l’injection ou non.
Changement de catalogue après relecture
Ce que vous avez approuvé n’est pas ce qui se lance ensuite. Un instantané épinglé est comparé au catalogue actuel et un changement substantiel demande une relecture au lieu de s’appliquer tout seul.
Usurpation dans un annuaire
Un tiers publie une fiche falsifiée. Le point de terminaison canonique et le manifeste sont servis par le service lui-même. Brèche ouverte : pas encore de signature de manifeste publiée ni de vérification de domaine.
Hors garantie
Nommé, pas sous-entendu.
- L’administrateur de l’hôte. Qui contrôle la machine contrôle ce qui y tourne.
- Un Guardian ou une clé de signature compromis.
- Les actions menées hors du chemin d’exécution enrôlé. Le receipt est muet à leur sujet par construction.
- Un canal auxiliaire que personne n’a observé.
- Le dommage que le mandat approuvé permettait déjà. Autoriser ne prouve ni la vérité, ni la bénignité, ni la justesse.
- La propriété juridique du compte fournisseur, qu’aucun receipt n’établit.
Aucune observation universelle
Il n’existe aucune vue de l’ensemble du contexte d’un hôte, de son courrier, de sa mémoire ou du trafic des autres serveurs MCP. Ce qui est connu, c’est le catalogue propre au bridge, les appels qui le traversent et les instantanés importés explicitement. Une empreinte de configuration décrit un profil ; ce n’est pas une attestation cryptographique de l’hôte. Un conteneur seul, sans démonstration de son réseau et de ses montages, ne prouve pas l’isolation.
À propos des signatures
La signature d’un manifeste atteste l’intégrité et la provenance. Elle n’atteste pas la bénignité, et aucun badge — le nôtre compris — ne rend un serveur MCP sûr.
Comment change une affirmation de cette page
Pas en la réécrivant. Une nouvelle affirmation de capacité est vérifiée contre le code et datée avant de paraître, et le tableau de vérification vit dans le dépôt, à côté du texte. Une page qui a échoué à un contrôle garde l’échec visible plutôt que d’être discrètement réécrite — une exécution ultérieure crée une nouvelle version au lieu de remplacer l’ancien résultat. Il n’y a ni programme de bug bounty financé ni audit indépendant par un tiers, et ni l’un ni l’autre ne seront annoncés avant d’exister.
Statut de cette page
Les niveaux de preuve et les règles ci-dessus sont en vigueur aujourd’hui. Le tableau par profil publiera les résultats observés de chaque lot de travail à mesure qu’ils se clôturent, avec dénominateurs, versions et configuration. Tant qu’un profil n’a pas son propre résultat contre un fournisseur réel, il figure comme simulé ou non évalué — jamais extrapolé depuis un mock ni depuis un autre connecteur.