NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grünes Schild MCP RBAC vor drei Türen, zwei verschlossen, eine offen

MCP RBAC: Rule Based Access Control für KI Agenten 2026

MCP RBAC ist Rule Based Access Control für das Model Context Protocol. Die Regel legt fest, welcher Agent welches Tool auf welchem MCP Server aufrufen darf, und zwar einzeln statt pauschal.
Der Unterschied zur klassischen Anmeldung ist entscheidend. OAuth 2.1 beantwortet die Frage, ob ein Client den Server überhaupt erreichen darf. Es beantwortet nicht, ob dieser eine Aufruf jetzt erlaubt ist. Genau dort setzt RBAC an.
Ein Beispiel aus dem Alltag: Ein Agent hängt am Git Server, an der Datenbank und am Ticketsystem. Ohne Regeln sieht er alle Tools. Mit RBAC sieht er nur die, die zu seiner Rolle gehören – und ein Aufruf ausserhalb wird abgelehnt, nicht nur unschön protokolliert.
Durchgesetzt wird an zwei Punkten. Erstens bei der Tool Discovery, damit das Modell verbotene Tools gar nicht erst im Kontext sieht. Zweitens bei der Ausführung, falls das Modell es trotzdem versucht. Beide Punkte gehören zusammen.

Inhalt

MCP RBAC mit NCA: Schnelle Hilfe vom Experten

Wir bauen MCP Server selbst. Unsere Sulu CMS Installation hängt an einem eigenen MCP Server, unser n8n ebenso. Wir wissen deshalb aus der Praxis, wie schnell ein Agent zu viele Rechte bekommt und wie unangenehm das wird, sobald der erste Schreibzugriff auf Produktivdaten läuft. Unser Leitmotiv bleibt: Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk. Grosse Modelle rechnen extern, die Daten bleiben lokal.
Passende Leistungen: die NCA MCP Middleware für Unternehmensdaten bringt eure Systeme kontrolliert an KI Agenten. Die NCA Agentic AI Coding Guardrails setzen Regeln und Deny Rules im Projekt auf. Beim Vibe Coding Security Audit prüfen wir bestehende Agenten Setups. Für Betrieb im eigenen Netz hilft Self Hosted KI mit Multi Tenant, für die rechtliche Seite die DSGVO Beratung zum Vibe Coding. In PHP Projekten greifen die NCA PHP AI Coding Guidelines.

MCP Berechtigungen sauber aufsetzen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum OAuth Scopes allein nicht reichen

Seit dem Spec Update im Juni 2025 gilt: ein MCP Server ist ein OAuth Resource Server, kein Authorization Server. Er prüft Tokens, er stellt keine aus. Das war ein wichtiger Schritt, löst aber nur die halbe Aufgabe.
Denn Scopes sind grob. Sie sagen: dieser Client darf auf diesen Server. Konventionen für einzelne Tools sind in der Spezifikation nicht standardisiert. Das Protokoll authentifiziert die Verbindung, nicht den einzelnen Tool Call. Praktisch heisst das: ein externer Dienstleister und ein Senior Entwickler mit jeweils gültigem Token sehen dieselbe Tool Liste.
Dazu kommen drei Muster, die in fast jedem gewachsenen Setup auftauchen:
  • Statische Rechte gegen dynamische Aufrufe. Der Scope wird beim Login vergeben, der Agent entscheidet erst zur Laufzeit, was er anfasst.
  • Credentials auf Endgeräten. Ein Token im Editor, eins beim Produktivagenten, eins in der Desktop App. Beim Offboarding muss jede Datei gefunden werden.
  • Kein brauchbarer Audit Trail. Tool Calls verteilen sich über Clients. Kein Log beantwortet, wer wann welches Tool gegen welches System aufgerufen hat.
RBAC füllt die Lücke mit expliziten Entscheidungen pro Tool. Jeder Schlüssel steht für einen konkreten Konsumenten – einen Agenten, ein Team, eine Kundenintegration – statt für eine globale Service Identität. Wer tiefer ins Protokoll will, findet die Grundlagen unter Web MCP und Remote MCP Server und die Entwicklung unter MCP Roadmap 2026.

Enterprise Managed Authorization: der neue Baseline

Am 18. Juni 2026 wurde die Enterprise Managed Authorization Extension, kurz EMA, stabil. Damit können Organisationen den Zugriff auf MCP Server zentral über ihren Identity Provider vergeben. Der Nutzer meldet sich einmal an, die freigegebenen Server sind verbunden. Kein OAuth pro App, keine Klickstrecke pro Server.
Technisch läuft das über den Identity Assertion JWT Authorization Grant, kurz ID-JAG. Beim Single Sign On holt der Client vom Identity Provider einen Grant und tauscht ihn beim Authorization Server des MCP Servers gegen ein Access Token. Der Nutzer sieht dabei keinen Consent Screen pro Server.
Drei Eigenschaften fallen dabei ab: einmal autorisieren und überall erben, zentrale Policy samt Audit im Admin Console des Identity Providers, und eine klare Trennung von privaten und geschäftlichen Konten. Okta ist der erste unterstützte Identity Provider. Anthropic hat die Extension in seiner MCP Schicht umgesetzt, Visual Studio Code unterstützt sie ebenfalls. Auf Serverseite sind unter anderem Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase dabei.
Wichtig für die Einordnung: EMA regelt, wer sich überhaupt verbinden darf. Welches Tool dieser Nutzer dann aufrufen darf, bleibt Sache der Rollen und Regeln auf dem Server oder im Gateway. EMA und RBAC ersetzen sich nicht, sie greifen ineinander.

Die vier Stufen der MCP Zugriffskontrolle

In der Beratung sehen wir immer wieder dieselbe Reihenfolge. Teams starten offen, merken beim ersten Vorfall, dass etwas fehlt, und ziehen die Regeln nach. Wer die Stufen kennt, überspringt die schmerzhaften unten.
Die Sicherheitslage im Ökosystem gibt der Vorsicht recht. Eine Analyse von Astrix Security zeigt, dass 53 Prozent aller MCP Server statische Secrets wie API Keys oder Personal Access Tokens einsetzen. Nur 8,5 Prozent nutzen OAuth. Knostic fand 1.862 öffentlich erreichbare MCP Server ganz ohne Authentifizierung.

MCP Zugriffskontrolle in vier Stufen

Stufe Was durchgesetzt wird Typisches Setup
Offen Nichts. Wer den Server erreicht, nutzt alle Tools Lokaler Server über STDIO, API Key in der Config
Server Zugang zum Server als Ganzes, alle Tools inklusive OAuth 2.1 mit PKCE, ein Scope pro Server
Tool Einzelne Tools pro Rolle, sichtbar und ausführbar getrennt Allow oder Deny Listen im Server oder Gateway
Policy Rolle, Kontext und Bedingung pro Aufruf, mit Audit Log Identity Provider mit EMA plus Gateway als Kontrollpunkt
Aufsteigendes Säulendiagramm der vier MCP RBAC Stufen Offen, Server, Tool, Policy. Inhalt steht textuell in der Tabelle darüber.

Regeln in der Praxis: Discovery und Ausführung

Eine Regel wirkt an zwei Stellen. Beim Auflisten der Tools filtert sie die Antwort, damit das Modell verbotene Werkzeuge gar nicht kennt. Beim Aufruf prüft sie erneut, damit ein Modell, das rät oder manipuliert wurde, eine Ablehnung bekommt.
Ein typisches Muster in Gateways und Proxies ist der Modus Allow oder Deny mit Ausnahmen. Lesbar, versionierbar, im Repository nachvollziehbar:
Code: 
          
policies:
  - name: mcp-acl-list
    params:
      tools:
        mode: allow
        exceptions:
          - admin-only-tool
          - deprecated-tool
      resources:
        mode: deny
        exceptions:
          - file:///public/documents
Auf Client Seite gilt dasselbe Prinzip. In Claude Code werden nur explizit freigegebene MCP Server aktiviert, ergänzt um Deny Rules für sensible Dateien. Eine pauschale Freigabe aller Projekt Server gehört nicht in ein Repository, dem man nicht vollständig vertraut.
Code: 
          
{
  "enabledMcpjsonServers": ["sulu", "n8n"],
  "permissions": {
    "deny": ["Read(.env)", "Read(.ssh/**)", "Read(**/credentials*)"]
  }
}
Drei Regeln, die sich bei uns bewährt haben: Schreibende Tools bekommen eine eigene Rolle, nie dieselbe wie lesende. Jeder Agent bekommt einen eigenen Schlüssel, damit das Log auswertbar bleibt. Und jede neue Freigabe wird begründet, sonst wächst die Rolle still weiter. Passend dazu Vise Coding mit Guardrails und der sichere Agent Stack NemoClaw.

Prompt Injection: warum Rechte wichtiger sind als Vertrauen

Ein Modell liest alles, was ihm ein Tool zurückgibt. Steht in einer README, einem Issue oder einer Tool Beschreibung eine versteckte Anweisung, kann das Modell sie ausführen. Invariant Labs hat solche Tool Poisoning Attacks 2025 dokumentiert: Schadcode steckt in der Beschreibung eines Tools, für den Nutzer unsichtbar.
Dazu kamen echte Lücken in weit verbreiteten Komponenten. CVE-2025-6514 mit CVSS 9.6 betraf das Paket mcp-remote mit über 437.000 Downloads. CVE-2025-49596 mit CVSS 9.4 erlaubte Remote Code Execution im offiziellen MCP Inspector über CSRF. CVE-2025-53967 traf den Framelink Figma MCP Server mit über 600.000 Downloads.
Der Schluss daraus ist unbequem, aber einfach: Man kann nicht verhindern, dass ein Modell etwas Dummes versucht. Man kann nur begrenzen, was dabei passieren kann. Rechte sind die letzte Verteidigungslinie, nicht die Formulierung im System Prompt. Ein Agent ohne Schreibrecht auf die Produktivdatenbank richtet auch mit einer perfekten Injection dort nichts an.

DSGVO: Rechte allein reichen nicht

RBAC beantwortet, wer was darf. Es beantwortet nicht, wohin die Daten fliessen. Genau diese zweite Frage entscheidet in deutschen Projekten über die Zulässigkeit.
Unsere Linie ist klar: Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk. Grosse Modelle laufen nicht auf Kundenhardware, das wäre wirtschaftlich unsinnig. Sie rechnen bei EU souveräner Inferenz wie TensorX oder in einer gehosteten Umgebung bei unserem Netzwerkpartner Conversis. Was am MCP Server hängt, bleibt im eigenen Netz.
Für die Entwicklung heisst das konkret: MCP Server, die Modelle ansprechen, die nicht auf eigener Infrastruktur laufen, arbeiten gegen lokale Entwicklungsumgebungen mit Fake Daten. Nie gegen echte Bestände. Für lokale Modelle nutzen wir Ollama, Details zur rechtlichen Einordnung stehen unter Lokale KI für Compliance.
Ein Gateway hilft hier doppelt. Es ist der Punkt, an dem Regeln greifen, und gleichzeitig der Punkt, an dem ein vollständiges Log entsteht. Wer das mit Langfuse oder LiteLLM kombiniert, bekommt Zugriffskontrolle und Nachvollziehbarkeit aus derselben Stelle.

OAuth Scopes, EMA, RBAC und Gateway im Vergleich

Mechanismus Was es löst Was offen bleibt
OAuth 2.1 mit PKCE Der Client weist sich gegenüber dem Server aus, Token sind kurzlebig Keine Aussage darüber, welches Tool erlaubt ist
Enterprise Managed Authorization Zentrale Freigabe über den Identity Provider, ein Login für alle Server Rechte innerhalb eines Servers bleiben Sache des Servers
RBAC pro Tool Rolle entscheidet über Sichtbarkeit und Ausführung einzelner Tools Muss gepflegt werden, sonst wachsen Rollen still weiter
Gateway als Kontrollpunkt Ein Ort für Auth, Regeln und vollständiges Audit Log Zusätzliche Komponente, die betrieben und überwacht werden will

Wann sich der Aufwand lohnt

Nicht jedes Setup braucht ein Gateway. Ein lokaler MCP Server über STDIO, der auf einem Entwicklerrechner gegen eine Testdatenbank läuft, kommt ohne Rollenmodell aus. Der Prozess selbst ist die Vertrauensgrenze.
Interessant wird es ab drei Punkten. Sobald mehrere Personen denselben Server nutzen, sobald ein Server schreibend auf Produktivdaten zugreift, oder sobald externe Beteiligte im Spiel sind. Ab dann ist die Frage nicht mehr ob, sondern wie fein.
Unser Vorgehen dabei ist bewusst unspektakulär. Erst inventarisieren wir, welche Tools ein Server überhaupt anbietet. Dann definieren wir Rollen entlang echter Aufgaben, nicht entlang von Personen. Dann setzen wir Deny Rules für alles Schreibende. Und erst danach kommt das Gateway, wenn es überhaupt nötig ist. Wer beim Aufbau eigener Server steht, findet Praxis unter GitHub MCP Server, glab als MCP Server und Sylius MCP Server.

As we move toward an interconnected AI workforce, security can't be an afterthought.

Aaron Parecki, Director of Identity Standards, Okta – Model Context Protocol Blog

Unsere Erfahrung mit MCP Servern im Alltag

Wir betreiben eigene MCP Server für unser Sulu CMS und für n8n. Beide laufen auf eigenen Servern in Deutschland. Die Rollen sind dort eng geschnitten, weil wir früh gemerkt haben, wie schnell ein Agent im Eifer eine Seite überschreibt, die noch gar nicht fertig war.
Was uns dabei geholfen hat, ist kein Produkt, sondern eine Reihenfolge. Erst Quality Gates: statische Analyse, Unit Tests, funktionale Tests und E2E Tests mit Cypress, sauber verankert in einer CI CD Pipeline mit Docker und Staging. Danach erst mehr Autonomie für den Agenten. Wer die Reihenfolge dreht, räumt hinterher auf.
Weiterführend: SKILL.md für Agent Skills, das A2A Protokoll, Claude Code Plugins und Shannon als KI Pentester. Für Teams, die gerade einsteigen, ist unser Vibe Coding Onboarding der passende Start, für bestehenden KI Code das Codebase Audit.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu MCP RBAC

Die wichtigsten Fragen zu Rollen, Rechten, OAuth und Enterprise Managed Authorization im Model Context Protocol – kurz und ohne Umwege beantwortet.

Was ist MCP RBAC 2026 genau?

MCP RBAC ist Rule Based Access Control für das Model Context Protocol. Statt einem Agenten pauschal alle Tools eines Servers freizugeben, bindet RBAC jeden Agenten an eine benannte Menge von Tools. Durchgesetzt wird zweifach: beim Auflisten der Tools, damit das Modell verbotene Werkzeuge gar nicht sieht, und beim Aufruf selbst, der sonst abgelehnt wird.

Reicht OAuth 2.1 als Zugriffskontrolle 2026 aus?

Nein. OAuth 2.1 regelt Authentifizierung und grobe Scopes, also ob ein Client einen Server überhaupt erreichen darf. Konventionen für einzelne Tools sind in der Spezifikation nicht standardisiert. Das Protokoll authentifiziert die Verbindung, nicht den einzelnen Aufruf. Für feingranulare Rechte braucht es zusätzlich Rollen auf dem Server oder in einem Gateway.

Was ist Enterprise Managed Authorization 2026?

EMA ist eine seit 18. Juni 2026 stabile MCP Extension. Organisationen vergeben den Zugriff auf MCP Server zentral über ihren Identity Provider. Nutzer melden sich einmal an und bekommen die freigegebenen Server automatisch verbunden, ohne OAuth pro App. Technisch läuft das über den Identity Assertion JWT Authorization Grant, kurz ID-JAG.

Welche MCP Spec Version gilt 2026?

Die Spezifikation 2026-07-28 ist die grösste Revision seit dem Start. Sie bringt einen zustandslosen Protokollkern, ein formales Extensions Framework, header basiertes Routing, cachebare Listenergebnisse und eine Härtung der Autorisierung. Der Handshake mit initialize entfällt, jede Anfrage beschreibt sich selbst. Das macht Server hinter normalen Load Balancern skalierbar.

Wer unterstützt EMA 2026 bereits?

Okta ist der erste unterstützte Identity Provider. Anthropic hat die Extension in seiner geteilten MCP Schicht umgesetzt, Visual Studio Code unterstützt sie ebenfalls. Auf Serverseite sind unter anderem Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase dabei, weitere kommen laufend hinzu.

Wie unterscheiden sich Allow und Deny Modus?

Im Allow Modus ist grundsätzlich alles erlaubt, ausser den aufgeführten Ausnahmen. Im Deny Modus ist grundsätzlich alles gesperrt, ausser den Ausnahmen. Für schreibende Tools empfehlen wir konsequent den Deny Modus, weil jede neue Funktion dann bewusst freigegeben werden muss statt still mitzulaufen.

Brauche ich für RBAC zwingend ein Gateway?

Nein. Ein Gateway ist ein bequemer Kontrollpunkt für Auth, Regeln und Audit an einer Stelle, aber kein Muss. Rollenbasierte Prüfung kann auch direkt im MCP Server stattfinden, wo Nutzeridentität und Kontext ohnehin vorliegen. Sinnvoll wird ein Gateway, sobald mehrere Server und mehrere Clients zusammenkommen.

Wie schütze ich mich gegen Prompt Injection?

Nicht durch bessere Formulierungen, sondern durch Rechte. Versteckte Anweisungen können in Tool Beschreibungen, README Dateien oder Antworten stecken. Ein Agent ohne Schreibrecht auf Produktivdaten kann auch mit einer erfolgreichen Injection dort nichts anrichten. Dazu kommen Sandboxing, Netzwerkisolation und Deny Rules für Dateien mit Zugangsdaten.

Gilt RBAC auch für lokale MCP Server?

Lokale Server über STDIO authentifizieren sich nicht, sie laufen in der Vertrauensgrenze des Host Prozesses und werden meist über Umgebungsvariablen konfiguriert. Für einen einzelnen Entwicklerrechner gegen Testdaten reicht das. Sobald mehrere Personen denselben Server nutzen oder Produktivdaten im Spiel sind, braucht es ein echtes Rollenmodell.

Ist MCP mit personenbezogenen Daten DSGVO konform nutzbar?

Das hängt am Datenfluss, nicht am Protokoll. Unsere Linie lautet: Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk. MCP Server, die Modelle ohne eigene Infrastruktur ansprechen, arbeiten gegen lokale Entwicklungsumgebungen mit Fake Daten. Für produktive Inferenz nutzen wir EU souveräne Anbieter oder lokale Modelle über Ollama.

Wie viele Rollen sind sinnvoll?

Weniger als man denkt. In der Praxis reichen oft drei: eine lesende Rolle für Recherche und Analyse, eine schreibende für Änderungen an Entwicklungsständen, und eine administrative für Freigaben. Wichtig ist, dass Rollen entlang von Aufgaben geschnitten werden und nicht entlang von Personen, sonst wachsen sie unkontrolliert.

Was kostet die Einführung bei NCA?

Wir arbeiten ohne Festpreise und ohne Pakete. Am Anfang steht ein kostenloses Kennenlernen, danach schätzen wir den Aufwand ehrlich ein und rechnen minutengenau ab. Für die Einführung von KI Setups sind realistisch 15 bis 30 Tage bis zum ersten verlässlichen Ergebnis anzusetzen, danach einige Tage pro Monat für die Pflege der Regeln.