MCP im Unternehmen: Model Context Protocol, Spezifikation 2026-07-28 und Sicherheit

KI-Agenten an Ticketsystem, Wiki oder ERP anbinden, mit klaren Rechten? WZ-IT baut Agenten und interne Assistenten auf eigener Infrastruktur: Werkzeugkatalog statt Vollzugriff, delegierte Identitäten, Freigaben für kritische Schritte und Protokollierung jedes Laufs. KI-Agenten ansehen · Interne KI-Assistenten · Termin vereinbaren

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen Werkzeuge und Datenquellen ansprechen. Ein einmal gebauter MCP-Server für ein Ticketsystem funktioniert in jedem Client, der MCP spricht, und überlebt den Wechsel des Sprachmodells. Für Unternehmen ist MCP damit eine Integrationsschicht, und wie jede Integrationsschicht eine Frage von Identität, Rechten und Angriffsfläche. Dieser Artikel erklärt Aufbau und Transporte, fasst die Spezifikation 2026-07-28 zusammen, ordnet die Autorisierung ein und beschreibt Risiken und Betrieb mit lokalen Modellen. Stand Oktober 2026.

Inhaltsverzeichnis

• Was MCP ist: Host, Client, Server
• Transporte: stdio und Streamable HTTP
• Spezifikation 2026-07-28: was sich geändert hat
• Autorisierung: OAuth 2.1 und Identity Provider
• MCP mit lokalen Modellen und Open WebUI
• Risiken: Tool Poisoning, stdio und Token
• Rechte und Freigaben im Betrieb
• Wann MCP sinnvoll ist und wann eine API reicht

Was MCP ist: Host, Client, Server

MCP ist ein offenes Protokoll auf Basis von JSON-RPC 2.0. Die Spezifikation nennt das Language Server Protocol als Vorbild: So wie LSP Programmiersprachen einheitlich an Editoren anbindet, bindet MCP Werkzeuge und Kontext einheitlich an KI-Anwendungen an (MCP-Spezifikation 2026-07-28). Anthropic hat das Protokoll am 25. November 2024 veröffentlicht und am 9. Dezember 2025 als Gründungsprojekt in die Agentic AI Foundation der Linux Foundation eingebracht.

Ein Server bietet drei Arten von Fähigkeiten an:

Der Nutzen liegt in der Entkopplung. Ohne Standard braucht jede Kombination aus KI-Anwendung und Zielsystem eine eigene Anbindung. Mit MCP schreibt man den Server einmal, und jeder MCP-fähige Host kann ihn nutzen. Das Sprachmodell selbst spricht kein MCP: Der Host übersetzt die Tool-Liste in die Tool-Calling-Schnittstelle des Modells und führt die Aufrufe aus.

Transporte: stdio und Streamable HTTP

Die Spezifikation definiert zwei Standard-Transporte (MCP, Transports). Die Wahl entscheidet über Betriebsmodell und Angriffsfläche.

Für Streamable HTTP schreibt die Spezifikation vor, dass Server den Origin-Header prüfen und bei ungültigem Wert mit 403 antworten, um DNS-Rebinding zu verhindern. Lokal laufende Server sollen nur auf 127.0.0.1 lauschen, nicht auf allen Schnittstellen (MCP, Streamable HTTP). Der ältere Transport HTTP+SSE aus der Version 2024-11-05 ist deprecated und soll migriert werden.

Im Unternehmen ist Streamable HTTP der Normalfall für gemeinsam genutzte Server: ein Dienst, eine Identität, zentrale Protokollierung. stdio passt für Entwickler-Werkzeuge auf dem eigenen Rechner.

Spezifikation 2026-07-28: was sich geändert hat

Die Revision 2026-07-28 ist am 28. Juli 2026 erschienen und löst 2025-11-25 ab (Ankündigung, Changelog). Sie baut MCP von einem zustandsbehafteten zu einem zustandslosen Request-Response-Protokoll um.

Für Betreiber ist der Wegfall der Sessions die folgenreichste Änderung. Ein MCP-Server, der bisher Zustand an eine Session gebunden hat, muss ihn künftig über Handles abbilden. Die Sicherheitsleitlinien halten dazu fest, dass der Besitz eines Handles nie als Authentifizierung gelten darf und Handles serverseitig an den authentifizierten Benutzer gebunden werden sollen. Die offiziellen SDKs für TypeScript, Python, Go und C# unterstützen die neue Version laut Ankündigung, das Rust-SDK als Beta. Clients, die ältere Server weiter unterstützen sollen, können die Generation des Gegenübers erkennen und auf den bisherigen Handshake zurückfallen.

Autorisierung: OAuth 2.1 und Identity Provider

Autorisierung ist in MCP optional. Wo ein HTTP-basierter Server sie umsetzt, folgt sie einem OAuth-2.1-Profil (MCP, Authorization). Der MCP-Server ist dabei Resource Server, der Host der OAuth-Client, das Token stellt ein Autorisierungsserver aus, im Unternehmen typischerweise der vorhandene Identity Provider wie Keycloak.

Die Issuer-Prüfung ist bewusst abgestuft: Kündigt ein Autorisierungsserver iss in seinen Metadaten an und fehlt der Wert in der Antwort, muss der Client sie verwerfen. Ein künftiges Upgrade von SHOULD auf MUST für die Server ist in der Spezifikation angekündigt (RFC 9207).

Für den Unternehmensbetrieb ergeben sich drei Punkte. Erstens sollten Scopes eng geschnitten sein: Die Sicherheitsleitlinien nennen Wildcard-Scopes und das Veröffentlichen aller Scopes in scopes_supported ausdrücklich als Fehler und empfehlen schrittweise Erweiterung per Step-up. Zweitens ist die Vorab-Registrierung im eigenen Identity Provider oft kontrollierter als offene Registrierungswege, weil nur bekannte Clients Tokens erhalten. Drittens braucht ein MCP-Server, der ein Drittsystem im Namen des Benutzers anspricht, ein eigenes Token für dieses System. Das Benutzer-Token des MCP-Servers weiterzureichen, ist genau der verbotene Token Passthrough.

MCP mit lokalen Modellen und Open WebUI

MCP hängt nicht an einem Modellanbieter. Voraussetzung ist ein Modell, das Tool Calling zuverlässig beherrscht, und ein Inferenz-Server, der die Tool-Schnittstelle bereitstellt. Open WebUI formuliert die Grenze klar: MCP verbindet die Oberfläche mit Werkzeugen, es verbessert nicht die Fähigkeit des Modells, sie zu benutzen (Open WebUI, MCP).

Ein typischer Aufbau mit lokalen Modellen: Das Modell läuft in vLLM oder Ollama, LiteLLM bündelt Modellzugänge und MCP-Server, Open WebUI ist die Oberfläche, der Identity Provider liefert die Benutzeridentität. MCP-Server laufen als eigene Container mit Streamable HTTP im internen Netz. Welche Modelle für Tool Calling auf eigener Hardware in Frage kommen, behandelt Welches LLM selbst hosten?, wie LiteLLM als Gateway arbeitet, Was ist LiteLLM?.

Ein Gateway zentralisiert Zugriffe, und damit auch das Risiko. Wer das Gateway übernimmt, erreicht alle angebundenen Server. Die Lücke GHSA-7hp6-4w63-5g45 in LiteLLM (veröffentlicht am 30. September 2026, CVSS 9.9) erlaubt einem einfachen Benutzer die Eskalation zum Proxy-Admin und darüber Befehlsausführung über den MCP-stdio-Endpunkt. Betroffene Versionen und Härtung beschreibt der Beitrag LiteLLM-Sicherheitslücke: Gateway absichern.

Risiken: Tool Poisoning, stdio und Token

Die Spezifikation hält selbst fest, dass Tools beliebige Codeausführung darstellen und Beschreibungen nicht vertrauenswürdiger Server als untrusted zu behandeln sind (MCP-Spezifikation, Security and Trust & Safety). Die wichtigsten Angriffswege:

Im Betrieb kommt ein weiterer Punkt hinzu: die Bündelung von Zugangsdaten. Ein MCP-Server für fünf Systeme hält fünf Sätze Zugangsdaten. Die Sicherheitsleitlinien beschreiben das Folgerisiko für Tokens, die mehrere Dienste akzeptieren: Wer einen Dienst kompromittiert, erreicht die anderen mit. Ein MCP-Server gehört deshalb in dieselbe Schutzklasse wie das sensibelste System, das er erreicht.

Wie sich indirekte Prompt Injection über Dokumente, E-Mails und Tool-Ergebnisse architektonisch begrenzen lässt, beschreibt Schutz vor Prompt Injection.

Rechte und Freigaben im Betrieb

MCP standardisiert den Zugriffsweg, nicht die Berechtigung. Wer welche Werkzeuge nutzen darf, entscheiden Katalog, Identity Provider und Zielsystem. Die Spezifikation empfiehlt für Tools ausdrücklich einen Menschen in der Schleife, der Aufrufe ablehnen kann, sowie Bestätigungsdialoge für sensible Operationen (MCP, Tools). Für den Unternehmenseinsatz ergibt sich daraus eine Prüfliste:

Die Grundlagen dazu, also welche Identität ein Agent im Zielsystem nutzt und welche Schritte eine Freigabe brauchen, behandelt KI-Agenten: Rechte und Freigaben. Wo RAG und Werkzeuge auf dieselben Daten zugreifen, gelten dieselben Regeln wie bei RAG mit Berechtigungen: Rechte werden vor dem Zugriff geprüft, nicht im Nachgang gefiltert.

Wann MCP sinnvoll ist und wann eine API reicht

MCP ist eine zusätzliche Schicht. Sie lohnt sich, wenn mehrere Anwendungen dieselben Werkzeuge nutzen oder wenn die Anbindung einen Modell- oder Frontend-Wechsel überdauern soll.

Wann ein Agent statt eines festen Workflows überhaupt sinnvoll ist, ordnet KI-Agenten und Automatisierung ein. Einen Vergleich der Frameworks aus Betreibersicht, einschließlich MCP-Unterstützung, enthält der Beitrag KI-Agenten-Frameworks im Vergleich.

Was das für Ihr Projekt heißt

MCP ist inzwischen eine verbreitete Schnittstelle zwischen KI-Anwendungen und Unternehmenssystemen, und mit der Revision 2026-07-28 auch betrieblich reifer: zustandslos, routbar über Header, mit strengeren OAuth-Vorgaben. Die Sicherheitsfragen bleiben dieselben wie bei jeder Integration, nur gebündelt: Wer darf was, unter welcher Identität, und wer sieht es im Nachhinein.

WZ-IT bindet freigegebene MCP-Server und vorhandene APIs mit begrenzten Rechten und dokumentierten Datenflüssen an KI-Agenten und interne Assistenten an. Die Basis bilden Open WebUI, LiteLLM, Langfuse und der vorhandene Identity Provider. Die Modelle laufen lokal auf dem AI Cube oder auf Managed GPU-Servern von WZ-IT mit NVIDIA RTX PRO 4000 Blackwell (24 GB) oder RTX PRO 6000 Blackwell Max-Q (96 GB). Support, Beratung und Implementierung durch WZ-IT.

Wie der übrige Stack aufgebaut ist, zeigt Open-Source-LLM-Stack. Wie lokale KI-Dienste sicher von außen erreichbar werden, beschreibt Lokale KI sicher von außen bereitstellen.