Das Model Context Protocol hat ein echtes Problem gelöst: Es gab KI-Modellen einen sauberen, standardisierten Weg nach außen. Statt jedes Modell von Hand an jede API zu kleben, richten Sie einen Client auf einen MCP-Server — und das Modell kann plötzlich Dateien auflisten, eine Datenbank abfragen, einen Pull Request öffnen oder eine Rückerstattung auslösen.
Genau das ist auch das Problem.
Ein MCP-Tool ist kein reiner Lese-Kontext. Es ist eine Fähigkeit — ein Knopf, den das Modell stellvertretend drückt. Sobald Sie einen Payments-Server anbinden, sind „Rechnung erstellen" und „Rückerstattung auslösen" nur einen Tool-Aufruf entfernt. Und in den meisten Organisationen lautet die ehrliche Antwort auf „welcher Nutzer oder Agent kann welches dieser Tools erreichen?": niemand weiß es, und nichts hält sie auf.
In diesem Artikel geht es darum, aus dieser Frage eine durchsetzbare Antwort zu machen. Kurzfassung: Sie tun es an einem Gateway — und für die Tools, die nie durch eines laufen, am Endgerät.
Warum das ein Rechte-Problem ist, kein Prompt-Problem
Die verlockende Lösung ist, den Tool-Zugriff im Prompt zu regeln: dem Agenten sagen „nutze nur die Lese-Tools". Das ist keine Kontrolle. Es ist ein Vorschlag an ein probabilistisches System und bricht beim ersten Jailbreak, beim Confused-Deputy-Angriff oder schlicht bei einem Fehler zusammen.
Tool-Zugriff ist ein Autorisierungs-Problem und hat dieselbe Form wie jedes andere Autorisierungsproblem, das Sie längst lösen:
- Ein Subjekt — ein Nutzer, ein Team oder ein autonomer Agent.
- Eine Ressource — ein bestimmtes MCP-Tool (
create-invoice, nicht nur „der Billing-Server"). - Eine Entscheidung — erlauben oder verweigern, getroffen von etwas, an dem das Subjekt nicht vorbeireden kann.
Der Fehler ist, diese Entscheidung in jede KI-App zu drücken. Jede App hat eigene Konfiguration, Nutzer können sie bearbeiten, und jeden Monat kommt eine neue dazu — Claude Desktop, Cursor, Codex, ein interner Agent, den jemand am Freitag geschrieben hat. Jeder von ihnen zu vertrauen, sich selbst zu kontrollieren, ist das „jeder Dienst macht seine eigene Auth"-Anti-Pattern, neu geboren für KI.
Die Lösung ist dieselbe, zu der Plattform-Teams schon immer gegriffen haben: die Entscheidung an einen Engpass verlagern, den jede Anfrage passieren muss.
Das Gateway: ein Engpass für jeden Tool-Aufruf
Ein MCP-Gateway sitzt zwischen Ihren KI-Clients und Ihren MCP-Servern. Jeder Client — Desktop-App, IDE, eigener Agent — verbindet sich mit dem Gateway statt direkt mit den Tools. Das Gateway ist gleichzeitig MCP-Client (zu den echten Tool-Servern) und MCP-Server (zu Ihren Apps) und sieht damit jeden Tool-Aufruf im Flug — und entscheidet über ihn.
Diese eine Position liefert, was App-Konfiguration nie kann: einen Ort, an dem die Antwort auf „darf dieser Aufrufer dieses Tool nutzen?" auf immer gleiche Weise fällt, jedes Mal.
Ich nehme Bifrost als konkretes Beispiel — ein Open-Source-KI-Gateway, das über 20 Modellanbieter bündelt und ein MCP-Gateway mit Tool-Filterung pro Anfrage mitbringt — aber das Muster gilt für jedes Gateway auf denselben Prinzipien.
Virtual Keys: Rechte an einen Aufrufer heften
Die Kontrolleinheit ist ein Virtual Key. Statt rohe Anbieter-Schlüssel zu verteilen, geben Sie jedem Nutzer, Team oder Agenten einen Virtual Key (sk-bf-…), den er bei jeder Anfrage mitschickt:
curl -X POST http://localhost:8080/v1/chat/completions \
-H "x-bf-vk: sk-bf-your-virtual-key" \
-H "Content-Type: application/json" \
-d '{ "model": "gpt-4o-mini", "messages": [{"role":"user","content":"Hallo"}] }'
Am Virtual Key hängt die Governance: welche Modelle und Anbieter er nutzen darf, sein Budget, seine Rate-Limits — und der Teil, um den es hier geht: welche MCP-Tools er berühren darf.
Verweigern als Standard
Das ist die Design-Entscheidung, die daraus eine echte Kontrolle macht: Ein Virtual Key ohne MCP-Konfiguration erhält kein Tool. Zugriff ist nichts, was man wegnimmt, sondern etwas, das man ausdrücklich gewährt.
Für jeden MCP-Client an einem Schlüssel wählen Sie genau, was er erreichen darf:
- Bestimmte Tools — nur die genannten Tools sind verfügbar.
-
*-Wildcard — alle aktuellen und künftigen Tools dieses Clients. - Leere Liste — alles von diesem Client ist blockiert.
- Gar nicht konfiguriert — dieser Client ist für den Schlüssel unsichtbar.
Ein durchgespieltes Beispiel. Angenommen, zwei MCP-Clients sind am Gateway angeschlossen:
-
billing-clientmit den Tools[create-invoice, check-status, issue-refund] -
support-clientmit den Tools[create-ticket, get-faq]
Der Virtual Key eines rein lesenden Support-Agenten lässt sich so einschränken:
{
"mcp_clients": {
"billing-client": ["check-status"],
"support-client": ["*"]
}
}
Dieser Schlüssel kann den Status einer Rechnung prüfen und jedes Support-Tool nutzen — aber create-invoice und issue-refund existieren für ihn schlicht nicht. Ein anderer Schlüssel, für das Finance-Team, gewährt billing-client: ["*"]. Gleiches Gateway, gleiche Tools, unterschiedliche Reichweite pro Aufrufer.
Zweimal durchgesetzt, damit das Modell nicht mogeln kann
Hier kommt der feine Punkt, der eine Kontrolle von einem Filter unterscheidet. Man könnte die gesperrten Tools nur dann ausblenden, wenn man dem Modell das Toolset präsentiert. Aber ein Modell, das einen Tool-Namen halluziniert — oder eine eingeschleuste Anweisung, die einen direkt nennt — würde durchrutschen.
Deshalb wird die Allow-Liste an zwei Stellen angewendet:
- Beim Inferenzieren — dem Modell werden nur die Tools angeboten, die der Schlüssel erlaubt. Es kann nicht wählen, was es nicht sieht.
- Bei der Tool-Ausführung — selbst wenn ein Aufruf für ein gesperrtes Tool doch eintrifft, weist das Gateway ihn ab, bevor er den Server erreicht.
Das Gateway übersetzt die Konfiguration des Schlüssels dazu in eine strikte x-bf-mcp-include-tools-Allow-Liste auf der Anfrage und prüft sie bei der Ausführung erneut. Ein Tool, das nicht auf der Liste steht, ist nicht nur versteckt — es ist unerreichbar.
Rechte an echte Menschen binden, nicht an anonyme Schlüssel
Ein Virtual Key ist nur so gut wie Ihr Wissen darüber, wer ihn hält. Schränken Sie einen Schlüssel perfekt ein und mailen ihn dann herum, sind Sie wieder bei geteilten Geheimnissen.
Deshalb muss benutzerbezogene MCP-Kontrolle an Ihren Identity-Provider anschließen. In der Enterprise-Stufe von Bifrost ist das OIDC + SCIM: Nutzer melden sich mit ihrem Firmenkonto an, und ihre Bifrost-Rolle, ihr Team und ihre Business-Unit werden automatisch aus dem IdP bereitgestellt — Okta, Entra ID, Keycloak, Google Workspace und andere.
Die Zuordnung ist attributgesteuert, sodass aus einem Claim des IdP eine Bifrost-Rolle wird:
{
"attribute": "department",
"value": "Finance",
"role": "developer",
"team": "Finance"
}
Jetzt ist die Kette vollständig und wartet sich selbst:
Firmenidentität → Team → Virtual Key → MCP-Tool-Allow-Liste.
Kommt jemand ins Finance-Team, erbt er dessen Tool-Zugriff. Verlässt er das Unternehmen, deprovisioniert SCIM ihn und der Zugriff verdampft — kein verwaister Schlüssel, der noch Rückerstattungen auslösen kann. Rechte folgen der Person, und das ist die einzige Version von „benutzerbezogener Kontrolle", die den Kontakt mit einer echten Organisation übersteht.
Das ist dasselbe Prinzip, das langlebige Cloud-Zugangsdaten abgeschafft hat. Wenn Sie noch statische Service-Account-Schlüssel verteilen, gilt der identitätsgebundene Ansatz auch dort — siehe Schluss mit Service-Account-Schlüsseln: Workload Identity Federation 2026.
Der blinde Fleck: Tools, die das Gateway nie berühren
Ein Gateway steuert alles, was durch es fließt. Die unbequeme Wahrheit ist, dass ein wachsender Anteil der MCP-Nutzung das nicht tut.
Ein Entwickler fügt einen Filesystem-MCP-Server zu Claude Desktop hinzu. Ein anderer verdrahtet einen Datenbank-Server direkt in Cursor. Ein dritter installiert etwas von GitHub in Codex. Nichts davon zeigt auf Ihr Gateway. Jedes ist ein lokaler Prozess auf einem Laptop mit echten Fähigkeiten — Dateien lesen, interne APIs treffen, Aktionen ausführen — und für Ihre zentrale Richtlinie völlig unsichtbar. Das ist Shadow MCP, und genau hier endet die Reichweite des Gateway-Modells.
Von der Server-Seite lässt sich das nicht lösen, denn diese Tools waren nie dafür konfiguriert, über einen Server zu laufen. Sie müssen es auf dem Gerät lösen.
Die Richtlinie bis ans Endgerät ziehen
Genau dafür ist ein Endgeräte-Agent wie Bifrost Edge da. Er läuft auf jeder Maschine — macOS, Windows, Linux — und tut zwei Dinge, die ein Gateway allein nicht kann:
- Erkennung. Er liest die MCP-Konfiguration in jeder KI-App auf dem Gerät und meldet sie zurück, wodurch ein flottenweites Inventar entsteht. Zum ersten Mal können Sie „welche MCP-Server laufen tatsächlich in unserer Organisation?" mit Daten beantworten statt mit einer Vermutung.
- Durchsetzung auf dem Gerät. Einen Server zu erlauben oder zu verweigern ist nicht bloß beratend. Verweigern Sie einen, setzt Edge das auf der Maschine durch, sodass das Tool nicht genutzt werden kann — selbst von einer App, die es vor der Richtlinie schon konfiguriert hatte.
Das Governance-Modell ändert sich nicht — es erweitert sich. Dieselben Identitäten, dieselben Virtual Keys, dieselben zentral definierten Allow/Deny-Entscheidungen werden nun auf Verkehr durchgesetzt, der das Gateway nie erreicht hätte: Desktop-Chat-Apps, Browser-KI, Coding-Agenten im Terminal und die lokalen MCP-Server, mit denen sie sich verbinden. Ein neuer Server auf einem Laptop kann eine Freigabeanfrage in der Admin-Konsole auslösen, statt still Zugriff zu erhalten.
Gateway und Endgerät sind die zwei Hälften einer Kontrolle: Das Gateway ist die Policy-Ebene für alles, was durch es läuft; der Endgeräte-Agent ist die letzte Meile für alles, was das nicht tut.
Alles zusammengesetzt
Hier die ganze Entwicklung, von keiner Kontrolle bis zu echtem Least Privilege für Agenten:
| Keine Kontrolle | Nur Gateway | Gateway + Endgerät | |
|---|---|---|---|
| Wer entscheidet über Tool-Zugriff | Jede App, jeder Nutzer | Zentrale Allow-Liste pro Virtual Key | Zentrale Allow-Liste, überall durchgesetzt |
| Standardhaltung | Alles erlaubt | Standardmäßig verweigern | Standardmäßig verweigern |
| An Identität gebunden | Nein | Über OIDC/SCIM → Schlüssel | Über OIDC/SCIM → Schlüssel |
| Durchsetzungspunkt | Keiner | Am Gateway (Inferenz + Ausführung) | Gateway und auf dem Gerät |
| Lokale IDE-MCP-Server | Unsichtbar | Unsichtbar | Inventarisiert + Allow/Deny |
| Offboarding von Abgängen | Manuell, leicht übersehen | Schlüssel deprovisioniert | Schlüssel deprovisioniert + Gerät durchgesetzt |
Die Prinzipien darunter sind nicht neu — es sind dieselben, die Plattform- und Security-Engineers auf jedes fähige System davor angewendet haben:
- Least Privilege. Standardmäßig verweigern; genau die Tools gewähren, die ein Aufrufer braucht, und nichts mehr.
- Ein Engpass. Zugriff an einer einzigen Stelle entscheiden, die jede Anfrage passiert, nicht verstreut über Apps.
- Fähigkeit an Identität binden. Rechte gehören einer Person oder einem Agenten mit Besitzer, nicht einem frei schwebenden Geheimnis.
- Dort durchsetzen, wo die Aktion passiert. Am Gateway für geroutet Verkehr; auf dem Gerät für alles andere.
MCP hat KI-Agenten wirklich handlungsfähig gemacht. Genau deshalb hört „welcher Nutzer oder Agent kann welches Tool erreichen" auf, ein Nice-to-have zu sein, und wird zur selben Art Frage, die Sie längst zu Datenbank-Rollen und Cloud-IAM stellen. Ein Enterprise-MCP-Gateway — standardmäßig verweigernd, über Virtual Keys eingeschränkt, an Identitäten gebunden und bis ans Endgerät erweitert — ist der Weg zu einer Antwort, die Sie wirklich durchsetzen können.
Wenn Sie die Mechanik im Detail sehen wollen: Bifrost ist das in diesem Artikel durchgehend verwendete KI-Gateway, die Gateway-Doku behandelt Virtual Keys und MCP-Tool-Filterung, und die Bifrost-Edge-Doku behandelt Endgeräte-Erkennung und Durchsetzung auf dem Gerät.
Ursprünglich auf meinem Blog veröffentlicht, wo ich ihn aktuell halte: Immer aktuelle Version lesen →
Ich schreibe über Platform Engineering, Google Cloud und Cloud-Security — auf Deutsch und Englisch. Mehr davon gibt es hier.
Top comments (0)