MCP-Server im Team freigeben: Scopes, Rechte, Identität

Ein MCP-Server ist schnell eingerichtet: ein Befehl, und der Agent kann plötzlich Tickets lesen, Datenbanken abfragen oder im Browser klicken. Genau deshalb wächst die Liste in vielen Teams unkontrolliert. Jede Person hat eigene Server, niemand weiß, welche Tools mit welchen Rechten verbunden sind, und Zugangsdaten liegen verstreut in lokalen Konfigurationen. Die Frage für Teamleads ist nicht, ob MCP sinnvoll ist, sondern wer entscheidet, welche Server im Team laufen.

Dass sich das Thema verschiebt, zeigte die AGNTCon + MCPCon 2026 in San José. Laut InfoQ ging es dort weniger um neue Protokollfunktionen als um Sicherheit und Identität.

Drei Ablageorte, drei Verantwortlichkeiten

Claude Code kennt drei Ebenen für MCP-Server. Der Local Scope ist der Standard: Der Server gilt nur im aktuellen Projekt und nur für die Person, die ihn angelegt hat, gespeichert in ~/.claude.json. Der User Scope liegt ebenfalls dort, gilt aber in allen Projekten dieser Person. Der Project Scope schreibt den Server in eine Datei .mcp.json im Wurzelverzeichnis, die ins Repository wandert. So bekommt das ganze Team dieselben Tools.

claude mcp add --scope project ...

Für Teams ergibt sich daraus eine einfache Regel: Was alle brauchen, gehört in .mcp.json und wird wie Code per Pull Request geändert und reviewt. Experimente und Server mit persönlichen Zugangsdaten bleiben im Local Scope. Damit Schlüssel nicht im Repository landen, ersetzt Claude Code in .mcp.json Platzhalter wie ${VAR} oder ${VAR:-default} durch Umgebungsvariablen.

Ist derselbe Servername in mehreren Ebenen definiert, gewinnt der Local Scope vor Project und User. Felder werden dabei nicht zusammengeführt, es gilt der ganze Eintrag der höchsten Ebene. Das ist eine typische Quelle für „bei mir geht es aber“.

Wer einen Server aus dem Repository freigibt

In interaktiven Sitzungen fragt Claude Code nach, bevor es Server aus .mcp.json nutzt. Ein frisch geklontes Repository kann sich dabei nicht selbst freigeben: Steht etwa enableAllProjectMcpServers in einer eingecheckten .claude/settings.json, ignoriert Claude Code das, solange die Person dem Workspace nicht vertraut hat. Das schützt vor fremden Repositories, die beim ersten Öffnen eigene Tools mitbringen. Wie solche Inhalte einen Agenten umlenken können, beschreibt unser Beitrag zu Prompt Injection im Team.

Wichtig für Automatisierung: In claude -p-Läufen, Agent-SDK-Sitzungen und Cloud-Sessions außerhalb eines Projekts kann diese Abfrage nicht erscheinen, die Server aus .mcp.json laden dann ohne Rückfrage. Wer Server gezielt ausschließen will, trägt sie in disabledMcpjsonServers ein, das in jedem Berechtigungsmodus greift, oder startet mit --strict-mcp-config und übergibt nur die gewünschten Server per --mcp-config. Für zentrale Vorgaben gibt es eine verwaltete Konfiguration mit managed-mcp.json sowie Erlaubnis- und Sperrlisten (allowedMcpServers, deniedMcpServers).

Rechte begrenzen statt Vertrauen voraussetzen

Viele MCP-Server melden sich per OAuth an. Bietet der Autorisierungsserver mehr Scopes an, als das Team gewähren will, lässt sich das mit oauth.scopes auf eine vom Security-Team abgestimmte Auswahl begrenzen. Fehlt später ein Recht, schlägt der Aufruf mit einer klaren Meldung fehl, statt still mehr zu bekommen.

Wie berechtigt die Sorge um Zugangsdaten ist, zeigt eine aktuelle Diskussion auf Reddit. Mehrere Entwickler berichten dort, ihr Agent habe persönliche Angaben wie die eigene E-Mail-Adresse an Dienste weitergegeben, andere konnten das nicht nachstellen. Einig waren sich viele bei den Gegenmitteln: Agenten in Containern laufen lassen, Netzwerkzugriff einschränken und Zugangsdaten vom Agenten trennen. Ein Kommentar wies darauf hin, dass ein Mechanismus, der echte Tokens erst nachträglich einsetzt, an den freigegebenen Host gebunden sein muss, sonst landet das Token beim falschen Ziel.

Was die MCPCon für eigene Server lehrt

Baut Ihr Team eigene MCP-Server, etwa für interne APIs, lohnen drei Punkte aus den Vorträgen. Erstens Tool-Annotations: OpenAI nimmt Server ins ChatGPT-Plugin-Verzeichnis nur auf, wenn jedes Tool als lesend oder verändernd gekennzeichnet ist. Lesende Aufrufe laufen dann schneller durch, verändernde werden bestätigt. Zweitens kleine Schemas: Zu große Tool-Schemas werden gekürzt, zuerst die Beschreibungen der Argumente. Etwa drei von vier Schemas auf veröffentlichten Servern sind kleiner als 1 kB. Drittens Identität: Die Auth-Roadmap des Protokolls führt Enterprise-Managed Authorization als stabil, Proof-of-Possession-Tokens und Workload Identity Federation als Entwurf und zielt auf Agenten, die sich als sie selbst anmelden statt mit einem geliehenen Nutzer-Token.

InfoQ weist selbst darauf hin, dass mehrere Zahlen Bühnenaussagen ohne veröffentlichte Daten waren und manche Sicherheitserweiterungen noch Entwürfe sind. Als Richtung taugen sie trotzdem.

Was das für Ihr Entwicklerteam bedeutet

MCP-Server sind Berechtigungen, keine Komfortfunktion. Behandeln Sie die Liste der Server wie eine Liste von Abhängigkeiten mit Zugriffsrechten: eine gepflegte .mcp.json im Repository, Änderungen nur per Pull Request, Schlüssel nur über Umgebungsvariablen, und eine bewusste Entscheidung, was in automatisierten Läufen ohne Rückfrage geladen wird. Wer gerade die Arbeitsweise mit Claude Code im Team aufbaut, sollte MCP von Anfang an in diese Regeln aufnehmen, statt später aufzuräumen. Weitere Schwerpunkte finden Sie auf unserer Seite zu Sicherheit im Training.

Sie wollen klären, welche MCP-Server Ihr Team mit welchen Rechten nutzt, und die Freigabe am eigenen Repository einrichten? Inhouse-Training anfragen.