Sicherheit von MCP-Servern für ein privates LLM: das Model Context Protocol, OAuth 2.1 und Risiken durch Tools

Was das Model Context Protocol ist und wer es pflegt

Das Model Context Protocol (MCP) ist ein offenes Protokoll, das eine LLM-Anwendung mit Werkzeugen und Daten verbindet. Die Anwendung, in der Terminologie von MCP der Host, betreibt je Server einen MCP-Client, und jeder Server bietet über JSON-RPC 2.0 Tools (Werkzeuge, die das Modell aufrufen kann), Resources (Ressourcen wie Dateien oder Datenbankschemas) und Prompts (Prompt-Vorlagen) an. Stand Oktober 2026 ist 2026-07-28 die aktuelle Revision der Spezifikation. Bei einem privaten LLM verbindet MCP das Modell mit internen Systemen; seine Sicherheit hängt deshalb davon ab, welche Server Sie zulassen und was jeder davon mit wessen Zugangsdaten tun darf.

Anthropic hat MCP eingeführt und am 9. Dezember 2025 angekündigt, das Protokoll an die Agentic AI Foundation zu spenden, nach Anthropics Beschreibung ein zweckgebundener Fonds (Directed Fund) unter dem Dach der Linux Foundation. Die Governance-Seite des Projekts nennt es Model Context Protocol a Series of LF Projects, LLC, mit Lead Maintainern, die die letzte Entscheidungsbefugnis haben, und Core Maintainern, die die Spezifikation steuern. Die Mitgliedschaft ist persönlich und nicht an ein Unternehmen gebunden, und Änderungen an der Spezifikation laufen über Specification Enhancement Proposals (SEPs).

Die Revision 2026-07-28, veröffentlicht am 28. Juli 2026, hat das Protokoll zustandslos gemacht: Der Handshake mit initialize und die Sitzungen auf Protokollebene entfallen, jede Anfrage trägt ihre Protokollversion und die Fähigkeiten des Clients, und Server müssen auf server/discover antworten. Revisionen bis 2025-11-25 nutzen den Handshake; Clients, die auch mit älteren Servern sprechen, beherrschen deshalb beides.

Hosts, Clients und Server: Tools, Resources und Prompts

Tools sind modellgesteuert: Das Modell findet sie und entscheidet, wann es sie aufruft, deshalb sind sie als Erstes einzuschränken. Resources sind anwendungsgesteuert, wobei der Host entscheidet, was in den Kontext gelangt, und Prompts sind nutzergesteuerte Vorlagen, die etwa als Slash-Befehle angeboten werden und deren Inhalt vom Server kommt. Sampling, über das ein Server beim Modell des Clients eine Completion anfordern konnte, ist in der Revision 2026-07-28 als veraltet markiert, ebenso Roots und Logging.

Die Spezifikation legt Grundsätze fest, die MCP selbst nicht durchsetzen kann: Nutzer stimmen allen Datenzugriffen und Operationen zu, Hosts holen vor jedem Tool-Aufruf eine ausdrückliche Zustimmung ein, und Tool-Annotationen gelten als nicht vertrauenswürdig, es sei denn, sie stammen von einem vertrauenswürdigen Server. Ihre Seite zu Tools verlangt „einen in den Ablauf eingebundenen Menschen, der Tool-Aufrufe ablehnen kann“, und Clients sollten die Eingaben eines Tools vor dem Aufruf anzeigen, Ergebnisse vor der Übergabe an das Modell validieren und die Nutzung der Tools protokollieren.

Transporte: stdio für lokale Server, Streamable HTTP für entfernte

Bei stdio (Standardein- und -ausgabe) startet der Client den Server als Unterprozess und tauscht mit ihm durch Zeilenumbrüche getrennte JSON-RPC-Nachrichten über stdin und stdout aus. Der Leitfaden zur Sicherheit lokaler Server auf modelcontextprotocol.io hält fest, dass der Client und ein stdio-Server „sich eine Vertrauensdomäne teilen“: Der Server läuft mit den Rechten des Nutzers, erbt die Umgebungsvariablen, kann SSH-Schlüssel und Cloud-Zugangsdaten lesen und ausgehende Verbindungen zu beliebigen Zielen öffnen. Der Autorisierungsablauf der Spezifikation ist nicht für stdio-Server gedacht, die ihre Zugangsdaten aus der Umgebung beziehen.

Bei Streamable HTTP ist der Server ein eigenständiger Prozess mit einem einzigen Endpunkt, der POST-Anfragen annimmt und mit JSON oder einem Stream aus Server-Sent Events antwortet. Server müssen den Origin-Header zum Schutz vor DNS-Rebinding prüfen, sollten sich bei lokalem Betrieb an 127.0.0.1 binden und sollten alle Verbindungen authentifizieren; der Leitfaden ergänzt, dass die Bindung an 127.0.0.1 keine Authentifizierungsgrenze ist, weil andere lokale Prozesse und über den Browser auch Websites den Port erreichen können. Seit 2026-07-28 gibt es den Header Mcp-Session-Id nicht mehr, und die Header Mcp-Method und Mcp-Name, die Server mit dem Body abgleichen müssen, erlauben es einem Gateway, Aufrufe zu routen und zu untersuchen, ohne den Body zu parsen; ein Gateway, das anhand dieser Header Richtlinien durchsetzt, sollte ältere Protokollversionen ablehnen. Der ältere Transport HTTP+SSE ist als veraltet markiert.

Autorisierung in MCP: OAuth 2.1 und Protected Resource Metadata

Der Abschnitt „Authorization“ der Spezifikation macht die Autorisierung optional und definiert sie für HTTP-basierte Transporte. Wo sie genutzt wird, ist der MCP-Server ein Resource Server nach OAuth 2.1 (die Spezifikation verweist auf draft-ietf-oauth-v2-1-13) und der MCP-Client der OAuth-Client. Jeder solche Server muss OAuth 2.0 Protected Resource Metadata (RFC 9728) veröffentlichen, also Metadaten zur geschützten Ressource, die mindestens einen Autorisierungsserver nennen und im Header WWW-Authenticate einer 401-Antwort oder unter einer Well-known-URI wie /.well-known/oauth-protected-resource bekannt gemacht werden.

Der Client durchläuft den Authorization Code Flow mit PKCE und muss in den Autorisierungs- und Token-Anfragen den Parameter resource (RFC 8707) mit der kanonischen URI des MCP-Servers senden. Der Server muss prüfen, dass jedes Token für ihn ausgestellt wurde, und darf „keine anderen Token annehmen oder weiterreichen“. Ohne Vorregistrierung empfiehlt die Revision 2026-07-28 Client ID Metadata Documents und markiert Dynamic Client Registration (RFC 7591) als veraltet, und Clients müssen einen zurückgegebenen Wert iss mit dem Aussteller abgleichen, den sie gespeichert haben (RFC 9207).

Im Sinne minimaler Rechte nennt der Server in seiner Challenge die Scopes, die ein Vorgang braucht, weist ein Token ohne diese Scopes mit 403 insufficient_scope ab und hält scopes_supported minimal. Für Unternehmen lässt die optionale Erweiterung Enterprise-Managed Authorization den Identity Provider des Unternehmens über einen ID-JAG entscheiden, welche MCP-Server ein Mitarbeiter nutzen darf, sodass Zugriffe zentral erteilt und entzogen werden, wo Clients und Autorisierungsserver das unterstützen.

Sicherheitsempfehlungen für MCP: Confused Deputy, Token Passthrough, SSRF

Die Sicherheitsempfehlungen der Spezifikation (Security Best Practices) für 2026-07-28 beschreiben Angriffe auf MCP-Implementierungen, viele davon in den OAuth-Abläufen. Ein Confused Deputy, also ein Dienst, der seine eigenen Rechte unwissentlich für einen Angreifer einsetzt, entsteht bei einem MCP-Proxy-Server, der die API eines Drittanbieters mit einer einzigen statischen Client-ID anspricht. Mit dynamischer Client-Registrierung am Proxy und einem Consent-Cookie beim Autorisierungsserver des Drittanbieters kann ein präparierter Link einen Autorisierungscode ohne neuen Zustimmungsdialog an einen Angreifer schicken; der Proxy muss deshalb die Zustimmung je Client einholen und Redirect-URIs exakt abgleichen. Token Passthrough, das unveränderte Weiterreichen des Tokens eines Clients an eine nachgelagerte API, ist verboten, weil es die Kontrollen des Servers umgeht und verschleiert, welcher Client einen Aufruf ausgelöst hat.

Server-Side Request Forgery (SSRF) missbraucht die OAuth-Discovery, bei der der Client URLs abruft, die ein bösartiger Server kontrolliert und die auf interne Hosts oder die Cloud-Metadatenadresse 169.254.169.254 zeigen können; Clients, die auf einem Server betrieben werden, sollten deshalb private Adressbereiche sperren und einen Egress-Proxy in Betracht ziehen. State Handle Hijacking, also die Übernahme eines Zustands-Handles, ersetzt das Session Hijacking (in der Fassung 2025-11-25 der Seite behandelt); Server dürfen den Besitz eines State Handles nicht als Authentifizierung werten und sollten jedes Handle an den authentifizierten Nutzer binden. Weitere Abschnitte behandeln die Kompromittierung lokaler Server, die Validierung von Autorisierungs-URLs, stdio-Proxys, Mix-up-Angriffe, Impersonation über Localhost-Redirect-URIs, Vertrauensrichtlinien für Client ID Metadata Documents und die Minimierung von Scopes.

Tool Poisoning, Rug Pulls und Injection über Tool-Ergebnisse

Namen und Beschreibungen von Tools gehören zu dem Text, den das Modell liest; die Tool-Liste eines Servers ist deshalb eine Angriffsfläche für Injection, noch bevor ein Tool läuft. Der Leitfaden zu lokalen Servern nennt darin versteckte Anweisungen Tool Poisoning, also Vergiftung der Tools, oder Tool Shadowing, wenn sie auf die Tools eines anderen Servers zielen, und eine nach der Freigabe geänderte Definition einen Rug Pull, den weder ein einmaliger Zustimmungsdialog noch ein gepinntes Paket erkennt. Alle konfigurierten Server teilen sich den Kontext des Modells, sodass jeder neue Server die Angriffsfläche der übrigen vergrößert.

Das OWASP GenAI Security Project definiert in seinem Cheat Sheet A Practical Guide for Securely Using Third-Party MCP Servers, Version 1.0 vom 23. Oktober 2025, Tool Poisoning als „eine Form der indirekten Prompt Injection“ und empfiehlt ein zentrales Verzeichnis freigegebener Server, einen Hash oder eine Prüfsumme über die Tool-Beschreibungen, Container, eng gefasste Berechtigungen je Aufgabe und eine menschliche Freigabe für Aktionen, die zuvor noch nicht ausgeführt wurden.

Tool-Ergebnisse sind der zweite Kanal. Ein Ticket oder eine Webseite, die ein Tool zurückgibt, gelangt wie jeder andere Text in den Kontext, und OWASPs Eintrag LLM01:2026 Prompt Injection nennt „die Ausgabe eines MCP-Servers“ unter den Quellen indirekter Prompt Injection. Der Eintrag verlangt, jeden MCP-Server zu pinnen, zu signieren und zu verifizieren, Tool-Beschreibungen auf versteckte Anweisungen zu prüfen und die Kombination von Tools zu überwachen, und hält fest, dass Pinning keinen Payload aufhält, der schon mit der gepinnten Version ausgeliefert wird. OWASPs separate MCP Top 10, noch im Beta-Stadium, führen MCP03:2025 Tool Poisoning und MCP09:2025 Shadow MCP Servers auf. Warum kein Filter Injection zuverlässig aufhält, erklärt unser Artikel zu Prompt Injection und LLM-Sicherheit.

MCP im Unternehmen: Risiken, Beispiele und erste Maßnahmen

MCP-Spezifikation 2026-07-28, ihre Sicherheitsempfehlungen und ihr Leitfaden zur Sicherheit lokaler Server; OWASPs MCP Cheat Sheet 1.0, LLM01:2026 und MCP Top 10, abgerufen am 6. Oktober 2026; Beispiele und Maßnahmen sind unsere Zusammenfassung.

Für eine Flotte von Rechnern ergänzt der Leitfaden zu lokalen Servern eine Allowlist geprüfter Server mit gepinnten Versionen, Isolation als Standard, die zentrale Bereitstellung von Servern, die nur eine SaaS-API kapseln, ein Inventar der Konfigurationsdateien der Clients, ein Audit-Log darüber, welcher Server wann welches Tool ausgeführt hat, und einen Plan, um den ausgehenden Datenverkehr eines verwundbaren Servers zu sperren und seine Zugangsdaten zu rotieren. Wie sich nicht freigegebene KI-Werkzeuge finden lassen, behandelt unser Artikel zu Richtlinien und Maßnahmen gegen Schatten-KI.

Unsere Leistung Private AI/ML umfasst Daten- und Berechtigungsverwaltung und die Protokollierung von Anfragen und Antworten. Schreiben Sie uns, welche internen Systeme ein Assistent über MCP erreichen soll, und wer Änderungen daran heute freigibt.

MCP mit einem privaten LLM: vLLM, Open WebUI und n8n

Der OpenAI-kompatible Server von vLLM wandelt die Ausgabe des Modells in Tool-Aufrufe um, wenn er mit --enable-auto-tool-choice und dem --tool-call-parser der Modellfamilie gestartet wird, und seine Dokumentation überlässt es der Anwendung des Aufrufers, die Tools zu definieren und die Aufrufe zu verarbeiten. MCP-Client ist deshalb meist das Frontend oder Workflow-Werkzeug vor vLLM, das die Tools der Server auflistet, die vom Modell gewählten Aufrufe ausführt und die Ergebnisse zurückgibt.

Dokumentation und Quellcode von vLLM 0.31.0, das Recipe für gpt-oss (22. September 2026), die MCP-Dokumentation von Open WebUI sowie Dokumentation und Node-Quellcode von n8n 2.42.3 (neuestes Release), abgerufen am 6. Oktober 2026.

Selbst gehostet betreiben Open WebUI und n8n ihre MCP-Clients auf einem Server in Ihrem Netz, und diesen Fall behandelt die Empfehlung zu SSRF; da interne MCP-Server private Adressen haben, stellen Sie diesen Host hinter einen Egress-Proxy, der nur die freigegebenen MCP- und Autorisierungsserver zulässt, statt alle privaten Adressbereiche zu sperren. Die Dokumentation von Open WebUI verlangt außerdem, die Richtlinien für Authentifizierung, Proxy und Ratenbegrenzung zu prüfen, bevor MCP nach außen erreichbar gemacht wird, und die Seite von n8n zum MCP Client Tool nennt noch einen SSE-Endpunkt, obwohl der Node in n8n 2.42.3 standardmäßig HTTP Streamable verwendet. Freigaben und Zugangsdaten je Tool in n8n behandelt unser Artikel zu KI-Agenten mit n8n auf einem privaten LLM, Anmeldung und Anfrageprotokolle in Open WebUI unser Leitfaden zu einer privaten ChatGPT-Alternative und die eigene API von vLLM unser Leitfaden zum Absichern eines GPU-Servers.

Unsere Leistung Private AI/ML umfasst das Deployment offener und kommerzieller Modelle on-premise mit vLLM, Ollama oder NVIDIA AI Enterprise. Beschreiben Sie im Formular unten die Tools, die Sie zuerst anbinden wollen, und die Systeme dahinter.

Was wir tun

Unsere Leistung Private AI/ML umfasst Agenten-Workflows und ITOps-Automatisierung mit n8n und Ansible nach Regeln, die Sie kontrollieren, den Schutz der Modelle vor Prompt Injection, Daten- und Berechtigungsverwaltung und die Protokollierung von Anfragen und Antworten. Die Modelle laufen auf Ihren Servern oder auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen, und nichts geht an öffentliche Dienste, solange Sie es nicht ausdrücklich freigeben. Wir starten mit einem Pilotprojekt auf einem Prozess mit klaren Metriken und skalieren nur, was seinen Wert bewiesen hat. Eurokommerz hält den Vertrag und liefert die Hardware, das Engineering kommt von unserem Engineering-Partner Vixen.UNO; das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest. Wie wir während eines Projekts mit Daten umgehen, beschreibt unsere Seite Sicherheit & Compliance.

FAQ