MCP-Server Sicherheit & DSGVO: so bleibt Ihr Einsatz sicher

Wie bleibt man mit MCP-Servern sicher?

Sicher bleiben Sie, wenn jeder MCP-Server nur angemeldete Anfragen annimmt, nur feste und eng berechtigte Werkzeuge anbietet, fremde Inhalte als Daten behandelt, jeden Aufruf protokolliert und erst nach einer Prüfung in Betrieb geht. Alles Weitere auf dieser Seite vertieft diese fünf Punkte.

• Anmeldung bei jeder Anfrage
• Enge Rechte je Werkzeug
• Fremdtext ist nie Befehl
• Protokoll jedes Aufrufs
• Freigabe vor Inbetriebnahme

Warum ist MCP-Sicherheit eine eigene Disziplin?

Weil ein KI-Agent zur Laufzeit selbst entscheidet, welches Werkzeug er aufruft, und dabei Texte liest, die jemand anderes geschrieben hat. Klassische Sicherheit fragt, wer hinein darf. Bei MCP kommt die Frage dazu, was der Agent eigenständig tun darf und wer ihm das gesagt hat.

Wenn Sie über das Model Context Protocol Fachsysteme anbinden, verlagert sich das Risiko von der reinen Zugriffskontrolle hin zur Frage, wie ein Agent dazu gebracht werden kann, etwas zu tun, das niemand wollte. Dieser Leitfaden ergänzt den allgemeinen Rahmen aus DSGVO-konforme KI um die konkreten Hebel auf MCP-Ebene.

Welche Angriffe drohen MCP-Servern? Das Bedrohungsmodell

Die wichtigsten Angriffe zielen auf die Anmeldung am Server, auf die Weitergabe von Zugangsdaten, auf manipulierte Werkzeuge und auf Texte, die das Modell als Befehl missversteht. Die Tabelle zeigt, wie es jeweils passiert und was dagegen hilft.

Was wir in der Praxis sehen: In unserer eigenen Sicherheitsforschung an öffentlich verfügbaren MCP-Servern lagen die hoch bewerteten Befunde durchweg auf der Transport- und Anmeldeebene, nicht in der Logik einzelner Werkzeuge. Ein typisches Muster ist eine Host-Prüfung, die nur den Anfang der Adresse vergleicht statt der ganzen. Deshalb steht die Anmeldung in der Prüfliste ganz oben. Hintergründe zu OAuth-Fallen im MCP-Umfeld liefert die Sicherheitsforschung von CyberSec42 zur MCP-OAuth-Sicherheit.

Wie Prompt-Injection im Detail funktioniert und welche Abwehr wirkt, beschreibt der Ratgeber Prompt-Injection und KI-Sicherheit.

Was verlangt die MCP-Spezifikation bei der Autorisierung?

Die aktuelle MCP-Spezifikation (Version 2026-07-28) macht Autorisierung optional. Wer sie über HTTP anbietet, soll aber OAuth 2.1 nach festen Regeln umsetzen, und der Server muss prüfen, dass jedes Token genau für ihn ausgestellt wurde.

Die wichtigsten Vorgaben aus der Autorisierungs-Spezifikation und dem Streamable-HTTP-Transport, Stand Oktober 2026 (Versionsübersicht):

• OAuth 2.1 als Grundlage: Autorisierungsserver müssen OAuth 2.1 umsetzen, der Ablauf nutzt PKCE.
• Anmeldung in jeder Anfrage: Das Token steht im Authorization-Header jeder HTTP-Anfrage, nie in der URL.
• Token nur für diesen Server: MCP-Server müssen prüfen, dass ein Token für sie als Empfänger ausgestellt wurde. Clients müssen den Server dafür per Resource Indicator (RFC 8707) benennen.
• Kein Durchreichen: Server dürfen keine anderen Tokens annehmen oder weitergeben. Das ist der Schutz gegen Token Passthrough.
• Metadaten: Server müssen OAuth 2.0 Protected Resource Metadata (RFC 9728) anbieten, damit Clients den richtigen Autorisierungsserver finden.
• Scopes mit Maß: Die Spezifikation empfiehlt, mit einem minimalen Satz von Scopes zu starten und weitere erst bei Bedarf nachzufordern.
• Lokale Server über stdio: Sie folgen der OAuth-Spezifikation nicht, sondern beziehen Zugangsdaten aus der Umgebung.
• Transport: Server müssen den Origin-Header prüfen, um DNS-Rebinding zu verhindern, sollen lokal nur an 127.0.0.1 binden und sollen jede Verbindung anmelden.
• Neu in dieser Version: Das Protokoll kennt keine Sitzungen mehr. Braucht ein Server Zustand über mehrere Anfragen, ist der Besitz einer solchen Kennung laut Spezifikation keine Anmeldung, jede Anfrage wird für sich geprüft. Die dynamische Client-Registrierung ist als veraltet markiert, bevorzugt werden Client ID Metadata Documents.

Die Security Best Practices der Spezifikation beschreiben außerdem Confused Deputy, Token Passthrough, SSRF bei der Metadaten-Suche, kompromittierte lokale Server und die Minimierung von Scopes ausführlich. Wer selbst einen Server baut, sollte beide Dokumente ganz lesen.

OWASP MCP Top 10: Welche Risiken nennt OWASP?

OWASP führt zehn Risikoklassen für MCP-Umgebungen, von ungeschützten Zugangsdaten bis zu nicht genehmigten Schatten-Servern. Das Projekt hat Stand Oktober 2026 den Status Beta (OWASP MCP Top 10).

Was verlangt SAP von eigenen MCP-Servern?

Das SAP Architecture Center knüpft eigene MCP-Server an eine Governance-Checkliste, die sich gut als Maßstab auch außerhalb von SAP eignet (SAP Architecture Center).

• Kein Durchreichen des Nutzertokens, stattdessen Token-Austausch nach RFC 8693 mit Agent- und Nutzerkontext
• Keine langlebigen Zugangsdaten, Secrets im Secrets-Store, TLS ab Version 1.2
• Eingaben prüfen, Orientierung an den OWASP MCP Top 10
• Rate Limits unterhalb der Quoten des Zielsystems, Timeouts und Schutzschalter
• Zustandsloser Betrieb und versionierte Werkzeugbeschreibungen
• Protokoll jedes Werkzeugaufrufs mit Aufrufer, Parametern mit geschwärzten personenbezogenen Daten, Ziel-API, Status und Laufzeit, verknüpft per W3C TraceContext

Was SAP darüber hinaus für KI-Agenten an SAP-Systemen erlaubt, steht im Ratgeber SAP MCP-Server und API Policy. Für den direkten Datenbankzugriff gibt es einen eigenen Ratgeber zum SAP HANA MCP-Server.

Prüfliste für den Betrieb von MCP-Servern

Diese Prüfliste nutzen wir vor jeder Inbetriebnahme und bei jeder Änderung. Jeder Punkt ist einzeln prüfbar.

• 1. Anmeldung je AnfrageKein Endpunkt ohne Anmeldung, auch nicht intern. Das Token wird bei jeder Anfrage geprüft, inklusive Empfänger und Ablauf.
• 2. Scope ist PflichtJedes Werkzeug verlangt einen passenden Scope. Ein Token, das nur Rechnungen lesen darf, kann keine Stammdaten ändern.
• 3. Lokal nur LoopbackLokale HTTP-Server binden an 127.0.0.1, prüfen Origin und Host exakt gegen eine feste Liste und verlangen trotzdem ein Token. Besser noch stdio.
• 4. Feste WerkzeugeEin Werkzeug je Anwendungsfall mit festen Feldern und Obergrenzen. Kein generisches „führe Abfrage aus“ oder „rufe URL auf“.
• 5. Lesen zuerstDer erste Server liest nur. Schreibende Werkzeuge kommen später, in einem eigenen Server und mit Freigabe durch einen Menschen.
• 6. Eingaben prüfenJeder Parameter wird gegen ein striktes Schema geprüft. Unerwartetes wird abgelehnt, nicht „repariert“.
• 7. Rate LimitsBegrenzung je Nutzer und je Werkzeug, unterhalb der Quoten des angebundenen Systems.
• 8. TimeoutsJeder Aufruf an ein Zielsystem hat eine Zeitgrenze und einen Schutzschalter, damit kein Agent ein Backend in Schleife ausbremst.
• 9. Protokoll ohne InhaltsdatenWer, welches Werkzeug, welche Parameter, Status, Dauer. Personenbezogene Werte geschwärzt, keine Mailtexte oder Belege im Log.
• 10. Fehlertexte nicht ans ModellFehlermeldungen der Zielsysteme enthalten oft Fremdtext und interne Details. Das Modell bekommt eine neutrale Meldung, der Volltext geht ins Protokoll.
• 11. Secrets-StoreZugangsdaten liegen in einem Secrets-Store, nicht in Konfigurationsdateien oder Umgebungsdateien im Repository, und werden regelmäßig gewechselt.
• 12. Updates mit fester VersionServer und Abhängigkeiten laufen in einer festen Version. Updates werden bewusst eingespielt, Werkzeugbeschreibungen dabei neu gelesen.
• 13. Freigabe neuer ServerKein MCP-Server geht ohne dokumentierte Prüfung in Betrieb, auch nicht „nur zum Testen“ mit echten Daten.
• 14. Rollen- und MandantentrennungEin Agent, der für Mandant A arbeitet, sieht keine Daten von Mandant B. Die Trennung ist technisch erzwungen, über mandantengebundene Tokens und Prüfung jedes Zugriffs gegen den Kontext.

Sie möchten wissen, wie Ihr bestehendes Setup gegen diese Liste abschneidet? Der MCP-Security-Quickcheck zeigt, was Ihre KI-Agenten heute erreichen können.

Lokale MCP-Server: Was gilt auf dem eigenen Rechner?

Lokale MCP-Server laufen mit den Rechten des angemeldeten Nutzers und sind deshalb so gefährlich wie jedes andere Programm, das man installiert. Die Spezifikation beschreibt drei Wege, wie das schiefgeht: ein schädlicher Startbefehl in der Konfiguration, schädlicher Code im Server selbst und ein offener lokaler Server, der per DNS-Rebinding aus einer Webseite heraus angesprochen wird.

• stdio bevorzugen: Dann spricht nur der eigene Client mit dem Server, es gibt keinen offenen Port.
• Wenn HTTP, dann eng: Bindung an 127.0.0.1, exakte Prüfung von Origin und Host, Token auch lokal.
• Startbefehl ansehen: Clients müssen bei Ein-Klick-Installation laut Spezifikation den genauen Befehl ungekürzt zeigen und eine Zustimmung einholen. Lesen Sie ihn tatsächlich.
• Begrenzt ausführen: Server in einer Sandbox oder einem Container starten, mit Zugriff nur auf die nötigen Ordner und Netzziele.

Wie geben Sie neue MCP-Server frei?

Mit einem festen Ablauf, der Herkunft, Code, Rechte, Netz und Herstellerbedingungen prüft, bevor ein Server an echte Daten kommt. OWASP nennt nicht genehmigte Server als eigene Risikoklasse (MCP09, Shadow MCP Servers).

1. Herkunft: Wer pflegt den Server, wie aktiv, gibt es einen Meldeweg für Sicherheitslücken?
2. Code und Version: Eine konkrete Version prüfen und genau diese einsetzen, nicht „latest“.
3. Werkzeuge lesen: Welche Werkzeuge bietet der Server, was steht in den Beschreibungen, gibt es freie Abfragen, Shell- oder URL-Werkzeuge?
4. Rechte und Netz: Mit welchem Konto greift er zu, welche Ziele darf er erreichen?
5. Herstellerbedingungen: Erlaubt der Anbieter des angebundenen Systems den Zugriff durch KI-Agenten überhaupt? Mehrere Hersteller haben dazu 2025 und 2026 Regeln veröffentlicht. Einen Überblick gibt der Ratgeber MCP und Herstellerrichtlinien.
6. Testbetrieb: Erst mit Testdaten, dann mit echten Daten und Protokoll.
7. Verzeichnis: Jeder freigegebene Server steht mit Version, Verantwortlichem und Zweck in einer Liste. Jedes Update ist eine neue Freigabe.

Protokollierung: revisionsfähig, aber ohne Inhaltsdaten

Ein MCP-Server sollte jeden Werkzeugaufruf so protokollieren, dass sich später belegen lässt, wer was ausgelöst hat, ohne dass das Protokoll selbst zur Datensammlung wird. Ein Agent, dessen Handeln Sie nicht nachvollziehen können, ist im Sinne der DSGVO nicht beherrschbar.

• Identität des Auslösers und eine Kennung für die Anfrage, verknüpfbar über Systeme hinweg
• Aufgerufenes Werkzeug und Parameter, personenbezogene Werte geschwärzt
• Ergebnisstatus, Datenmenge und Dauer
• Zeitstempel, gespeichert nur zum Anhängen, nachträglich nicht änderbar

Im Streitfall, etwa bei der Frage „Wer hat diese Rechnung versendet?“, ist das der Unterschied zwischen einer belegbaren Antwort und einem Schulterzucken. Legen Sie Aufbewahrungsfristen und Zugriffsrechte für das Protokoll selbst fest, denn auch Protokolle sind personenbezogene Daten.

DSGVO: Was müssen Sie beim MCP-Einsatz regeln?

Für den MCP-Einsatz brauchen Sie eine Rechtsgrundlage, Auftragsverarbeitungsverträge mit allen Dienstleistern, Datenminimierung schon im Werkzeug, eine ehrliche Aufstellung, wer welchen Teil betreibt, und häufig die Beteiligung des Betriebsrats. Das ist eine Einordnung, keine Rechtsberatung.

Auftragsverarbeitung

Sobald personenbezogene Daten an einen Dienstleister gehen, der sie in Ihrem Auftrag verarbeitet, brauchen Sie einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO (DSGVO). Das betrifft den Modellanbieter, den Betreiber des MCP-Servers, wenn das nicht Sie selbst sind, und Hosting-Dienstleister. Der Vertrag regelt Zweckbindung, Unterauftragnehmer, Löschfristen und Verarbeitungsorte. Die großen Modellanbieter stellen solche Verträge in ihren Unternehmens- und Cloud-Angeboten bereit.

Datenminimierung im Werkzeug

Art. 5 Abs. 1 lit. c DSGVO verlangt, dass nur die nötigen Daten verarbeitet werden, Art. 25 verlangt Datenschutz durch Technikgestaltung. Bei MCP heißt das: Das Werkzeug entscheidet, welche Felder das Modell überhaupt sieht. Eine Mahnroutine braucht Betrag und Fälligkeit, nicht die Gesprächsnotizen zum Ansprechpartner. Was das Werkzeug nicht liefert, kann das Modell weder verarbeiten noch weitergeben.

Standort ehrlich darstellen

Eine MCP-Kette hat mehrere Teile, und jeder kann woanders laufen. Halten Sie für jeden Teil fest, wer ihn betreibt und wo:

Den MCP-Server selbst betreiben wir in der EU, etwa in der Azure-Region Germany West Central (Frankfurt) oder bei einem deutschen Hoster. Für das Sprachmodell nutzen wir Angebote mit vertraglich wählbarer EU-Region. Ist ein US-Anbieter im Pfad, bleibt ein Drittlandbezug nach Art. 44 ff. DSGVO zu prüfen, etwa über Konzernzugriff oder Support. Eine pauschale Zusage, dass Daten Europa nie verlassen, geben wir in diesem Fall nicht.

Betriebsrat

Nach § 87 Abs. 1 Nr. 6 BetrVG bestimmt der Betriebsrat mit, wenn technische Einrichtungen dazu geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen (BetrVG). Protokolle, die festhalten, wer welche Frage an den Assistenten gestellt hat, können darunter fallen. Binden Sie den Betriebsrat deshalb früh ein und legen Sie fest, wofür Protokolle ausgewertet werden dürfen.

On-Premise, EU-Cloud oder hybrid?

Beide Wege lassen sich DSGVO-gerecht umsetzen. Die Entscheidung sollte an der Datenklasse hängen, nicht am Bauchgefühl:

1. On-Premise oder eigenes Rechenzentrum Daten bleiben im eigenen Netz, die Kontrolle liegt bei Ihnen. Dafür betreiben, patchen und überwachen Sie selbst. Sinnvoll bei besonders sensiblen Daten oder bestehender starker IT.
2. EU-Cloud (verwaltet) Klar definierte Region in Europa bei deutlich geringerem Betriebsaufwand. Für viele mittelständische Unternehmen der pragmatische Standard, vorausgesetzt, Hosting und Modellanbieter halten die gewählte Region ein.
3. Hybrid Sensible Verarbeitung lokal, weniger kritische Schritte in der EU-Cloud. Mehr Architekturaufwand, dafür feine Steuerung, oft die Antwort für gewachsene IT im Mittelstand.

Häufige Fragen

Wie bleibt man auf MCP-Servern sicher?

Mit fünf Grundregeln: Jede Anfrage an den Server ist angemeldet, jedes Werkzeug hat eng gefasste Rechte, Inhalte aus Mails, Dokumenten und Werkzeugantworten gelten als Daten und nie als Anweisung, jeder Aufruf wird protokolliert, und neue Server gehen erst nach einer Prüfung in Betrieb. Lesende Werkzeuge kommen zuerst, schreibende nur mit Freigabe durch einen Menschen.

Was ist die häufigste schwere Lücke in MCP-Servern?

Nach unserer eigenen Sicherheitsforschung an öffentlich verfügbaren MCP-Servern liegen die schweren Lücken vor allem auf der Transport- und Anmeldeebene. Typisch ist ein HTTP-Endpunkt ohne oder mit lückenhafter Anmeldung. Wer den Endpunkt erreicht, nutzt die Werkzeuge mit den Zugangsdaten des Betreibers. Bei lokalen Servern kommt das über DNS-Rebinding sogar aus dem Browser heraus in Reichweite.

Was ist Token Passthrough und warum ist es verboten?

Token Passthrough heißt, dass ein MCP-Server ein Token annimmt, das nicht für ihn ausgestellt wurde, und es an eine nachgelagerte Schnittstelle weiterreicht. Die MCP-Spezifikation verbietet das, weil dabei Prüfungen, Begrenzungen und die Nachvollziehbarkeit verloren gehen und der Server zum Werkzeug für Datenabfluss werden kann.

Was ist Tool Poisoning?

Bei Tool Poisoning stecken manipulierte Anweisungen in der Beschreibung oder in den Antworten eines Werkzeugs. Für Menschen bleibt das oft unsichtbar, das Modell liest es mit. Schutz bieten geprüfte Server mit fester Version, eine Prüfung der Werkzeugbeschreibungen bei jedem Update und eine Freigabe für schreibende Aktionen.

Ist ein MCP-Server DSGVO-gerecht betreibbar?

Ja, wenn Rechtsgrundlage, Auftragsverarbeitungsverträge, Datenminimierung im Werkzeug und Protokollierung stimmen und Sie ehrlich festhalten, wer welchen Teil betreibt und wo verarbeitet wird. Ist ein US-Anbieter im Pfad, lässt sich ein Drittlandbezug nicht ausschließen. Das ist eine Einordnung, keine Rechtsberatung.

Brauche ich einen AVV mit dem KI-Anbieter?

Sobald personenbezogene Daten an einen Dienstleister gehen, der sie in Ihrem Auftrag verarbeitet, brauchen Sie einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Das gilt für den Modellanbieter ebenso wie für den Betreiber des MCP-Servers, wenn das nicht Sie selbst sind.

Bleiben die Daten in der EU?

Das hängt an jedem einzelnen Teil der Kette: Assistent, Modell, MCP-Server und angebundene Systeme. Eine EU-Region bei Cloud-Anbietern ist ein wichtiger Baustein. Eine pauschale Zusage, dass Daten Europa nie verlassen, geben wir nicht, wenn ein US-Anbieter beteiligt ist.

Was gehört in das Protokoll eines MCP-Servers?

Je Aufruf: wer ihn ausgelöst hat, welches Werkzeug mit welchen Parametern, Ergebnisstatus, Datenmenge, Dauer und Zeitpunkt. Personenbezogene Werte werden geschwärzt, Inhaltsdaten wie Mailtexte oder Belege gehören nicht ins Protokoll. Gespeichert wird es so, dass Einträge nachträglich nicht geändert werden können.

Muss der Betriebsrat beim MCP-Einsatz beteiligt werden?

Häufig ja. Nach § 87 Abs. 1 Nr. 6 BetrVG bestimmt der Betriebsrat mit, wenn technische Einrichtungen dazu geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen. Protokolle von KI-Assistenten können das sein. Binden Sie ihn deshalb früh ein.

Wie prüfe ich einen fremden MCP-Server vor der Freigabe?

Herkunft und Pflege des Projekts prüfen, Code und Abhängigkeiten in einer festen Version ansehen, Werkzeuge und ihre Beschreibungen lesen, Rechte und Netzzugriffe auf das Nötige begrenzen, die Bedingungen des angebundenen Herstellers prüfen und den Server erst in einer Testumgebung laufen lassen. Jedes Update ist eine neue Freigabe.