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.

Primärquellen und wissenschaftliche Einordnung

Die Darstellung folgt der versionierten MCP-Spezifikation. Normative Anforderungen werden von Architektur- und Betriebsempfehlungen getrennt; experimentelle Funktionen sind entsprechend gekennzeichnet.