Audit MCP : sécuriser et gouverner chaque appel d'outil

Ce que MCP normalise et où commence la gouvernance¶

Dans la spécification MCP actuelle, un client et un serveur initialisent une session, négocient des capacités et échangent des messages de protocole. Un serveur doté de la capacité outils peut publier des définitions d'outils via tools/list. Chaque définition peut inclure un nom, une description, une entrée de schéma JSON, un schéma de sortie facultatif et des annotations de comportement. Un client invoque l'un de ces outils avec tools/call.

Cette séquence de protocole donne aux auditeurs des objets stables à référencer : version du protocole, informations d'implémentation du serveur, définition de l'outil découvert, schéma d'entrée, identifiant d'appel, arguments, résultat et état d'erreur. La propriété responsable, la classification des conséquences, l'autorité de l'entreprise, le routage Decision Request, la conservation et la preuve de l'intégrité des enregistrements appartiennent à la couche hôte ou passerelle qui voit chaque appel.

La spécification définit également une règle de confiance importante. Les clients doivent traiter les annotations d'outils comme non fiables, sauf si elles proviennent d'un serveur approuvé. Les descriptions guident la sélection des outils modèles et méritent le même examen. Microsoft documente l'empoisonnement des outils comme un chemin d'injection d'invite indirect dans lequel des instructions malveillantes sont placées dans les descriptions des outils. Un inventaire de production enregistre donc la définition reçue du serveur et la définition approuvée ou le résumé examiné par la sécurité.

Créer l'inventaire des outils gouvernés avant l'exécution¶

Une population d'audit commence par les serveurs et les outils qu'un agent peut réellement atteindre. Enregistrez le propriétaire du serveur, le transport, la version du package ou de l'image, le référentiel source, l'environnement de déploiement, la méthode d'authentification, la ressource ou l'audience OAuth, les étendues accordées, les destinations des données, les chemins de sortie et les agents et processus autorisés à se connecter.

Pour chaque outil découvert, conservez la définition complète et un résumé canonique. Passez en revue le nom, la description, le schéma d'entrée, le schéma de sortie, les annotations et tout comportement de tâche déclaré. Lorsqu'un serveur publie une liste modifiée, suspendez les outils nouvellement ajoutés ou substantiellement modifiés jusqu'à ce que le propriétaire approuve la différence. Un modèle ne devrait jamais obtenir un nouveau chemin d'écriture car une description distante a changé entre les sessions.

Classer l'action à partir du comportement réel. Les annotations en lecture seule, destructrices, idempotentes et en monde ouvert sont des conseils de révision utiles. Le schéma MCP actuel indique qu'il s'agit d'indices et donne des valeurs par défaut prudentes. Les contrôles réseau, le sandboxing, les informations d'identification étendues et l'application des politiques apportent la garantie.

• Identité : identifiants stables du serveur, de l'outil, de l'agent, du principal, du locataire et du propriétaire.
• Chaîne d'approvisionnement : source, éditeur, résumé, statut de signature, examen des dépendances et canal de mise à jour approuvé.
• Autorité : outils exacts, actions, destinations, limites des données, étendues OAuth et expiration de la délégation.
• Contrôle des modifications : résumé de définition approuvé, heures de première consultation et de dernière révision, et différence pour chaque modification de liste.
• Emplacement d'exécution : environnement, région, limite du réseau, référence secrète et stratégie de sortie.

Normaliser chaque outil/appel dans un contexte de porte¶

La passerelle doit analyser la requête JSON-RPC et ajouter les faits que le message électronique ne peut pas transporter en toute sécurité. Le contexte de porte a besoin d'identifiants de locataire et d'exécution, d'identités de principal et d'agent, de flux de travail et d'étape, d'environnement, de noms canoniques de serveur et d'outil, de destination, d'arguments d'outil, de classification de données, de versions de modèle et d'invite et de la version de politique actuelle.

Validez les arguments par rapport au schéma d'entrée approuvé avant l'évaluation de la politique. Hachez les arguments canoniques et conservez les valeurs sensibles en dehors des journaux ordinaires. Le moteur de politiques peut évaluer les champs structurés sélectionnés lorsque le schéma de l'outil les déclare, tandis que l'enregistrement des preuves conserve un résumé et des références contrôlées aux données sources protégées.

Pour les transports HTTP, suivez la spécification d'autorisation MCP : liez les jetons à la ressource prévue, validez leur audience sur le serveur MCP, demandez les étendues minimales et utilisez des jetons en aval distincts pour les API en amont. Pour stdio, la spécification MCP demande aux implémentations d'obtenir les informations d'identification de l'environnement. Dans les deux cas, stockez les métadonnées des jetons et les décisions de portée dans l'enregistrement d'audit tout en excluant les jetons bruts et les secrets.

{
  "jsonrpc": "2.0",
  "id": "call-1842",
  "method": "tools/call",
  "params": {
    "name": "cmb_decision_request.create",
    "arguments": {
      "case_id": "case-1842",
      "recommended_action": "require_human_approval",
      "reason_codes": [
        "confirmed_sanctions_hit"
      ],
      "approver_group": "aml-l1-approval",
      "urgency": "elevated",
      "evidence_refs": [
        "evidence://case-1842/screening"
      ]
    }
  }
}

Évaluer la politique avant que l'outil puisse agir¶

L'authentification prouve quel principal a atteint le serveur. L'autorisation établit la ressource et la portée que le principal peut utiliser. La politique d'exécution détermine si cette action peut être exécutée ici, avec ces arguments, dans ce processus, à ce moment précis.

Utilisez une valeur par défaut fermée en cas d'échec. Les contrats KLA PolicyVersion représentent quatre résultats. allow libère l'appel. warn le libère et crée un signal révisable. require_approval le met en pause et achemine un Decision Request vers un groupe autorisé. block le refuse. Les règles correspondantes comportent un code motif stable, les champs évalués, une classification déterministe et une correction configurée. La décision par défaut bloque les appels qui ne correspondent à aucune règle et émet sa raison de repli générique.

L'exemple ci-dessous correspond au schéma KLA PolicyVersion actuel et au vocabulaire Policy Builder. Il utilise les noms d’outils et le groupe de réviseurs du modèle de démonstration guidée AML actuel de KLA. Liez la portée de la stratégie et les noms des outils à la cible Tool Catalog avant la publication. La valeur par défaut bloque tous les outils absents d'une règle explicite.

{
  "schemaVersion": "1.0.0",
  "policyId": "pol_mcp_tool_calls",
  "workspaceId": "workspace-regulated-operations",
  "name": "MCP tool-call controls",
  "description": "Governs AML alert reads, evidence retrieval, and Decision Desk routing.",
  "status": "draft",
  "version": "1.0.0",
  "policyKind": "guardrail",
  "scope": {
    "workflowIds": [],
    "agentIds": [],
    "stepIds": [],
    "environments": [
      "prod"
    ]
  },
  "defaultDecision": "block",
  "rules": [
    {
      "ruleId": "allow-alert-read",
      "name": "Allow scoped alert reads",
      "interceptionPoint": "tool_call",
      "when": {
        "expression": {
          "==": [
            {
              "var": "context.action.toolName"
            },
            "cmb_alerts.read"
          ]
        }
      },
      "then": {
        "decision": "allow",
        "reason": "The registered read tool may inspect an alert within its configured data scope.",
        "reasonCodes": [
          "aml_scoped_alert_read"
        ]
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.action.toolName"
        ],
        "artifactRefs": [],
        "sensitivityTier": "internal"
      }
    },
    {
      "ruleId": "warn-evidence-retrieval",
      "name": "Flag evidence retrieval",
      "interceptionPoint": "tool_call",
      "when": {
        "expression": {
          "==": [
            {
              "var": "context.action.toolName"
            },
            "cmb_evidence.retrieve"
          ]
        }
      },
      "then": {
        "decision": "warn",
        "reason": "The tool retrieves case evidence under class-aware governance.",
        "reasonCodes": [
          "aml_evidence_retrieval"
        ],
        "remediation": {
          "summary": "Review the evidence class and references before a consequential action.",
          "steps": []
        }
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.action.toolName"
        ],
        "artifactRefs": [],
        "sensitivityTier": "restricted"
      }
    },
    {
      "ruleId": "approve-decision-desk-routing",
      "name": "Decision Desk routing requires approval",
      "interceptionPoint": "tool_call",
      "when": {
        "expression": {
          "==": [
            {
              "var": "context.action.toolName"
            },
            "cmb_decision_request.create"
          ]
        }
      },
      "then": {
        "decision": "require_approval",
        "reason": "An AML L1 reviewer must confirm the material recommendation.",
        "reasonCodes": [
          "aml_decision_desk_routing_requires_approval"
        ],
        "remediation": {
          "summary": "Assign the request to AML L1 review.",
          "steps": [
            {
              "title": "Review the case packet",
              "description": "Inspect the recommendation, rationale, evidence references, and missing information."
            }
          ]
        },
        "approverGroup": "aml_l1_reviewers"
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.action.toolName",
          "context.action.toolArgs"
        ],
        "artifactRefs": [],
        "sensitivityTier": "restricted"
      }
    }
  ]
}

Faire de l'approbation humaine un contrôle durable¶

Un contrôle d'approbation durable enregistre qu'une personne autorisée a examiné une action définie dans le cadre d'une politique définie avant son exécution.

Montrez à l'examinateur l'agent et le principal, l'outil et la destination, les arguments importants dans un affichage sécurisé, les conséquences commerciales, la base politique, les codes de motif, les références des preuves, l'expiration et la décision exacte demandée. Appliquer la séparation créateur-vérificateur lorsqu'une personne a proposé ou initié l'action. Vérifiez le rôle de réviseur lorsque la décision est soumise.

Liez le Decision Request au hachage de l'argument et à l'identifiant de la porte. Après approbation, relancez le même appel logique et vérifiez les arguments par rapport au hachage scellé. Un montant, une destination, un identifiant d'enregistrement ou une référence de preuve modifié nécessite une nouvelle décision. Rejetez les approbations expirées et les approbations émises pour un autre locataire, environnement, version de stratégie ou outil.

MCP tools/call ne définit pas de workflow d'approbation d'entreprise. L'hôte peut interrompre son moteur de flux de travail durable, renvoyer un marqueur structuré d'approbation requise ou utiliser le flux augmenté par tâches expérimental lorsque les deux parties négocient le support. L'objectif du contrôle reste constant : aucun effet secondaire ne se produit jusqu'à ce que la décision autorisée soit résolue, et les nouvelles tentatives ne peuvent pas créer d'effets en double.

• En attente : conservez le Decision Request et arrêtez-vous avant l'exécution.
• Approuvé : vérifie l'autorité, l'expiration, l'ID de porte, la version de la politique et le hachage de l'argument ; exécuter une fois.
• Rejeté : ferme la demande et renvoie un résultat bloqué stable.
• Appel modifié : crée une nouvelle demande avec un nouvel historique de hachage et de décision.
• Délai d'expiration ou panne : applique le résultat de fermeture sur échec publié et conserve la tentative échouée.

Contrôlez l'exécution, la sortie et les nouvelles tentatives¶

Écrivez une intention d'idempotence avant un appel à effets secondaires. Transmettez la clé d'idempotence en aval lorsque l'outil la prend en charge, puis validez le résultat. Une nouvelle tentative peut renvoyer le résultat validé, reprendre une approbation en attente ou récupérer une intention en cours sous la même clé. Il ne peut pas exécuter silencieusement l’effet secondaire deux fois.

Validez la sortie structurée par rapport au schéma de sortie approuvé lorsque l'outil en déclare un. Traitez le texte renvoyé, les liens, les ressources intégrées, les images et le contenu structuré comme des données non fiables. Appliquez la rédaction, la politique de contenu, les contrôles de destination et une porte de sortie avant que le modèle ou un autre outil consomme le résultat.

Enregistrez séparément les erreurs de protocole et les erreurs d'exécution de l'outil. Les résultats de l'outil MCP peuvent contenir « isError : true », tandis que les requêtes mal formées et les outils inconnus utilisent des erreurs de protocole. Préservez les deux classes car elles prennent en charge différents tests de contrôle : validation client, disponibilité du serveur, défaillance commerciale en aval et refus de politique.

Enregistrez l'unité d'audit complète¶

Un enregistrement d'audit MCP doit relier l'action proposée, la décision de gouvernance, la décision humaine, le résultat de l'exécution et la preuve. Une trace client avec le nom de l’outil et la latence ne couvre qu’une partie de cette unité.

Utilisez un identifiant de corrélation entre le client, la passerelle, le moteur de stratégie, le service d'approbation, le serveur d'outils, le système en aval, la piste d'audit et l'exportation de preuves. Réconciliez les décomptes entre ces couches. Chaque appel découvert doit se terminer dans un état de gouvernance terminal, et chaque effet secondaire exécuté doit avoir une décision plus un enregistrement de résultat.

Scellez les preuves et préservez les limites de vérification¶

Evidence Factory de KLA exporte un Sealed Evidence Bundle avec un manifeste, des hachages de contenu, des signatures, du matériel de vérification et une limite de population documentée. Conservez les enregistrements bruts en ajoutant uniquement lorsque cela est possible et conservez les instantanés de définition de politique et d'outil nécessaires à leur interprétation.

Les outils de preuve KLA créent un SHA-256 digest du manifeste canonique et le signe avec les clés de service et de locataire ES256. L'ensemble contient des clés de vérification publiques et le vérificateur hors ligne vérifie les signatures du manifeste, les signatures des reçus de gouvernance et les liens de commande, les graphiques de hachage du grand livre applicables, l'inclusion de l'artefact Merkle et l'ancre d'horodatage. Chaque contrôle a un résultat explicite.

La preuve d'intégrité a une limite. Une signature valide prouve que les octets signés correspondent à la clé et au manifeste. L'exhaustivité nécessite une population définie de manière indépendante, un rapprochement avec les systèmes sources et un point d'ancrage terminal ou un contrôle équivalent où une chaîne pourrait être tronquée. Indiquez les enregistrements manquants et les dépendances indisponibles comme limitations dans le rapport d’audit.

Utilisez l'échantillon de lignée d'exécution pour inspecter la forme d'un artefact de révision. Le guide policy-as-code explique le côté création, et Execution Lineage couvre l'enquête et la relecture.

Exécutez l'audit MCP en tant que programme reproductible¶

Définissez la période, les environnements, les agents, les serveurs, les outils et les actions consécutives dans la portée. Exportez l’inventaire approuvé et chaque appel d’outil observé. Rapprochez les appels des clients avec les décisions de passerelle, les résultats des outils, les reçus en aval et les entrées de preuves avant de sélectionner des échantillons.

Testez les populations complètes pour les assertions déterministes telles que le résumé de serveur approuvé, l'outil reconnu, le schéma valide, la décision politique présente, l'approbation requise si configurée, le hachage d'argument inchangé, la clé d'idempotence unique, le résultat du terminal et l'entrée du manifeste. Échantillon de jugement humain pour la justification, l'autorité du réviseur, la suffisance de l'affichage sécurisé, la gestion des exceptions et les conséquences commerciales.

Oriente l'échantillon vers des outils nouveaux ou modifiés, des actions d'écriture et destructrices, une récupération en monde ouvert, des données sensibles, des frontières entre locataires ou entre régions, des remplacements d'approbation, des refus, des erreurs, des tentatives, des pannes de politique, des échecs de preuves et les premiers appels après la publication d'un outil ou d'une politique.

• Test de population : chaque appel observé correspond à une définition de serveur et d'outil approuvée.
• Test de contrôle : chaque appel a une validation de terminal ou un résultat de politique ; chaque appel valide selon le schéma comporte une décision appliquée dans le cadre de la stratégie active à ce moment-là.
• Test d'approbation : chaque approbation requise précède l'exécution et se lie au même hachage d'argument.
• Test de résultat : les appels exécutés se réconcilient avec un effet en aval et un enregistrement de résultat.
• Test d'intégrité : la vérification du bundle réussit et les tests de falsification négatifs échouent comme prévu.
• Test d'exhaustivité : le nombre de sources, les exclusions, les événements tardifs, les échecs d'exportation et les lacunes non résolues sont quantifiés.

Sources principales et portée actuelles¶

Le comportement du protocole dans ce guide a été vérifié sur 27 juillet 2026 against la spécification officielle MCP 2025-11-25 tools, autorisation spécification, spécification du cycle de vie, spécification des tâches expérimentales et meilleures pratiques de sécurité MCP.

La description et les mesures d'atténuation de l'empoisonnement de l'outil ont été vérifiées par rapport à Microsoft pour les développeurs, Protection contre les attaques par injection d'invite indirecte dans MCP. Le nombre d'exploits, les réclamations sur les forums et les rapports de défauts de produits sans avis principaux sont exclus.

MCP évolue grâce à des révisions de protocole datées. Épinglez la révision en cours d'audit, archivez les définitions de schéma et d'outil reçues au cours de cette session et revérifiez la spécification actuelle lors de la modification du comportement du client, du serveur ou de l'autorisation.