Ausgangslage und Problemstruktur
MCP erweitert die klassische API-Angriffsfläche um dynamische Tool-Auswahl, untrusted resources, server-to-client Requests und nutzernahe Freigaben. Bestehende IAM- und Gatewaykontrollen bleiben notwendig, decken aber nicht alle neuen Entscheidungswege ab.
Ein Bedrohungsmodell erfasst Hosts, Clients, Server, Authorization Server, Downstream-APIs, Datenklassen und Trust Boundaries. Bedrohungen umfassen Prompt Injection, Tool Poisoning, Confused Deputy, Token Theft, SSRF und Session Hijacking.
Fachliche und technische Analyse
Jeder Capability-Aufruf wird auf Identität, Audience, Scope, Objektberechtigung, Datenzweck und Nebenwirkung untersucht. Token-Passthrough und technische Sammelkonten werden als explizite Risiken behandelt.
Für stdio sind zu prüfen Prozessrechte, Roots, Secrets und Sandbox. Für Streamable HTTP zusätzlich TLS, Origin, Protected Resource Metadata, Egress, Sessions und horizontale Skalierung.
Referenzarchitektur und Sicherheitsgrenzen
Das Ergebnis ist eine Defense-in-Depth-Architektur: Clientfilter, Consent, Gatewaypolicy, Serverautorisierung, Backendrecht, Ausgabeminimierung und Audit wirken unabhängig.
Kill Switches deaktivieren einzelne Tools. Idempotenz, Zustandsabgleich und Vier-Augen-Freigabe sichern irreversible Reise-, Zahlungs- oder Veröffentlichungsprozesse.
Prüfmethode und erforderliche Artefakte
Prüfbare Architekturartefakte sind Referenzarchitektur, Datenflussdiagramme, Threat Model, Rollen- und Scopematrix, Tool-Risikoklassen, Logging- und Löschkonzept sowie Security-Testkatalog.
Kontrollen werden in technische Akzeptanzkriterien übersetzt, damit sie in Code, Infrastruktur und CI überprüfbar sind.
Bewertungskriterien und belastbare Evidenz
Abnahme umfasst negative Rechtefälle, falsche Audience, abgelaufene Tokens, manipulierte Ressourcen, SSRF-Ziele, Retry und Parallelität.
Architektur gilt erst als tragfähig, wenn ein Incident rekonstruierbar ist und einzelne Fähigkeiten ohne Gesamtausfall gesperrt werden können.
FAQ zu MCP-Architektur und Security verstehen
Reicht OAuth?
Nein. OAuth begrenzt den Protokollzugriff; Fachrechte, Eingabevalidierung, Consent, Ausgabekontrolle und Betrieb bleiben zusätzlich nötig.
Ist On-Premises automatisch sicherer?
Nein. Datenlage und Kontrolle können passen, aber lokale Prozessrechte und fehlende Patchprozesse erzeugen eigene Risiken.
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.