---
title: "Benutzerbezogene Zugriffskontrolle für MCP-Tools mit einem Enterprise-MCP-Gateway"
description: "MCP gibt Ihren KI-Agenten echte Macht — Dateien lesen, APIs aufrufen, Geld bewegen. Aber wer entscheidet, welcher Nutzer oder Agent welches Tool erreichen darf? So macht ein Enterprise-MCP-Gateway aus dieser Frage eine Richtlinie, die Sie wirklich durchsetzen können — vom Gateway bis auf jeden Laptop."
author: Aleksei Aleinikov
date: 2026-07-06
lang: de
tags: [mcp, ai-gateway, access-control, bifrost, platform-engineering, ai-security]
canonical: https://www.alekseialeinikov.com/de/blog/topics/security/benutzerbezogene-zugriffskontrolle-mcp-tools-gateway-2026
source: alekseialeinikov.com
---

# Benutzerbezogene Zugriffskontrolle für MCP-Tools mit einem Enterprise-MCP-Gateway

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](https://www.getbifrost.ai) als konkretes Beispiel — ein Open-Source-[KI-Gateway](https://www.getbifrost.ai), 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.

![Ein MCP-Gateway als einziger Engpass: KI-Clients authentifizieren sich mit einem Virtual Key, das Gateway wendet eine Allow-Liste von MCP-Tools pro Schlüssel an und setzt sie sowohl beim Inferenzieren als auch bei der Tool-Ausführung durch.](https://www.alekseialeinikov.com/blog/mcp-gateway-tool-filtering-2026.webp)

### 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:

```bash
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-client` mit den Tools `[create-invoice, check-status, issue-refund]`
- `support-client` mit den Tools `[create-ticket, get-faq]`

Der Virtual Key eines rein lesenden Support-Agenten lässt sich so einschränken:

```json
{
  "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:

1. **Beim Inferenzieren** — dem Modell werden nur die Tools angeboten, die der Schlüssel erlaubt. Es kann nicht wählen, was es nicht sieht.
2. **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](https://www.getbifrost.ai) 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:

```json
{
  "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](https://www.alekseialeinikov.com/de/blog/topics/security/service-account-schluessel-abschaffen-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.

![Eine Kontrollebene, überall durchgesetzt: Bifrost definiert Identität, Virtual Keys und MCP-Richtlinie zentral; ein Edge-Agent auf jeder Maschine synchronisiert diese Richtlinie und setzt Allow oder Deny für lokale MCP-Server direkt auf dem Gerät durch.](https://www.alekseialeinikov.com/blog/mcp-gateway-edge-enforcement-2026.webp)

### Die Richtlinie bis ans Endgerät ziehen

Genau dafür ist ein Endgeräte-Agent wie [Bifrost Edge](https://www.getbifrost.ai) 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:

1. **Least Privilege.** Standardmäßig verweigern; genau die Tools gewähren, die ein Aufrufer braucht, und nichts mehr.
2. **Ein Engpass.** Zugriff an einer einzigen Stelle entscheiden, die jede Anfrage passiert, nicht verstreut über Apps.
3. **Fähigkeit an Identität binden.** Rechte gehören einer Person oder einem Agenten mit Besitzer, nicht einem frei schwebenden Geheimnis.
4. **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](https://www.getbifrost.ai) ist das in diesem Artikel durchgehend verwendete KI-Gateway, die [Gateway-Doku](https://docs.getbifrost.ai/overview) behandelt Virtual Keys und MCP-Tool-Filterung, und die [Bifrost-Edge-Doku](https://docs.getbifrost.ai/edge/overview) behandelt Endgeräte-Erkennung und Durchsetzung auf dem Gerät.

Sie können Bifrost auf [GitHub](https://github.com/maximhq/bifrost) erkunden oder die [offizielle Website](https://www.getbifrost.ai/) besuchen, um mehr zu erfahren.