MCP-Sicherheit: sichere Konfiguration, Identität und Gateway-Autorisierung
Wie Sie das Model Context Protocol produktiv sicher betreiben: ein MCP-Gateway, Autorisierung und Scoping sowie Kontrollen für Maschinenidentitäten, die Agenten-Tooling unter Kontrolle halten.
Definition
Das Model Context Protocol (MCP) ist ein offener Standard, der KI-Agenten über eine einheitliche Schnittstelle mit externen Tools und Daten verbindet. Seine schnelle Verbreitung 2025 schuf ein Identitätsproblem: Agenten handeln als Maschinenidentitäten, die eingegrenzte, widerrufbare Autorisierung statt langlebiger geteilter Schlüssel brauchen.
Als das Model Context Protocol 2025 durchstartete, löste es ein reales Problem: Jeder Agent brauchte einen eigenen Adapter für jedes Tool, und MCP gab ihnen eine Schnittstelle. Doch eine einheitliche Tür zu Ihren Systemen ist auch eine einheitliche Tür für Angreifer. Das Schwierige an MCP ist nicht das Protokoll — es ist die Identität.
Warum schafft MCP ein Identitätsproblem?
Ein über MCP verbundener Agent handelt auf Ihren Systemen. Dafür authentifiziert er sich — mit einem API-Schlüssel, einem Token, einem Zertifikat. Das macht den Agenten zu einer Non-Human Identity (NHI), und die meisten Organisationen haben dafür keine echte Verwaltung. Prozesse wurden für Menschen gebaut: Eintritt, Wechsel, Austritt. Ein Agent ist nichts davon und kann dennoch eine Datenbank lesen oder eine E-Mail senden.
Das Ergebnis nennen Fachleute eine Identitätskrise: Tausende Maschinen-Credentials, oft langlebig, weit gefasst und niemandem zugeordnet. Wird ein Agent durch Prompt Injection kompromittiert, sind diese Credentials der Schadensradius.
Authentifizierung ist nicht Autorisierung
Ein häufiger Fehler ist, bei der Authentifizierung stehenzubleiben: Der Agent weist nach, wer er ist, und darf dann alles, was diese Identität darf. Für autonome Systeme ist das viel zu grob.
Die entscheidende Kontrolle ist die Laufzeit-Autorisierung — die Entscheidung im Moment jeder Aktion, ob diese Identität diese Aktion jetzt im gegebenen Kontext ausführen soll. Ein Lese-Token darf nie stillschweigend zum Schreiben werden. Ein Tool, das Rechnungen zusammenfasst, darf keine Zahlungen auslösen.
| Aspekt | Authentifizierung | Autorisierung |
|---|---|---|
| Welche Frage sie beantwortet | Wer ist diese Identität? | Darf sie diese Aktion jetzt, in diesem Kontext? |
| Wann sie läuft | Einmal, bei der Verbindung | Bei jeder sensiblen Aktion |
| Wenn Sie hier aufhören | Die Identität darf alles, was ihre Rolle erlaubt | Jede Aktion wird gegen Policy geprüft |
| MCP-Beispiel | Der Agent legt ein Token vor | Das Gateway erlaubt Lesen, verweigert Zahlung |
Das Gateway: ein Ort für die Frage „soll das geschehen?”
Der Kontrollpunkt, der Laufzeit-Autorisierung praktikabel macht, ist ein MCP-Gateway — eine Schicht zwischen Ihren Agenten und den MCP-Servern, die sie aufrufen. Statt inkonsistentem Vertrauen pro Server bündelt das Gateway vier Dinge: Eingrenzung (welche Identität welches Tool aufrufen darf — Least Privilege an einer Stelle), Laufzeit-Policy (Regeln zur Aufrufzeit, sodass ein Lese-Token nie stillschweigend zum Schreiben wird), Freigabe-Routing (folgenreiche Aktionen gehen vor der Ausführung an einen Menschen) und Audit pro Identität (ein zuordenbarer Trail statt Fragmente über Server hinweg).
| Kontrolle | Mit Gateway | Ohne |
|---|---|---|
| Eingrenzung | Least Privilege an einer Stelle erzwungen | Jeder Server entscheidet, inkonsistent |
| Laufzeit-Policy | Regeln zur Aufrufzeit geprüft | Vertrauen per Default nach Login |
| Freigabe | Folgenreiche Aktionen an einen Menschen geleitet | Ad hoc pro Server verdrahtet oder übersprungen |
| Audit | Ein Trail pro Identität | Über Server zersplittert |
Für einen Agenten mit einem vertrauenswürdigen Tool ist ein Gateway Zeremonie, die Sie noch nicht brauchen — grenzen Sie dieses eine Credential eng ein und gehen Sie weiter. Ergänzen Sie eines in dem Moment, in dem eine falsche Aktion realen Schaden anrichten könnte: mehrere Agenten, MCP-Server von Dritten oder Tools, die Geld bewegen oder Produktion berühren. Drei Gewohnheiten halten es steuerbar: Berechtigungen als Policy-as-Code (versioniert und testbar), standardmäßig verweigern und irreversible Aktionen zur menschlichen Freigabe leiten. Es ist kein API-Gateway unter neuem Namen — ein API-Gateway bewacht die Haustür eines Dienstes pro Request, ein MCP-Gateway entscheidet Aktion für Aktion, ob der denkende Agent dahinter einen Hebel ziehen darf; in den meisten Architekturen koexistieren beide.
Ein praktischer Kontroll-Stack
- Inventar. Listen Sie jeden MCP-Server und seine Credentials. Nicht zugeordnete Identitäten zuerst beheben.
- Least Privilege pro Tool. Grenzen Sie jedes Credential auf das Minimum ein. Bevorzugen Sie kurzlebige, automatisch rotierte Tokens statt statischer Schlüssel.
- Laufzeit-Autorisierung. Setzen Sie eine Policy-Entscheidung vor sensible Aktionen — ein MCP-Gateway oder eine Autorisierungsschicht, nicht Vertrauen per Default.
- Audit pro Identität. Protokollieren Sie, welche Identität was getan hat, mit signierten, manipulationssicheren Aufzeichnungen. Eine nicht zuordenbare Aktion ist eine nicht steuerbare Aktion.
- Zero-Trust zwischen Agenten. In Multi-Agent-Systemen darf ein Agent die Anfrage eines anderen nicht als automatisch sicher behandeln.
Die 30/90/180-Sicht
In den ersten 30 Tagen inventarisieren und die schlimmsten langlebigen Schlüssel beseitigen. Nach 90 Tagen Tools auf Least Privilege eingrenzen und ein Gateway für sensible Aktionen ergänzen. Nach 180 Tagen hat jede Maschinenidentität einen Eigentümer, einen Lebenszyklus und einen Audit-Trail.
Identität ist der Punkt, an dem Agenten-Sicherheit und Governance zusammentreffen. Klären Sie das Vokabular im Glossar und beginnen Sie dann mit dem, was sich immer auszahlt: erfassen, was Sie haben.
Häufige Fragen
Ist MCP selbst unsicher?
Das Protokoll ist nicht der Kern des Problems — die Verkabelung ist es. MCP standardisiert, wie Agenten Tools erreichen, sodass bestehende Autorisierungsfehler (weite Tokens, langlebige Schlüssel, überberechtigte Tools) plötzlich über eine Schnittstelle skalieren. Die Lösung ist nicht, den Standard aufzugeben, sondern disziplinierte Autorisierung: eingegrenzte, kurzlebige Credentials, eine Policy-Entscheidung vor sensiblen Aktionen sowie Eigentümer und Audit-Trail für jede Maschinenidentität.
Wie unterscheidet sich ein MCP-Gateway von einem API-Gateway?
Sie teilen die Form, beantworten aber verschiedene Fragen. Ein API-Gateway übernimmt HTTP-Belange — Routing, Limits, Authentifizierung — für Clients Ihrer Dienste, pro Request. Ein MCP-Gateway ist für Agentenverhalten gebaut: feingranulare Autorisierung pro Aktion für Maschinenidentitäten, die Tools in einer Schleife aufrufen, plus Freigabe-Routing und Audit pro Identität. In den meisten Architekturen koexistieren beide.
Womit sollten wir beginnen?
Mit einem Inventar, vor allem anderen. Erfassen Sie jeden MCP-Server, jeden Agenten und jedes Credential, und markieren Sie die langlebigen, weit gefassten und niemandem zugeordneten — das ist Ihr unmittelbares Risiko. Beseitigen oder rotieren Sie die schlimmsten statischen Schlüssel, grenzen Sie den Rest auf Least Privilege ein und setzen Sie vor wirklich sensible Aktionen eine Laufzeitprüfung. Erst Entdeckung, dann Eindämmung.
Warum sind langlebige API-Schlüssel für Agenten so riskant?
Dauer mal Reichweite. Ein statischer Schlüssel funktioniert unbefristet, eine über ein Log, eine Prompt Injection oder eine kompromittierte Abhängigkeit geleakte Kopie bleibt also lange nach dem Vorfall gültig — und trägt meist weit mehr Zugriff, als eine Aufgabe braucht. Ersetzen Sie statische Schlüssel durch kurzlebige, eingegrenzte, automatisch rotierte Tokens mit Audit pro Identität, damit ein gestohlenes Credential schnell abläuft und nachverfolgbar ist.