1. Bedrohungsmodell
Angreifer können Nutzer, Clients, Server, Dokumente oder Downstream-Systeme kontrollieren. Auch legitime Nutzer mit zu breiten Rechten sind ein Risiko. Datenflussdiagramme markieren Identitäten, Trust Boundaries, Secrets und Nebenwirkungen.
Prompt Injection ist nur eine Klasse. Confused Deputy, Token Theft, SSRF, DNS-Rebinding, Session Hijacking, Tool Poisoning und Supply-Chain-Angriffe benötigen technische Kontrollen außerhalb des Modells.
2. Authentifizierung und Autorisierung
Authentifizierung identifiziert Nutzer oder Workload; Autorisierung entscheidet pro Operation. HTTP-MCP verwendet ein OAuth-basiertes Modell, lokale stdio-Server häufig Prozess- und Umgebungscredentials.
Der Server validiert Signatur, Issuer, Ablauf, Audience und Scopes. Danach folgen objektbezogene Fachrechte. Ein gültiger Token ist keine pauschale Erlaubnis.
3. Token Audience und Passthrough
RFC 8707 bindet Tokens über Resource Indicators an die Zielressource. Der MCP-Server akzeptiert nur für ihn ausgestellte Tokens.
Token-Passthrough ist verboten, weil es Audience, Rate Limits und Audit umgeht. Downstreamzugriff verwendet korrekt delegierte oder serverseitige Credentials mit minimalem Umfang.
4. Confused Deputy und Consent
Ein MCP-Proxy mit statischer Third-Party-Client-ID darf frühere Zustimmung nicht für einen neuen MCP-Client wiederverwenden. Consent wird pro Client und Scope gespeichert.
Redirect-URIs werden exakt geprüft; State ist zufällig, einmalig und kurzlebig. Die Consent-Oberfläche zeigt Client, Scopes und Ziel.
5. SSRF und Metadaten
OAuth Discovery verarbeitet URLs aus Metadaten. Private, Loopback- und Link-local-Ziele werden blockiert, Redirects erneut geprüft und HTTPS erzwungen.
RFC 9728 definiert Protected Resource Metadata. Das resource-Feld muss exakt zum angefragten Ressourcen-Identifier passen.
6. Prompt Injection und Datenabfluss
Ressourceninhalte sind untrusted data. Eingebettete Anweisungen dürfen Systempolicy oder Toolfreigaben nicht überschreiben.
Der Host trennt Daten von Instruktionen, begrenzt ausgehende Tools und zeigt sensible Aktionen. Der Server minimiert Resultate und verhindert freie Exfiltrationsziele.
7. Sessions, Tasks und Elicitation
Session-IDs sind zufällig und an den autorisierten Nutzer gebunden, aber keine Authentifizierung. Tasks liefern nur Ergebnisse desselben Requestors.
Elicitation bindet Initiator und abschließenden Nutzer. Form Mode fragt keine Secrets ab; URL Mode zeigt Domain und benötigt Zustimmung.
8. Governance
Jedes Tool erhält Owner, Risikoklasse, Datenfluss, Scopes, Tests, SLO und Deprecation. Publisher und Abhängigkeiten werden inventarisiert.
Regelmäßige Reviews entfernen ungenutzte Rechte und verwaiste Server. Incident Response kann einzelne Capabilities über Kill Switches deaktivieren.
9. Datenschutz und Audit
Datenminimierung, Zweckbindung, Löschfristen und Mandantentrennung gelten für Eingabe, Ergebnis, Modellkontext und Telemetrie.
Audit erfasst Identität, Client, Tool, Entscheidung und Wirkung, aber keine Tokens oder unnötigen Vollinhalte. Nachvollziehbarkeit und Vertraulichkeit müssen gemeinsam gestaltet werden.
Kontrollmatrix für Travel-Capabilities
| Capability | Hauptrisiko | Pflichtkontrollen |
|---|---|---|
| search_offers | Datenabfluss, falsche Frische | Minimierung, Provenienz, Limits |
| revalidate_offer | Falsche Preiszusage | Autoritative Quelle, Ablauf, Differenz |
| create_order | Doppelbuchung, Fremdzugriff | Objektrecht, Zustimmung, Idempotenz |
| refund_payment | Finanzieller Schaden | Erhöhte Rolle, Audit, Limits |
Suche, Repricing, Buchung und Erstattung erhalten getrennte Rechte und Wiederherstellungswege.
Negativtest: manipulierte Hotelbeschreibung
Eine Ressource fordert das Modell auf, Regeln zu ignorieren und Profildaten an eine externe URL zu senden. Der Host behandelt dies als untrusted data; Egress-Ziel und Tool sind nicht freigegeben. Der Server würde Scope, Mandant und Objekt zusätzlich prüfen.
Bestanden ist der Test nur, wenn keine verborgene Anfrage, Vollinhalt-Telemetrie oder Folgeaktion entsteht. Schutz kombiniert Kontexttrennung, Capability-Filter, Egress-Kontrolle, Autorisierung und beobachtbare Negativtests.
Autorisierung vom Token bis zum Reiseobjekt
Ein gültiges Access Token beantwortet nicht, ob die handelnde Person genau diese Buchung lesen, ändern oder stornieren darf. Der Resource Server prüft Signatur, Issuer, Ablauf und Audience; anschließend folgen Mandant, Rolle, Objektbeziehung, Markt und aktueller Fachzustand. Support- oder Vermittlerzugriffe benötigen gegebenenfalls Delegationsnachweis, Begründung und zeitliche Begrenzung.
Scopes sollten fachlich eng sein. Ein Scope `booking.write` ist für Storno, Umbuchung und Namenskorrektur häufig zu grob, weil Auswirkungen und Freigaben verschieden sind. Der Server darf Downstreamtokens nicht blind durchreichen. Er verwendet eine definierte Delegation oder eigene minimale Credentials und protokolliert die resultierende Entscheidung ohne Token oder unnötige personenbezogene Vollinhalte.
Governance als überprüfbarer Betrieb
Jede Capability besitzt Owner, Risikoklasse, Datenfluss, unterstützte Clients, SLO, negative Tests, Deprecation und Kill Switch. Neue Tools werden nicht allein aufgrund technischer Funktionsfähigkeit veröffentlicht. Die Abnahme prüft verständliche Beschreibung, Fehlselektion durch Modelle, unzulässige Objektzugriffe, Ergebnisgröße, Frische und Wiederherstellung nach Downstreamfehlern.
Incidents müssen bis zur fachlichen Wirkung rekonstruierbar sein. Eine gemeinsame Korrelations-ID verbindet Hostentscheidung, Clientaufruf, Serverautorisierung und Lieferantenergebnis. Telemetrie trennt abgelehnte Rechte von Systemfehlern und veralteten Offers. Regelmäßige Reviews entfernen ungenutzte Scopes und Capabilities; ein einzelnes riskantes Tool muss abschaltbar sein, ohne den gesamten Domänenserver außer Betrieb zu nehmen.
FAQ zu MCP-Sicherheit und Governance
Ist eine Nutzerbestätigung ausreichend?
Nein. Zustimmung ergänzt, aber ersetzt keine serverseitige Autorisierung.
Schützt ein Systemprompt vor Prompt Injection?
Nein. Systemprompts sind keine verlässliche Sicherheitsgrenze. Tool- und Datenkontrollen müssen technisch erzwungen werden.
Braucht stdio OAuth?
Die HTTP-Autorisierungsspezifikation ist für entfernte Server gedacht. Lokale Server nutzen typischerweise Prozesskontext oder Umgebungscredentials und benötigen Sandboxing.
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.