Claude MCP im Unternehmen: Server freigeben und absichern

TL;DR

Claude MCP verbindet Claude über lokale stdio-Server oder entfernte HTTP-Server mit Ihren Systemen. Im Unternehmen ist jeder MCP-Server Code mit Datenzugriff. Geben Sie Server zentral frei, erzwingen Sie das per managed-mcp.json oder allowedMcpServers mit allowManagedMcpServersOnly, prüfen Sie nach URL oder Befehl statt nach Namen, nutzen Sie OAuth mit engen Scopes und protokollieren Sie Tool-Aufrufe.

Was ist Claude MCP, und worin unterscheiden sich lokale und entfernte Server?

Das Model Context Protocol (MCP) ist ein offenes Protokoll, über das Claude Tools aufruft und Daten aus anderen Systemen liest. Ein lokaler Server läuft als Unterprozess auf dem Rechner des Nutzers und spricht über stdio. Ein entfernter Server läuft woanders und wird über Streamable HTTP erreicht. Beide geben Claude echte Fähigkeiten, deshalb brauchen beide eine Freigabe.

Anthropic hat MCP am 25. November 2024 vorgestellt, als Standard, um KI-Assistenten an die Systeme anzubinden, in denen die Daten liegen. Am 9. Dezember 2025 hat Anthropic MCP an die Agentic AI Foundation übergeben, einen Fonds unter dem Dach der Linux Foundation. Damals zählte Anthropic mehr als 10.000 aktive öffentliche MCP-Server, über 97 Mio. SDK-Downloads pro Monat für Python und TypeScript und mehr als 75 Connectoren im Claude-Verzeichnis. Bei 10.000 öffentlichen Servern finden Ihre Entwickler für fast alles einen. Genau das ist das Governance-Problem.

Die aktuelle Transport-Spezifikation (Revision 2026-07-28) kennt zwei Standardtransporte:

	Lokaler Server (stdio)	Entfernter Server (Streamable HTTP)
Wo er läuft	Unterprozess auf dem Laptop	Eigener Host, Cloud des Anbieters oder hinter einem Tunnel
Wer ihn erreicht	Nur der Client, der ihn gestartet hat	Jeder, der die URL erreicht, also braucht er Authentifizierung
Zugangsdaten	Aus der Umgebung, laut Spezifikation	Autorisierung auf Basis von OAuth 2.1
Hauptrisiko	Beliebige Codeausführung mit Nutzerrechten	Zu weite Tokens, Daten fließen an Dritte
Allowlist-Schlüssel in Claude Code	serverCommand	serverUrl

Die MCP-Spezifikation sagt klar: Tools sind beliebige Codeausführung, und Beschreibungen des Tool-Verhaltens gelten als nicht vertrauenswürdig, solange sie nicht von einem vertrauenswürdigen Server stammen. Diesen Satz sollten Sie kennen, bevor Sie einen Community-Server freigeben.

In Claude taucht MCP an zwei Stellen auf. Claude Code liest Server aus Konfigurationsdateien. Die Claude-Apps (claude.ai, Desktop, Cowork) nutzen Connectoren, also entfernte MCP-Server, die per URL hinzugefügt werden. In Team- und Enterprise-Plänen fügt nur ein Owner einen Custom Connector für die Organisation hinzu. Jedes Mitglied verbindet sich danach mit dem eigenen Konto.

Wie konfiguriert Claude Code MCP-Server?

Claude Code kennt drei Scopes. Local ist der Standard und bleibt privat für ein Projekt auf einem Rechner. Project schreibt .mcp.json ins Repository, damit das Team dieselben Server nutzt. User gilt für alle Projekte eines Nutzers. Darüber legt die Organisation über verwaltete Konfiguration eine vierte Ebene.

Die MCP-Referenz von Claude Code nennt die Speicherorte:

Scope	Lädt in	Mit dem Team geteilt	Gespeichert in
Local (Standard)	Nur aktuelles Projekt	Nein	~/.claude.json
Project	Nur aktuelles Projekt	Ja, über Versionskontrolle	.mcp.json im Projektstamm
User	Alle eigenen Projekte	Nein	~/.claude.json

Server über die CLI hinzufügen:

claude mcp add --transport http tickets --scope project https://mcp.internal.example.com/mcp
claude mcp add --transport stdio pgread --scope project -- npx -y @example/postgres-mcp@1.4.2
claude mcp list

Die entstehende .mcp.json ist die Datei, die Sie im Pull Request prüfen. Geheimnisse bleiben über ${VAR}-Expansion draußen:

{
  "mcpServers": {
    "tickets": {
      "type": "http",
      "url": "https://mcp.internal.example.com/mcp",
      "headers": { "Authorization": "Bearer ${TICKETS_MCP_TOKEN}" }
    },
    "pgread": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/postgres-mcp@1.4.2"],
      "env": { "DATABASE_URL": "${PGREAD_URL}" }
    }
  }
}

Drei Verhaltensweisen gehören in jedes Security-Review:

1. In interaktiven Sitzungen fragt Claude Code nach, bevor es Project-Server aus .mcp.json nutzt. In claude -p, im Agent SDK und in Cloud-Sitzungen kann es diese Abfrage nicht zeigen und lädt die Server ohne Rückfrage. Ein CI-Job, der einen fremden Branch auscheckt, startet also, was in dessen .mcp.json steht.
2. In url und headers eines entfernten Servers werden Credential-Variablen wie ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN und AWS_BEARER_TOKEN_BEDROCK als leer gelesen. Eine bösartige .mcp.json kann Ihr Bedrock-Token nicht an den eigenen Server schicken.
3. Claude Code warnt ab 10.000 Tokens MCP-Ausgabe und begrenzt sie standardmäßig auf 25.000 Tokens (MAX_MCP_OUTPUT_TOKENS hebt die Grenze an). Große Tool-Ausgaben kosten Tokens und sind zugleich der Kanal, über den eingeschleuster Text das Modell erreicht.

Ein Detail für den EU-Betrieb: Connectoren aus claude.ai lädt Claude Code nur, wenn der Nutzer mit einem claude.ai-Abo angemeldet ist. Ist Bedrock oder Google Cloud aktiv, werden sie nicht geholt. Wer Claude Code wie in unserer Anleitung Claude Code auf Bedrock einrichten in einer EU-Region betreibt, bezieht jeden MCP-Server aus eigenen Konfigurationsdateien.

Wie setzen Sie MCP-Regeln im ganzen Unternehmen durch?

Mit verwalteter Konfiguration, nicht mit einer Wiki-Seite. Claude Code bietet eine feste Serverliste per managed-mcp.json, zentral bereitgestellte Server per managedMcpServers und Filter per allowedMcpServers und deniedMcpServers. Für eine harte Allowlist setzen Sie zusätzlich allowManagedMcpServersOnly: true, sonst können Nutzer sie in eigenen Settings erweitern.

Die Seite zu Managed MCP beschreibt die Muster. Diese sehen wir in der Praxis:

Muster	Wirkung	Konfiguration
MCP abschalten	Nur eingebaute Server laden	managed-mcp.json mit "mcpServers": {}
Feste Ausstattung	Alle bekommen dieselben Server, sonst nichts	managed-mcp.json mit Ihren Servern
Freigegebener Katalog	Nutzer wählen aus einer freigegebenen Liste	allowedMcpServers plus allowManagedMcpServersOnly: true
Nur Denylist	Bekannt schlechte Server sperren	deniedMcpServers

managed-mcp.json liegt unter macOS in /Library/Application Support/ClaudeCode/, unter Linux und WSL in /etc/claude-code/ und unter Windows in C:\Program Files\ClaudeCode\. Jeder Nutzer des Rechners kann sie lesen. API-Schlüssel gehören deshalb nie in deren env-Blöcke. Eine Managed-Settings-Datei für den freigegebenen Katalog:

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.internal.example.com/*" },
    { "serverCommand": ["npx", "-y", "@example/postgres-mcp@1.4.2"] }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ]
}

Die Regeln dahinter:

• Ein Treffer auf der Denylist sperrt den Server. Nichts hebt das auf.
• serverCommand vergleicht exakt, jedes Argument in derselben Reihenfolge. Steht die Paketversion im Befehl, gibt die Allowlist eine Version frei und nicht nur einen Namen.
• Ein serverName-Eintrag ist keine Sicherheitskontrolle. Jeder kann einen beliebigen Server github nennen. Das steht so in der Anthropic-Doku.
• managedMcpServers (nur entfernte Server, nur https://, keine Befehle) braucht Claude Code ab Version 2.1.259.

Die Falle für EU-Setups: Wer CLAUDE_CODE_USE_BEDROCK oder einen anderen Drittanbieter setzt, umgeht die Server-Managed-Settings aus der claude.ai-Konsole. Auf Bedrock verteilen Sie die Allowlist also als managed-settings.json, per MDM-Profil oder über ein selbst betriebenes Claude-Apps-Gateway. Bei Cowork auf einem Drittanbieter liefert und sperrt Claude Desktop die MCP-Server selbst. Dieses Setup beschreibt unser Artikel zu Claude Cowork im Unternehmen.

Für das Monitoring setzen Sie OTEL_LOG_TOOL_DETAILS=1 mit OpenTelemetry-Export. Dann tragen Tool-Events die Namen von MCP-Server und Tool, und Sie sehen, welche Server tatsächlich genutzt werden.

Welche MCP-Risiken zählen, und wie begegnen Sie ihnen?

Vier Risiken dominieren: Prompt Injection über Tool-Ausgaben, manipulierte oder still geänderte Tool-Beschreibungen, zu weite oder durchgereichte Tokens und lokale Server, die beliebigen Code ausführen. Für jedes gibt es eine konkrete Kontrolle in der MCP-Spezifikation oder in den Admin-Einstellungen von Claude. Ein Label im Verzeichnis löst keines davon.

Risiko	Was passiert	Kontrolle
Prompt Injection	Ein Server holt externe Inhalte und liefert Text mit Anweisungen zurück	Nur vertrauenswürdige Server, Einzelfreigabe für schreibende Tools, unnötige Tools sperren
Tool Poisoning	Eine Tool-Beschreibung versteckt Anweisungen oder ändert sich nach der Freigabe	Beschreibungen als unsicher behandeln, Versionen pinnen, bei Änderung neu prüfen
Token-Durchreichung	Ein Server reicht ein Token weiter, das nicht für ihn ausgestellt wurde	Spezifikation: Server dürfen solche Tokens nicht akzeptieren
Zu weite Scopes	Ein geleaktes Token öffnet Dateien, Datenbank und Admin	Minimale Scopes, Erhöhung erst bei privilegierten Aufrufen
Kompromittierter lokaler Server	Ein Startbefehl schickt Schlüssel nach außen	Sandbox, exakte Befehls-Allowlist, kein npx ohne Version

Die Prüfliste von Anthropic für Connectoren lehnt Tool-Beschreibungen ab, die versteckte, verschleierte oder kodierte Anweisungen enthalten oder Claude zu Tools schicken, die der Nutzer nicht angefragt hat. Nutzen Sie dieselbe Liste für Ihr internes Review. Die Seite zur Connector-Verifizierung ist deutlich: Das Label Verified ist kein Security-Audit, und der Entwickler kann Tools nach der Prüfung ändern.

Die Security Best Practices von MCP setzen zwei Regeln für Server, die Sie selbst bauen. MCP-Server dürfen keine Tokens akzeptieren, die nicht explizit für sie ausgestellt wurden. Und Scopes starten minimal, erweitert wird erst, wenn ein privilegiertes Tool zum ersten Mal aufgerufen wird, statt Wildcards wie files:* oder admin:*. Die Autorisierungs-Spezifikation verlangt Resource Indicators (RFC 8707), damit ein Token an genau einen Server gebunden ist.

In Claude Code bilden Berechtigungsregeln die zweite Linie: mcp__github__get_* erlaubt nur die get_-Tools eines Servers, "mcp__*" in einer Deny-Regel entfernt jedes MCP-Tool. In den Claude-Apps kann ein Admin einzelne Connector-Tools auf Blocked setzen.

Zur DSGVO: Ein entfernter MCP-Server eines Anbieters erhält alles, was der Tool-Aufruf mitschickt, oft personenbezogene Daten. Damit ist der Anbieter Auftragsverarbeiter oder eigener Verantwortlicher, braucht einen AVV oder eine andere Rechtsgrundlage und gehört ins Verzeichnis der Verarbeitungstätigkeiten wie jedes andere SaaS. Custom Connectoren in claude.ai werden aus der Infrastruktur von Anthropic aufgerufen, der Server muss von dort erreichbar sein. Für Server, die im eigenen Netz bleiben sollen, können Enterprise-Kunden MCP-Tunnel anfragen: eine Research Preview mit bis zu 10 aktiven Tunneln pro Organisation, bei der Cloudflare als Unterauftragsverarbeiter dazukommt.

Wie sieht ein tragfähiger Freigabeprozess für MCP aus?

MCP-Server laufen durch dasselbe Tor wie jede Software mit Datenzugriff: Antrag, Prüfung durch Security und Datenschutz, gepinnte und per Allowlist erzwungene Konfiguration, erneute Prüfung bei jeder Änderung. Eine Freigabe ist erst echt, wenn die Allowlist sie auf jedem Rechner durchsetzt.

1. Antrag: Das Team nennt Server, Transport, URL oder exakten Befehl, benötigte Tools und betroffene Daten.
2. Prüfung: Security liest Tool-Beschreibungen und Quellcode (bei stdio), der Datenschutz bewertet den Datenfluss und prüft den Vertrag mit dem Anbieter.
3. Konfiguration: Version pinnen, OAuth mit den engsten Scopes, schreibende Tools auf ask setzen.
4. Durchsetzung: Den Eintrag serverUrl oder serverCommand in die Managed Settings aufnehmen und ausrollen.
5. Überwachung und Neuprüfung: Nutzung per OpenTelemetry verfolgen, bei jedem Versionssprung oder Tool-Wechsel neu prüfen.

Schritt	Verantwortlich	Nachweis
Antrag	Anfragendes Team	Server, Tools, Datenkategorien, Geschäftszweck
Security-Prüfung	IT-Sicherheit	Gelesene Tool-Beschreibungen, geprüfter Code oder Anbieter, Auth-Modell
Datenschutz	DSB	Rolle des Anbieters, AVV, Drittlandtransfer, VVT-Eintrag
Durchsetzung	Plattformteam	Commit in den Managed Settings, gepinnte Version
Neuprüfung	Plattformteam und Security	Changelog-Prüfung bei jedem Update

Server, die nur öffentliche Dokumentation lesen, dürfen eine Schnellspur nehmen. Server mit Schreibzugriff auf Produktionsdaten, Personal- oder Kundendaten gehen immer durch das volle Verfahren.

Selbst betreiben oder auslagern?

MCP im eigenen Haus zu betreiben ist Plattformarbeit, keine einmalige Einrichtung. Jemand muss das Serververzeichnis pflegen, gepinnte Versionen aktualisieren, Geheimnisse rotieren und Logs lesen. Bei einer Handvoll lesender Server schafft das ein internes Team nebenbei. Bei Dutzenden Servern mit Schreibrechten liegt in dieser laufenden Arbeit das Argument für einen Dienstleister.

Die wiederkehrenden Aufgaben aus unserer Sicht:

Aufgabe	Inhalt	Rhythmus (unsere Schätzung)
Serverinventar	Eine Liste freigegebener Server mit Owner, Version, Datenkategorien	Bei jeder Freigabe
Patchen	Versionen anheben, geänderte Tools neu prüfen, Allowlist anpassen	Wöchentlicher Check, bei Advisories sofort
Secret-Rotation	OAuth-Clients, statische Header, Tunnel-Token und TLS-Schlüssel	Nach Ihrer Richtlinie, sofort nach einem Leak
Logging	OpenTelemetry-Pipeline, Alarme bei unbekannten Servern oder neuen Tools	Laufend
Richtlinien-Rollout	MDM oder Managed Settings, Info an Nutzer, wenn Server gesperrt werden	Bei jeder Änderung

Unsere grobe Schätzung für eine mittelgroße Entwicklungsorganisation: ein Bruchteil einer Plattform-Stelle plus einige Stunden Security-Review pro neuem Server. Das ist eine Schätzung, kein Benchmark.

Auslagern lohnt sich, wenn Ihnen ein Plattformteam fehlt, das MDM und Secrets-Management schon betreibt, oder wenn jemand anderes entfernte MCP-Server mit SLA hosten soll. Wenig Sinn ergibt es, wenn Sie nur zwei oder drei Connectoren von Anbietern nutzen. Dann ist der Anbieter bereits der Betreiber.

Was Sie bei MCP von einem Dienstleister verlangen sollten:

• SLA für gehostete MCP-Server, inklusive der Frist für Patches nach einem Security-Advisory.
• Einen AVV, der MCP-Tool-Aufrufe ausdrücklich als Verarbeitung nennt, und die Liste der Unterauftragsverarbeiter, inklusive Tunnel- und Hosting-Anbieter.
• Ein Zugriffsmodell mit Tokens pro Server, minimalen Scopes und ohne Token-Durchreichung, bei dem Ihr IdP die Quelle der Identität bleibt.
• Logs, die Sie in Ihr eigenes SIEM exportieren können.
• Exit: Serverdefinitionen, Allowlists und Inventar liegen in Ihrem Repository, nicht nur in der Konsole des Dienstleisters.

Wer zusätzlich ein Gateway für den Modellverkehr betreibt, stellt dort dieselben Fragen. Unser Artikel zum LiteLLM-EU-Gateway behandelt diese Seite.

FAQ

Was kostet Claude MCP?

Das Protokoll ist offen und kostet keine Lizenzgebühr. Kosten entstehen durch den Betrieb der Server, durch Abos für gehostete Connectoren und durch Tokens: Tool-Ausgaben zählen als Eingabe für das Modell. Claude Code begrenzt MCP-Ausgaben standardmäßig auf 25.000 Tokens und warnt ab 10.000.

managed-mcp.json oder allowedMcpServers: was passt besser?

managed-mcp.json, wenn alle exakt dieselben Server bekommen sollen und sonst nichts, denn die Datei übernimmt die exklusive Kontrolle. allowedMcpServers mit allowManagedMcpServersOnly: true, wenn Teams aus einem freigegebenen Katalog wählen. Beides wird durchgesetzt, das Erste ist strenger.

Sind Connectoren im Anthropic-Verzeichnis sicherheitsgeprüft?

Nein. Anthropic prüft Connectoren gegen seine Aufnahmekriterien, auditiert oder verwaltet aber keinen MCP-Server. Das Label Verified bedeutet eine genauere Prüfung auf Qualität und Kompatibilität, keine Garantie. Der Entwickler kann Tools nach der Prüfung ändern.

Funktionieren claude.ai-Connectoren in Claude Code auf Bedrock?

Nein. Claude Code holt claude.ai-Connectoren nur bei Anmeldung mit einem claude.ai-Abo. Mit Bedrock, Google Cloud oder einem API-Schlüssel werden sie nicht geladen. Server konfigurieren Sie dann über .mcp.json, den User-Scope oder verwaltete Dateien.

Kann ich einen Server über seinen Namen sperren?

Ja, aber das ist keine Sicherheitskontrolle. Der Name ist ein Label, das der Nutzer vergibt, also kann er jeden Server umbenennen. Sperren und erlauben Sie entfernte Server über serverUrl und stdio-Server über den exakten serverCommand.

Macht OAuth einen entfernten MCP-Server sicher?

OAuth macht Zugriffe zuordenbar und widerrufbar, was statische Schlüssel nicht leisten. Gegen Prompt Injection oder ein bösartiges Tool hilft es nicht. Kombinieren Sie OAuth mit minimalen Scopes, an einen Server gebundenen Tokens, geprüfter Tool-Liste und Einzelfreigabe für schreibende Aktionen.

Quellen

1. Claude Code Docs: MCP-Server anbinden (1. Oktober 2026)
2. Claude Code Docs: MCP-Zugriff für die Organisation steuern (1. Oktober 2026)
3. Claude Code Docs: Sicherheit (1. Oktober 2026)
4. Claude Code Docs: Server-Managed-Settings (1. Oktober 2026)
5. Claude Code Docs: Berechtigungen (1. Oktober 2026)
6. Claude Docs: Connector außerhalb des Verzeichnisses hinzufügen (1. Oktober 2026)
7. Claude Docs: Connector-Verifizierung (1. Oktober 2026)
8. Claude Docs: MCP-Tunnel (1. Oktober 2026)
9. Claude Docs: Prüfliste vor der Connector-Einreichung (1. Oktober 2026)
10. MCP-Spezifikation 2026-07-28 (1. Oktober 2026)
11. MCP-Spezifikation: Transporte (1. Oktober 2026)
12. MCP-Spezifikation: Autorisierung (1. Oktober 2026)
13. MCP: Security Best Practices (1. Oktober 2026)
14. Anthropic: Introducing the Model Context Protocol (1. Oktober 2026)
15. Anthropic: MCP an die Agentic AI Foundation übergeben (1. Oktober 2026)