MCP-Gateway-Sicherheit: Beweisen Sie, dass jeder Tool-Aufruf das Tor passiert

Die Sicherheit des MCP Gateways wird nicht durch das Einfügen eines Proxys in das Architekturdiagramm hergestellt. Der vertretbare Standard ist strenger: Beweisen Sie, dass jeder Aufruf eines geschützten Produktionstools das vorgesehene Gateway passierte, die erwartete Richtlinienrevision verwendete, eine validierte Identität und einen Bereich mit den geringsten Rechten trug, eine Prüfbestätigung erstellte und mit einer verifizierten Wirkung oder einem expliziten Wartezustand endete . Diese Unterscheidung ist wichtig, weil „Gateway“ eine Platzierung beschreibt, nicht ein Ergebnis. Die aktuellen US Suchergebnisse vermischen Gateway Produkte, Vergleiche, Architekturerklärungen und Sicherheitsaussagen. Ihr gemeinsames Versprechen ist ein zentraler Kontrollpunkt zwischen Agenten und MCP Servern. Die betriebliche Frage ist, ob dieser Punkt tatsächlich einen bestimmten Anruf besaß. DerMCP AutorisierungsspezifikationDefiniert die Autorisierung für HTTP Transporte, Metadaten geschützter Ressourcen, Erkennung und Bereichsauswahl. Das ProtokollBest Practices für die SicherheitVon den Implementierern wird verlangt, dass sie die Risiken verwirrter Stellvertreter, die Validierung der Token Zielgruppe, Gefahren durch Token Passthrough, Einwilligung und Überprüfbarkeit berücksichtigen. Keines der Dokumente verwandelt die bloße Anwesenheit eines Vermittlers in einen Beweis dafür, dass jede Route kontrolliert wird. Definieren Sie den Beweisvertrag, bevor Sie den Datenverkehr weiterleiten Beginnen Sie mit einem Routenmanifest, das klein genug ist, um neben der Gateway Konfiguration versendet zu werden: Das Manifest erstellt fünf überprüfbare Behauptungen: 1. Die Anfrage wurde über das benannte Gateway und nicht über eine direkte Server URL weitergeleitet. 2. Das Gateway hat eine nicht geheime Arbeitslast oder Benutzeridentität validiert. 3. Die Entscheidung resultierte aus der erwarteten, neuen politischen Überarbeitung. 4. Der gewährte Geltungsbereich deckte das ausgewählte Tool ab, ohne den Zugriff stillschweigend zu erweitern. 5. Das Gateway hat eine Prüfbestätigung ausgegeben, die mit dem Downstream Ergebnis verknüpft werden kann. Die Routenbehauptung ist nicht theoretisch. Cloudflare ist aktuellDokumentation zu MCP Serverportalenbeschreibt einen optionalen Gateway Pfad für Tool Aufrufe, während die Hintergrundsynchronisierung eine direkte Verbindung zu Upstream Servern herstellt. Außerdem wird gewarnt, dass ein blockierter Benutzer weiterhin die direkte URL eines Upstream Servers verwenden kann, sofern auf diesem Server keine Authentifizierung erzwungen wird. Dies sind legitime produktspezifische Verhaltensweisen und keine universellen MCP Regeln, aber sie zeigen, warum ein Inventar alle Pfade umfassen muss, anstatt davon auszugehen, dass ein Portal oder Gateway Seitentüren eliminiert hat. Erfassen Sie pro Entscheidung einen inhaltsfreien Umschlag. Es sind keine Eingabeaufforderungen, Toolargumente, Ergebniskörper, Zugriffstoken oder Geheimnisse erforderlich: Undurchsichtige Kennungen reichen aus, um den Routeneigentum, die Durchsetzung der Identität, die Aktualität der Richtlinien, den Geltungsbereich, den Genehmigungsstatus und die Empfangskontinuität zu testen. Bewahren Sie geheime Werte an ihrer Quelle. Wenn ein Vorfall eine Inhaltsprüfung erfordert, behandeln Sie dies als separaten, explizit autorisierten Workflow mit eigener Aufbewahrungsgrenze. Autorisierung und Richtliniendurchsetzung hängen zusammen, sind jedoch nicht austauschbar. Die MCP Spezifikation besagt, dass die Autorisierung für eine Implementierung optional ist; Wenn die HTTP Autorisierung unterstützt wird, fungiert der geschützte Server als OAuth Ressourcenserver. Ein Gateway kann daher keinen Beweis erbringen, indem es feststellt, dass ein Bearer Token vorhanden war. Es muss die beabsichtigte Ressource und Identität validieren, die entsprechende Tool Richtlinie bewerten und genügend nicht geheime Beweise aufbewahren, um die Entscheidung zu erklären. Die MCP Sicherheitsrichtlinien identifizieren Token Passthrough ausdrücklich als Anti Pattern, da es Kontrollen umgehen und die Verantwortlichkeit beeinträchtigen kann. Wiederholen Sie acht Zustände, die „erlaubt“ sind Das zugehörige Fixture enthält acht synthetische Anfragen. Sein Klassifikator wendet die Tore in betriebsbereiter Reihenfolge an: Führen Sie es lokal aus: Jedes Urteil erfordert eine andere begrenzte Reaktion: Urteil Was die Beweise sagen Nächste Aktion GATEWAY BYPASS Der geschützte Anruf verwendete eine andere Route oder Gateway Identität Inventarisierung von Client und Upstream Endpunkten; den direkten Weg schließen oder separat regeln IDENTITY NOT ENFORCED Die Route war zentral, aber der Anrufer wurde nicht validiert Lehnen Sie anonyme Produktionsaufrufe ab und korrigieren Sie die Arbeitslast oder Benutzeridentität an der Grenze POLICY DRIFT Die Entscheidung stützte sich auf eine alte Revision oder veraltete Beweise Gleichen Sie das laufende Gateway mit dem genehmigten Richtlinienartefakt ab, bevor Sie es erneut versuchen AUTHORIZATION GAP Das Tool bzw. dessen geforderter Umfang entsprach nicht der Entscheidung Lehnen Sie den Aufruf ab, reduzieren Sie den Umfang und fügen Sie einen Regressionsfall auf Toolebene hinzu AUDIT GAP Der Anruf wurde möglicherweise zugelassen, es liegt jedoch keine beitrittsfähige Quittung vor Reparieren Sie den Protokollierungs /Exportpfad. Halten Sie das Urteil unbekannt und nicht grün EFFECT UNCERTAIN Der Transport oder die Fertigstellung des Werkzeugs ergaben keinen Nachweis über das Ziel Lesen Sie das Ziel, bevor Sie es erneut versuchen, insbesondere nach einer Zeitüberschreitung WAITING Eine geschützte Aktion verfügt über eine benannte Genehmigungsabhängigkeit Benachrichtigen Sie den Eigentümer und halten Sie die Frist ein. Beschriften Sie den Agenten nicht HEALTHY Route, Identität, Richtlinie, Umfang, Prüfung, Genehmigung und Wirkung stimmen überein Bewahren Sie die Belege im Vorfallprüfungsfenster auf Der Vorrang verhindert, dass ein bequemes Warten auf die Genehmigung eine Umgehung oder veraltete Richtlinie verbirgt. WAITING ist erst verfügbar, nachdem Routen , Identitäts , Richtlinien , Autorisierungs und Audit Gates bestanden wurden. Ebenso entschuldigt ein erfolgreicher Downstream Effekt nicht einen Aufruf, der den Kontrollpfad umgangen hat. Das Experiment ist bewusst inhaltsfrei. Es prüft einen normalisierten Vertrag, kein Live Gateway Produkt. Ordnen Sie die Felder Ihres Gateways dem Gerät zu, anstatt Feldnamen zu kopieren, als ob MCP sie standardisiert hätte. Das Protokoll definiert Nachrichten und Autorisierungsverhalten; Gateway Richtlinienrevisionskennungen, Audit Empfangsformen und Zielprüfer bleiben Implementierungsoptionen. Trennen Sie die Erlaubnis vom resultierenden Effekt Eine Zulassungsentscheidung beweist nur, dass eine Richtlinie einen Versuch zugelassen hat. Es beweist nicht, dass das Tool einmal ausgeführt wurde, das beabsichtigte Ziel geändert oder die angeforderte Leistung erbracht hat. Verbinden Sie für eine Mutation den Gateway Beleg mit einem Ziel Beleg: Dies ist besonders nach einer Auszeit wichtig. Ein erneuter Versuch, weil das Gateway keine Antwort erhalten hat, kann einen Effekt duplizieren, den das Upstream System bereits festgeschrieben hat. EFFECT UNCERTAIN weist den Betreiber an, zuerst das Ziel abzugleichen. Ein Gateway kann die Rate begrenzen oder einen Wiederholungsversuch autorisieren, aber das Ziel ist normalerweise die stärkere Quelle dafür, ob der ursprüngliche Effekt vorhanden ist. Bei schreibgeschützten Tools kann das Ergebnis eine Schemaprüfung, Aktualitätszusicherung oder ein deterministischer Vergleich mit den erforderlichen Feldern der Aufgabe sein. Für Schreibvorgänge bevorzugen Sie einen API Rücklesevorgang, eine unveränderliche Objektversion, eine Provider Nachrichten ID, einen Commit Hash plus Prüfungen oder eine andere zieleigene Empfangsbestätigung. Das JSON RPC Erfolgsergebnis eines Tools ist schwächer, wenn das versprochene Ergebnis anderswo vorhanden ist. Ein praktischer Rollout kann eng bleiben: 1. Wählen Sie einen Produktions MCP Server und ein leistungsstarkes Tool. 2. Zählen Sie jeden Client Endpunkt und die direkte Upstream URL auf, die ihn erreichen kann. 3. Pinnen Sie eine Gateway Identität und eine Richtlinienrevision im Bereitstellungsnachweis. 4. Senden Sie eine zugelassene und eine abgelehnte Prüfung mit undurchsichtigen Anforderungs IDs. 5. Überprüfen Sie die Identität des Anrufers, den erforderlichen Umfang, die Tool Entscheidung, die Aktualität und einen Prüfbeleg für beides. 6. Probieren Sie den dokumentierten direkten Weg aus und beweisen Sie, dass er blockiert oder explizit geregelt ist. 7. Führen Sie einen genehmigungspflichtigen Anruf aus und behalten Sie ihn bei WAITING bis ein namentlich genannter Eigentümer entscheidet. 8. Simulieren Sie eine Zeitüberschreitung nach dem Upstream Effekt und prüfen Sie dann, ob das Runbook das Ziel liest, bevor Sie es erneut versuchen. 9. Wiederholen Sie die Tests nach Änderungen an Gateway, Identitätsanbieter, Richtlinie, Client oder MCP Server. Es gibt Grenzen. Dieses Fixture testet nicht den Parser, die DLP Engine, die Prompt Injection Abwehrmaßnahmen oder den Schwachstellenscanner eines bestimmten Anbieters. Es beweist nicht, dass ein zentrales Gateway die richtige Architektur für jeden lokalen STDIO Server ist. Ein lokaler Prozess benötigt möglicherweise Steuerungen auf Hostebene anstelle eines Netzwerk Gateways. Es macht Sidewisp auch nicht zu einem erforderlichen Modell oder Tool Gateway. Die beabsichtigte Rolle von Sidewisp ist ähnlich: Erreichbarkeit, Fortschritt, Werkzeuge, Ergebnisse, Zeit und Budgetnachweise in eine Sichtweise der Agentengesundheit einbringen und die menschliche Autorität in Bezug auf die Wiederherstellung bewahren. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Das Live Erlebnis ist eine Early Access Website und eine interaktive Demonstration; Ein Produktions MCP Gateway Adapter, eine Live Überwachungs Engine und ein automatisierter Wiederherstellungs Executor werden nicht mitgeliefert. Verwenden Sie den Durchsetzungsbeleg mit Ihren aktuellen Gateway und Zielsystemen, anstatt davon auszugehen, dass Sidewisp diese derzeit überwacht oder repariert. Die Lösung ist konkret: Routen inventarisieren, Gate und Richtlinie festlegen, Identität und Least Privilege Bereich überprüfen, einen beitrittsfähigen Prüfbeleg verlangen, legitimes Warten wahren und das Ziel überprüfen, bevor der Erfolg erklärt wird. Die Sicherheit des MCP Gateways wird erst dann zum Betriebsbeweis, wenn der Kontrollpfad und die Wirkung übereinstimmen.