Gouvernance IA fondée sur le contrat

Un seul MCP Contract. Un fondement déterministe pour la gouvernance des agents IA.

Le MCP Contract joue le même rôle pour les outils des agents IA qu'un contrat OpenAPI pour une API REST — une source de vérité unique, lisible par machine. La différence tient à ce que cette source de vérité vous apporte : évaluée de la même manière à chaque fois, pour que le résultat tienne lieu de preuve, et non d'un instantané.

Pourquoi c'est important

Le document unique sur lequel une équipe de sécurité, un régulateur et un agent IA peuvent tous s'appuyer.

Un MCP Contract fonctionne pour la même raison qu'un contrat OpenAPI fonctionne — tout le monde cesse de se disputer sur des versions différentes de la vérité et travaille à partir d'une seule. Les équipes de sécurité obtiennent une déclaration précise et versionnée de ce qu'un serveur expose et autorise, au lieu d'une page wiki ou d'un fil Slack. L'agent IA appelant obtient ce qui se rapproche le plus d'une vérité de terrain sur la finalité réelle d'un outil. Et parce que le contrat est lisible par machine, l'évaluation qui en découle est déterministe : le même serveur évalué deux fois renvoie le même score, les mêmes résultats et le même verdict — ce qui transforme une décision de gouvernance en preuve d'audit, et non en opinion ponctuelle.

Ce qu'apporte un bon contrat

Quatre choses qu'un MCP Contract déterministe apporte, qu'un document de politique ne peut pas offrir.

Gouvernance reproductible

L'évaluation s'effectue par rapport au contrat déclaré, pas à la lecture qu'un humain fait du serveur un jour donné. Notez un serveur deux fois, obtenez la même réponse deux fois.

Preuve de qualité audit

Un verdict déterministe est quelque chose que vous pouvez remettre à un régulateur ou lors d'une revue de sécurité client — pas une capture d'écran de tableau de bord horodatée.

Application en CI/CD, sans contrôle manuel

Parce que le contrat est structuré, une Security Quality Gate peut bloquer automatiquement un serveur non conforme — personne n'a besoin de se souvenir de le relire.

S'adapte d'un serveur à tout le parc

Le même modèle de contrat gouverne dix serveurs MCP ou dix mille, sans que la qualité de la gouvernance dépende de la discipline de chaque équipe.

Aucune rédaction manuelle de spécification requise

Pointez-le vers une URL. Le contrat s'écrit tout seul.

Le contrat n'a pas besoin d'être rédigé à la main. Connectez-vous à n'importe quelle URL de serveur MCP en direct, et la passe de découverte génère automatiquement le contrat — chaque outil, ressource et prompt exposé par le serveur, ainsi que des inférences au mieux pour le niveau de risque, la classification des données et les effets de bord.

Tout ce qui ne peut pas être déduit en toute sécurité est marqué # STUB plutôt que deviné — afin qu'un humain comble délibérément le vide au lieu de publier un faux sentiment d'exhaustivité.

$ mcp-scanner -addr https://your-server/mcp \ -contract contract.yaml \ -server-name io.acme/crm-mcp \ -server-version 2.4.1 ✓ 14 outils, 3 ressources, 2 prompts découverts ✓ contract.yaml généré (mcpContract: "0.2") → 6 champs marqués # STUB — à compléter avant l'audit
Ce qu'il contient

Neuf sections. Une seule est réelle aujourd'hui.

Le schéma est délibérément structuré de sorte que les descriptions en texte libre — la partie qu'un modèle d'IA lit réellement — se trouvent dans leur propre section, séparée des déclarations structurelles examinées par les équipes de sécurité. Les sections structurelles définissent le schéma sur lequel la plateforme 42Crunch effectue ses audits et sa notation.

En direct — analyse réelle dès aujourd'hui

content

Le champ description en texte intégral de chaque outil et prompt — ajouté dans la version de schéma mcpContract: "0.2" aux côtés du title tronqué existant. C'est ce qu'un modèle d'IA appelant lit réellement, et c'est ce que la plateforme 42Crunch analyse automatiquement à la recherche de prompt injection, tool poisoning, data exfiltration et tool shadowing.

Schéma existant — la notation est sur la feuille de route

Huit sections structurelles

serverNom, version, identité reverse-DNS
initializeInstructions données à l'agent appelant
integritySignature des messages, protection contre le rug-pull
resolutionInvariants d'audit
capabilitiesOutils, ressources, prompts et leurs niveaux de risque
authenticationSchémas, comportements par défaut fail-closed
authorizationRôles, rejet des autorisations génériques (wildcard)
throttlingLimites de débit, comportement fail-closed
Producteur et consommateur

Un seul contrat, lu par deux publics très différents.

C'est la même idée qui rend un contrat OpenAPI précieux — simplement appliquée à un nouveau type de consommateur.

Pour les producteurs (votre équipe)

Une déclaration précise et versionnée de ce que votre serveur MCP autorise et n'autorise pas — la base de la gouvernance, des tests automatisés et d'un contrôle CI/CD qui ne dépend pas du fait que quelqu'un se souvienne de relire une pull request.

Pour les consommateurs (l'agent IA)

Le contrat est ce qui se rapproche le plus d'une vérité de terrain dont dispose un modèle d'IA sur la finalité réelle d'un outil. Une section content bien rédigée et durcie est ce qui se dresse entre un agent appelant et une description d'outil qui tente de le manipuler.

Foire aux questions

MCP Contract, questions fréquentes.

Qu'est-ce qui différencie la gouvernance MCP basée sur un contrat de l'analyse du trafic ? +

La détection basée sur le trafic vous indique ce qui s'est passé ; un contrat vous indique ce qui est autorisé, ce qui permet à une équipe de sécurité de tester et de bloquer un serveur avant même qu'il soit appelé par un agent, plutôt que de simplement enregistrer ce qu'un agent a déjà fait.

Pourquoi le déterminisme compte-t-il particulièrement pour la gouvernance de l'IA ? +

Parce que la charge de la preuve est différente — un régulateur ou un auditeur a besoin d'un résultat qui ne change pas selon le moment où on le demande. Un verdict déterministe fondé sur un contrat est reproductible ; un score de risque basé sur le trafic en direct ne l'est généralement pas.

Le contrat remplace-t-il la protection à l'exécution ? +

Non — c'est la déclaration à partir de laquelle l'application à l'exécution est construite. Le contrat indique ce qui est permis ; une couche d'exécution (MCP Runtime Protection) est ce qui bloque effectivement un serveur qui s'en écarte.

Que se passe-t-il pour les champs qui ne peuvent pas être déduits automatiquement ? +

Ils sont marqués # STUB plutôt que devinés silencieusement, afin qu'un humain comble délibérément le vide — le contrat ne revendique jamais plus d'exhaustivité qu'il n'en a réellement.

Générez votre premier MCP Contract dans le temps qu'il vous faut pour lire cette page.