MCP Proxy vs. Gateway: Wann ein Gateway unverzichtbar wird

MCP-Tools gewinnen in der KI-Entwicklung an Bedeutung, doch viele Entwickler verwechseln die Rollen von MCP-Proxys und MCP-Gateways. Beide leiten Anfragen zwischen KI-Agenten und MCP-Servern weiter – doch ihre Funktionen könnten unterschiedlicher nicht sein.

Während ein Proxy lediglich die technische Verbindung herstellt, übernimmt ein Gateway die Kontrolle über Sicherheit, Zugriffsrechte und Compliance. Dieser Unterschied wird erst sichtbar, sobald Teams oder mehrere Server im Spiel sind. Doch genau dann wird er entscheidend.

Die technische Grundfunktion eines MCP-Proxys

Ein MCP-Proxy agiert als reiner Transportmechanismus. Seine einzige Aufgabe besteht darin, Datenströme weiterzuleiten – etwa wenn ein lokaler KI-Client wie Claude Code oder Cursor über Stdio (Standard Input/Output) mit einem entfernten MCP-Server kommunizieren muss.

Typische Szenarien, in denen ein Proxy sinnvoll ist:

• Ein MCP-Server läuft in einem Docker-Container oder auf einem Remote-Server.
• Der KI-Client unterstützt keine direkte Kommunikation mit dem Server.
• Die Netzwerkverbindung erfordert eine Umleitung (z. B. über HTTP, SSE oder WebSockets).

Was ein Proxy NICHT leistet:

• Er prüft keine Berechtigungen oder Identitäten.
• Er speichert keine Audit-Protokolle mit Nutzerzuordnung.
• Er setzt keine Richtlinien für einzelne Tools oder Teams durch.
• Er verwaltet keine Zugangstokens zentral.

Für einzelne Entwickler in einer Testumgebung ist ein Proxy oft ausreichend. Doch sobald mehrere Teams, Server oder Agenten im Spiel sind, stößt diese Lösung an ihre Grenzen.

Warum ein reiner Proxy in der Praxis scheitert

Ein reales Beispiel zeigt, warum viele Teams früher oder später ein Gateway benötigen. Ein Entwicklungsteam betrieb sechs interne MCP-Server für Tools wie GitHub, Jira, Confluence, Sentry, Datadog und eine interne Daten-API. Jede:r Entwickler:in verwaltete selbstständig die Zugangsdaten – mit fatalen Folgen.

1. Credential-Sprawl und Sicherheitslücken

Jede:r Entwickler:in besaß eigene API-Schlüssel für die verschiedenen Dienste. Bei einem Wechsel des Teams oder einem Ausscheiden aus dem Unternehmen mussten Zugangsdaten manuell gesucht und deaktiviert werden. In einem Fall wurde ein ehemaliger Auftragnehmer mit einem aktiven Jira-Zugang übersehen – erst eine Sicherheitsprüfung deckte das Problem auf.

2. Prompt-Injection als reales Risiko

Ein KI-Agent nutzte den Confluence-MCP-Server, um Dokumentationen in den Kontext einzubinden. Ein:e Lieferant:in hatte in einem Support-Ticket eine versteckte Anweisung in der Formatierung hinterlassen. Der KI-Agent verarbeitete diesen Text und begann, Schritte aus der injizierten Anweisung auszuführen – glücklicherweise ohne katastrophale Folgen. Doch das Beispiel zeigte eindrücklich, wie gefährlich fehlende Schutzmechanismen sein können.

3. Fehlende Transparenz und Compliance

Als die Sicherheitsabteilung nach 30 Tagen wissen wollte, welche Agenten auf die interne Daten-API zugegriffen hatten, war die Antwort ernüchternd: „Wir wissen es nicht.“ Die Serverprotokolle des APIs zeigten zwar Zugriffe, aber ohne Zuordnung zu Nutzer:innen oder Agenten. Eine nachträgliche Rekonstruktion war unmöglich.

Diese Vorfälle machten eines klar: Das Problem lag nicht in der technischen Weiterleitung, sondern in der fehlenden Governance.

MCP-Gateway: Die Lösung für nachhaltige KI-Sicherheit

Ein MCP-Gateway geht über die reine Transportfunktion hinaus. Es fungiert als zentrale Kontrollinstanz für alle MCP-Anfragen und setzt organisatorische Richtlinien durch. Die entscheidenden Unterschiede:

1. Identitätsmanagement und Authentifizierung Ein Gateway integriert sich in bestehende Unternehmens-Identitätsprovider (z. B. Okta, Azure AD, SAML). Nutzer:innen authentifizieren sich zentral, und ihre Berechtigungen werden automatisch synchronisiert. Bei einem Austritt aus dem Unternehmen werden alle Zugriffe sofort gesperrt – ohne manuelle Pflege.

2. Feingranulare Zugriffskontrolle (RBAC) Nicht nur ganze Teams erhalten Zugriff, sondern einzelne Funktionen der MCP-Server. Beispiel:

• Ein Team darf Repositories suchen und Dateien lesen, aber keine Commits pushen oder Branches löschen.
• Ein anderes Team erhält nur Lesezugriff auf Dokumentationen in Confluence, nicht aber auf sensible Projektmanagement-Daten.

3. Detaillierte Audit-Protokolle Jede Tool-Aufruf wird lückenlos dokumentiert – inklusive:

• Nutzeridentität
• Verwendetes Tool
• Parameter der Anfrage
• Antwort des Servers
• Zeitstempel und Latenz

Diese Protokolle lassen sich an SIEM-Systeme (Security Information and Event Management) weiterleiten und sind für Compliance-Prüfungen unverzichtbar.

4. Schutz vor Prompt-Injection und Datenlecks Ein Gateway kann vor und nach der Tool-Ausführung prüfen:

• Vorher: Sind die Eingabeparameter sicher? Enthalten sie versteckte Anweisungen?
• Nachher: Enthält die Antwort sensible Daten wie Passwörter oder personenbezogene Informationen?

So wird verhindert, dass KI-Agenten ungewollt schädliche oder vertrauliche Inhalte verarbeiten.

Wann brauchen Sie ein Gateway?

Die Entscheidung zwischen Proxy und Gateway hängt von Ihrer Skalierung und Sicherheitsanforderungen ab. Ein Gateway wird unverzichtbar, wenn:

• Mehrere Teams auf MCP-Server zugreifen.
• Sensible Daten (z. B. Quellcode, Kundendaten) verarbeitet werden.
• Compliance-Vorgaben (DSGVO, SOC 2, ISO 27001) eingehalten werden müssen.
• Sicherheitsvorfälle (wie Prompt-Injection) vermieden werden sollen.

Für Einzelentwickler:innen oder Testumgebungen reicht ein Proxy oft aus. Doch sobald Ihr MCP-Einsatz produktionsreif wird, sollten Sie über ein Gateway nachdenken.

Fazit: Technik folgt der Governance

MCP-Proxys und -Gateways mögen auf den ersten Blick ähnlich wirken – doch ihre Funktionen könnten unterschiedlicher nicht sein. Ein Proxy löst ein technisches Problem: Wie kommen Daten von A nach B? Ein Gateway löst ein organisatorisches Problem: Wie stellen wir sicher, dass diese Daten nur von berechtigten Personen, mit den richtigen Rechten und nachvollziehbar genutzt werden?

Die meisten Teams starten mit einem Proxy und erkennen zu spät, dass sie eigentlich ein Gateway benötigen. Wer frühzeitig auf Governance setzt, spart sich teure Nachbesserungen – und schläft ruhiger.

Die Frage ist nicht, ob Sie ein Gateway brauchen, sondern wann.