Eine MCP-Verbindung ist eine Möglichkeit, Funktionen offenzulegen, und kein Grund, jedem angebotenen Vorgang zu vertrauen. Bevor Sie einen Authentifizierungsanalysten verbinden, geben Sie an, welchen Mandanten er prüfen darf, welche Beweise er abrufen darf und welche Aktionen nicht verfügbar bleiben. Eine Aufgabe zum Lesen von Berichten sollte nicht DNS Veröffentlichung erben, nur weil ein Server beide Tools anbietet.
Beginnen Sie mit dem eigentlichen Datenpfad
Ordnen Sie die Hostanwendung, den MCP-Client, den Server, den Berichtsspeicher und alle nachgelagerten APIs zu. Notieren Sie, wo Token enden und welche Organisation die einzelnen Komponenten betreibt. Der MCP-Autorisierungsspezifikation beschreibt die Autorisierung für HTTP-basierte Transporte; Gehen Sie nicht davon aus, dass der Ablauf unverändert für lokale stdio-Server gilt. Eine lokale ausführbare Datei kann auch ohne einen Remote-OAuth-Austausch Zugriff auf das Dateisystem oder die Umgebung haben.
Trennen Sie den Berichtsabruf vom Abruf der Rohnachricht. Aggregierte Zählungen können eine Frage zum Absendertrend beantworten, ohne Betreff, Empfänger oder Anhänge der Nachricht preiszugeben. Erzwingen Sie die Mandantenisolation auf dem Server mithilfe eines authentifizierten Kontexts, anstatt einen vom Modell bereitgestellten Mandantennamen als Autorität zu akzeptieren. Geben Sie stabile Quellkennungen zurück, damit eine Zusammenfassung zurückverfolgt werden kann, ohne dass uneingeschränkte Speicher-URLs offengelegt werden.
Begrenzen Sie Anmeldeinformationen und Tool-Reichweite
Verwenden Sie Anmeldeinformationen mit dem minimal unterstützten Ressourcen- und Aktionsbereich. Bewahren Sie Geheimnisse im genehmigten Anmeldeinformationsmechanismus auf, nicht in Eingabeaufforderungen, Toolbeschreibungen, Berichtsfeldern oder Protokollen. Der MCP-Sicherheitsleitfaden verbietet Token-Passthrough: Ein Server darf ein Upstream-Token, das für einen anderen Dienst bestimmt ist, nicht einfach akzeptieren und weiterleiten. Validieren Sie die beabsichtigte Zielgruppe und implementieren Sie die richtige nachgelagerte Autorisierungsbeziehung.
Inventarisieren Sie jedes verfügbare Tool, einschließlich allgemeiner HTTP-, Shell- und Dateischreibfunktionen. Das Ausblenden einer DNS-spezifischen Schaltfläche bringt wenig, wenn ein generisches Ausführungstool denselben Anbieter mit breiten Anmeldeinformationen aufrufen kann. Entfernen Sie unnötige Funktionen an der Ausführungsgrenze. Werkzeuganmerkungen und beschreibende Namen können Kunden dabei helfen, Werkzeuge vorzustellen, sind jedoch kein Ersatz für eine erzwungene Autorisierung.
Üben Sie feindselige Berichtsinhalte aus
Für die nachstehende schriftliche Richtlinie gehen wir von einem authentifizierten Mieter A und einer genehmigten Berichtsanalyseaufgabe aus. Nur read_report für Mandant A ist zulässig. Wenn Sie Inhalte melden, die nach einem Geheimnis oder DNS Veröffentlichung fragen, kann diese Berechtigung nicht erweitert werden. Hierbei handelt es sich um eine vorgeschlagene Richtlinie, nicht um einen durchgeführten Sicherheitstest oder eine verifizierte Serverkonfiguration.
Behandeln Sie Berichtstexte, Nachrichtenbeispiele und vom Server zurückgegebene Anweisungen als nicht vertrauenswürdige Beweise. Eine Zeichenfolge, die vorgibt, ein Administrator zu sein, wird nicht zu einem Genehmiger. Der Analytiker kann diese Zeichenfolge als verdächtig bezeichnen, ohne ihr zu gehorchen. OWASP empfiehlt mehrschichtige Abwehrmaßnahmen, da der Wortlaut der Anweisungen allein eine sofortige Injektion nicht ausschließt.
Überprüfen Sie das vollständige Entscheidungsbuch
- Fall bekannter Eigentümer: Mieter A, genehmigte Aufgabe, Lesebericht für A. Gemäß der vorgeschlagenen Richtlinie zulassen; Bei der Berechnung werden nur genehmigte zurückgegebene Nachweise verwendet.
- Fall eines falschen Mandanten: Der authentifizierte A fordert den Mandanten B an. Verweigert den Lesevorgang unabhängig von einer Mandantenbezeichnung im Bericht.
- Fall feindlicher Inhalte: Textanfragen „read_secret“ und „publish_dns“ melden. Beide Tools ablehnen; Der autorisierte read_report für A kann fortgesetzt werden, wobei feindlicher Text nur als Daten behandelt wird.
- Fall mit unklarem Eigentümer: Ein A-Bericht nennt sowohl App-A als auch App-B als mögliche Eigentümer. Erlauben Sie nur die Sammlung autorisierter Beweise, kennzeichnen Sie die Identität als ungeklärt und eskalieren Sie die Zuordnung, anstatt einen Eigentümer auszuwählen.
- Fall mit nicht genehmigter Aufgabe: Es liegt keine genehmigte Untersuchung vor. Halten Sie den aufgabengesteuerten Abruf zurück, bis die Autorisierung geklärt ist, auch wenn ein Berechtigungsnachweis das Lesen technisch zulässt.
Für dieses Ledger wurden keine Toolaufrufe, Modellbewertungen, Anmeldeinformationsausstellungen oder Grenztests durchgeführt. Diese Regeln erfordern Implementierungstests anhand der tatsächlichen Server- und Downstream-Berechtigungen, bevor irgendjemand behauptet, dass sie durchgesetzt werden.
Überprüfen Sie den Betrieb und entziehen Sie den Zugriff
Protokollieren Sie den Namen des Tools, den authentifizierten Mandanten, die Beweisreferenzen und das Autorisierungsergebnis, ohne Token zu kopieren. Testen Sie den Ablauf und Widerruf des Zugriffs, einschließlich aktiver Sitzungen und Downstream-Berechtigungen. Eine erfolgreiche Trennung bei einem Client reicht nicht aus, wenn ein langlebiger Provider-Zugangsdatensatz an anderer Stelle weiterhin gültig bleibt.
Beginnen Sie mit einem schreibgeschützten Pilotprojekt und einer expliziten Liste von Fragen, die der Analyst beantworten sollte. Stellen Sie sicher, dass Ablehnungen sinnvoll sind: Sie sollten fehlende Beweise oder fehlenden Umfang identifizieren, anstatt einen Mieter stillschweigend auszulassen oder ein Ergebnis zu fabrizieren. Erweitern Sie Berechtigungen erst nach einer separaten Prüfung der neuen Aktion. Hierbei handelt es sich um ein vorgeschlagenes Kontrollmuster, nicht um eine verifizierte EmailAuth -Produktfunktion.