MCP im Unternehmensbetrieb: Welche 5 Freigabegrenzen IT- und Service-Teams vor dem Anschluss interner Systeme ziehen müssen

Viele IT-Organisationen beobachten das Model Context Protocol, kurz MCP, gerade mit einer Mischung aus Neugier und Nervosität. Das ist verständlich. Denn MCP verspricht genau das, was Fachbereiche an generativer KI bisher vermissen: Assistenten sollen nicht nur reden, sondern auf Kalender, Tickets, Dateien, Wikis, Datenbanken oder Automatisierungen zugreifen können. Damit wird aus dem Chatfenster schrittweise eine operative Oberfläche.

Genau darin liegt aber auch die eigentliche Managementaufgabe. Mit MCP wächst nicht nur der Nutzen, sondern vor allem die Reichweite von KI-Systemen. Die Frage lautet 2026 deshalb nicht mehr, ob ein Modell gute Antworten formuliert. Entscheidend ist, welche Systeme es sehen darf, welche Werkzeuge es auslösen kann und welche Grenzen zwischen Lesen, Schreiben und Ausführen sauber gezogen sind.

Die offizielle MCP-Dokumentation beschreibt das Protokoll als offenen Standard, mit dem KI-Anwendungen an externe Datenquellen, Werkzeuge und Workflows angebunden werden. In der Architektur sind dabei Host, Client und Server klar getrennt. Das klingt technisch sauber, darf im Unternehmen aber nicht mit operativer Harmlosigkeit verwechselt werden. Denn jeder zusätzliche MCP-Server erweitert die Angriffs- und Fehlbedienungsfläche.

Für IT-Leitungen, Service Owner, Informationssicherheit und Plattformteams sind deshalb vor allem fünf Freigabegrenzen wichtig.

1. Nicht „MCP freigeben“, sondern jeden Server und jedes Tool einzeln klassifizieren

Der erste Fehler beginnt schon in der Sprache. In vielen Häusern heißt es derzeit, man wolle „MCP erlauben“ oder „MCP testen“. Genau das ist zu ungenau. Freigegeben wird in der Praxis nie ein Protokoll als Ganzes, sondern immer eine konkrete Kombination aus Host, Server, Tools, Daten und Nutzergruppe.

Die MCP-Architektur erlaubt es einem Host, mehrere Server parallel anzusprechen. Genau deshalb braucht jedes Unternehmen vor der ersten produktiven Nutzung eine kleine, aber verbindliche Klassifikation. Welche Server liefern nur Lesedaten, etwa aus einer Wissensdatenbank? Welche dürfen Tickets anlegen oder ändern? Welche können Dateien schreiben, Shell-Befehle auslösen oder externe APIs anstoßen? Und welche Nutzergruppen dürfen welche Kombinationen überhaupt verwenden?

Praktisch bewährt sich hier ein einfaches Freigabemodell in drei Stufen: rein lesend, schreibend innerhalb definierter Fachobjekte und operativ ausführend. Alles, was über lesenden Zugriff hinausgeht, sollte nicht als Komfortfunktion, sondern als eigener Kontrollbereich behandelt werden. Wer diese Trennung sauber dokumentiert, verhindert später die typische Ausrede, man habe doch „nur einen Assistenten angeschlossen“.

2. Lokale MCP-Server müssen wie ausführbarer Code behandelt werden, nicht wie harmlose Add-ons

Besonders heikel ist der Umgang mit lokalen MCP-Servern. Die VS-Code-Dokumentation warnt sehr deutlich, dass lokale MCP-Server beliebigen Code auf dem eigenen Rechner ausführen können und deshalb nur aus vertrauenswürdigen Quellen eingebunden werden sollten. Genau dieser Hinweis gehört in jede Unternehmensbewertung, denn im Alltag werden lokale Server schnell wie ein normales Plugin missverstanden.

Für den Betrieb heißt das: lokale MCP-Server gehören in denselben Denkrahmen wie Skripte, Entwicklerwerkzeuge oder Admin-Helfer mit echter Maschinenwirkung. Sie brauchen Herkunftsnachweis, Eigentümer, Versionskontrolle und idealerweise einen klaren Installationspfad über Standardarbeitsplätze oder verwaltete Entwicklerumgebungen. Ein Copy-and-paste aus einem Repository oder einer Community-Anleitung reicht nicht.

Ebenso wichtig ist die Frage, auf wessen Rechner der Server läuft. Ein lokaler Filesystem- oder Browser-Server auf einem privilegierten Admin-Arbeitsplatz ist ein anderes Risikoprofil als ein read-only Server in einer isolierten Testumgebung. Unternehmen sollten deshalb nicht nur Servertypen bewerten, sondern auch den Ausführungskontext: Benutzerrechte, Netzwerkreichweite, Zugriff auf Secrets und mögliche Seiteneffekte auf dem Endgerät.

3. Remote-MCP braucht saubere Identität, Autorisierung und Secret-Trennung

Bei Remote-MCP-Servern verschiebt sich das Problem von der lokalen Ausführung zur Identitätsschicht. Die Autorisierungsspezifikation des MCP beschreibt für HTTP-basierte Transporte eine Anbindung an etablierte OAuth-Mechanismen. Zugleich weist sie darauf hin, dass lokale STDIO-Verbindungen ihre Credentials typischerweise aus der Umgebung beziehen. Genau daraus entsteht eine klare Managementregel: lokale und entfernte Verbindungen dürfen nicht in einem gemeinsamen Graubereich betrieben werden.

Praktisch sollten IT-Teams für Remote-MCP mindestens vier Fragen verbindlich beantworten: Welche Identität handelt gegenüber dem Server, also Nutzer, Service Principal oder technischer Agent? Nach welchem Berechtigungsschnitt werden Tokens ausgestellt? Wo werden Secrets oder Token-Reste gespeichert? Und wie schnell lassen sich Zugriffe sperren, wenn ein Server auffällig wird oder ein Client kompromittiert erscheint?

Wer diese Fragen nicht vorab klärt, baut sehr schnell eine schicke Demo mit schlechter Revisionsfähigkeit. Gerade weil MCP den Anschluss an interne Systeme vereinfacht, muss die Berechtigungsseite enger und nicht lockerer werden. Sauber ist ein Modell mit getrennten technischen Identitäten, kurzen Laufzeiten, dokumentierten Scopes und klarer Zuordnung zu einem verantwortlichen Owner pro Server.

4. Schreibende und ausführende Tools brauchen eine andere Governance als lesende Abfragen

Ein häufiger Denkfehler in frühen MCP-Piloten ist die Gleichbehandlung aller Tools. Genau davon sollte man sich lösen. Schon die Tool-Planung in OpenAI- und MCP-nahen Dokumentationen folgt dem Prinzip, Lese- und Schreiboperationen sauber zu trennen. Für den Unternehmensbetrieb ist das mehr als nur Designhygiene. Es ist eine Governance-Frage.

Lesende Tools, etwa für Knowledge Bases, Monitoring-Daten oder Ticket-Abfragen, können oft mit vertretbarem Risiko eingeführt werden. Schreibende Tools, zum Beispiel zum Anlegen von Changes, Aktualisieren von CMDB-Einträgen oder Auslösen von Automationen, brauchen dagegen strengere Regeln. Noch kritischer sind ausführende Tools, die Shell-Befehle, Infrastrukturänderungen oder produktive Transaktionen anstoßen.

Bewährt hat sich hier ein Vierklang: geringstmögliche Rechte, explizite Nutzerbestätigung vor schreibenden Aktionen, protokollierte Parameterübergabe und technische Sperren für Hochrisiko-Aktionen. Ein Assistent darf eben nicht deswegen produktiv eingreifen, weil ein Tool vorhanden ist. Er darf es nur, wenn Freigabe, Kontext und Kontrolle dafür sauber definiert sind. Gerade Service-Organisationen sollten diesen Unterschied in ihre Standard-Changes, Runbooks und Tool-Abnahmen übernehmen.

5. Prompt Injection, Output-Risiken und Logging müssen Teil des Betriebsmodells sein

Wer MCP nur als Integrationsfrage betrachtet, unterschätzt die Sicherheitsseite. OWASP führt Prompt Injection und Improper Output Handling weiter als zentrale Risiken für GenAI-Anwendungen. Das ist für MCP unmittelbar relevant. Sobald ein Modell externe Inhalte aus Dateien, Webseiten, Wikis oder Tickets verarbeitet und anschließend Werkzeuge ansteuern darf, steigt das Risiko, dass manipulierte Inhalte zu ungewollten Aktionen führen oder Ausgaben unkontrolliert in Drittsysteme gelangen.

Für die Praxis bedeutet das dreierlei. Erstens sollten Unternehmen nie davon ausgehen, dass ein interner Datenbestand automatisch vertrauenswürdig ist. Auch interne Wikis, PDFs, Ticketkommentare oder Quelltexte können schädliche Instruktionen enthalten. Zweitens dürfen LLM-Ausgaben nicht blind an nachgelagerte Systeme übergeben werden. OWASP empfiehlt hier ausdrücklich einen Zero-Trust-Blick auf Modell-Outputs, also Validierung, Sanitizing und kontextbezogene Absicherung. Drittens braucht der Betrieb nachvollziehbare Logs: welcher Host hat welchen Server genutzt, welches Tool wurde mit welchen Parametern aufgerufen und welche Wirkung trat ein?

Genau an diesem Punkt wird der NIST AI Risk Management Framework praktisch. NIST betont, dass Organisationen vertrauenswürdige KI nicht abstrakt versprechen, sondern Risiken entlang ihrer Ziele, Prioritäten und Nutzungskontexte steuern müssen. Für MCP heißt das: keine Freigabe ohne Logging, keine Anbindung ohne Incident-Pfad und keine produktive Tool-Kette ohne überprüfbaren Fallback.

Fazit

MCP ist 2026 keine Spielerei mehr, sondern ein echter Betriebshebel für interne KI-Assistenten. Gerade deshalb reicht es nicht, das Thema an Entwicklerteams oder einzelne Innovationseinheiten zu delegieren. Entscheidend sind klare Freigabegrenzen: pro Server und Tool statt pauschal, lokale Server wie ausführbarer Code, Remote-Zugriffe mit sauberer Identität, schreibende Aktionen mit eigener Governance und ein Betriebsmodell, das Prompt-Injection-, Output- und Logging-Risiken ernst nimmt.

Wer diese fünf Grenzen vor dem Rollout festzieht, gewinnt mehr als Sicherheit. Er schafft die Voraussetzung dafür, dass KI-Assistenten im Unternehmen nicht nur beeindruckend aussehen, sondern belastbar, prüfbar und im Alltag tatsächlich steuerbar bleiben.

Quellen

• Model Context Protocol: Introduction
• Model Context Protocol: Architecture Overview
• Model Context Protocol Specification: Authorization
• Visual Studio Code: Add and manage MCP servers
• NIST: AI Risk Management Framework
• OWASP GenAI Security Project: Prompt Injection
• OWASP GenAI Security Project: Improper Output Handling