Macht MCP Agenten sicherer oder unsicherer?

Sicherer pro Integration, riskanter in der Gesamtheit. Ein einziges Protokoll bedeutet eine einzige Stelle für Überprüfungen und Widerrufe – aber es senkt auch die Hürde, einen Agenten mit einem anderen System zu verbinden, und jede Verbindung ist eine neue Vertrauensentscheidung, die jemand treffen muss.

Benötige ich eine Authentifizierung für einen schreibgeschützten Server?

Nicht zwingend, wenn die Daten wirklich öffentlich sind. Sie benötigen dennoch ein Rate Limiting und einen Audit-Trail: Öffentlich bedeutet nicht kostenlos, und ein unbegrenzter öffentlicher Endpunkt ist ein Verstärker, der auf Ihre eigene Infrastruktur gerichtet ist.

Warum sollte man den Origin-Header prüfen, wenn Agenten keinen senden?

Genau deshalb. Der headerlose Traffic ist die legitime Zielgruppe; eine Anfrage, die einen fremden Origin enthält, ist ein Browser, der im Namen eines Dritten handelt – und genau das ist der Fall, den es abzuweisen gilt.

Was ist ein Tool Rug Pull und wie schütze ich mich davor?

Ein Server, der harmlose Tool-Beschreibungen anzeigt, wenn der Benutzer ihn freigibt, und diese im Nachhinein ändert. Die Schutzmaßnahmen bestehen darin, die Serverversion zu pinnen, Beschreibungen bei Änderungen neu zu validieren und einem Remote-Server keine Berechtigungen zu erteilen, die Sie nicht auch einer Code-Abhängigkeit gewähren würden.

GovernanceAktualisiert 2026-08-22 · Version 1.0

Was ist MCP-Sicherheit?

MCP-Sicherheit verhindert, dass ein Model Context Protocol-Server zum einfachsten Einfallstor in ein System wird. Das Protokoll standardisiert, wie Agenten Tools erkennen und aufrufen; es entscheidet nicht, wer sie aufrufen darf, was sie erreichen können oder was passiert, wenn eine Tool-Beschreibung bösartig wird. Diese Entscheidungen liegen beim Server: Authentifizierung, Herkunfts- und Transportvalidierung, eng eingegrenzte Tools, Ratenbegrenzungen (Rate Limits) und ein Audit-Trail.

Evidenz: ProduktionKonfidenz: HochQuelle: ProduktionssystemQuelle: Persönliche ErfahrungQuelle: Branchenbeobachtung

Maschinenlesbar: JSON

Definition

MCP-Sicherheit ist die Gesamtheit der Kontrollmaßnahmen, die auf einen Model Context Protocol-Server und seine Clients angewendet werden – Authentifizierung und Autorisierung, Herkunfts- und Transportvalidierung, Tool-Scoping, Eingabe- und Ausgabeverarbeitung, Ratenbegrenzung und Auditierung –, damit die Bereitstellung von Funktionen für einen KI-Agenten nicht die dahinter liegenden Systeme gefährdet.

Wichtigste Erkenntnisse

MCP standardisiert die Infrastruktur, nicht das Vertrauen: Jeder Server bestimmt seine eigene Sicherheitsstruktur.
Eine Tool-Beschreibung ist eine nicht vertrauenswürdige Eingabe für das Modell – sie kann Anweisungen enthalten und sich nach der Genehmigung ändern.
Lokale stdio-Server und Remote-HTTP-Server haben unterschiedliche Bedrohungsmodelle; die gefährlichen Fehler unterscheiden sich.
Herkunftsprüfungen (Origin Checks) und Ratenbegrenzungen gehören in den Server, da Clients nicht unter Ihrer Kontrolle stehen.
„Read-only“ ist eine Eigenschaft der Implementierung, niemals des Tool-Namens.

Kontext

MCP bietet einem Agenten eine einheitliche Möglichkeit, Funktionen zu erkennen und aufzurufen. Diese Einheitlichkeit ist sowohl der Nutzen als auch das Risiko: Ein Client kann auf viele Server verweisen, und jeder Server erfordert eine neue Vertrauensentscheidung, die in der Praxis von der Person getroffen wird, die eine URL in eine Konfigurationsdatei kopiert hat.

Zwei Bereitstellungsformen dominieren. Ein lokaler stdio-Server läuft mit den eigenen Rechten des Benutzers auf dessen Rechner: Es gibt keine Netzwerkgrenze, daher stellt sich die Frage, was er lesen kann und ob er Daten nach Hause sendet. Ein Remote-HTTP-Server ist ein öffentlicher Endpunkt: Hier stellt sich die Frage, wer von wo aus wie oft aufruft und ob ein Browser dazu verleitet werden kann, ihn im Namen eines Benutzers aufzurufen.

Wir betreiben für diese Wissensdatenbank jeweils eine dieser Formen – einen öffentlichen HTTP-Endpunkt und ein veröffentlichtes stdio-Paket –, sodass die folgenden Kontrollmaßnahmen so beschrieben werden, wie sie implementiert sind, und nicht als generische Checkliste.

Architektur

Entscheiden Sie zuerst über die Freigabe: öffentlich lesbar, authentifiziert oder rein lokal. Alles andere ergibt sich aus dieser Antwort, und die meisten Vorfälle resultieren aus einem Server, der diesen Schritt nie geschafft hat.

Validieren Sie den Transportweg, bevor Sie irgendwelche Aktionen ausführen. Überprüfen Sie bei HTTP-Servern den Origin-Header gegen eine Allowlist und weisen Sie vom Browser initiierte Cross-Site-Aufrufe ab, bevor ein Handler ausgeführt wird – DNS-Rebinding und CSRF-artiger Missbrauch erfolgen beide auf diesem Weg.

Halten Sie den Server zustandslos, wo immer das Protokoll es zulässt. Kein Session-Store bedeutet keine Session-Fixation, keine Kontamination zwischen Anfragen und kein Zustand, der zwischen Aufrufern offengelegt werden kann.

Grenzen Sie Tools eng ein. Ein Tool, eine Funktion, keine Verben, die sich mit einem Argument ändern – ein „query“-Tool, das auch schreiben kann, ist eine Privilege Escalation, die nur auf den richtigen Parameter wartet.

Implementieren Sie ein Rate Limiting pro Aufrufer und antworten Sie mit einem echten 429 und Retry-After. Ein Agent, der es erneut versucht, ist normaler Traffic; ein Agent, der unbegrenzt fehlschlägt und es erneut versucht, ist ein Denial-of-Service-Tool, das auf Ihr eigenes Backend gerichtet ist.

Protokollieren Sie jeden Aufruf mit ausreichend Struktur, um Missbrauch zu rekonstruieren – Tool, Ergebnis, Latenz, Identität des Aufrufers – und ohne Daten, die das Log selbst zu einer Sicherheitslücke machen.

Behandeln Sie jedes Tool-Ergebnis auf dem Rückweg als nicht vertrauenswürdigen Inhalt. Ein Server, der externe Daten weiterleitet, ist konstruktionsbedingt ein Kanal für indirekte Prompt-Injections.

Komponenten

Authentifizierung: Keine für wirklich öffentlich lesbare Daten, ein Token oder OAuth für alles andere – wobei diese Entscheidung dokumentiert sein muss, da „keine Authentifizierung“ eine bewusste Entscheidung und kein Versehen sein darf.Origin- und Host-Validierung für Remote-Server, abgeleitet aus gemessenem Traffic statt angenommen aus einem Web-App-Standardwert.Autorisierung pro Tool: Was dieser Aufrufer ausführen darf, nicht nur, ob er sich verbinden darf.Eingabevalidierung an der Tool-Grenze mit derselben Strenge wie bei einer öffentlichen API – denn genau das ist es.Ausgabe-Shaping: Geben Sie nur das Minimum zurück, das der Aufrufer benötigt; leiten Sie niemals rohe Upstream-Payloads direkt durch.Rate Limiting und Quotas, mit ausreichend korrekten Headern, sodass sich gut verhaltende Clients von selbst zurückziehen.Audit-Protokollierung und Metriken, die lange genug für Untersuchungen aufbewahrt und ausreichend aggregiert werden, um eine sichere Speicherung zu gewährleisten.Supply-Chain-Hygiene für den Server selbst: gepinnte Abhängigkeiten, überprüfte Updates, veröffentlichte Provenienz, damit Clients erkennen können, dass sie mit dem von Ihnen entwickelten Server kommunizieren.

Vorteile

Ein gut eingegrenzter MCP-Server bietet eine kleinere Angriffsfläche als die Ad-hoc-Integration, die er ersetzt: ein Protokoll, ein Audit-Punkt, eine Stelle zum Widerrufen.
Zustandslosigkeit und eng eingegrenzte Tools machen den Server leicht verständlich – die Sicherheitsüberprüfung passt auf eine einzige Seite.
Standardfehler und Rate-Limit-Header machen das Client-Verhalten vorhersagbar, was an sich schon eine defensive Eigenschaft ist.
Da alles über eine einzige Grenze läuft, ist die Messung quasi kostenlos: Missbrauch und normale Nutzung erscheinen in denselben Logs und sehen unterschiedlich aus.

Risiken

Tool Rug Pulls: Ein Server, der sich zum Zeitpunkt der Freigabe ordnungsgemäß verhält und seine Tool-Beschreibungen später ändert, sobald der Client nicht mehr nachfragt.
Zu weit gefasste lokale Server: Ein stdio-Server, der Zugriff auf das Dateisystem und die Anmeldedaten des Benutzers hat, stellt eine vollständige Agenten-Funktion dar, ohne dass eine Netzwerkgrenze dies abfangen könnte.
Confused Deputy: Der Server besitzt Anmeldedaten, die der Aufrufer nicht hat, sodass jeder, der ihn erreicht, dessen Berechtigungen erbt.
Stille öffentliche Freigabe: Ein Remote-Server, der ohne Authentifizierung, Origin-Prüfung und Rate Limiting bereitgestellt wird, ist leicht auffindbar und kann ungehindert missbraucht werden.
Injection-Relay: Tool-Ausgaben, die aus Drittquellen stammen und an das Modell übergeben werden, als handele es sich um vertrauenswürdige Anweisungen.

Tools & Technologien

Die MCP-Spezifikation und ihre Richtlinien zur Transportsicherheit – die Baseline, an der sich jeder Server messen lassen sollte.Origin-Allowlists und CORS-Konfigurationen, die angewendet werden, bevor der Anwendungscode ausgeführt wird.Rate-Limiting-Speicher (Redis oder Äquivalent), die über eine gehashte Identität des Aufrufers statt über eine rohe IP-Adresse indiziert werden.Strukturierte Anfrage-Logs und Latenzmetriken, sodass Missbrauch und Kosten in derselben Ansicht sichtbar sind.OWASP Top 10 für LLM-Anwendungen, für die Kategorien Injection und Excessive Agency, die durch MCP-Server verstärkt werden.Registry-Einträge und signierte Veröffentlichungen, damit Clients überprüfen können, ob der installierte Server dem von Ihnen bereitgestellten entspricht.

Beispiele

Diese Knowledge Base stellt einen öffentlichen, schreibgeschützten HTTP-MCP-Endpunkt bereit. Er ist standardmäßig zustandslos, sodass keine Session fixiert oder wiederholt werden kann; die Tools geben nur veröffentlichte Inhalte zurück; und jeder Aufruf ist pro gehashtem Aufrufer mit einem echten 429 und Retry-After ratenbegrenzt.
Bevor wir eine Origin-Regel für diesen Endpunkt definiert haben, haben wir zuerst dessen Traffic gemessen: Fast jede Anfrage enthielt überhaupt keinen Origin-Header, keine enthielt null, und jede Anfrage, die einen enthielt, stammte von dieser Website. Die implementierte Regel folgt dieser Messung – sie weist Browser-Origin-Aufrufe von überall sonst ab und lässt den headerlosen Agenten-Traffic zu, der die eigentliche Zielgruppe darstellt – anstatt eine Richtlinie aus einem Web-App-Standardwert zu kopieren.
Das für dieselbe Knowledge Base veröffentlichte stdio-Paket läuft lokal ohne Anmeldedaten und ohne Zugriff auf das Dateisystem, da es lediglich einen ausgehenden Aufruf an den öffentlichen Endpunkt benötigt. Einem lokalen Server, der nichts benötigt, sollte auch nichts gegeben werden.

FAQs

Macht MCP Agenten sicherer oder unsicherer?: Sicherer pro Integration, riskanter in der Gesamtheit. Ein einziges Protokoll bedeutet eine einzige Stelle für Überprüfungen und Widerrufe – aber es senkt auch die Hürde, einen Agenten mit einem anderen System zu verbinden, und jede Verbindung ist eine neue Vertrauensentscheidung, die jemand treffen muss.
Benötige ich eine Authentifizierung für einen schreibgeschützten Server?: Nicht zwingend, wenn die Daten wirklich öffentlich sind. Sie benötigen dennoch ein Rate Limiting und einen Audit-Trail: Öffentlich bedeutet nicht kostenlos, und ein unbegrenzter öffentlicher Endpunkt ist ein Verstärker, der auf Ihre eigene Infrastruktur gerichtet ist.
Warum sollte man den Origin-Header prüfen, wenn Agenten keinen senden?: Genau deshalb. Der headerlose Traffic ist die legitime Zielgruppe; eine Anfrage, die einen fremden Origin enthält, ist ein Browser, der im Namen eines Dritten handelt – und genau das ist der Fall, den es abzuweisen gilt.
Was ist ein Tool Rug Pull und wie schütze ich mich davor?: Ein Server, der harmlose Tool-Beschreibungen anzeigt, wenn der Benutzer ihn freigibt, und diese im Nachhinein ändert. Die Schutzmaßnahmen bestehen darin, die Serverversion zu pinnen, Beschreibungen bei Änderungen neu zu validieren und einem Remote-Server keine Berechtigungen zu erteilen, die Sie nicht auch einer Code-Abhängigkeit gewähren würden.