Model Context Protocol (MCP) im Unternehmen sicher einsetzen

Kurzantwort: Was ist MCP – und was löst es nicht?

Das Model Context Protocol (MCP) ist ein offener Standard, über den eine KI-Anwendung Funktionen, Datenquellen und vorbereitete Anweisungen eines Servers entdecken und verwenden kann. Ein MCP-Server kann beispielsweise Werkzeuge zum Suchen eines Auftrags, Lesen einer Rechnung oder Speichern eines Antwortentwurfs bereitstellen. Der Client vermittelt diese Funktionen an das Sprachmodell und führt erlaubte Aufrufe aus.

MCP vereinheitlicht damit die technische Verständigung. Es ist jedoch weder ein Rollenmodell noch eine Prozessfreigabe. Der Protokollstandard kennt nicht automatisch Ihre Mandantengrenzen, Zeichnungsregeln, Löschverbote oder Vier-Augen-Prüfungen. Diese Kontrollen müssen MCP-Server, Integrationsschicht und Fachsystem weiterhin technisch erzwingen.

Stand 14. September 2026 ist die Spezifikation 2026-07-28 die aktuelle veröffentlichte Fassung. Sie stellt den HTTP-Betrieb auf zustandslose Anfragen um, ergänzt klarere Routinginformationen und härtet die Autorisierung. Diese Änderungen erleichtern den skalierbaren Betrieb, ersetzen aber keine eigene Risiko- und Berechtigungsarchitektur.

MCP, direkte API oder Workflow: zuerst den richtigen Integrationsweg wählen

MCP ist sinnvoll, wenn mehrere KI-Anwendungen auf einen kontrollierten Katalog wiederverwendbarer Werkzeuge zugreifen sollen oder wenn Tools dynamisch entdeckt werden müssen. Ein standardisierter Server kann dann dieselbe fachliche Funktion verschiedenen kompatiblen Clients anbieten, ohne jede Verbindung neu zu entwerfen.

Für eine einzelne stabile Integration bleibt eine direkte API oft einfacher. Muss ein Ablauf immer dieselben Schritte und Freigaben durchlaufen, eignet sich ein deterministischer Workflow besser als eine freie Tool-Auswahl durch ein Modell. In vielen Unternehmensprozessen ist die belastbarste Lösung hybrid: Der Agent interpretiert den Vorgang und schlägt eine Aktion vor; ein Workflow prüft Regeln und vollzieht die verbindliche Änderung.

• MCP: mehrere Clients, wechselnde Tool-Kataloge oder standardisierte Agentenintegrationen
• direkte API: ein klarer Verbraucher, festes Datenmodell und geringe Integrationsbreite
• Workflow: feste Reihenfolge, verbindliche Regeln und reproduzierbare Zustandsübergänge
• hybrid: KI plant oder klassifiziert, Prozesslogik autorisiert und schreibt ins Zielsystem

Vier Vertrauensgrenzen statt einer vermeintlich direkten Verbindung

Eine produktive MCP-Verbindung besteht mindestens aus vier Rollen: der handelnden Person oder einem auslösenden Prozess, der KI-Anwendung als Host, dem MCP-Server und dem nachgelagerten Fachsystem. Jede Rolle verarbeitet andere Informationen und benötigt eine eigene Sicherheitsentscheidung. Ein erfolgreicher Login im KI-Client darf deshalb nicht automatisch Vollzugriff auf ERP, CRM oder DMS bedeuten.

Zeichnen Sie den vollständigen Daten- und Befehlsweg auf. Dazu gehören Aufruf, Parameter, Modellkontext, Serverprotokoll, nachgelagerte API, Rückgabe und mögliche Speicherung. Erst dieses Bild zeigt, wo personenbezogene Daten, Geschäftsgeheimnisse und schreibende Aktionen tatsächlich die Grenze eines Systems überschreiten.

• Auslöser: Wer startet den Vorgang und in wessen Auftrag wird gehandelt?
• Host und Client: Welche Server und Tools darf die KI-Anwendung verbinden?
• MCP-Server: Welche Parameter, Rechte und Geschäftsregeln werden geprüft?
• Zielsystem: Welche Identität führt die Aktion aus und bestätigt deren Wirkung?

Identität und Autorisierung an jeder Grenze neu prüfen

Für entfernte HTTP-Verbindungen beschreibt MCP einen OAuth-basierten Autorisierungsablauf. Die aktuelle Spezifikation verlangt unter anderem, Zugriffstoken für den vorgesehenen MCP-Server zu prüfen. Die Sicherheitsdokumentation verbietet Token-Passthrough: Ein Server darf ein fremdes Zugriffstoken nicht ungeprüft an das Zielsystem weiterreichen. Andernfalls verschwimmen Zielgruppe, Verantwortlichkeit und Protokollspur.

Trennen Sie daher das Token vom Client zum MCP-Server von der Berechtigung des Servers am ERP, CRM oder DMS. Der Server ermittelt aus geprüfter Identität, delegiertem Auftrag und Fachregel den kleinsten erlaubten Zugriff. Kurzlebige, zweck- und zielgebundene Berechtigungen begrenzen den Schaden; geteilte API-Schlüssel und dauerhafte Administrationsrechte verhindern eine verlässliche Zuordnung.

Die Spezifikation 2026-07-28 stärkt unter anderem die Prüfung des Ausstellers im Autorisierungsfluss und bindet Client-Zugangsdaten an den ausstellenden Server. Für zentral verwaltete Umgebungen existiert außerdem eine stabile Erweiterung zur unternehmensgesteuerten Autorisierung. Ob diese Mechanismen im eingesetzten Client und Server tatsächlich unterstützt und korrekt konfiguriert sind, muss vor der Freigabe geprüft werden.

MCP-Tools als fachliche Verträge gestalten

Ein Tool-Name und eine JSON-Struktur sind noch kein sicherer Vertrag. Definieren Sie für jedes Werkzeug Zweck, zulässige Eingaben, Datenbereich, Wirkung, Fehlerzustände und erforderliche Freigabe. Aus einem offenen Werkzeug wie „SQL ausführen“ werden beispielsweise getrennte Funktionen zum Suchen eines Auftrags, Lesen freigegebener Felder und Speichern eines Entwurfs.

Die aktuelle MCP-Spezifikation verlangt bei Tools eine Eingabestruktur und erlaubt strukturierte Ausgaben. Nutzen Sie diese Formate für strenge Validierung, nicht nur als Hinweis an das Modell. Mandant, Datensatz, Betragsgrenze, Empfänger, Status und erlaubte Werte werden serverseitig geprüft. Schreibende Werkzeuge benötigen eindeutige Vorgangs- und Aktionsschlüssel, damit ein Wiederholungsversuch nicht dieselbe Buchung oder Nachricht doppelt ausführt.

• lesen, vorbereiten, kommunizieren, verändern und löschen als getrennte Werkzeuge
• Parameter auf Typ, Wertebereich, Mandant, Ziel und maximale Datenmenge prüfen
• Autorisierung unmittelbar vor der Ausführung erneut bewerten
• Wirkung durch bestätigte Antwort des Zielsystems statt nur durch Tool-Erfolg belegen
• Version, Besitzer und Änderungsverlauf jedes Tool-Vertrags dokumentieren

Tool-Beschreibungen und Inhalte als nicht vertrauenswürdige Eingaben behandeln

Ein Agent kann manipulierte Anweisungen aus E-Mails, Dokumenten, Webseiten oder Tool-Rückgaben aufnehmen. Bei MCP kommt eine weitere Oberfläche hinzu: Auch Server- und Tool-Beschreibungen beeinflussen, welches Werkzeug ein Modell auswählt und mit welchen Erwartungen es den Aufruf vorbereitet. Ein neu verbundener oder veränderter Server ist deshalb eine Code- und Konfigurationsänderung, keine harmlose Inhaltsquelle.

Client und Server müssen Berechtigungen außerhalb des Modells erzwingen. Externe Inhalte dürfen weder zusätzliche Tools aktivieren noch Empfänger, Mandanten oder Datenbereiche erweitern. Erlaubte Server, Tool-Versionen, Ziel-Domains und Aktionen gehören auf Positivlisten. Änderungen am Tool-Katalog werden geprüft und freigegeben, bevor sie produktiv im Modellkontext erscheinen.

• Server nur aus geprüftem Inventar verbinden und Konfiguration gegen unbemerkte Änderungen schützen
• Tool-Beschreibungen, Schemas und Versionen vor Nutzung fachlich und technisch prüfen
• eingelesene Inhalte klar als Daten kennzeichnen und von Systemanweisungen trennen
• Datenabfluss, unerlaubte Tool-Ketten und manipulierte Rückgaben gezielt testen
• nachgelagerte APIs als letzte Autorisierungsgrenze beibehalten

Freigaben an der Wirkung platzieren

Eine Bestätigung ist nur wirksam, wenn die prüfende Person die konkrete Aktion versteht. Zeigen Sie deshalb Quelle, Ziel, betroffene Daten, geplante Änderung und mögliche Folge unmittelbar vor der Ausführung. Ein pauschales „Tool erlauben?“ ohne Parameter und Wirkung erzeugt keine belastbare Kontrolle.

Die 2026-07-28-Spezifikation kann fehlende Eingaben oder eine Bestätigung innerhalb eines laufenden Aufrufs über Multi Round-Trip Requests anfordern. Das schafft einen technischen Transport für Rückfragen. Welche Aktionen zwingend freigegeben werden, wer freigeben darf und welche Werte danach unveränderlich bleiben, definiert weiterhin der Geschäftsprozess.

• Entwürfe und lesende Abfragen können innerhalb enger Grenzen automatisch laufen
• externe Kommunikation benötigt Empfänger-, Inhalts- und Anhangskontrolle
• Bestellungen, Zahlungen, Löschungen und Rechteänderungen verlangen eine starke Freigabe
• nach der Freigabe dürfen Ziel, Betrag und kritische Parameter nicht still verändert werden

Lokale und entfernte MCP-Server unterschiedlich absichern

Ein lokaler Server ist nicht automatisch sicherer. Er kann mit den Rechten des aufrufenden Prozesses auf Dateien, Umgebungsvariablen und lokale Programme zugreifen. Die offizielle MCP-Sicherheitsdokumentation empfiehlt deshalb sichtbare Zustimmung vor der Ausführung, minimale Standardrechte und eine Sandbox mit begrenztem Datei- und Netzwerkzugriff.

Ein entfernter Server ist dagegen ein gewöhnlicher Netzwerkdienst mit zusätzlicher Tool-Bedeutung. Er benötigt HTTPS, sauber geprüfte Autorisierungsendpunkte, Netzwerkkontrollen, Rate Limits, Mandantentrennung und Betriebsüberwachung. Die zustandslose HTTP-Architektur der aktuellen Spezifikation erleichtert Lastverteilung; fachlichen Zustand wie eine Vorgangs-ID muss der Server trotzdem sicher an Nutzer und Berechtigung binden.

Datenminimierung und Nachweis gemeinsam planen

Der MCP-Server sollte nur die Daten zurückgeben, die der nächste Schritt benötigt. Ein Werkzeug zur Auftragsprüfung braucht beispielsweise nicht automatisch alle Kundennotizen oder Dokumentanhänge. Filterung und Feldfreigabe erfolgen serverseitig, bevor Informationen in den Modellkontext gelangen.

Für den Nachweis verbinden Sie Vorgangs-ID, Nutzer- und Clientidentität, Server- und Tool-Version, geprüfte Parameter, Freigabe, Zielsystemantwort und fachliche Wirkung. Vollständige Prompts, Dokumente oder Zugangsdaten gehören nicht pauschal in technische Protokolle. Legen Sie Zweck, Zugriff und Aufbewahrung für jedes Log fest und schützen Sie es vor unbemerkter Veränderung.

Vier Anwendungsszenarien mit sinnvollen MCP-Grenzen

Im ERP kann ein MCP-Tool freigegebene Aufträge suchen und Buchungsvorschläge vorbereiten. Die endgültige Buchung bleibt ein separates Werkzeug mit enger Rolle, Zustandsprüfung und Freigabe. Eine allgemeine Datenbankabfrage wird nicht angeboten.

Im DMS kann ein Tool Dokumente anhand einer Vorgangs-ID abrufen und zulässige Metadaten zurückgeben. Export, Löschung und Änderung von Aufbewahrungsmerkmalen bleiben getrennt. So wird aus „Dokumente finden“ kein unbemerkter Massenabzug.

Im CRM kann ein Agent Gesprächskontext lesen und einen Aktivitätsentwurf speichern. Das Ändern von Stammdaten oder Versenden einer Nachricht erfolgt über eigene Tools mit Empfänger- und Feldprüfung. Die CRM-Berechtigung der delegierenden Person begrenzt die Auswahl zusätzlich.

In E-Mail- und Serviceprozessen kann ein Server Klassifikation, Vorgangssuche und Antwortentwurf bereitstellen. Anhänge, externe Links und Nachrichtentext gelten als nicht vertrauenswürdig. Der Versandpfad validiert Domain, Empfänger, sensible Daten und erforderliche Freigabe unabhängig vom Modell.

MCP-Server in sieben Schritten produktiv einführen

Behandeln Sie einen MCP-Server wie eine produktive Integrationskomponente. Verantwortliche aus Fachbereich, IT und Sicherheit prüfen nicht nur, ob ein Tool funktioniert, sondern auch seine Wirkung bei falschen, unvollständigen und manipulierten Eingaben. Der erste Pilot bleibt lesend oder erzeugt nur Entwürfe.

Erst nach bestandenen Normal-, Grenz- und Angriffsfällen wird eine kleine schreibende Funktion freigegeben. Neue Tools, geänderte Beschreibungen, zusätzliche Datenquellen, andere Identitätsflüsse oder eine neue Protokollversion lösen denselben Änderungsprozess aus. Eine zentrale Sperrmöglichkeit muss Server, Token und laufende Jobs kontrolliert stoppen können.

• 1. inventarisieren: Besitzer, Zweck, Client, Server, Zielsystem und Datenklassen erfassen
• 2. abgrenzen: erlaubte Tools, Nicht-Ziele, Rechte, Mandanten und Freigabeschwellen festlegen
• 3. prüfen: Quelle, Abhängigkeiten, Startbefehl, Netzwerkziele und Tool-Verträge bewerten
• 4. testen: normale, fehlerhafte, wiederholte und manipulierte Aufrufe abdecken
• 5. pilotieren: read-only oder Entwurfsmodus mit begrenzten Nutzern und Daten einsetzen
• 6. betreiben: Logs, Fehlerraten, Tool-Nutzung, Rechte und Änderungen überwachen
• 7. beenden: Tokens sperren, Server entfernen, offene Jobs schließen und Nachweise erhalten

Datenschutz und AI Act am Einsatzfall bewerten

MCP ist eine technische Schnittstelle und keine eigene Rechtskategorie. Werden personenbezogene Daten über Client, Server, Modellanbieter oder Zielsystem verarbeitet, müssen Zweck, Rechtsgrundlage, Rollen, Empfänger, Datenminimierung, Speicherorte und Betroffenenrechte den gesamten Datenfluss abdecken. Bei voraussichtlich hohem Risiko ist vor dem Einsatz eine Datenschutz-Folgenabschätzung zu prüfen.

Auch der AI Act knüpft nicht an das Protokoll allein an. Maßgeblich sind Rolle, vorgesehener Zweck und Einsatzgebiet des konkreten KI-Systems. Protokoll- und Tool-Inventar helfen bei technischer Dokumentation und Änderungssteuerung, ersetzen aber keine rechtliche Einordnung. Dieser Beitrag bietet eine fachlich-technische Orientierung und keine Rechtsberatung im Einzelfall.

Der kompakte MCP-Betriebscheck

Ein erfolgreicher Verbindungsaufbau belegt nur technische Kompatibilität. Vor dem produktiven Einsatz sollte jede beteiligte Stelle bestätigen können, dass Identität, Wirkung, Ausnahmen und Abschaltung auch außerhalb einer Demo beherrscht werden.

• Ist für jeden Server ein fachlicher und technischer Besitzer benannt?
• Sind Nutzer, Client, MCP-Server und Zielsystem als getrennte Identitäten nachvollziehbar?
• Erhält jedes Tool nur die kleinsten notwendigen Daten und Rechte?
• Prüfen Server und Zielsystem Mandant, Parameter, Zustand und Freigabe selbst?
• Wurden Prompt Injection, Tool-Manipulation, Datenabfluss und Doppelaufrufe getestet?
• Sind Protokolle, Aufbewahrung, Monitoring, Alarmierung und Not-Aus eingerichtet?
• Lösen Server-, Tool-, Rechte- und Protokolländerungen eine erneute Prüfung aus?