FACT COPY · DE
Faktenfassung: MCP-Security-Check
Prüfraster für Identität, Autorisierung, Prompt Injection, Datenzugriff und Nebenwirkungen.
Originalseite: https://travel-mcp.com/de/praxiswissen/security-check/
Sachliche Zusammenfassung
Der Security-Check verbindet Protokollanforderungen mit Travel-Daten, Fachrechten und realen Betriebsrisiken. Kann jede Identität nur die für ihren Zweck erforderlichen Daten und Wirkungen erreichen – auch bei manipuliertem Kontext, gestohlenem Token oder fehlerhaftem Modell?
Leitfrage und Entscheidungsgrenze
Kann jede Identität nur die für ihren Zweck erforderlichen Daten und Wirkungen erreichen – auch bei manipuliertem Kontext, gestohlenem Token oder fehlerhaftem Modell?
Der Security-Check verbindet Protokollanforderungen mit Travel-Daten, Fachrechten und realen Betriebsrisiken.
Architektur und Verantwortlichkeiten
Zu unterscheiden sind Mensch, Host, Client, MCP-Server, Authorization Server, Workload und Backendidentität. Für HTTP agiert ein geschützter MCP-Server als OAuth Resource Server. Resource Indicators und Audience-Prüfung binden Tokens an die Zielressource. Objektberechtigungen entscheiden zusätzlich, welche konkrete Buchung oder welcher Mandant erreichbar ist.
Analytische Methode
Der Check verfolgt einen Aufruf vom Toolangebot über Auswahl, Autorisierung, Backendzugriff und Ergebnis bis zu Logs. Geprüft werden Token-Passthrough, Confused Deputy, Prompt Injection, Tool Poisoning, SSRF, Sessionbindung, Secret Handling, Egress und Datenminimierung. Jeder Befund erhält Angriffspfad, bestehende Kontrolle, Test und Restrestrisiko.
- Authentifizierung und Audience
- Scopes und Objektberechtigungen
- Tool- und Ressourcensicherheit
- Nutzerzustimmung
- Logging, Löschung und Incident Response
Travel-Fallstudie
Ein Buchungstool benötigt nicht nur OAuth, sondern Zugriff auf genau den berechtigten Vorgang, gebundene Zustimmung, Idempotenz und autoritativen Zustandsabgleich.
Das Beispiel gilt erst dann als belastbar, wenn Quellen, Zustände, Rechte und Fehlerpfade genauso konkret dokumentiert sind wie der gewünschte Normalfall.
Typische Fehlkonstruktionen
OAuth allein verhindert weder fremde Buchungszugriffe noch manipulative Toolergebnisse. Scopes sind meist zu grob für Objektzugriff. Ein Bestätigungsdialog ist wirkungslos, wenn Preis, Empfänger oder Nebenwirkung unverständlich bleiben oder Parameter nach der Zustimmung verändert werden können.
Erforderliche Evidenz
Pflichtnachweise sind negative Autorisierungstests, Audience-Mismatch, abgelaufene Tokens, fremde Objekt-IDs, manipulierte Toolresultate, doppelte Aufrufe, unzulässige Redirects und überprüfbare Auditereignisse. Ein Fragebogen ohne praktische Tests ist kein Security Review.
Messgrößen und Abnahmekriterien
Relevant sind abgewiesene Zugriffe, Policy-Fehler, Prompt-Injection-Treffer, Secrets in Logs, mittlere Sperrzeit kompromittierter Capabilities, privilegierte Toolnutzung und Vollständigkeit sicherheitsrelevanter Auditketten.
Ergebnis und weiterführende Analyse
Eine priorisierte Kontrollliste unterscheidet Pflichtkontrollen, risikobedingte Erweiterungen und offene Nachweise.