Sicherheitsteams fragen mich immer wieder, was MCP-Sicherheit eigentlich bedeutet. Nicht im Sinne von „Bitte definieren Sie das Akronym“. Sondern im Sinne von „Wir haben drei MCP-Server auf Entwickler-Laptops gefunden, und niemand weiß, wem sie gehören“. Das ist die eigentliche Frage. Und sie unterscheidet sich von den Fragen, für deren Beantwortung die meisten API-Sicherheitsleitfäden geschrieben wurden.
MCP-Sicherheit ist nicht API-Sicherheit unter einem neuen Namen. Das Protokoll schafft eine Vertrauensbeziehung zwischen KI-Agenten und Produktionssystemen, für deren Prüfung die meisten vorhandenen Kontrollen nie ausgelegt waren. Ein Standard-API-Gateway überwacht den Perimeter. MCP übergibt einem KI-Agenten die Schlüssel zu allem, was sich dahinter befindet, und erwartet dann von Ihnen, dass Sie die Governance später klären.
Das ist der Teil, den Teams erst spät lernen.
Die Angriffsfläche, für die niemand Budget eingeplant hat
- MCP schafft einen bidirektionalen Vertrauenspfad zwischen KI-Agenten und internen Systemen, den Standard-API-Gateways nicht prüfen.
- 53 % der MCP-Server verwenden langlebige statische Secrets – genau das Credential-Muster, das Supply-Chain-Kompromittierungen erleichtert.
- Hijacking auf Registry-Ebene ist ohne Schwachstelle im Code möglich; Metadaten allein reichen aus.
- Ein gehärtetes LLM plus gehärtete zugrunde liegende Systeme lassen Sie weiterhin angreifbar, wenn die MCP-Server-Schicht unkontrolliert ist.
- Klassische Schwachstellen treten in großem Umfang auf: 43 % Command Injection, 22 % Path Traversal in getesteten Implementierungen.
Was MCP-Sicherheit tatsächlich bedeutet
MCP-Sicherheit umfasst die Kontrollen, Schutzmaßnahmen und Überwachung für MCP-Hosts, -Server und -Registries, um Datenoffenlegung, unbefugte Tool-Ausführung und Missbrauch auf Protokollebene zu verhindern. Diese Definition klingt überschaubar, bis Sie sich ansehen, was sie in der Praxis abdecken muss.
Standard-API-Sicherheit schützt eine Request/Response-Grenze. Sie authentifizieren am Rand, validieren Eingaben und protokollieren, was die Grenze überschreitet. MCP funktioniert strukturell anders. Es schafft eine bidirektionale Vertrauensbeziehung zwischen einem KI-Agenten und den Systemen, mit denen er verbunden ist. Das bedeutet: Der Agent fragt nicht nur eine Ressource ab, sondern kann Tools aufrufen, Dateien lesen, Befehle ausführen und diese Aktionen über mehrere verbundene Systeme hinweg verketten. Der KI-Agent befindet sich innerhalb des Perimeters. Der MCP-Server fungiert als Brücke.
Diese Brücke ist genau das, wofür die meisten API-Gateways nicht ausgelegt sind. Sie können erkennen, dass eine Anfrage stattgefunden hat. In der Regel können sie jedoch nicht sehen, was dem KI-Agenten mitgeteilt wurde, welches Tool er aufzurufen beschlossen hat oder ob die Tool-Beschreibung, der er vertraut hat, vorgelagert manipuliert wurde. Die Angriffsfläche erstreckt sich auf die Protokollebene, die Registry, in der Server entdeckt werden, und die Host-Umgebung, in der der Agent ausgeführt wird. Keine dieser Ebenen existiert in einer herkömmlichen API-Integration.
Diese Unterscheidung ist wichtig, weil Teams, die MCP als „nur eine weitere Integration“ behandeln, die falschen Kontrollen anwenden, die falschen Logs prüfen und die falschen Fehler übersehen – meist, bis bereits Daten verschoben wurden, die nicht hätten verschoben werden dürfen.
Wie MCP funktioniert und wo die Vertrauensgrenze liegt
Das Model Context Protocol hat drei Komponenten, und jede bringt ein eigenes Problem an der Vertrauensgrenze mit sich. Sie getrennt zu verstehen, ist keine akademische Übung. Es entscheidet darüber, ob Sie wissen, wo Kontrollen hingehören, oder sie an der falschen Stelle installieren.
Der Host ist die Umgebung, in der der KI-Agent tatsächlich ausgeführt wird. Eine IDE wie Claude Desktop oder Cursor ist ein Host. Ebenso eine Orchestrierungsplattform, ein Runner für agentische Pipelines oder eine benutzerdefinierte Anwendung, die ein KI-Modell einbettet. Der Host entscheidet, welche Server der Agent erreichen kann, verwaltet die Zusammenstellung des Agenten-Kontexts und bestimmt letztlich den Schadensradius, falls etwas schiefgeht. Ein kompromittierter oder fehlkonfigurierter Host setzt nicht nur ein Tool offen. Er setzt alles offen, was der Agent aus dieser Umgebung heraus sehen kann.
Der Client ist der Connector auf Protokollebene. Er übernimmt die tatsächliche Kommunikation zwischen dem Host und einem bestimmten MCP-Server: Sitzungen initiieren, Anfragen senden, Tool-Antworten empfangen. Der Client übersetzt die Absicht eines Agenten in einen konkreten Netzwerkaufruf.
Der Server stellt dem Agenten Tools, Ressourcen und Prompts bereit. Er ist die Komponente, die Ihren tatsächlichen Systemen am nächsten ist – Ihren Datenbanken, Ihren Source-Code-Repositories, Ihren Cloud-APIs. Wenn der Agent ein Tool aufruft, führt der Server es aus. Diese Ausführung kann Dateien lesen, CI/CD-Pipelines auslösen, Abfragen ausführen oder nachgelagerte APIs aufrufen – abhängig davon, was der Server bereitstellt.
Entscheidend ist, dass diese Komponenten eine Kette delegierten Vertrauens bilden. Der Host vertraut dem Client. Der Client vertraut dem Server. Der Server vertraut den Tool-Definitionen, die er bereitstellt. Ein Angreifer, der ein Glied dieser Kette beeinflussen kann, kann das Verhalten des Agenten beeinflussen – nicht indem er das LLM direkt angreift, sondern indem er die Umgebung manipuliert, in der das LLM arbeitet.
MCP-Host und MCP-Client: Was jede Komponente steuert
Teams verwechseln diese beiden ständig. Ich habe Sicherheitsarchitekten erlebt, die Kontrollen für die Client-Schicht festlegten, weil dort die Netzwerkaktivität stattfindet, und dabei völlig übersahen, dass die Berechtigungen des Agenten im Host tatsächlich definiert werden.
Der MCP-Host steuert die umfassendere Ausführungsumgebung. Er definiert, mit welchen Servern sich der Agent verbinden kann, verwaltet die lokale MCP-Server-Konfiguration und bestimmt, welchen Kontext der Agent erhält. Der Host ist der Ort, an dem der Sicherheitsperimeter zuerst etabliert werden sollte, weil er den gesamten Handlungsspielraum des Agenten regelt. Ein fehlkonfigurierter Host bedeutet einen fehlkonfigurierten Schadensradius.
Der MCP-Client sendet Anfragen auf Protokollebene an einen bestimmten Server. Er ist ein Connector, keine Steuerinstanz. Der Client entscheidet nicht, was der Agent tun darf – das ist Aufgabe des Hosts. Der Client baut aber die Sitzung auf, übernimmt die Authentifizierung und verwaltet die Transportschicht für jede Serververbindung. Er ist ein engerer Kontrollpunkt, als die meisten Teams annehmen, wenn sie „Client“ hören.
MCP arbeitet mit diesen beiden Komponenten in einer Abfolge. Der Host legt die Umgebung fest; der Client agiert innerhalb dieser Umgebung. Wenn Sie sie nicht unterscheiden, landen Zugriffskontrollen an der falschen Stelle – und genau dort beginnen die meisten Fehlkonfigurationen.
Wo der MCP-Server in eine agentische KI-Pipeline passt
Der MCP-Server ist das Ziel mit dem höchsten Wert in der Pipeline. Alles, was der KI-Agent tatsächlich tun kann, fließt durch ihn. Ein oder mehrere MCP-Server stellen die Tools, Ressourcen und Prompts bereit, die der Agent aufrufen kann – und „Tools“ bedeutet in diesem Kontext echten Systemzugriff: eine Datei lesen, eine Datenbank abfragen, Code pushen, eine externe API aufrufen, eine Benachrichtigung senden.
Wenn ein KI-Agent einen Aufruf an den MCP-Server tätigt, stellt er keine Frage. Er fordert eine Aktion an. Die Antwort des Servers beeinflusst, was der Agent als Nächstes tut. Verfügbare Tools sind im Manifest des Servers aufgeführt, und der Agent wählt auf Basis seiner Anweisungen und seines Kontexts daraus aus. Deshalb ist MCP-Server-Sicherheit wichtiger, als sie von außen erscheinen mag: Kontrollieren Sie den Server, kontrollieren Sie die Aktionen des Agenten. Kompromittieren Sie den Server, und die agentische KI-Pipeline wird zu einem Auslieferungsmechanismus für alles, was der Angreifer ausführen lassen möchte.
Hier beginnt in der Regel das Ticket.
MCP-Sicherheitsrisiken, denen Sie tatsächlich begegnen werden
Die Risiken einer MCP-Bereitstellung sind keine hypothetischen Randfälle, die Forschende für Konferenzvorträge dokumentieren. Sie sind messbar, reproduzierbar, und mehrere davon finden sich in der Mehrheit realer Implementierungen. Die Bedrohungslandschaft lässt sich in einige klar unterscheidbare Kategorien gliedern, die unterschiedliche Schutzmaßnahmen erfordern.
Context Poisoning und indirekte Prompt Injection über MCP
Dieser Punkt überrascht Teams, weil er von außen nicht wie eine Schwachstelle aussieht. Ein böswilliger Akteur muss weder das KI-Modell noch die zugrunde liegende Datenbank angreifen. Es reicht, schädliche Inhalte über MCP in das Kontextfenster des Modells einzuschleusen – über ein Dokument, das der Agent liest, eine API-Antwort, die er empfängt, oder eine Tool-Ausgabe, die er verarbeitet.
Sobald dieser Inhalt im Kontext ist, kann er Anweisungen an das Modell geben, die dessen Verhalten überschreiben oder umleiten. Der Benutzer sieht es nicht. Die sichtbare Oberfläche sieht normal aus. Doch der Agent könnte nun Credentials exfiltrieren, Daten an einen vom Angreifer kontrollierten Endpunkt senden oder Aktionen ausführen, die der Benutzer nie autorisiert hat – nur weil eine externe Eingabe in der MCP-Umgebung ihm dies mitgeteilt hat. Invariant Labs hat diese Angriffsklasse mit funktionierenden Beispielen gegen reale MCP-Bereitstellungen demonstriert. Die Verteidigung besteht nicht darin, dem Modell stärker zu vertrauen. Sie besteht darin, nicht vertrauenswürdige externe Inhalte so zu isolieren, dass sie den Modellkontext niemals als Anweisungen enthaltende Eingabe erreichen.
Command Injection, Path Traversal und SSRF: Klassische Schwachstellen, die weiterhin gelten
Ein wiederkehrender Irrtum lautet, dass sich die Sicherheitslage von MCP hauptsächlich um Prompt Injection dreht – ein KI-Problem, das KI-Abwehrmaßnahmen erfordert. Die Daten sprechen eine andere Sprache.
Eine empirische Studie zu MCP-Implementierungen ergab, dass 43 % der getesteten Server Schwachstellen für Command Injection aufwiesen, 22 % Path Traversal oder beliebige Dateizugriffe erlaubten und 30 % SSRF-Schwachstellen hatten. Dabei handelt es sich um traditionelle Schwächen von Webanwendungen, die in KI-Tools mit Raten auftreten, die in jedem anderen Kontext alarmierend wären. Sie gelten hier, weil MCP-Server Eingaben akzeptieren, sie an Systembefehle und Dateioperationen weitergeben und ausgehende Netzwerkanfragen stellen – genau dieselben Muster, die diese Schwachstellen in herkömmlichen Anwendungen erzeugen.
Die MCP-Einordnung verändert die zugrunde liegenden Mechanismen nicht. Ein Server, der nicht bereinigte Eingaben an einen Shell-Befehl weitergibt, ist für Command Injection anfällig – unabhängig davon, ob ein LLM diese Eingabe erzeugt oder ein Mensch sie eingegeben hat. Was sich mit MCP verändert, ist die Reichweite des Angreifers: Er kann die Eingabe beeinflussen, ohne den Server jemals direkt zu berühren, indem er manipuliert, was dem KI-Agenten zum Senden mitgeteilt wurde.
📊 Die Zahlen:
In getesteten MCP-Implementierungen hatte fast die Hälfte ausnutzbare Schwachstellen für Command Injection, und nahezu ein Drittel wies SSRF-Schwachstellen auf. Das sind keine Randfälle oder theoretischen Risiken – es sind dieselben Schwachstellenklassen, die zu großen Sicherheitsverletzungen in herkömmlicher Webinfrastruktur geführt haben und nun in der Schicht auftreten, die KI-Agenten direkten Zugriff auf interne Systeme gewährt.
Server-Hijacking auf Registry-Ebene und Supply-Chain-Risiko
Dieser Punkt widerlegt das Argument „Wenn wir das LLM und die zugrunde liegenden Systeme härten, ist MCP nur Infrastruktur auf Plumbing-Ebene“ am direktesten.
Eine Studie zu 67.057 MCP-Servern in sechs öffentlichen Registries fand 833 anfällige Server sowie 18 mit verdächtigen Beschreibungen, die Manipulationen von Aufrufen und Hijacking auf Registry-Ebene ermöglichten. Der Angriff erfordert keine Schwachstelle im Code. Schwache Eigentumsprüfungen und nicht vertrauenswürdige Metadaten in der Registry reichen aus. Ein Angreifer, der einen bösartigen oder veränderten Server in die Registry einschleusen kann, den ein Agent oder Entwickler entdeckt, kann logisches Schlussfolgern des Modells und das Verhalten des Agenten großflächig beeinflussen – noch bevor der Agent das gehärtete LLM oder die gehärtete Datenbank erreicht.
MCP-Server von Drittanbietern aus öffentlichen Registries bergen ein Supply-Chain-Risiko, das mit ungeprüften npm-Paketen vergleichbar ist – und im MCP-Ökosystem ist die Prüfungsinfrastruktur weit weniger ausgereift. Sicherheitsforschende haben Tool-Poisoning-Angriffe demonstriert, bei denen scheinbar harmlose Server-Beschreibungen versteckte Anweisungen enthielten, die Agenten zur Datenexfiltration oder Umleitung von Aktionen veranlassten, ohne dass Endbenutzer einen sichtbaren Hinweis erhielten. Die Discovery-Schicht des MCP-Ökosystems ist eine Angriffsfläche. Teams, die sie nicht als solche behandeln, treffen eine Annahme, die von den Daten nicht gestützt wird.
Sicherheitskontrollen, die MCP-Risiken tatsächlich von theoretisch zu beherrschbar machen
Hier endet die Theorie. Die folgenden Kontrollen adressieren die oben beschriebenen spezifischen Fehlermodi, nicht die allgemeine Kategorie „KI-Systeme absichern“. Sie basieren auf dem praxisorientierten MCP-Leitfaden der Coalition for Secure AI und der Forschung von Astrix Security zu MCP-Credential-Praktiken.
Authentifizierung, Autorisierung und Tool-Zugriff nach dem Least-Privilege-Prinzip
Beginnen Sie mit der Identität. Jede MCP-Serververbindung sollte eine starke Authentifizierung erfordern. Mindestens TLS; gegenseitiges TLS für Server-zu-Server-Verbindungen, bei denen Sie beide Endpunkte kontrollieren. Credentials sollten kurzlebig und klar eingegrenzt sein – keine API-Schlüssel, die in Umgebungsvariablen gespeichert sind. Diese wurden laut Astrix Security „State of MCP Server Security 2025“ in 79 % der Implementierungen gefunden und sind genau die Art statischer Secrets, die Credential-Diebstahl erleichtern.
Die MCP-Autorisierung sollte exakt auf das begrenzt sein, was der KI-Agent für die jeweilige Aufgabe benötigt – nicht auf das, was bequem bereitzustellen ist. Ein Tool, das ein Agent zum Lesen von CRM-Datensätzen benötigt, sollte nicht auch Schreibzugriff erhalten, sofern der Workflow dies nicht ausdrücklich verlangt. MCP-Tools als Vertrauensgrenze zu behandeln, wie es die Sicherheitscommunity empfiehlt, bedeutet, den Zugriff auf bestimmte Verzeichnisse und APIs einzuschränken, statt weitreichende Berechtigungen zu erteilen und darauf zu vertrauen, dass das Modell innerhalb der Grenzen bleibt.
Eine praktische Checkliste für den Einstieg:
- Ersetzen Sie statische API-Schlüssel durch OAuth oder kurzlebige Tokens. Derzeit verwenden nur 8,5 % der MCP-Server OAuth. In jeder Bereitstellung, die Sie kontrollieren, muss dieser Anteil deutlich höher sein.
- Begrenzen Sie Credentials pro Tool, nicht pro Server. Ein Server mit zehn Tools sollte nicht einen Credential-Satz verwenden, der Zugriff auf alles bietet, was diese zehn Tools theoretisch benötigen könnten.
- Rotieren Sie Secrets nach Zeitplan, nicht erst nach einem Sicherheitsvorfall. Wenn die Credential-Rotation manuelle Schritte erfordert, wird sie nicht konsequent stattfinden. Automatisieren Sie sie oder akzeptieren Sie, dass sie nicht passiert.
- Prüfen Sie den Umfang der Tool-Berechtigungen quartalsweise. Verfügbare Tools sammeln im Laufe der Zeit Berechtigungen an. Was als reiner Lesezugriff begann, wird tendenziell erweitert. Überprüfen Sie dies.
Eingabevalidierung, isolierte Ausführung und was Sie nicht protokollieren sollten
Angesichts der Raten von Command Injection und Path Traversal in realen Bereitstellungen ist es nicht optional, alle externen Eingaben als nicht vertrauenswürdig zu behandeln. Validieren und bereinigen Sie alles, bevor es ein Tool erreicht, das Befehle ausführt, Dateien liest oder ausgehende Anfragen stellt. Das ist nicht MCP-spezifisch – es ist Standard für sichere Entwicklung. Die KI-Einordnung führt Teams manchmal dazu, diesen Schritt zu überspringen, weil sie glauben, das Modell sei die Validierungsschicht. Das ist es nicht.
Eine isolierte Ausführung begrenzt den Schadensradius, wenn etwas durchkommt. Ein MCP-Server, der Child-Prozesse startet oder auf das lokale Dateisystem zugreift, sollte in einer Umgebung laufen, in der diese Fähigkeiten ausdrücklich eingeschränkt sind – bestimmte Verzeichnisse, bestimmte Netzwerkziele und kein Zugriff auf Produktions-Secrets innerhalb der isolierten Umgebung. Strikte Dateisystem- und Netzwerkbegrenzungen gelten aus gutem Grund als bewährte Praxis: Ein lokaler MCP-Server mit uneingeschränktem Dateisystemzugriff ist eine Path-Traversal-Schwachstelle, die nur darauf wartet, dass jemand die passende Eingabe findet.
Zum Logging: Protokollieren Sie jeden Tool-Aufruf. Halten Sie fest, was aufgerufen wurde, mit welchen Argumenten und was zurückgegeben wurde. Ein bösartiger MCP-Server könnte jedoch versuchen, sensible Tokens aus Logs zu extrahieren, falls diese Logs zugänglich sind. Protokollieren Sie keine Rohwerte von Credentials, Auth-Tokens oder Secrets, die in Payloads erscheinen. Protokollieren Sie genug, um den Vorgang zu rekonstruieren, aber nicht genug, um einem Angreifer bei kompromittierten Logs alles Nötige zu liefern. Das ist die Empfehlung von Black Hills Information Security, die Teams regelmäßig überspringen.
MCP-Interaktionen überwachen und Transparenz über den gesamten Graphen erhalten
Ein MCP-Server tätigt nicht nur einen API-Aufruf. Er kann Ketten von Tool-Aufrufen über mehrere Systeme hinweg auslösen, und diese Ketten können sich verzweigen. Eine einzelne kompromittierte Interaktion kann sich auf Arten durch einen Workflow fortpflanzen, die in den Logs eines einzelnen Systems unsichtbar bleiben, in einer Sicht auf Graph-Ebene der Interaktionssequenz jedoch klar erkennbar sind.
Kontinuierliches Monitoring für MCP-Bereitstellungen bedeutet, nicht nur nachzuverfolgen, ob ein Tool aufgerufen wurde, sondern auch, was es nachgelagert aufgerufen hat. Achten Sie auf: Tool-Aufrufe zu Ressourcen außerhalb des erwarteten Umfangs, ungewöhnliche Argumentmuster (lange Zeichenketten in Dateisystempfaden, unerwartete Netzwerkadressen), Authentifizierungsfehler bei Tool-Aufrufen und jedes Tool, das plötzlich häufiger als seine Baseline ausgeführt wird. Veraltete MCP-Server-Konfigurationsdateien sind ebenfalls ein Signal – ein Server, der seit sechs Monaten nicht angefasst wurde, könnte von seiner ursprünglichen Sicherheitslage abgewichen sein, ohne dass es jemand bemerkt hat.
Teams, die dies in Latenode umsetzen, haben einen Vorteil: Der AI Agent Builder ermöglicht mehrstufige Orchestrierung, bei der jede Agentenaktion ein separater Workflow-Schritt mit eigenem Ausführungslog ist. Dadurch werden Tool-Aufrufketten als strukturierte Ausführungssequenzen sichtbar und nicht als intransparente Inferenzspuren – ein praktischer Weg zu der Transparenz auf Graph-Ebene, die MCP-Monitoring erfordert, ohne von Grund auf einen eigenen Observability-Stack entwickeln zu müssen.
Wer tatsächlich MCP-Sicherheitskontrollen benötigt und was diese Teams verhindern wollen
Drei Teams befassen sich derzeit mit unterschiedlichen Ausprägungen dieses Problems. Jedes versucht, einen konkreten Fehler zu verhindern, nicht eine allgemeine Kategorie von „KI-Sicherheitsrisiko“.
Sicherheits- und Plattform-Engineering-Teams, die Observability- und CI/CD-Daten für KI-Agenten bereitstellen
Diese Teams verbinden KI-Agenten mit Deployment-Pipelines, Monitoring-Systemen und Infrastruktur-APIs, damit Entwickler Build-Status abfragen, Rollbacks auslösen oder Vorfälle über eine Konversationsoberfläche untersuchen können. Sie versuchen, einen unkontrollierten Produktionspfad zu verhindern: Ein Agent, der Deployment-Logs lesen kann, könnte unter falschen Bedingungen auch Deployments auslösen. Das Bedrohungsmodell besteht aus einem fehlkonfigurierten Tool-Umfang plus einer ausreichend überzeugenden Prompt Injection in einem Incident-Report oder Log-Eintrag. Die Kontrolle, die ihnen am häufigsten fehlt, ist Tool-Zugriff nach dem Least-Privilege-Prinzip – Lese- und Schreibzugriff sauber auf der MCP-Server-Schicht getrennt. Die KI-Einführung geht in diesem Kontext schnell genug voran, dass Sicherheitskontrollen erst nachträglich ergänzt werden, also genau dann, wenn die Gefährdung bereits eingetreten ist.
Teams für Developer Experience und KI-Tools, die IDE-Integrationen und Workflows für Code-Assistenten entwickeln
Diese Teams verbinden MCP-Server mit Source-Code-Repositories, Issue-Trackern und Code-Review-Systemen, damit KI-Assistenten Entwicklern helfen können, Kontext zu finden, Korrekturen vorzuschlagen und Codebasen zu verstehen. Sie wollen unbefugte Codeänderungen und Credential-Exfiltration durch Tool Poisoning verhindern – etwa durch einen MCP-Server eines Drittanbieters, der wie ein hilfreiches Tool für die Codesuche aussieht, jedoch versteckte Anweisungen in seiner Tool-Beschreibung enthält, die den Agenten dazu umleiten, API-Schlüssel aus .env-Dateien zu exfiltrieren. Sicherheitsexperten in diesem Bereich behandeln jeden Registry-Eintrag eines MCP-Drittanbieters zunehmend so, wie Application-Security-Teams ungeprüfte npm-Pakete behandeln: als nicht vertrauenswürdiges Artefakt, das vor dem Einsatz in der Produktion geprüft werden muss. KI-Assistenten mit Zugriff auf Source-Code-Repositories sind hochwertige Ziele, und der Supply-Chain-Vektor über die Registry ist derjenige, den die meisten Teams für Developer Tools noch nicht vollständig berücksichtigt haben.
AppSec- und DevSecOps-Teams, die einer neuen KI-Angriffsfläche zuvorkommen wollen
Diese Teams erleben MCP als Schatten-IT: Neue KI-Tools tauchen immer wieder in Produktionsumgebungen auf, jedes mit eigener MCP-Server-Konfiguration, ohne zentrale Inventarisierung und mit unklaren Zugriffsbereichen. Sie wollen Registry-Hijacking und nicht erfasste Zugriffspfade verhindern – Situationen, in denen einem Agent der Zugriff auf ein System gewährt wurde, dessen Auditierung Compliance-Vorgaben verlangen, aber niemand den MCP-Server zum Asset-Inventar hinzugefügt hat, weil ein Entwickler ihn an einem Freitagnachmittag installierte. Die neue KI-Herausforderung ist hier keine technische. Sie ist eine Governance-Herausforderung. Die Agenten selbst werden zunehmend gut geregelt; die Server, mit denen sie sich verbinden, sind es nicht.
Drei Missverständnisse über MCP-Sicherheit, die echte Lücken schaffen
Diese drei Missverständnisse tauchen wiederholt vor Sicherheitsvorfällen auf. Nicht in der theoretischen Phase, in der sie leicht zu korrigieren wären. Sondern in der Designphase, in der sie die Architektur prägen.
Missverständnis eins: MCP ist nur ein weiteres Plugin-System, daher decken API-Sicherheitskontrollen es ab. Das klingt plausibel, bis Sie sich das Vertrauensmodell ansehen. Eine herkömmliche API-Integration hat einen definierten Client, einen definierten Endpunkt und einen festen Satz von Operationen, die der Client anfordern kann. MCP erlaubt einem KI-Agenten, Tools dynamisch auf Basis seines Laufzeitkontexts und seiner Anweisungen zu entdecken und aufzurufen. Die Entscheidungen des Agenten werden durch Eingaben geprägt, die der Sicherheits-Stack oft nie berührt – Tool-Beschreibungen, aus externen Dokumenten eingeschleuster Kontext, Registry-Metadaten. Standard-API-Kontrollen können nicht prüfen, was dem Agenten als Entscheidungsgrundlage mitgeteilt wurde; sie können nur beobachten, was er anschließend angefordert hat. Diese Lücke ist die MCP-spezifische Angriffsfläche.
Missverständnis zwei: Wenn das LLM und die zugrunde liegenden Systeme gehärtet sind, ist MCP ein nachrangiger Middleware-Aspekt. In diese Denkweise geraten sicherheitsbewusste Teams am häufigsten, weshalb sie auch die gefährlichste ist. Teams, die erheblich in LLM-Sicherheit und die Härtung ihrer Infrastruktur investiert haben, behandeln MCP oft als Plumbing – als Rohr zwischen zwei sicheren Dingen. Doch genau dieses Rohr ist der Angriffspfad, den die Forschung auf Registry-Ebene identifiziert hat. Die arXiv-Studie zu 67.057 Servern konnte Bedingungen für Hijacking auf Registry-Ebene in öffentlichen Registries feststellen, ohne dass es eine Schwachstelle im Code der zugrunde liegenden Systeme gab. Der Agent kann nur über MCP-Tools handeln. Kontrollieren Sie die Tools, kontrollieren Sie den Agenten – unabhängig davon, wie stark das Modell oder die Datenbank dahinter gehärtet sein mag.
🤔 Moment.
Wenn ein KI-Agent nur über MCP-Tools handeln kann, hat ein kompromittierter MCP-Server direkten Zugriff auf alles, wofür dem Agenten Berechtigungen erteilt wurden. Das Sicherheitstraining des LLM hilft hier nicht – Sicherheitstraining betrifft, was das Modell nicht erzeugen will, nicht was eine manipulierte Tool-Anweisung ihm zur Ausführung vorgibt. Der Schadensradius eines kompromittierten Servers entspricht exakt dem Berechtigungsumfang des Servers. Haben Sie diesen kürzlich eingegrenzt?
Missverständnis drei: Prompt Injection ist das einzige echte MCP-Sicherheitsproblem. Wenn wir das behandeln, sind wir abgesichert. Die Equixly-Statistiken zu Injection und SSRF widerlegen dies direkt. 43 % Command Injection, 30 % SSRF, 22 % Path Traversal – das sind klassische Infrastrukturschwachstellen, die in KI-Tools mit Raten auftreten, welche in jedem herkömmlichen Kontext Remediation-Programme auslösen würden. Prompt Injection ist eine reale und wichtige Bedrohungsklasse. Sie ist nicht die einzige. MCP-Server akzeptieren Eingaben von KI-Agenten und führen echte Operationen auf echten Systemen aus. Sie sind über das Web erreichbare Dienste. Sie sollten mit denselben sicheren Entwicklungspraktiken behandelt werden wie jeder andere über das Web erreichbare Dienst.
Ich sehe weiterhin Teams, die die Arbeit an klassischen Schwachstellen überspringen, weil die MCP-Sicherheitsdebatte von KI-spezifischen Angriffsvektoren dominiert wurde. Diese Einordnung ist korrekt, soweit sie reicht. Sie reicht nur nicht weit genug.
Wie die Zukunft der MCP-Sicherheit mit der Reifung des Ökosystems aussieht
Einige Entwicklungen sind eindeutig im Gange. Andere sind echte offene Probleme, die weder Anbieter noch Standardisierungsgremien gelöst haben.
Registry-Governance ist die offensichtlichste Lücke. Die Diskussion um MCP-Sicherheitschecklisten hat sich im vergangenen Jahr schnell weiterentwickelt, aber es gibt weiterhin keinen standardisierten Prozess zur Serververifizierung für öffentliche Registries. Jeder kann einen MCP-Server veröffentlichen. Die Einführung von MCP in Entwickler-Tools hat die Fähigkeit des Ökosystems überholt, das Übernommene zu prüfen. Remote-MCP-Server, die über öffentliche Registries entdeckt werden, bergen dasselbe Supply-Chain-Risiko wie ungeprüfte Open-Source-Pakete – allerdings ohne die sozialen Governance-Signale, die npm- und PyPI-Communities zur Identifizierung verdächtiger Pakete nutzen.
Standardisierte Server-Signierung ist die technische Antwort. Doch eine Signierung auf Ebene des MCP-Ökosystems zu unterstützen, erfordert Koordination zwischen mehreren Registry-Betreibern und Toolchain-Anbietern. Diese Koordination befindet sich noch in einer frühen Phase. Die Erkenntnis aus der Astrix-Forschung, dass 88 % der Server Credentials benötigen, während die meisten statische Secrets verwenden, legt nahe, dass die Identitätsschicht Standardisierungsarbeit benötigt, bevor die Signierungsschicht relevant wird.
Missbrauch von Kontext über mehrere Agenten hinweg ist ein aufkommendes Bedrohungsmodell, das noch nicht gut definiert ist. Je verbreiteter Multi-MCP-Bereitstellungen werden – ein Agent ruft Tools mehrerer Server auf und teilt Kontext zwischen ihnen –, desto stärker wächst die Interaktionsfläche für Context Poisoning und Privilegieneskalation in einer Weise, die Sicherheitsmodelle für einzelne Server nicht abdecken. Wer trägt die Verantwortung für die Auditierung einer Kontextkette, die drei Server im Besitz von drei Teams überschreitet? Auf diese Frage gibt es heute keine klare Antwort. Ich erwarte, dass sie die erste Welle schwerwiegender Vorfälle mit agentischer KI auslösen wird, wenn jemand es auf die harte Tour herausfindet.
