Polygraph : Notes de confiance comportementale pour les serveurs MCP

Les agents câblent des serveurs MCP tiers et font ensuite confiance à tout ce que les outils de ces serveurs retournent. Polygraph teste le comportement d'un serveur MCP avant que votre agent ne le fasse, et lui assigne une note de A à F soutenue par des preuves reproductibles.

Une note positive est une mesure, non une garantie — elle dit « cette surface d'outils exacte ne s'est pas mal comportée sous ces sondages », et parce que le harnais est ouvert et déterministe, n'importe qui peut le réexécuter et réfuter une mauvaise note. Cette falsifiabilité est tout l'intérêt.

Accueil / méthodologie : polygraph.so
CLI de recherche (npm) : polygraphso
Harnais de notation : @polygraphso/litmus (open source)

Ce qu'une note mesure

Polygraph se connecte à un serveur comme un agent le ferait — stdio pour les packages locaux, HTTP Streamable pour les URLs distantes — prend l'empreinte de sa surface d'outils exacte (tools/list → JSON canonique → sha256 → bytes32), puis exécute quatre catégories de sondage :

C-01 — Injection de sortie d'outil. Le serveur essaie-t-il de détourner l'agent ? Scan statique des noms, descriptions et schémas d'outils pour du contenu en forme d'injection (unicode invisible, imitation d'instructions, astuces markdown) plus des appels d'appât dynamiques qui vérifient si les sorties d'outils contrebandent des instructions.
C-02 — Surcharge de permissions / sortie réseau. Le serveur fait-il plus que ce qu'il prétend ? Signale les outils qui déclarent readOnlyHint: true mais portent des verbes destructeurs, et exécute le serveur dans un bac à sable Docker par défaut-refus renforcé où toute tentative de réseau sortant est un problème.
C-03 — Traitement des données sensibles. Le serveur fuit-il des secrets ? Place des valeurs de canari dans l'environnement et le répertoire de travail, exerce les outils, et scanne à la fois les sorties d'outils et la sortie réseau pour tout canari qui remonterait.
C-04 — Traitement des entrées adversariales. Le serveur reste-t-il robuste face aux entrées hostiles ? Exécute deux sondages sur les outils qui ne changent pas l'état, sans Docker requis : teste chaque outil avec des entrées malformées et surdimensionnées (échoue si le serveur plante, se bloque ou fuit une trace de pile non capturée — une erreur de validation propre ou un résultat bénin réussit) ; et alimente des chaînes de motif de jailbreak et scanne les sorties du serveur avec les scanners d'injection C-01, échouant seulement si le serveur émet du contenu en forme d'injection qu'il n'a pas simplement reflété de l'entrée (un écho littéral est exclu). Un échec C-04 plafonne la note globale à D.

Échelle de notation

Note	Signification
A	A réussi les quatre catégories. Pas d'injection, pas de sortie réseau inattendue, pas de fuite de données, pas d'échec d'entrée adversariale.
B	Contrôles d'injection et de fuite de données réussis ; la sortie réseau n'a pas été vérifiée. Le plafond pour toute exécution sans bac à sable Docker local — y compris tous les serveurs distants (HTTP), qui ne peuvent pas être mis en bac à sable.
D	Sortie réseau inattendue / surcharge de permissions (C-02) ou un échec de robustesse d'entrée adversariale (C-04 : plantage, fuite d'internals, ou amplification). Pas d'injection ou de fuite → plafonné à D.
F	Disqualifiant : injection active de sortie d'outil (C-01) ou fuite de données sensibles (C-03) — un serveur qui nuirait à un agent qui lui fait confiance.

Lire un B. Sous la méthodologie actuelle, la sortie réseau ne peut être observée qu'en exécutant le serveur dans un bac à sable par défaut-refus local — donc un serveur MCP distant plafonne à B peu importe sa propreté. Un B distant est une limite de la mesure, non une marque contre le serveur ; ne le lisez pas comme « pire qu' » un A local, car les deux ne sont pas directement comparables. (Les notes C et E ne sont pas attribuées aujourd'hui ; C est réservée.)

Chaque note est accompagnée d'une justification en anglais clair — jamais une lettre nue. Voir references/methodology.md pour la logique décisionnelle complète et chaque sondage en détail.

Vérifier une note

Une recherche sub-seconde contre les notes publiées. Cela exécute la CLI lookup de polygraphso : elle lit une note publiée et n'installe ou n'exécute pas le serveur cible. npx récupère et exécute bien notre CLI — donc c'est une recherche, pas un contrôle « sans installation » ; épinglez la version dans tout contexte automatisé ou de confiance (par ex. avant que Bankr n'installe un serveur) :

$ npx polygraphso@<version> check npm/@modelcontextprotocol/server-filesystem
→ polygraph: A · litmus-v10 · 2026-06-26
→ details → polygraph.so/#checks

Les notes sont actives et couvrent la gamme complète. Parcourez l'ensemble actuellement noté avec polygraphso list, ou sur polygraph.so. Une note est une preuve ponctuelle — traitez votre propre exécution, ou l'attestation actuelle, comme la source de vérité plutôt que n'importe quelle lettre copiée dans un document.

Les refs sont préfixées par registre — le préfixe lève l'ambiguïté (redis existe sur npm, PyPI, et GitHub avec un contenu différent) : npm/…, pypi/…, github/…. Un serveur suivi mais non noté rapporte not available yet avec un lien de notification. Référence CLI complète : references/cli.md.

Vérifier avant de faire confiance (intégration Bankr)

Le plus haut cas d'usage à l'exécution : portes un serveur MCP à travers sa note avant que votre agent ne l'utilise, ne le paie, ou ne route une transaction via celui-ci. Polygraph est l'étape verify ; Bankr est l'étape execute. Deux vérifications, toutes deux requises :

La note répond à votre seuil. Par défaut (DEFAULT_PASSING) : accepter A/B, refuser D/F. Pour une action signée ou un paiement, relevez le seuil à un A local (PAYMENT_PASSING, ou gateDecision(…, { requireEgressVerified: true })): un serveur distant plafonne à B parce que sa sortie réseau n'a jamais été observée — donc un B est exactement le cas où l'exfiltration réseau n'a pas été testée. N'auto-routez pas une transaction Bankr via un B distant ; exigez un A local ou une revue manuelle.
L'empreinte correspond toujours. Une attestation n'est valide que pour la surface d'outils exacte qu'elle a notée. Recalculez l'empreinte de surface d'outils actuelle du serveur et exigez qu'elle soit égale à celle attestée avant d'agir — une vérification rug-pull intégrée contre un serveur noté-puis-échangé.
L'attestation est suffisamment digne de confiance pour l'action. readAttestation se lie à notre schéma EAS (fail-closed) et une Base RPC fixe, et gateDecision vérifie la révocation, l'expiration, et la liaison ref-serveur. Une note auto-signée est toujours forgeable, donc avant que Bankr route de la valeur exigez aussi une liste blanche d'attestateurs (gateDecision(…, { allowedAttesters })) et une version de méthodologie acceptée — ou, le plus fort, réexécutez le harnais ouvert (run_litmus) et comparez. La reproductibilité, non la signature, est ce qui rend une note digne de confiance.

Déposez le MCP tool verify_attestation en amont de l'exécution, ou utilisez l'assistant gateDecision.

Portez ceci dans la décision : une note est une mesure, non une garantie. Un serveur qui détecte le contexte de test pourrait se comporter pendant la notation et se mal comporter en production — l'evasion est la limite résiduelle divulguée. Gardez les propres gardes de vérification de transaction de Bankr activées, même pour un A.

Motifs complets, la config serveur MCP, et un exemple travaillé « vérifier-puis-exécuter » : references/bankr-integration.md.

★ Faire noter votre projet

Exécutez le harnais ouvert sur votre propre serveur MCP, obtenez une note A–F plus un bundle de preuves reproductibles, et publiez-le onchain pour que les agents puissent le vérifier :

# Notez votre serveur end-to-end (ref npm, URL https, ou chemin local)
npx -y -p @polygraphso/litmus polygraphso-litmus litmus npm/@your-scope/your-mcp-server

Vous obtenez la note, les verdicts par catégorie, l'empreinte de votre surface d'outils, et un bundle de preuves adressé par contenu. Publier cette note comme une attestation EAS onchain sur Base (pour que d'autres agents puissent la rechercher et la vérifier) est un transfert en une étape — voir references/methodology.md.

Préférez ne pas l'exécuter vous-même ? Demandez une note ou soyez notifié quand la vôtre est publiée sur polygraph.so.

Une ligne pour les builders : vérifiez n'importe quel serveur MCP avant que votre agent ne l'utilise avec npx polygraphso check <server>, et faites noter votre propre serveur sur polygraph.so.

Exécuter le harnais localement

Le harnais est le même moteur ouvert, déterministe qui produit les notes publiées :

npm i -g @polygraphso/litmus        # ou utiliser npx, ci-dessus
polygraphso-litmus litmus npm/@modelcontextprotocol/server-filesystem
polygraphso-litmus litmus https://example.com/mcp --bearer "$TOKEN"
polygraphso-litmus litmus ./path/to/local-mcp-server --json

Node ≥ 18. Docker est optionnel mais recommandé — sans lui le sondage de sortie réseau (C-02) est ignoré et la note est plafonnée à B (comme l'est toute cible distante/HTTP, qui ne peut pas être mise en bac à sable).
--bearer est envoyé comme en-tête Authorization à la cible. Ne le passez que sur un distant que vous faites explicitement confiance et que vous avez épinglé ; utilisez un token scoped, de courte durée — jamais sur une cible auto-découverte ou non fiable.
Les codes de sortie sont CI-friendly : non-zéro pour une note échouée (D/F), zéro pour A/B — déposez-la dans un pipeline pour portes les dépendances.

Les drapeaux, vars env, sortie --json, et les sous-commandes check / list sont tous dans references/cli.md.

Portes votre CI sur les notes

Transformez la note en vérification de build : la porte CI polygraph échoue un build quand un serveur MCP ou une Agent Skill note D/F. Ajoutez l'action GitHub à un repo — épinglez-la à un SHA de commit (pas la balise mutable @v1) et déclenchez sur pull_request, jamais pull_request_target :

on: [pull_request]                          # pas pull_request_target
# …
- uses: polygraphso/litmus@<commit-sha>     # épinglez un SHA pour une porte de sécurité
  with:
    servers: |                              # nommez les cibles explicitement (recommandé)
      npm/@modelcontextprotocol/server-filesystem
    skills: |
      ./my-skill

— ou exécutez-la n'importe où avec npx @polygraphso/litmus@<version> ci (épinglez la version). Noter un serveur exécute son code (la sortie réseau est en bac à sable Docker, mais il s'exécute quand même), donc sur un repo public gardez l'auto-découverte off (le défaut) et nommez les cibles explicitement plutôt que de noter les .mcp.json / .vscode / .cursor contrôlés par PR. Les cibles non-gradables avertissent sauf strict. Une note de skill est une analyse statique, non une preuve comportementale — traitez une skill qui exécute du code d'installation ou porte des instructions de transaction comme ayant besoin d'une revue manuelle indépendamment de sa lettre. Configuration complète, entrées, et notes de sécurité : references/ci-gate.md.

Pourquoi un serveur a obtenu la note X

Chaque exécution affiche la méthodologie, le verdict par catégorie, l'empreinte de la surface d'outils, et la note avec une justification d'un paragraphe :

→ litmus · npm/@modelcontextprotocol/server-filesystem
→ version 0.1.0
→ C-01 pass · C-02 pass · C-03 pass · C-04 pass
→ fingerprint 0x1a2b3c4d…5e6f7890
→ grade: A
   All four categories passed. No injection, no unexpected egress, no data leak.

En cas d'échec, le rapport met en avant les principales conclusions de sévérité HAUTE (nom d'outil, type de finding, l'extrait offensant). references/methodology.md mappe chaque note et type de finding à sa cause.

Combien faire confiance à la note (limites honnêtes)

La reproductibilité est l'ancre de confiance. Le harnais est open source et déterministe, donc une note fausse est falsifiable — n'importe qui peut le réexécuter contre le même serveur et le résultat doit correspondre.
Une note auto-publiée est forgeable par celui qui la signe ; c'est pourquoi la reproductibilité (non la signature) est ce qui rend une note digne de confiance, et pourquoi la revérification d'empreinte protège contre un serveur noté-puis-échangé.
L'evasion est la limite résiduelle : un serveur qui détecte le contexte de test pourrait se comporter pendant la notation et se mal comporter en production. C'est divulgué, non caché.
Des garanties plus fortes et indépendantes (obligations, exécutions soutenues par TEE, re-notation indépendante) sont en feuille de route, non prétendues aujourd'hui.

Ressources

Accueil + méthodologie : https://polygraph.so
CLI de recherche : npx polygraphso check <registry>/<owner>/<name> · https://www.npmjs.com/package/polygraphso
Harnais de notation : @polygraphso/litmus (open source — voir polygraph.so pour le repo)
Preuve onchain : Attestations EAS sur Base
Références : methodology.md · cli.md · bankr-integration.md · ci-gate.md