Wie MCP funktioniert
MCP definiert eine Client-Server-Architektur mit drei klar abgegrenzten Rollen. Diese zu verstehen ist die Voraussetzung dafür, sie zu regeln.
Host, Client und Server
Der Host ist die Anwendung, mit der der Nutzer interagiert — eine Chat-Oberfläche, ein IDE-Assistent oder eine autonome Agent-Runtime. Der Host instanziiert einen oder mehrere MCP-Clients, von denen jeder eine eigene Verbindung zu einem einzelnen MCP-Server unterhält. Der Server ist ein separater Prozess (lokal oder remote), der dem Modell Fähigkeiten in strukturierter, auffindbarer Form bereitstellt.
Server bieten drei Primitive an:
- Tools — Funktionen, die das Modell aufrufen kann, um Aktionen auszuführen: eine Datenbank abfragen, eine E-Mail senden, ein Ticket erstellen, einen Shell-Befehl ausführen.
- Ressourcen — Daten, die das Modell lesen kann: Dateien, Datensätze, API-Antworten, Dokumente.
- Prompts — wiederverwendbare Vorlagen, die der Server dem Host anbietet.
Wenn ein Modell entscheidet, eine Fähigkeit zu nutzen, leitet der Client eine strukturierte Anfrage an den Server weiter, der Server führt sie aus, und das Ergebnis wird in den Kontext des Modells zurückgegeben. Der Transport erfolgt typischerweise über JSON-RPC über stdio für lokale Server oder über HTTP für entfernte.
Warum es wichtig ist
Vor MCP war jede Verbindung zwischen einer AI-Anwendung und einem externen System eine maßgeschneiderte Integration. MCP verwandelt dieses N×M-Integrationsproblem in ein N+M-Problem: Jeder MCP-kompatible Host kann mit jedem MCP-Server kommunizieren. Das Ergebnis ist ein schnell wachsendes Ökosystem von Servern — offiziell, von der Community und von Anbietern erstellt —, die ein Agent zur Laufzeit kombinieren kann. Genau diese Kombinierbarkeit macht MCP strategisch wichtig, und genau sie macht es zu einem Sicherheitsthema.
MCP im Vergleich zur klassischen API-Integration
MCP und eine handgebaute API-Integration können dasselbe Backend-System erreichen, unterscheiden sich jedoch darin, wie Fähigkeiten bereitgestellt, entdeckt und kontrolliert werden.
| Klassische API-Integration | Model Context Protocol (MCP) | |
|---|---|---|
| Kopplung | Eine Integration je App-/Dienst-Paar | Jeder MCP-Host verbindet sich mit jedem MCP-Server |
| Fähigkeitserkennung | Fest kodiert zur Build-Zeit | Dynamisch vom Server zur Laufzeit angeboten |
| Aufrufer | Deterministische Anwendungslogik | Ein nicht-deterministisches Modell, das Tools und Argumente wählt |
| Vertrauensgrenze | Geprüfter, versionierter Code unter Ihrer Kontrolle | Drittanbieter-Serverprozess, den Sie evtl. nicht kontrollieren |
| Netzwerk-Einblick | Standard-ausgehende API-Calls, oft protokolliert | Tool-Calls über stdio/lokalen Transport, oft unsichtbar |
| Governance-Punkt | Anwendungscode und API-Gateway | Die Agent-Runtime, bevor der Tool-Call ausgeführt wird |
Die entscheidende Verschiebung ist der Aufrufer. Eine klassische Integration führt Code aus, den ein Entwickler geschrieben und geprüft hat; ein MCP-Tool-Call wird von einem Modell zur Inferenzzeit gewählt, mit Argumenten, die aus einem Kontext abgeleitet sind, der nicht vertrauenswürdige Eingaben enthalten kann.
Sicherheitsimplikationen von MCP
MCP erweitert, was ein Agent tun kann, und damit erweitert es, was ein Angreifer über den Agenten tun kann. Die folgenden Risiken sind keine theoretischen Randfälle — sie folgen direkt aus dem Design des Protokolls.
Überberechtigte Server und übermäßige Handlungsmacht
MCP-Server werden häufig mit weitreichenden, langlebigen Zugangsdaten konfiguriert — eine Datenbankverbindung mit vollem Lese-/Schreibzugriff, ein API-Token mit Gültigkeit für einen gesamten Workspace. Das Modell verfügt dann faktisch über die gesamte Autorität, die der Server besitzt. „Übermäßige Handlungsmacht" (Excessive Agency) beschreibt die Lücke zwischen dem, was ein Agent für eine Aufgabe tun muss, und dem, was er technisch tun kann. Ein Zusammenfassungs-Agent, der ein löschfähiges Datenbank-Tool hält, kann dazu verleitet werden, Datensätze zu löschen, auch wenn das Löschen nie Teil seiner Aufgabe war.
Für Netzwerk- und DLP-Kontrollen unsichtbare Tool-Calls
Lokale MCP-Server kommunizieren über stdio, und selbst entfernte tragen freie Argumente statt erkennbarer Dateiübertragungen. Eine Netzwerk-DLP-Appliance sieht eine verschlüsselte Sitzung oder gar nichts; sie sieht nicht, dass ein Tool-Call-Argument eine Kundenliste oder ein Geheimnis enthält. Die Aktion, die ein Agent ausführt — und die Daten, die er übergibt — geschieht unterhalb der Schicht, die die meiste Enterprise-Überwachung prüft.
Indirekte Prompt-Injection über Tool-Ergebnisse
Dies ist das für MCP spezifischste Risiko. Wenn ein Server eine Ressource zurückgibt — eine Webseite, eine E-Mail, ein Dokument, einen Datensatz —, gelangt dieser Inhalt in den Kontext des Modells und wird als anweisungsführender Text behandelt. Ein Angreifer, der Text in einer Datenquelle platzieren kann, die der Agent lesen wird (eine Kalendereinladung, ein Support-Ticket, ein Code-Kommentar), kann Anweisungen einschleusen, nach denen das Modell dann handelt — unter Verwendung seiner legitimen Tools. Der Agent ist im klassischen Sinne nicht kompromittiert; er befolgt getreu Anweisungen, die über Daten eintrafen.
Supply-Chain-Risiko von Drittanbieter-Servern
Einen MCP-Server zu installieren bedeutet, Code zu installieren, der mit den Berechtigungen des Agenten läuft und das Verhalten des Modells prägt. Zu den Risiken zählen bösartige oder per Typosquatting nachgeahmte Server, Tool-Beschreibungen, die das Modellverhalten manipulieren sollen („Tool Poisoning"), und das stille Umdefinieren eines Tools, nachdem es genehmigt wurde („Rug Pulls"). Da Server leicht hinzuzufügen sind und das Ökosystem jung ist, sind Herkunft und Integrität oft ungeprüft.
Authentifizierung und Wildwuchs bei Zugangsdaten
Jeder Server benötigt Zugangsdaten zu dem System, das er vorschaltet. Ohne zentrales Brokering häufen sich diese Geheimnisse über Host-Konfigurationen hinweg an, sind häufig zu weit gefasst und werden selten rotiert. Eine einzige geleakte Serverkonfiguration kann dauerhaften Zugang zu einem Produktivsystem offenlegen.
Fragen, die MCP-Governance beantworten sollte
- Welche MCP-Server sind verbunden, und was stellen sie bereit? — Inventar der Server, Tools und der Scopes, die sie halten.
- Was hat dieser Agent tatsächlich getan? — Ein Datensatz je Aufgabe über jeden Tool-Call, seine Argumente und sein Ergebnis.
- War dieser Tool-Call richtlinienkonform? — Least-Privilege-Durchsetzung, ausgewertet vor der Ausführung, nicht danach.
- Wurde eine risikoreiche Aktion menschlich freigegeben? — Freigabe-Datensätze mit Prüfer-Identität für destruktive oder sensible Operationen.
- Ging diese Aktion auf eingeschleusten Inhalt zurück? — Nachverfolgbarkeit von einem Tool-Call zurück zu den Daten, die ihn ausgelöst haben.
