Praxisleitfaden

MCP-Server sicher einrichten

Ziel ist es, einen begrenzten MCP-Server für einen konkreten Zweck aufzubauen. Dokumentiert werden folgende Prüfpunkte: minimale Tools, klare Schemas, Authentifizierung, Logging und Tests.

WERKVERSTAND / INTELLIGENZ VERBINDEN

Auf den Punkt

Ein betrieblicher MCP-Server braucht einen engen Zweck, ein überprüfbares Werkzeugangebot und passende Zugriffsgrenzen. Wählen Sie zuerst lokalen STDIO-Betrieb oder einen HTTP-Dienst. Authentifizierung, Geheimnisse und Rechte werden für diesen Transport und die nachgelagerten Systeme konkret eingerichtet und getestet.

01 / FIT

Geeignet, wenn

  • Ein konkreter Arbeitsauftrag und ein fachlicher Verantwortlicher sind benannt.
  • Die Abnahme zeigt einen erlaubten Tool-Aufruf, einen verweigerten unzulässigen Zugriff und einen wirksamen Widerruf im gewählten Transport. Die Fehlerausgabe enthält keine Geheimnisse.

02 / GRENZEN

Nicht die erste Wahl, wenn

  • Zu vermeiden: universelle Toolrechte und ungefilterte Fehlermeldungen. Ein Server mit universellen Rechten oder ungefilterten Fehlerausgaben ist durch eine erfolgreiche Verbindung allein nicht hinreichend eingegrenzt.

Transport und Betriebsort festlegen

Ein STDIO-Server läuft als lokaler Prozess; ein HTTP-Server wird über eine Adresse erreicht. Die MCP-Autorisierungsspezifikation beschreibt HTTP. Für STDIO sieht sie stattdessen die Bereitstellung von Zugangsdaten über die Umgebung vor. Das ist kein Freibrief für breite Prozessrechte. Dokumentieren Sie, wer den Prozess startet, welche Umgebung er erhält und welche Dateien oder Dienste erreichbar sind.

Authentifizierung an der richtigen Stelle durchsetzen

Bei einem geschützten HTTP-Server prüfen Sie die vorgesehene Autorisierung und die für diesen Server ausgestellten Tokens. Tokens für einen anderen Dienst dürfen nicht einfach übernommen oder durchgereicht werden. Für die eigentliche Fachanwendung kommen eigene Rechte hinzu. Ein akzeptierter Login ist daher nur ein Teil des Nachweises: Der konkrete Tool-Aufruf muss ebenfalls zum zugelassenen Scope passen.

Erlaubten Zugriff, Ablehnung und Widerruf testen

Beginnen Sie beispielsweise mit einer Suchfunktion statt einer universellen Verwaltungsfunktion. Prüfen Sie gültige Eingaben, falsche Parameter, fehlende Rechte und einen entzogenen Zugang. Fehlermeldungen dürfen keine Schlüssel oder unnötigen Quelldaten ausgeben. Der Betreiber erhält eine kurze Dokumentation zu Version, Updateweg und Abschaltung. Eine erfolgreiche Verbindung allein ist keine Betriebsabnahme.

Entscheidungsmatrix

PrüfpunktWeiter, wennStoppen, wenn
Zugriff und DatenwegDokumentiert: minimale Tools, klare Schemas, Authentifizierung, Logging und Tests.Scope, Daten oder Verantwortung sind noch ungeklärt.
Verbindung im TestDie Abnahme zeigt einen erlaubten Tool-Aufruf, einen verweigerten unzulässigen Zugriff und einen wirksamen Widerruf im gewählten Transport. Die Fehlerausgabe enthält keine Geheimnisse.Es liegt nur eine unbewertete Demo ohne Abnahmenachweis vor.
Externe WirkungOwner, Freigabe, Ersatzweg und nächster Prüftermin sind festgelegt.Zu vermeiden: universelle Toolrechte und ungefilterte Fehlermeldungen. Ein Server mit universellen Rechten oder ungefilterten Fehlerausgaben ist durch eine erfolgreiche Verbindung allein nicht hinreichend eingegrenzt.

Nachvollziehbar bleiben

Primärquellen

Nächster sinnvoller Schritt

Welches KI-System passt zu Ihrem Betrieb?

In acht Schritten vom allgemeinen KI-Interesse zu einer klareren Entscheidung für Ihren Betrieb.

KI-Systemcheck starten
KostenlosAnbieterneutralKeine Zugangsdaten