MCP Governance, Benutzerrollen und Berechtigungen — warum es für Unternehmen zählt

Das versteckte Problem der meisten MCP-Setups

Das Model Context Protocol hat einen sauberen Weg geöffnet, damit AI-Agenten mit echten Systemen sprechen können. Die erste Welle von MCP-Servern wird als CLI-Binary ausgeliefert: auf dem Entwickler-Laptop installieren, Claude Desktop darauf zeigen, fertig. Das funktioniert für einen einzelnen Power-User.

Für ein Unternehmen funktioniert es nicht.

Sobald mehr als eine Person im Unternehmen MCP nutzen muss, tauchen drei Governance-Fragen auf einmal auf:

1. Wer darf welchen Konnektor benutzen?
2. Was darf jeder Benutzer tun, wenn er verbunden ist (read? write? delete?)
3. Wo lebt der Audit-Trail?

CLI-basierte MCP-Server antworten "jeder mit dem Binary" / "alles was die API erlaubt" / "stdout, morgen weg". Für ein reguliertes Unternehmen ist das ein hartes Stoppschild.

Genau diese Lücke schließt AnythingMCP.

Was Governance im MCP-Kontext bedeutet

In einem klassischen SaaS heißt Governance Benutzer, Gruppen, Rollen, Berechtigungen und ein Audit-Log. Dieselben Primitive gelten für MCP — mit einer zusätzlichen Dimension: dem Tool.

Ein MCP-Server stellt dem AI-Client eine Liste von Tools zur Verfügung. Jedes Tool ist eine diskrete Fähigkeit — list_invoices, create_quote, delete_account. Ohne Access Control pro Tool bedeutet "den CRM-Konnektor freigeben" gleich jedem Tool des Konnektors freizugeben. Das entspricht einem Root-SSH-Zugang für einen Praktikanten, weil er ein Log tail-en muss.

AnythingMCP behandelt vier Ebenen als First-Class:

Jeder Aufruf wird gegen alle vier geprüft und dann geloggt.

Das AnythingMCP-Governance-Modell

Benutzer und SSO

Benutzer können manuell aus dem Dashboard angelegt werden — oder, was Enterprise-Kunden tatsächlich tun, der existierende Identity Provider angebunden werden:

• SAML 2.0 für Okta, Azure AD, OneLogin, Ping, Auth0, Keycloak
• SCIM 2.0 für automatisches Provisioning und De-Provisioning (wenn jemand das Unternehmen verlässt, verschwindet sein MCP-Zugriff mit dem AD-Account — nicht drei Wochen später, wenn Ops dazu kommt)
• Gruppe → Rolle Mapping: die AD-Gruppe eng-platform wird automatisch zur Rolle developer in AnythingMCP

Kein separates Passwort zum Rotieren, keine Schatten-Benutzerliste zum Synchronisieren.

Rollen

Eine Rolle ist ein benanntes Bündel von Berechtigungen. AnythingMCP liefert sinnvolle Defaults — admin, developer, viewer — und lässt eigene definieren.

Eine Rollendefinition sieht konzeptionell so aus:

role: finance
description: Finance-Team — Rechnungen überall lesen, in DATEV buchen
connectors:
  - slug: datev
    tools:
      list_clients: read
      list_invoices: read
      create_booking: write
      delete_booking: off
  - slug: weclapp
    tools:
      list_invoices: read
      list_orders: read
  - slug: sap-erp
    tools:
      "*": off    # explizit verboten

Der Wildcard "*" ist wichtig: wenn später ein neues Tool zum SAP-Konnektor hinzukommt, erbt die Rolle finance automatisch off — fail-closed statt fail-open.

Zugriff pro Konnektor

Das häufigste Enterprise-Muster: Konnektoren entlang Teamgrenzen trennen.

• Vertrieb sieht das CRM.
• Finance sieht ERP und Buchhaltung.
• Engineering sieht Produktionsdatenbanken (read-only).
• Customer Support sieht das Ticketsystem.

Der AI-Agent jedes Teams — Claude, ChatGPT, Copilot, egal — sieht nur die Tools, die seine Rolle erlaubt. Eine Vertriebsperson, die ChatGPT bittet "lösche den Kundeneintrag", bekommt eine saubere Ablehnung vom Gateway, kein 500 von SAP nachdem die Aktion schon halb durch ist.

Berechtigungen pro Tool

Das ist die Granularität, die CLI-Server nicht bieten können.

Ein einzelner MCP-Konnektor für Salesforce kann 30+ Tools exponieren: list_accounts, get_opportunity, create_opportunity, update_opportunity, delete_opportunity, list_leads, … Für jedes unterstützt AnythingMCP drei Modi:

• read — das Tool ist aufrufbar und liefert Daten, Mutationen werden gefiltert
• write — das Tool ist voll aufrufbar
• off — das Tool ist vor dem Agenten komplett versteckt (es taucht nicht einmal in der MCP-Antwort tools/list auf)

"Versteckt" ist der entscheidende Punkt. Ein Modell kann nicht zu einem Tool jailbreakt werden, das es nicht kennt. Indem der Tool-Katalog pro Rolle gekürzt wird, sinkt die Angriffsfläche auf das Minimum, das jeder Benutzer tatsächlich braucht.

Audit-Log

Jeder Tool-Aufruf schreibt eine Zeile: wer, wann, welches Tool, welcher Konnektor, mit welchen Argumenten, was zurückgegeben wurde (oder welcher Fehler). Das Log lebt in Ihrem PostgreSQL — nicht in unserer Cloud, nicht im S3 eines Dritten — und ist wie jede andere Tabelle abfragbar.

Für regulierte Branchen (Banken, Gesundheitswesen, öffentlicher Sektor) ist genau das, was MCP überhaupt nutzbar macht. Sie können "hat jemand letztes Quartal die Patientenakte 1234 gelesen" mit einer einzigen SQL-Abfrage beantworten.

Warum das mit CLI-only MCP-Servern unmöglich ist

Das MCP-Ökosystem ist voll mit single-purpose CLI-Servern — mcp-server-postgres, mcp-server-github, etc. Für den persönlichen Gebrauch sind sie super. Für Enterprise-Governance sind sie strukturell ungeeignet — aus vier Gründen:

1. Kein Benutzerkonzept. Ein CLI-Binary läuft als der OS-Benutzer, der es gestartet hat. Es gibt kein "Max" vs "Anna" — nur whoami. Zwei Personen, die denselben Claude-Desktop-Install teilen, teilen dieselbe MCP-Identität — by design.

2. Kein Tool-Scoping. Wenn die CLI query_database exponiert, kann jeder Benutzer mit dem Binary jedes SQL ausführen. Sie können das nicht auf nur SELECT oder bestimmte Tabellen beschränken, ohne das Binary zu forken.

3. Kein zentrales Audit. Jedes Binary loggt in seinen eigenen stdout. Es gibt keinen Ort, an dem Sie fragen können "zeig mir jeden MCP-Aufruf des Unternehmens der letzten Woche".

4. Kein Deprovisioning. Wenn jemand geht, müssten Sie jeden Laptop mit dem Binary aufspüren und die Credentials ziehen. In der Praxis macht das niemand.

Das sind keine Bugs der CLI-Server — sie sind der Architektur inhärent. Ein Binary auf einer Entwicklermaschine hat kein Konzept von organisatorischer Identität.

Warum gehostete SaaS-Gateways das umgekehrte Problem haben

Die andere offensichtliche Antwort ist "ein gehostetes MCP-Gateway als SaaS nutzen". Das löst die Governance — schafft aber ein schlimmeres Problem: Ihre Produktions-Credentials leben jetzt bei einem Dritten.

Für eine deutsche GmbH oder ein reguliertes US-Unternehmen scheitert das typischerweise:

• Compliance — DSGVO, BDSG, HIPAA, SOX erschweren (oder verbieten) die Weitergabe von Service-Account-Credentials an Dritte
• Blast Radius — wenn der SaaS kompromittiert wird, sind die verbundenen Produktionssysteme jedes Kunden auf einmal exponiert
• Vendor Lock-in — Credentials, Audit-Logs, Rollendefinitionen, alles lebt in einem System, das Sie nicht kontrollieren

AnythingMCP ist self-hosted by design. Das Gateway läuft in Ihrem VPC, Ihrem Kubernetes-Cluster, Ihrer Hetzner-Box, Ihrem Laptop — wo Sie wollen. Credentials verlassen Ihren Perimeter nie. Das Audit-Log lebt in Ihrer Datenbank. Governance-Policies werden in Ihrem Git-Repo versioniert, wenn Sie wollen.

Sie bekommen die Governance eines gehosteten Gateways mit der Trust Posture eines self-hosted Binaries.

Warum das speziell für Unternehmen zählt

Drei Muster, die wir bei Enterprise-Käufern immer wieder sehen:

Muster 1 — das Security-Review-Gate

Ein Pilot startet in IT oder Innovation. Sobald das Projekt in die Produktion geht, setzt die Security Review ein und fragt:

• Können wir den Zugriff für einen bestimmten Benutzer entziehen?
• Können wir nachweisen, wer welches Tool aufgerufen hat?
• Wo sind die Credentials gespeichert, und wer kann sie entschlüsseln?

CLI-Server scheitern an allen drei. AnythingMCP beantwortet jede mit einem Screenshot des Dashboards.

Muster 2 — das Legal/Compliance-Gate

Legal fragt: "Wenn ein Regulator uns wegen einer AI-getriebenen Entscheidung vorlädt, können wir den Aufruf-Trail liefern?"

Die Antwort muss ja lauten, mit Timestamps, Benutzeridentität und den vollständigen Tool-Argumenten. Das Audit-Log von AnythingMCP ist genau dafür strukturiert — jeder Aufruf ist eine Zeile mit Timestamp, Benutzer, Konnektor, Tool, args, Antwortstatus. Das als CSV für Legal zu exportieren ist eine Ein-Zeilen-Query.

Muster 3 — das Cross-Team-Gate

Sobald ein Team MCP zum Laufen hat, wollen es drei weitere. Ohne Governance bekommt jedes Team entweder:

• Eine eigene CLI-Installation (Verlust der zentralen Übersicht)
• Eine geteilte Installation ohne Isolation (der Fehler eines Teams bricht die Daten eines anderen)

AnythingMCP erlaubt einer einzigen Instanz, alle Teams sicher zu bedienen — Vertrieb sieht nur CRM, Finance nur ERP, Eng nur die Metrics-DB. Jeder Team-AI-Client bekommt eine andere /mcp-URL mit seinem eigenen scoped Tool-Katalog.

Ein praktisches Setup, End-to-End

So sieht ein typischer Enterprise-Rollout in AnythingMCP Schritt für Schritt aus:

1. Deploy des Gateways in Ihrer Infrastruktur (Docker, Helm, Railway, DigitalOcean — Ihre Wahl). Etwa 60 Sekunden.

2. SSO einbinden. Okta oder Azure AD auf den SAML-Endpunkt des Gateways zeigen lassen. AD-Gruppen auf AnythingMCP-Rollen mappen.

3. Konnektoren hinzufügen. Vom Dashboard aus AnythingMCP auf Ihre APIs zeigen lassen (OpenAPI-URL, WSDL, Datenbank-Connection-String). Generiert den MCP-Tool-Katalog automatisch.

4. Rollen definieren. Für jede Rolle festlegen, welche Konnektoren und welche Tools sie aufrufen darf (read / write / off). Wildcards defaulten auf off — neue Tools später freischalten geht nie aus Versehen.

5. MCP-Endpunkt verteilen an die Benutzer. Jeder Claude / ChatGPT / Copilot-Client bekommt dieselbe Gateway-URL — AnythingMCP liefert den scoped Tool-Katalog basierend auf der Rolle des authentifizierten Benutzers zurück.

6. Monitoring via Audit-Log. Jeder Aufruf lebt in Ihrem Postgres; ein Metabase-Dashboard darauf an einem Nachmittag.

TL;DR — warum AnythingMCP für Governance

Wenn Governance auf Ihrer AI-Roadmap steht und self-hosted nicht verhandelbar ist — AnythingMCP ist die einzige Option, die Ihnen beides gibt.

Loslegen

Sie können das Governance-Modell auf AnythingMCP Cloud testen (7 Tage kostenlos, ohne Kreditkarte) oder den Open-Source-Build mit einem Befehl self-hosten. Beide liefern dieselbe RBAC-Engine.

→ Kostenlos in der Cloud starten → Auf GitHub self-hosten → Mit dem Team über Enterprise-Rollouts sprechen