Was ist ein MCP Gateway, und wann braucht ein Team eines?

10. Juli 2026 · 6 Min. Lesezeit

Das Model Context Protocol (MCP) hat sich als gängiger Weg etabliert, KI-Assistenten mit anderen Systemen zu verbinden. Ein MCP-Client, etwa Claude Code, Cursor oder VS Code, spricht mit einem MCP-Server, und dieser Server stellt Werkzeuge bereit, zum Beispiel „Jira-Issues suchen“ oder „Kommentar zu einem Pull Request schreiben“. Das Modell entscheidet, welches Werkzeug es aufruft, und der Server führt den Aufruf im eigentlichen System aus.

Für eine einzelne Entwicklerin mit einem einzelnen Werkzeug funktioniert das gut. Schwieriger wird es, wenn ein Unternehmen viele Agenten und viele Werkzeuge hat und zusätzlich Anforderungen aus IT-Sicherheit oder Compliance erfüllen muss. Ein MCP Gateway setzt hier an, indem es einen einzigen Kontrollpunkt zwischen alle MCP-Clients und alle Werkzeuge stellt. Dieser Artikel erklärt, was ein Gateway tut, worin es sich von direkt angebundenen MCP-Servern unterscheidet und wann sich die zusätzliche Komponente lohnt.

Wie Agenten ohne Gateway angebunden sind

Im direkten Aufbau konfiguriert jede Person die benötigten MCP-Server in ihrem eigenen Client. Jeder Server meldet sich mit einem Zugangsschlüssel beim Zielsystem an, meist mit einem persönlichen API-Token oder einer OAuth-Freigabe der Person, die ihn eingerichtet hat. Manche Hersteller bieten inzwischen eigene Remote-MCP-Server an. Diese funktionieren nach demselben Prinzip: Der Agent handelt mit den Rechten der angemeldeten Person.

Daraus ergeben sich drei praktische Folgen. Erstens hat der Agent meist sämtliche Rechte eines Menschen, obwohl er nur einen kleinen Teil davon braucht. Ein Token, mit dem man Tickets lesen kann, erlaubt oft auch das Löschen. Zweitens gibt es keinen zentralen Ort, an dem man sieht, welcher Agent welches System erreicht; die Konfiguration steckt in einzelnen Clients und persönlichen Tokens. Drittens hängt die Protokollierung vom jeweiligen Zielsystem ab. Manche Systeme zeichnen API-Aufrufe detailliert auf, andere kaum, und keines hält fest, was der Agent versucht hat, aber nicht durfte.

Was ein MCP Gateway tut

Ein Gateway ist ein Proxy, der gegenüber den Clients MCP spricht und in ihrem Auftrag mit den Zielsystemen kommuniziert. Der Agent hält keine Zugangsdaten mehr für Jira oder GitHub, sondern einen einzigen Schlüssel für das Gateway. Die Zugangsdaten für die Zielsysteme liegen verschlüsselt im Gateway und werden nie an den Client zurückgegeben.

Bei jedem Aufruf durchläuft ein Gateway typischerweise dieselben Schritte:

Authentifizierung. Wer ruft an? Die Anfrage trägt einen API-Schlüssel, der eine Person oder einen Agenten identifiziert.
Autorisierung. Darf dieser Aufrufer diese Operation auf dieser Ressource mit diesen Parameterwerten ausführen? Zum Beispiel: Issues lesen, aber nur im Projekt MOB, und niemals löschen.
Datenregeln. Enthalten Anfrage oder Antwort Werte, die nicht weitergegeben werden dürfen, etwa E-Mail-Adressen oder Kontonummern? Diese lassen sich maskieren oder entfernen.
Rate Limiting. Bleibt der Aufrufer innerhalb seiner Grenzen? Eine fehlerhafte Agenten-Schleife sollte gebremst werden, bevor sie Hunderte Tickets anlegt.
Audit. Der Aufruf wird mit seinem Ergebnis protokolliert, egal ob er erlaubt, abgelehnt, zur Freigabe angehalten oder wegen des Limits gebremst wurde.

Ein Aufruf durch das Gateway: Die fünf Prüfungen laufen der Reihe nach, bevor die Anfrage Jira, GitHub oder Confluence erreicht.

Ein nützlicher Nebeneffekt: Der Agent sieht nur die Werkzeuge, die er auch aufrufen darf. Die Liste der verfügbaren Werkzeuge wird gefiltert, bevor sie beim Modell ankommt. Das verringert auch die Wahrscheinlichkeit, dass das Modell eine Operation versucht, die es nichts angeht.

Gateway oder direkte MCP-Server?

Der Unterschied liegt weniger im Funktionsumfang als darin, wo Entscheidungen getroffen werden. Bei direkten Servern ist die Zugriffskontrolle eine Eigenschaft jedes einzelnen Tokens und jedes Zielsystems. Bei einem Gateway ist sie eine Richtlinie an einer Stelle, die bei jedem Aufruf ausgewertet wird.

Links: Jeder Client hält für jedes Tool ein eigenes Token. Rechts: Jeder Agent hat einen Gateway-Key, und eine Richtlinie entscheidet, was bei welchem Tool ankommt.

Frage	Direkte MCP-Server	MCP Gateway
Welche Rechte hat der Agent?	Die der Token-Inhaberin	Die pro Operation freigegebenen
Wo wird der Zugriff konfiguriert?	In jedem Client und jedem Tool	In einer Richtlinie
Werden abgelehnte Versuche protokolliert?	Meist nicht	Ja, mit Begründung
Lässt sich ein Schlüssel für alle Tools sperren?	Nein, ein Token pro Tool	Ja
Wer hält die Zugangsdaten der Tools?	Der Rechner des Clients	Das Gateway

Ein Gateway ersetzt das Berechtigungsmodell des Zielsystems nicht. Jira setzt seine eigenen Rechte für das Konto, mit dem das Gateway arbeitet, weiterhin durch. Das Gateway ergänzt darüber eine engere Schicht, die auf den Agenten und seine Aufgabe zugeschnitten ist.

Wann ein Team ein Gateway braucht

Nicht jedes Team braucht eines. Wer als einzelner Entwickler einen Agenten an einem Testprojekt ausprobiert, kommt ohne Gateway aus; es würde vor allem Einrichtungsaufwand bedeuten.

Anders sieht es aus, wenn mehrere der folgenden Punkte zutreffen:

Mehr als eine Handvoll Personen oder Agenten nutzen KI-Clients auf gemeinsamen Systemen.
Agenten dürfen schreiben und nicht nur lesen: Tickets, Pull Requests, Seiten, Nachrichten.
Die Systeme enthalten personenbezogene Daten oder Kundendaten.
IT-Sicherheit oder Compliance wollen wissen, wer worauf zugreifen kann, und verlangen Nachweise.
Das Unternehmen nutzt mehr als einen KI-Client oder Anbieter und möchte die Governance nicht für jeden neu aufbauen.

In diesen Fällen ist der Aufwand für eine zentrale Komponente in der Regel geringer als der Aufwand, Zugriffe zu prüfen, die über viele Werkzeuge und persönliche Tokens verteilt sind. Zwei konkrete Beispiele für solche Schreibzugriffe sind ein Agent, der Sprints in Jira vorbereitet, und ein Agent, der Pull Requests auf GitHub oder in Azure DevOps prüft.

Worauf man bei einem MCP Gateway achten sollte

Gateways unterscheiden sich deutlich. Folgende Kriterien helfen beim Vergleich:

Granularität. Lässt sich der Zugriff pro Operation und pro Parameterwert einschränken, etwa pro Repository oder Jira-Projekt, oder nur pro Werkzeug?
Filterung der Antworten. Können Felder oder sensible Werte aus der Antwort entfernt werden, bevor das Modell sie sieht?
Qualität des Audit-Logs. Sind nachträgliche Änderungen erkennbar? Sind abgelehnte Aufrufe enthalten? Lässt sich das Log an bestehende Sicherheitswerkzeuge übergeben?
Betrieb. Läuft das Gateway auf der eigenen Infrastruktur, oder geht jeder Aufruf durch die Cloud eines Dritten?
Schnittstellen. Nur MCP, oder können auch Skripte und CI-Jobs dieselben kontrollierten Operationen über REST nutzen?
Abdeckung. Welche Werkzeuge und welche Operationen werden heute unterstützt?

Wie Vordix das umsetzt

Vordix ist ein selbst gehostetes MCP Gateway. Es läuft als Docker-Compose-Deployment auf der Infrastruktur des Kunden, und im Aufrufpfad liegt kein Dienst, den Vordix betreibt.

Der Zugriff wird auf drei Ebenen konfiguriert. Die Organisation legt eine Obergrenze fest, was überhaupt erlaubt werden kann. Ein Projekt wählt innerhalb dieser Obergrenze aus. Ein Workspace ist schließlich der eigentliche Gateway-Endpunkt mit eigener URL, eigenem Rate Limit und eigenem Notschalter, und mit ihm verbindet sich der Agent. Regeln für einen einzelnen Agenten werden umgesetzt, indem dieser Agent einen eigenen Workspace bekommt. Innerhalb dieser Ebenen lässt sich der Zugriff nach Integration, Operation, Parameterwert und Antwortfeld einschränken. Jede Operation ist sowohl über MCP als auch über REST verfügbar.

Jeder Aufruf landet in einem nur erweiterbaren, per Hash-Kette gesicherten Audit-Log, auch abgelehnte Aufrufe samt Begründung. Menschen melden sich per SSO an, zum Beispiel über Entra ID oder Okta. API-Schlüssel werden genau einmal angezeigt und nur als Hash gespeichert. Die unterstützten Werkzeuge decken Planung, Dokumentation, Code, Daten und Kommunikation ab; der Überblick über KI-Agenten in der Softwareentwicklung geht sie Phase für Phase durch.

Trade-offs und Einschränkungen

Ein Gateway fügt jedem Aufruf einen zusätzlichen Netzwerkschritt hinzu, und es ist eine weitere Komponente, die betrieben und verfügbar gehalten werden muss. Fällt das Gateway aus, erreichen die Agenten die Werkzeuge nicht. Außerdem braucht es jemanden, der die Richtlinien verantwortet. Die wichtigste Einschränkung in der Praxis ist die Abdeckung: Ein Gateway kann nur die Operationen kontrollieren, die es implementiert. Ein Team sollte daher prüfen, ob die benötigten Operationen unterstützt werden, bevor es Agenten hinter das Gateway verlegt.

Fazit

Ein MCP Gateway macht aus dem Agentenzugriff, der sonst in vielen persönlichen Tokens steckt, eine einzige überprüfbare Richtlinie, die bei jedem Aufruf ausgewertet und in einem Log festgehalten wird. Für eine einzelne Person ist das oft mehr als nötig. Für ein Team mit mehreren Agenten, Schreibrechten und sensiblen Daten ist es ein praktikabler Weg, Agenten arbeiten zu lassen, ohne den Überblick darüber zu verlieren, was sie dürfen. Wie ein solches Protokoll aussehen sollte, beschreibt der Artikel Audit-Log für KI-Agenten und der EU AI Act.

Wenn Sie ein Gateway für Ihre eigenen Werkzeuge konfiguriert sehen möchten, können Sie eine Vordix-Demo anfragen.