Wie man MCP-Architekturen für die Enterprise-Produktion absichert

Ich habe gesehen, wie das Model Context Protocol (MCP) unglaubliche agentenbasierte Workflows ermöglicht, aber es gibt eine harte Wahrheit, die ich meinen Kunden immer sage: Der Aufbau der technischen Architektur ist der einfache Teil. Die meisten MCP-Projekte scheitern an der Diskrepanz zwischen "es funktioniert perfekt in meiner Demo" und "das Sicherheitsteam des Unternehmens gibt es für die Produktion frei".

Um eure KI-Agenten aus der Sandbox in die Produktion zu bringen, müsst ihr vom ersten Tag an Sicherheit, Governance und Unternehmensrealität berücksichtigen. Im Folgenden findet ihr einen pragmatischen Leitfaden zu den Sicherheitsüberlegungen und Best Practices, die ich bei der Entwicklung von MCP für Unternehmen anwende.

1. OAuth-Token-Verwaltung in zustandslosen Architekturen

Der MCP-Server funktioniert in der Demo perfekt. Dann wird euer Container über Nacht auf Null skaliert, und alles geht kaputt.

Das Kernproblem ist das Ablaufen von OAuth-Tokens. Wenn eure "zustandslose" Architektur das Token in dem Moment verliert, in dem ein Container herunterfährt, muss sich der Benutzer jeden Morgen neu authentifizieren, ohne dass er ein neues Token erhält. Das Sicherheitsteam eures Unternehmens wird ein System mit derartigen Problemen nicht genehmigen.

Im Folgenden findet ihr vier Lösungsansätze, geordnet nach der Schwierigkeit der Implementierung:

• Getrennte Token-Speicherung (geringes Problem): Speichert Refresh-Tokens außerhalb des Containers in einem Secrets Manager oder einer leichtgewichtigen Persistenzschicht. Beim Booten des Containers wird nahtlos ein neues Token geholt.
• Trennung von Lese- und Schreibzugriff (mittlere Schwierigkeit): Die meisten MCP-Anwendungsfälle sind stark leseorientiert. Verwendet ein langlebiges Service-Konto-Token für Nur-Lese-Vorgänge und verlangt OAuth auf Benutzerebene ausschließlich für Schreibvorgänge.
• Haltet den Container warm (hohe Kosten, geringe Schmerzen): Deaktiviert einfach die automatische Skalierung auf Null. Das ist zwar teuer, könnte aber die richtige Entscheidung sein, wenn euer Sicherheitsteam die Token-Persistenz blockiert.
• 90-Tage-Refresh-Fenster (der Sweet Spot): Konfiguriert das System so, dass das Refresh-Token gültig bleibt, wenn Benutzer mindestens einmal alle 90 Tage damit interagieren. Der Container kann nachts heruntergefahren werden, aber die Authentifizierung bleibt bestehen, solange er regelmäßig genutzt wird.

2. Grenzen des Datenzugriffs: das Sandbox-Muster

Lasst euren KI-Agenten niemals seine eigenen Daten abrufen.

Wenn ein Agent direkten Zugriff auf Produktionsdatenquellen hat, erbt er die Berechtigungen seines Dienstkontos. In den meisten Unternehmen verfügen Dienstkonten über weit mehr Zugriffsrechte, als ein einzelner Benutzer haben sollte. Anfang 2026 prüfte ich eine Kundenumgebung, in der ein KI-Assistent mit Leseberechtigung ein veraltetes Dienstkonto erbte, das immer noch über DROP TABLE-Berechtigungen für drei Produktionsdatenbanken verfügte. Der Agent versteht weder die IAM-Grenzen noch die Datenklassifizierung; er fragt fröhlich alles ab, was er erreichen kann.

Dies führt häufig dazu, dass der Agent sensible Daten entdeckt und sie in einer prompten Antwort preisgibt. Um dies zu verhindern, implementiert das Sandbox-Muster:

1. Ein separater Prozess holt die Daten mit den tatsächlichen Rechten des Kunden ab, nicht mit denen des Agenten.
2. Diese Daten werden in eine Sandbox-Umgebung geladen.
3. Der Agent arbeitet ausschließlich innerhalb dieser Sandbox.
4. Der Agent kann physisch keine IAM-Regeln überspringen, da er die Quellsysteme nie berührt.

Behandelt euren KI-Agenten wie einen nicht vertrauenswürdigen Praktikanten mit guten Absichten. Gebt ihm genau die Daten, die er benötigt, auf der Berechtigungsebene des Benutzers, und nicht mehr.

3. Berechtigungsmodelle und der Mensch in der Schleife

Teams gewähren Agenten oft einen umfassenden Zugriff, da die Erstellung von Berechtigungsmodellen Zeit kostet. Dies führt zu drei verschiedenen Fehlermodi: Verstoß gegen undokumentierte API-Verträge, Zerstörung von Daten durch rücksichtslose Optimierung und Auslösung kaskadierender Systemausfälle.

Um diese Risiken zu mindern, solltet ihr diese drei Grundsätze durchsetzen:

Skalierte Token, keine Berechtigungsnachweise

Jede Interaktion eines Agenten mit der Produktion muss über zweckgebundene APIs mit den minimal erforderlichen Berechtigungen erfolgen. Agenten sollten niemals über Admin-Schlüssel, Bereitstellungsanmeldeinformationen oder Token verfügen, die destruktive Operationen ausführen können.

Obligatorische menschliche Genehmigungen

Alles, was nicht einfach rückgängig gemacht werden kann, muss von Menschen genehmigt werden. Datenbankänderungen, Produktionsbereitstellungen und externe Kommunikation müssen von jemandem überprüft werden, der über den Geschäftskontext verfügt, der der KI fehlt.

Dokumentiert Beschränkungen im Code

KI optimiert für das ihr vorgegebene Ziel, basierend auf dem Kontext, den sie lesen kann. Wenn ein API-Vertrag, eine Abhängigkeit oder eine Geschäftsregel existiert, muss sie in der Codebasis vorhanden sein. Kommentare, Konfigurationsdateien und Architekturentscheidungsdatensätze sind für den Agenten sichtbar. PDFs, die in SharePoint vergraben sind, nicht.

4. Operative Leitplanken für KI-Workflows

Dynamische KI-Workflows eignen sich hervorragend für das Prototyping, führen aber in der Produktion zu Unvorhersehbarkeiten. Haltet diese vier operativen Regeln ein:

• Lasst KI nicht die langweiligen Teile überspringen: KI ist auf Fertigstellung optimiert und überspringt langsame Schritte wie Code-Scans oder Sicherheitsprüfungen. Integriert Qualitätssicherungen in die Pipeline, damit sie nicht verhandelbar sind.
• Gebt niemals Schreibberechtigungen für kritische Systeme: Wenn ein Agent eine gefährliche Aktion durchführen muss, muss er die Genehmigung durch ein menschliches Gate in der Schleife über skalierte APIs einholen.
• Kontext ist rar: KI weiß nicht, was sie nicht weiß. Jede undokumentierte Einschränkung ist eine tickende Zeitbombe.
• Standardisiert dynamische Workflows: Sobald eine KI einen erfolgreichen dynamischen Workflow entdeckt hat, friert ihn ein. Wandelt ihn in eine deterministische, wiederholbare Pipeline um, so wie ich es Teams mit unseren Standard-DevSecOps-Verfahren empfehle.

5. Sicherheit der Lieferkette: die Slopsquatting-Bedrohung

KI-Codierassistenten täuschen häufig Paketnamen vor. Angreifer haben dies erkannt und registrieren diese gefälschten Namen in öffentlichen Registern. Dies wird als "Slopsquatting" bezeichnet und ist sehr vorhersehbar, da KI-Modelle dazu neigen, immer wieder dieselben gefälschten Pakete zu halluzinieren.

Die Angriffskette sieht wie folgt aus:

1. Ein KI-Assistent schlägt in einem Codeschnipsel ein nicht existierendes Paket vor.
2. Ein Angreifer erkennt diese häufige Halluzination und registriert das bösartige Paket bei npm oder PyPI (wie bei den jüngsten Angriffen auf die Lieferkette, die im 2026 State of the Software Supply Chain Report von Sonatype dokumentiert sind).
3. Ein Entwickler folgt den Vorschlägen der KI und installiert das Paket.
4. Die CI/CD-Pipeline führt den bösartigen Code mit vollem Zugriff auf die Build-Umgebung aus.

Um dies abzuschwächen, solltet ihr eure Abhängigkeiten mithilfe von Hash-Verifizierung strikt sperren, alle von der KI vorgeschlagenen Pakete vor der Installation überprüfen und in Ihren CI/CD-Pipelines allowlists verwenden, um nur vorab genehmigte Bibliotheken zuzulassen.

6. Token und Zugriffsverwaltung

Unabhängig davon, ob es sich um GitHub-Integrationen oder MCP-Server handelt, erfordert der programmatische Zugriff eine strenge Governance. Jedes Unternehmen benötigt diese vier grundlegenden Dokumente, um endlose Feuergefechte zu vermeiden:

• PAT- und SSH-Zugriffsrichtlinien: Legt fest, welche Authentifizierungsmethode zu verwenden ist, sowie Einschränkungen des Anwendungsbereichs und Ablaufrichtlinien.
• Migrationspfad zu Apps: Skizziert, wie ihr von den alten Personal Access Tokens zu Apps mit granularem Geltungsbereich wechselt.
• Plan für die Reaktion auf einen Vorfall: Beschreibt die genauen Schritte zur Erkennung, Eskalation und Behebung bei kompromittierten Token oder Geheimnissen.
• API-Zugriffsentscheidungsbaum: Ordnet spezifische Anwendungsfälle den genehmigten Zugriffsmethoden und Sicherheitskompromissen zu.

7. Kontextmanagement auf Unternehmensebene

Kontextdateien (wie AGENTS.md) eignen sich hervorragend für kleine Teams mit einem einzigen Repository. Im Unternehmensmaßstab mit Hunderten von Repositories bricht dieser Ansatz jedoch zusammen.

Historisches Wissen ist in Wikis gespeichert, die Domänenlogik befindet sich in den Köpfen der Mitarbeiter, und architektonische Entscheidungen sind verstreut. Es ist nicht möglich, 200 dezentralisierte Markdown-Dateien zu pflegen, da sich die Muster mit der Zeit verändern. Während Kontextdateien für einzelne Repos unmittelbare Vorteile bieten, muss die Kontextebene auf Unternehmensebene zentralisiert und plattformübergreifend dynamisch abrufbar sein.

8. Datenresidenz vs. Souveränität

Wenn Unternehmensarchitekten nach "souveräner KI" für MCP-Implementierungen fragen, müsst ihr die Terminologie klären, bevor ihr eine Lösung entwerft.

• Datenresidenz: Eure Daten bleiben in einer bestimmten geografischen Region in der Infrastruktur eines Cloud-Anbieters. Dies erfüllt die GDPR und deckt 95 % der Unternehmensanforderungen ab.
• Datenhoheit: Ihr habt die Kontrolle über den gesamten Stack. Kein ausländisches Unternehmen kann den Zugriff vorschreiben.

Verwendet diesen Entscheidungsrahmen für MCP-Hosting:

Wenn ihr nicht auf ein bestimmtes Gesetz oder eine Vertragsklausel verweisen könnt, die Tier 3 vorschreibt, seid ihr wahrscheinlich zu weit gegangen.

Zusammenfassung: Die MCP-Sicherheitscheckliste

Ein MCP-Projekt in Produktion zu bringen bedeutet, die Sicherheitsüberprüfung zu überstehen. Verwendet diese Checkliste als Grundlage: