Produit · Gouvernance MCP
Gouvernez MCP — cataloguez chaque outil, reliez qui utilise quoi
Module V, Capacités. Le client MCP interroge tools/list et resources/list sur chaque serveur et les consigne dans un registre interne ; vous obtenez ainsi un catalogue versionné de serveurs, de skills et d’outils — ainsi qu’un graphe de câblage indiquant quel agent utilise quel outil. La configuration gérée référence vos secrets par référence ; les valeurs en clair n’entrent jamais dans le catalogue.
Dans le produit
La console des capacités
Une capture d’écran authentique, avec des données d’exemple. Des onglets pour les serveurs, les skills, les outils, le graphe de câblage des capacités et les configurations gérées. L’état de connexion est dérivé de signaux réels ; les entrées approuvées portent un hash de contenu et, lorsqu’une clé de signature existe, une signature Ed25519.
Ce que vous gouvernez
Un registre pour chaque outil que vos agents peuvent atteindre
Le client MCP communique via stdio et Streamable HTTP, inspecte chaque serveur et consigne ce qu’il trouve — ainsi le catalogue reflète ce que les serveurs exposent réellement, et non ce qu’affirme un tableur.
Un catalogue issu de l’inspection
Le client appelle tools/list et resources/list via stdio ou Streamable HTTP (SSE est hérité) et écrit le résultat dans un registre interne. Vous obtenez un catalogue versionné de serveurs MCP, de skills et d’outils, avec un état de connexion dérivé de signaux réels — et non maintenu à la main.
Un graphe de câblage des capacités
Voyez quel agent est relié à quel outil — le graphe du « qui utilise quoi » au cœur de la console. C’est une cartographie d’usage ; elle est distincte de la carte d’accès lecture / lecture-écriture, qui est une surface à part répondant à une autre question.
Des secrets par référence, jamais en clair
La configuration MCP gérée référence vos secrets par référence (secret_refs). Les valeurs en clair ne sont jamais stockées ni lues depuis le catalogue — la configuration pointe vers le secret, elle ne le contient pas.
Les annotations sont déclarées, non fiables
Les serveurs MCP peuvent déclarer read_only_hint ou destructive_hint sur un outil. Nous les présentons comme un signal déclaré et non fiable émis par le serveur — jamais comme un badge de sécurité faisant autorité. Considérez-les comme une indication à vérifier, et non comme une vérité de sécurité.
Ce qui est réel
Le catalogue, le graphe et la configuration gérée sont en service ; la mise en conformité complète avec la MCP-RC est en cours
Nous sommes précis sur ce que le contrat garantit aujourd’hui et ce qu’il ne garantit pas :
- En service (contrat v1 stable) : le client MCP sur stdio et Streamable HTTP, l’inspection de tools/list et resources/list vers le registre interne, le catalogue de serveurs / skills / outils, le graphe de câblage des capacités et la configuration gérée qui référence les secrets par référence. L’état de connexion est dérivé de signaux réels.
- Approbation et intégrité : les entrées approuvées du catalogue portent un hash de contenu et une signature Ed25519 optionnelle. Lorsqu’aucune clé de signature n’est configurée, une entrée apparaît comme « approuvée mais non signée » — nous le disons clairement plutôt que de laisser entendre une signature qui n’existe pas.
- Pas de conformité complète à la spécification : la mise en conformité avec la MCP RC (spécification du 2026-07-28) est en cours, et plusieurs évolutions de la spécification ne sont pas encore implémentées — nous ne revendiquons pas de conformité complète ni à jour avec la spécification MCP. Le registre public MCP est en préversion et rejette aujourd’hui les serveurs privés ; un sous-registre privé figure sur la feuille de route.
- Posture : lecture d’abord et détection par défaut. Le catalogue et le graphe décrivent ce que vos serveurs exposent et la manière dont les outils sont câblés ; ils ne recâblent ni n’actionnent rien en silence.
Gouvernance MCP — questions
Les annotations read_only_hint / destructive_hint m’indiquent-elles qu’un outil est sûr ?
Non. Ces annotations sont déclarées par le serveur MCP lui-même : il s’agit donc d’un signal non fiable — un serveur peut affirmer n’importe quoi. Nous les présentons dans le catalogue comme une indication déclarée, destinée à vous aider à décider ce qu’il faut vérifier, jamais comme un badge de sécurité faisant autorité. Ne considérez pas une annotation « lecture seule » comme la preuve qu’un outil ne peut pas écrire.
En quoi le graphe de câblage diffère-t-il de la carte d’accès ?
Le graphe de câblage des capacités répond à « quel agent utilise quel outil » — c’est une cartographie d’usage des connexions de cette console. La carte d’accès lecture / lecture-écriture est une surface produit distincte qui répond à « quel niveau d’accès une identité possède-t-elle sur une ressource ». Elles sont délibérément distinctes ; nous ne confondons pas l’une avec l’autre.
Mes secrets sont-ils stockés dans le catalogue MCP ?
Non. La configuration MCP gérée référence les secrets par référence (secret_refs) — la configuration pointe vers un secret, elle ne contient pas la valeur en clair. Le catalogue ne stocke ni ne lit jamais de matériel secret en clair.
Olivares est-il pleinement conforme à la spécification MCP actuelle ?
Pas encore, et nous ne l’affirmerons pas avant que ce soit le cas. Le client MCP en service est un contrat v1 stable sur stdio et Streamable HTTP (SSE est hérité), mais la mise en conformité avec la MCP RC (spécification du 2026-07-28) reste en cours, plusieurs évolutions n’étant pas encore implémentées. Le registre public MCP est en préversion et rejette les serveurs privés ; un sous-registre privé figure sur la feuille de route.
Cataloguez et gouvernez votre parc MCP
Déployez Olivares sur votre propre infrastructure, inspectez vos serveurs MCP pour alimenter un catalogue versionné, voyez qui est relié à quel outil et gardez vos secrets référencés — jamais en clair.