MCP-Audit: Sichern und steuern Sie jeden Tool-Aufruf

Was MCP standardisiert und wo Governance beginnt¶

In der aktuellen MCP-Spezifikation initialisieren ein Client und ein Server eine Sitzung, handeln Funktionen aus und tauschen Protokollnachrichten aus. Ein Server mit der Tools-Funktion kann Tooldefinitionen über tools/list veröffentlichen. Jede Definition kann einen Namen, eine Beschreibung, eine JSON-Schema-Eingabe, ein optionales Ausgabeschema und Verhaltensanmerkungen enthalten. Ein Client ruft eines dieser Tools mit tools/call auf.

Diese Protokollsequenz bietet Prüfern stabile Referenzobjekte: Protokollversion, Serverimplementierungsinformationen, erkannte Tooldefinition, Eingabeschema, Aufruf-ID, Argumente, Ergebnis und Fehlerstatus. Verantwortungsvolles Eigentum, Konsequenzklassifizierung, Unternehmensautorität, Weiterleitung von Entscheidungsanfragen, Aufbewahrung und Nachweis der Datensatzintegrität gehören zur Host- oder Gateway-Ebene, die jeden Anruf sieht.

Die Spezifikation legt auch eine wichtige Vertrauensregel fest. Clients müssen Toolanmerkungen als nicht vertrauenswürdig behandeln, es sei denn, sie stammen von einem vertrauenswürdigen Server. Beschreibungen dienen als Leitfaden für die Auswahl von Modellwerkzeugen und verdienen die gleiche Bewertung. Microsoft dokumentiert Tool-Poisoning als einen indirekten Prompt-Injection-Pfad, bei dem bösartige Anweisungen in Tool-Beschreibungen eingefügt werden. Ein Produktionsinventar zeichnet daher die vom Server empfangene Definition und die genehmigte Definition oder den Digest auf, die von der Sicherheit überprüft wurden.

Erstellen Sie den verwalteten Werkzeugbestand vor der Laufzeit¶

Eine Prüfpopulation beginnt mit den Servern und Tools, die ein Agent tatsächlich erreichen kann. Notieren Sie den Serverbesitzer, den Transport, die Paket- oder Image-Version, das Quell-Repository, die Bereitstellungsumgebung, die Authentifizierungsmethode, die OAuth-Ressource oder -Zielgruppe, gewährte Bereiche, Datenziele, Ausgangspfade sowie die Agenten und Prozesse, die eine Verbindung herstellen dürfen.

Behalten Sie für jedes entdeckte Tool die vollständige Definition und eine kanonische Zusammenfassung bei. Überprüfen Sie den Namen, die Beschreibung, das Eingabeschema, das Ausgabeschema, die Anmerkungen und jedes deklarierte Aufgabenverhalten. Wenn ein Server eine geänderte Liste veröffentlicht, pausieren Sie neu hinzugefügte oder wesentlich geänderte Tools, bis der Eigentümer den Unterschied genehmigt. Ein Modell sollte niemals einen neuen Schreibpfad erhalten, weil sich eine Remote-Beschreibung zwischen Sitzungen geändert hat.

Klassifizieren Sie die Aktion anhand des tatsächlichen Verhaltens. Schreibgeschützte, destruktive, idempotente und Open-World-Anmerkungen sind nützliche Überprüfungshinweise. Das aktuelle MCP-Schema gibt an, dass es sich dabei um Hinweise handelt und gibt vorsichtige Standardwerte an. Netzwerkkontrollen, Sandboxing, eingeschränkte Anmeldeinformationen und Richtliniendurchsetzung bieten die Garantie.

• Identität: stabile Server-, Tool-, Agent-, Prinzipal-, Mandanten- und Eigentümer-IDs.
• Lieferkette: Quelle, Herausgeber, Digest, Signaturstatus, Abhängigkeitsprüfung und genehmigter Update-Kanal.
• Autorität: genaue Tools, Aktionen, Ziele, Datengrenzen, OAuth-Bereiche und Ablauf der Delegation.
• Änderungskontrolle: genehmigter Definitionsüberblick, Zeitpunkt der ersten und letzten Überprüfung sowie ein Unterschied für jede Listenänderung.
• Laufzeitplatzierung: Umgebung, Region, Netzwerkgrenze, geheime Referenz und Ausgangsrichtlinie.

Normalisieren Sie alle Tools/Aufrufe in einem Gate-Kontext¶

Das Gateway sollte die JSON-RPC-Anfrage analysieren und die Fakten hinzufügen, die die Wire-Nachricht nicht sicher übertragen kann. Der Gate-Kontext benötigt Mandanten- und Ausführungskennungen, Prinzipal- und Agentenidentitäten, Workflow und Schritt, Umgebung, kanonische Server- und Toolnamen, Ziel, Toolargumente, Datenklassifizierung, Modell- und Eingabeaufforderungsversionen sowie die aktuelle Richtlinienversion.

Validieren Sie die Argumente vor der Richtlinienauswertung anhand des genehmigten Eingabeschemas. Hashen Sie die kanonischen Argumente und halten Sie vertrauliche Werte aus gewöhnlichen Protokollen fern. Die Richtlinien-Engine kann ausgewählte strukturierte Felder auswerten, wenn sie vom Tool-Schema deklariert werden, während der Beweisdatensatz einen Digest und kontrollierte Verweise auf geschützte Quelldaten beibehält.

Befolgen Sie für HTTP-Transporte die MCP-Autorisierungsspezifikation: Binden Sie Token an die vorgesehene Ressource, validieren Sie ihre Zielgruppe auf dem MCP-Server, fordern Sie die Mindestbereiche an und verwenden Sie separate Downstream-Tokens für Upstream-APIs. Für stdio weist die MCP-Spezifikation Implementierungen an, Anmeldeinformationen aus der Umgebung abzurufen. Speichern Sie in beiden Fällen Token-Metadaten und Bereichsentscheidungen im Prüfdatensatz und schließen Sie Roh-Tokens und Geheimnisse aus.

{
  „jsonrpc“: „2.0“,
  „id“: „call-1842“,
  „Methode“: „Tools/Aufruf“,
  "params": {
    „name“: „cmb_decision_request.create“,
    „Argumente“: {
      „case_id“: „case-1842“,
      „recommended_action“: „require_human_approval“,
      „reason_codes“: [
        „confirmed_sanctions_hit“
      ],
      „approver_group“: „aml-l1-approval“,
      „Dringlichkeit“: „erhöht“,
      „evidence_refs“: [
        „evidence://case-1842/screening“
      ]
    }
  }
}

Bewerten Sie die Richtlinie, bevor das Tool wirken kann¶

Durch die Authentifizierung wird nachgewiesen, welcher Prinzipal den Server erreicht hat. Durch die Autorisierung wird festgelegt, welche Ressource und welchen Umfang dieser Prinzipal verwenden darf. Die Laufzeitrichtlinie bestimmt, ob diese Aktion zu diesem Zeitpunkt hier, mit diesen Argumenten, in diesem Prozess ausgeführt werden darf.

Verwenden Sie einen Fail-Closed-Standard. KLA PolicyVersion-Verträge repräsentieren vier Ergebnisse. allow gibt den Anruf frei. warn gibt es frei und erzeugt ein überprüfbares Signal. require_approval pausiert es und leitet eine Entscheidungsanfrage an eine autorisierte Gruppe weiter. block lehnt es ab. Abgeglichene Regeln enthalten einen stabilen Ursachencode, die ausgewerteten Felder, eine Determinismusklassifizierung und eine konfigurierte Behebung. Die Standardentscheidung blockiert Aufrufe, die keiner Regel entsprechen, und gibt den generischen Fallback-Grund aus.

Das folgende Beispiel entspricht dem aktuellen KLA PolicyVersion-Schema und dem Policy Builder-Vokabular. Es verwendet Toolnamen und die Prüfergruppe aus der aktuellen AML-Vorlage für geführte Demos von KLA. Binden Sie den Richtlinienbereich und die Werkzeugnamen vor der Veröffentlichung an den Ziel-Werkzeugkatalog. Die Standardeinstellung blockiert jedes Tool ohne explizite Regel.

{
  „schemaVersion“: „1.0.0“,
  „policyId“: „pol_mcp_tool_calls“,
  „workspaceId“: „workspace-regulated-operations“,
  „name“: „MCP-Tool-Call-Steuerelemente“,
  „description“: „Regelt das Lesen von AML-Warnungen, das Abrufen von Beweismitteln und die Weiterleitung durch den Decision Desk.“,
  „status“: „Entwurf“,
  „Version“: „1.0.0“,
  „policyKind“: „guardrail“,
  "Umfang": {
    „workflowIds“: [],
    "agentIds": [],
    "stepIds": [],
    „Umgebungen“: [
      „Produkt“
    ]
  },
  „defaultDecision“: „block“,
  „Regeln“: [
    {
      „ruleId“: „allow-alert-read“,
      „name“: „Lesevorgänge für bereichsbezogene Warnungen zulassen“,
      „interceptionPoint“: „tool_call“,
      „wann“: {
        „Ausdruck“: {
          "==": [
            {
              „var“: „context.action.toolName“
            },
            „cmb_alerts.read“
          ]
        }
      },
      „dann“: {
        „Entscheidung“: „allow“,
        „reason“: „Das registrierte Lesetool kann eine Warnung innerhalb seines konfigurierten Datenbereichs untersuchen.“,
        „reasonCodes“: [
          „aml_scoped_alert_read“
        ]
      },
      „Ausführung“: {
        „Modus“: „deterministisch“
      },
      „Beweis“: {
        „evaluatedFields“: [
          „context.action.toolName“
        ],
        „artifactRefs“: [],
        „sensitivityTier“: „intern“
      }
    },
    {
      „ruleId“: „warn-evidence-retrieval“,
      „name“: „Beweisabruf kennzeichnen“,
      „interceptionPoint“: „tool_call“,
      „wann“: {
        „Ausdruck“: {
          "==": [
            {
              „var“: „context.action.toolName“
            },
            „cmb_evidence.retrieve“
          ]
        }
      },
      „dann“: {
        „Entscheidung“: „warn“,
        „reason“: „Das Tool ruft Fallbeweise unter klassenbewusster Governance ab.“,
        „reasonCodes“: [
          „aml_evidence_retrieval“
        ],
        „Sanierung“: {
          „summary“: „Überprüfen Sie die Beweisklasse und Referenzen vor einer Folgemaßnahme.“,
          „Schritte“: []
        }
      },
      „Ausführung“: {
        „Modus“: „deterministisch“
      },
      „Beweis“: {
        „evaluatedFields“: [
          „context.action.toolName“
        ],
        „artifactRefs“: [],
        „sensitivityTier“: „eingeschränkt“
      }
    },
    {
      „ruleId“: „approve-decision-desk-routing“,
      „name“: „Decision Desk Routing erfordert Genehmigung“,
      „interceptionPoint“: „tool_call“,
      „wann“: {
        „Ausdruck“: {
          "==": [
            {
              „var“: „context.action.toolName“
            },
            „cmb_decision_request.create“
          ]
        }
      },
      „dann“: {
        „Entscheidung“: „require_approval“,
        „reason“: „Ein AML L1-Prüfer muss die Materialempfehlung bestätigen.“,
        „reasonCodes“: [
          „aml_decision_desk_routing_requires_approval“
        ],
        „Sanierung“: {
          „summary“: „Weisen Sie die Anfrage der AML L1-Überprüfung zu.“,
          „Schritte“: [
            {
              „title“: „Überprüfen Sie das Fallpaket“,
              „description“: „Überprüfen Sie die Empfehlung, Begründung, Beweisverweise und fehlende Informationen.“
            }
          ]
        },
        „approverGroup“: „aml_l1_reviewers“
      },
      „Ausführung“: {
        „Modus“: „deterministisch“
      },
      „Beweis“: {
        „evaluatedFields“: [
          „context.action.toolName“,
          „context.action.toolArgs“
        ],
        „artifactRefs“: [],
        „sensitivityTier“: „eingeschränkt“
      }
    }
  ]
}

Machen Sie die menschliche Zustimmung zu einer dauerhaften Kontrolle¶

Eine dauerhafte Genehmigungskontrolle zeichnet auf, dass eine autorisierte Person eine definierte Aktion im Rahmen einer definierten Richtlinie vor der Ausführung überprüft hat.

Zeigen Sie dem Prüfer den Agenten und Auftraggeber, das Werkzeug und das Ziel, wesentliche Argumente in einer sicheren Anzeige, geschäftliche Konsequenzen, Richtliniengrundlage, Ursachencodes, Beweisreferenzen, Ablauf und die genaue angeforderte Entscheidung. Erzwingen Sie die Trennung zwischen Hersteller und Prüfer, wenn eine Person die Aktion vorgeschlagen oder initiiert hat. Überprüfen Sie die Prüferrolle, wenn die Entscheidung eingereicht wird.

Binden Sie die Entscheidungsanforderung an den Argument-Hash und die Gate-ID. Führen Sie nach der Genehmigung denselben logischen Aufruf erneut durch und überprüfen Sie die Argumente anhand des versiegelten Hashs. Eine Änderung des Betrags, des Bestimmungsorts, der Datensatz-ID oder der Beweisreferenz erfordert eine neue Entscheidung. Lehnen Sie abgelaufene Genehmigungen und Genehmigungen ab, die für einen anderen Mandanten, eine andere Umgebung, eine andere Richtlinienversion oder ein anderes Tool ausgestellt wurden.

MCP tools/call definiert keinen Unternehmensgenehmigungsworkflow. Der Host kann seine dauerhafte Workflow-Engine anhalten, eine strukturierte Markierung „Genehmigung erforderlich“ zurückgeben oder den experimentellen aufgabenerweiterten Ablauf verwenden, wenn beide Parteien über Unterstützung verhandeln. Das Kontrollziel bleibt konstant: Es treten keine Nebenwirkungen auf, bis die autorisierte Entscheidung gelöst ist, und Wiederholungsversuche können keine doppelten Effekte erzeugen.

• Ausstehend: Behalten Sie die Entscheidungsanforderung bei und stoppen Sie sie vor der Ausführung.
• Genehmigt: Autorität, Ablauf, Gate-ID, Richtlinienversion und Argument-Hash überprüfen; einmal ausführen.
• Abgelehnt: Schließen Sie die Anfrage und geben Sie ein stabiles blockiertes Ergebnis zurück.
• Geänderter Aufruf: Erstellen Sie eine neue Anfrage mit einem neuen Hash und einem neuen Entscheidungsverlauf.
• Zeitüberschreitung oder Ausfall: Wenden Sie das veröffentlichte Fail-Closed-Ergebnis an und behalten Sie den fehlgeschlagenen Versuch bei.

Steuern Sie die Ausführung, Ausgabe und Wiederholungsversuche¶

Schreiben Sie vor einem Aufruf mit Nebeneffekten eine Idempotenzabsicht. Übergeben Sie den Idempotenzschlüssel nachgeschaltet, wenn das Tool ihn unterstützt, und schreiben Sie dann das Ergebnis fest. Ein Wiederholungsversuch kann das festgeschriebene Ergebnis zurückgeben, eine ausstehende Genehmigung fortsetzen oder eine laufende Absicht unter demselben Schlüssel wiederherstellen. Der Nebeneffekt kann nicht zweimal stillschweigend ausgeführt werden.

Validieren Sie die strukturierte Ausgabe anhand des genehmigten Ausgabeschemas, wenn das Tool eines deklariert. Behandeln Sie zurückgegebene Texte, Links, eingebettete Ressourcen, Bilder und strukturierte Inhalte als nicht vertrauenswürdige Daten. Wenden Sie Schwärzung, Inhaltsrichtlinien, Zielkontrollen und ein Ausgabegate an, bevor das Modell oder ein anderes Tool das Ergebnis verarbeitet.

Erfassen Sie Protokollfehler und Fehler bei der Toolausführung separat. MCP-Tool-Ergebnisse können isError: true enthalten, während fehlerhafte Anfragen und unbekannte Tools Protokollfehler verwenden. Behalten Sie beide Klassen bei, da sie unterschiedliche Kontrolltests unterstützen: Clientvalidierung, Serververfügbarkeit, Downstream-Geschäftsausfall und Richtlinienverweigerung.

Erfassen Sie die komplette Prüfeinheit¶

Ein MCP-Prüfungsdatensatz sollte die vorgeschlagene Maßnahme, die Governance-Entscheidung, die menschliche Entscheidung, das Ausführungsergebnis und den Nachweis miteinander verbinden. Ein Client-Trace mit Toolname und Latenz deckt nur einen Teil dieser Einheit ab.

Verwenden Sie eine Korrelationskennung für den Client, das Gateway, die Richtlinien-Engine, den Genehmigungsdienst, den Tool-Server, das nachgelagerte System, das Prüfprotokoll und den Beweisexport. Gleichen Sie die Zählungen über diese Ebenen hinweg ab. Jeder erkannte Aufruf sollte in einem Terminal-Governance-Status enden und jeder ausgeführte Nebeneffekt sollte eine Entscheidung und einen Ergebnisdatensatz haben.

Beweise versiegeln und Verifizierungsgrenzen einhalten¶

Die Evidence Factory der KLA exportiert ein versiegeltes Beweispaket mit einem Manifest, Inhalts-Hashes, Signaturen, Verifizierungsmaterial und einer dokumentierten Bevölkerungsgrenze. Bewahren Sie Rohdatensätze nach Möglichkeit nur als Anhang auf und bewahren Sie die Richtlinien- und Tooldefinitions-Snapshots auf, die zu ihrer Interpretation erforderlich sind.

KLA-Beweistools erstellen einen SHA-256-Digest des kanonischen Manifests und signieren es mit ES256-Dienst- und Mandantenschlüsseln. Das Paket enthält öffentliche Verifizierungsschlüssel, und der Offline-Verifizierer überprüft die Manifestsignaturen, Governance-Belegsignaturen und Bestelllinks, anwendbare Ledger-Hash-Diagramme, Artefakt-Merkle-Einbindung und Zeitstempel-Anker. Jede Prüfung hat ein explizites Ergebnis.

Der Integritätsnachweis hat eine Grenze. Eine gültige Signatur beweist, dass die signierten Bytes mit dem Schlüssel und dem Manifest übereinstimmen. Vollständigkeit erfordert eine unabhängig definierte Population, einen Abgleich mit Quellsystemen und einen Endanker oder eine gleichwertige Kontrolle, an der eine Kette abgeschnitten werden könnte. Geben Sie fehlende Datensätze und nicht verfügbare Abhängigkeiten als Einschränkungen im Prüfbericht an.

Verwenden Sie das Ausführungsherkunftsbeispiel, um die Form eines Überprüfungsartefakts zu überprüfen. Der Richtlinien-als-Code-Leitfaden erklärt die Autorenseite und Ausführungslinie behandelt die Untersuchung und Wiedergabe.

Führen Sie das MCP-Audit als wiederholbares Programm aus¶

Definieren Sie den Zeitraum, die Umgebungen, Agenten, Server, Tools und Folgeaktionen im Umfang. Exportieren Sie den genehmigten Bestand und jeden beobachteten Werkzeugabruf. Gleichen Sie Kundenanrufe mit Gateway-Entscheidungen, Tool-Ergebnissen, nachgelagerten Belegen und Beweiseinträgen ab, bevor Sie Proben auswählen.

Testen Sie vollständige Populationen auf deterministische Aussagen wie genehmigter Server-Digest, erkanntes Tool, gültiges Schema, vorhandene Richtlinienentscheidung, erforderliche Genehmigung, sofern konfiguriert, unveränderter Argument-Hash, eindeutiger Idempotenzschlüssel, Terminalergebnis und Manifesteintrag. Beispielhaftes menschliches Urteilsvermögen in Bezug auf Begründung, Prüferbefugnis, ausreichende sichere Anzeige, Ausnahmebehandlung und geschäftliche Konsequenzen.

Richten Sie die Stichprobe auf neue oder geänderte Tools, Schreib- und Zerstörungsaktionen, Open-World-Abruf, sensible Daten, mandanten- oder regionsübergreifende Grenzen, Genehmigungsüberschreibungen, Ablehnungen, Fehler, Wiederholungsversuche, Richtlinienausfälle, Beweisfehler und die ersten Aufrufe nach der Veröffentlichung eines Tools oder einer Richtlinie aus.

• Populationstest: Jeder beobachtete Aufruf wird einer genehmigten Server- und Tooldefinition zugeordnet.
• Kontrolltest: Jeder Anruf hat eine Terminalvalidierung oder ein Richtlinienergebnis; Jeder schemagültige Aufruf hat eine erzwungene Entscheidung gemäß der zu diesem Zeitpunkt aktiven Richtlinie.
• Genehmigungstest: Jede erforderliche Genehmigung geht der Ausführung voraus und bindet an denselben Argument-Hash.
• Ergebnistest: Ausgeführte Aufrufe werden mit einem Downstream-Effekt und einem Ergebnisdatensatz abgeglichen.
• Integritätstest: Die Paketüberprüfung besteht den Test und negative Manipulationstests schlagen erwartungsgemäß fehl.
• Vollständigkeitstest: Quellenanzahl, Ausschlüsse, verspätete Ereignisse, fehlgeschlagene Exporte und ungelöste Lücken werden quantifiziert.

Aktuelle Primärquellen und Umfang¶

Das Protokollverhalten in diesem Leitfaden wurde am 27. Juli 2026 anhand der offiziellen MCP 2025-11-25 Tools-Spezifikation, Autorisierungsspezifikation, Lebenszyklusspezifikation, experimentelle Aufgabenspezifikation und MCP-Best Practices für die Sicherheit überprüft.

Die Tool-Poisoning-Beschreibung und die Abhilfemaßnahmen wurden mit Microsoft for Developers, Schutz vor indirekten Prompt-Injection-Angriffen in MCP überprüft. Exploit-Zählungen, Forenansprüche und Produktfehlerberichte ohne primäre Hinweise sind ausgeschlossen.

MCP entwickelt sich durch veraltete Protokollrevisionen weiter. Fixieren Sie die zu prüfende Revision, archivieren Sie die in dieser Sitzung empfangenen Schema- und Tooldefinitionen und überprüfen Sie die aktuelle Spezifikation erneut, wenn Sie das Client-, Server- oder Autorisierungsverhalten ändern.