Nützlich, aber gefährlich : Betrachtungen zum Model-Context-Protocol für den Cybersecurity-Einsatz und als Sicherheitsproblem

Model, Agent und Kontext

Bei der bisherigen Nutzung von KI-Agenten und deren Schnittstellen (Agentic AI) gibt es meist größere und wiederkehrende Aufwände unter anderem für die Spezifizierung der Interaktion mit dem Large Language-Model und beispielsweise der Erstellung von Befehlen sowie Ausgaben für einen REST-API-Endpoint. Mit MCP gibt es nun einen Standard, der festlegt, wie APIs einem LLM Informationen präsentieren und dazu auch Kontextinformationen einbeziehen: Diese können zum Beispiel den Umgang mit einer bestimmten Datenquelle, einem Werkzeug oder einer Anwendung beschreiben.

Auf diese Weise lassen sich leicht viele MCP-fähige Tools in einen Workflow integrieren, den ein KI-Agent steuert. Für selbstbestimmte, autonome Softwareagenten, die eigenständig Aufgaben (Informationsbeschaffung, Toolnutzung, Koordination etc.) übernehmen, dient MCP somit als technische Grundlage für eine „ökosystemische“ KI, in der Agenten modulare Aufgaben erledigen und flexibel mit externen Ressourcen interagieren.

Das Zukunftsversprechen durch vernetztes Handeln und dynamische Skalierung umfasst hierbei die komplette KI-gestützte Automation von industriellen Prozessen, persönlichem Assistenzwesen sowie Multi-Agent-Kollaboration.

Komponenten, Aufbau und Funktionweise

MCP basiert auf einer recht klassischen Client-Server-Architektur, die natürlich für die KI-Nutzung angepasst wurde (vgl. Abb. 1). Daran sind die folgenden Akteure beziehungsweise Komponenten beteiligt:

• Die genutzte KI-Anwendung (z.B. eine generative KI-App, ein Vibe-Coding-Programm oder ein KISOC-Analyst) dient als MCP-Host: Dieser verwaltet die Verbindungen zu verschiedenen MCP-Servern und kommuniziert normalerweise mit dem verwendeten Model (LLM). Er soll sicherstellen, dass alle Aktionen der KI autorisiert werden
• Innerhalb des Hosts läuft der MCP-Client, der als Konnektor jeweils eine dedizierte Verbindung zu einem MCP-Server (über JSONRPC 2.0) aufrecht hält. Dabei kümmert er sich um die Protokolldetails, ermittelt Fähigkeiten des Servers und managt den Nachrichtenaustausch.
• Der MCP-Server fungiert als Übersetzer beziehungsweise Wrapper: Funktionen eines externen Systems (z.B. API einer Sicherheitsanwendung, ein Workflow, lokale Dateien oder eine Datenbank) werden im MCP-Format bereitgestellt – der Server stellt also Tools und Daten bereit.

MCP arbeitet mit einigen grundlegenden „Features“, die aus Sicherheitssicht besonders zu betrachten sind:

• Als Tools bezeichnet man die Funktionen, die LLMs aufrufen können – sie sind sozusagen die „Knöpfe“, die eine KI drücken kann. Sollte es sich hierbei um Befehle handeln (z.B. „contain this device!“) ist es angebracht, genauer über Sicherheit und Nutzerfreigaben nachzudenken.
• Die Datenpunkte, auf die KI-Anwendungen lesend zugreifen können, werden als Resources bezeichnet. Letztendlich sind dies die Daten, die der KI den Kontext liefern (z.B. Richtlinien, Logs, Threat Intelligence etc.). Die KI kann sie nutzen, aber nicht verändern.
• Durch Nutzer vordefinierte Anweisungen, Workflows und Templates, die der KI zeigen, wie sie Tools oder Daten für komplexe Aufgaben optimal einsetzt, nennt man auch hier Prompts. Durch sie werden Interaktionen strukturiert und optimiert.

Überdies dürften auch die Prozesse für die Initialisierung, bei der Erkennung und Kontextbereitstellung sowie die automatisierte Synchronisation und das Zustandsmanagement für Agenten-Workflows Merkmale des Protokolls darstellen, die Sicherheitsforschern zukünftig bestimmt noch „viel Freude“ bereiten werden.

Vorzüge und neue Risiken

Grundsätzlich lässt sich jedoch feststellen, dass man durch die Ablösung des Kopplungsproblems (von M×N zu M+N) eine verbesserte Skalierbarkeit des gesamten Systems erlangt. Darüber hinaus stellt MCP eine dynamische Erkennung von Tools sowie deren Integration bereit („Plug & Play“) und gibt sich dadurch entwicklerfreundlich, flexibel und agnostisch gegenüber LLMs und Plattformen. Außerdem wird Sicherheit durch Zugriffskontrollen und die Verwaltung von Zugriffsrechten integriert. Die Trennung zwischen Datenabruf (Resources) und Aktionen (Tools) folgt dem Prinzip minimaler Berechtigungen (Least Privilege-Principle).

MCP ermöglicht aber, wie bereits erwähnt, die dynamische Entdeckung von Fähigkeiten sowie einen bidirektionalen Austausch: Mit der Sampling-Funktion kann der Server sogar Aufgaben und Anfragen an das auf dem MCP-Host laufende LLM übergeben, ohne selbst direkten Zugriff auf das LLM zu haben.

Das ermöglicht zwar komplexe KI Ketten, muss aber, um Missbrauch zu verhindern, sorgfältig kontrolliert werden – umso mehr, wenn man bedenkt, dass sich damit beispielsweise sogar Windows  11 (dessen Einstellungen, Dateisystem und Anwendungsberechtigungen) mittels MCP von einem LLM fernsteuern ließe (siehe auch [7]).

Heilsbringer der Cybersicherheit?

Derzeit wird sehr offensiv der Einsatz von MCP in Security-Operations-Centers (SOCs) von Organisationen oder Managed-Security-Service-(MSSP)-Providern diskutiert: Die Vorstellung, dass ein SOC, in dem KI-Agenten Routineaufgaben wie Analyse und Reaktion übernehmen, während menschliche Analysten sich auf Überwachung, komplexe Probleme und strategische Bedrohungsjagd konzentrieren können, soll hier sowohl den Arbeitsplatz an sich attraktiver machen als auch dem Fachkräftemangel begegnen.

Das Ziel ist ferner auch, durch eine verstärkte Integration von Detektionswerkzeugen, schnelle Bereitstellung technischer Bedrohungslageninformationen sowie automatisierte Behebungen wesentliche Leistungskennzahlen (Key-Performance-Indicators, KPIs) der Sicherheit deutlich zu verbessern – etwa die Mean Time to Detect (MTTD) oder Mean Time to Respond (MTTR).

Die Idee dahinter: Agenten fragen über MCP Logs aus SIEM-Systemen ab, korrelieren Ereignisse, fassen Vorfälle zusammen oder lösen automatisierte Reaktionen aus (SOAR). Die KI kann SIEM-Alarme (Resources) analysieren oder gezielte Suchen (Tools) durchführen und dabei verschiedene Query-Languages abbilden. MCP könnte so zur Steuerzentrale für KI-Agenten werden, die je nach Vorfall passende Playbooks und Tools auswählen, diese ausführen und damit die Aufgaben von Security-Orchestration, -Automation and -Response (SOAR) übernehmen.

In verschiedenen anderen Sicherheitsbereichen, die aber idealerweise auch mit einem SOC verbunden sind, ließe sich MCP ebenfalls sinnvoll einsetzen, indem es KI-Agenten über eine gemeinsame Sprache mit spezialisierten Tools verbindet: Solche KI-Agenten könnten das Protokoll etwa nutzen, um den Status von Endpoints abzufragen (z.B. über EDR-Lösungen), Logs zu analysieren, Scans zu starten oder Maschinen zu sperren. Entsprechende MCP-Server gibt es bereits.

Überdies ermöglicht MCP KI-Agenten die Kommunikation mit Analyse-Tools – etwa das Senden von Samples, das Abrufen von Berichten (z.B. über MISP mit MISPerer, vgl. www.misp-project.org und https://github.com/Eacus/misp-mcp) oder die Anbindung an Reverse Engineering-Tools wie Ghidra (via ghidraMCP, siehe https://github.com/NationalSecurityAgency/ghidra und https://github.com/LaurieWired/GhidraMCP). Über spezifische MCP-Server könnten Agenten auch Threat-Intelligence-Plattformen wie MISP oder OpenCTI nach technischen Angriffsindikatoren (IOCs) abfragen.

MCP ersetzt keine Sicherheitstools, gibt der KI aber eine standardisierte Schnittstelle an die Hand – quasi als universelle Fernbedienung für KI-Agenten im SOC. Es gibt mittlerweile MCP-Server für Firewalls, Schwachstellenscanner, Cloud-Security und weitere Domänen – und die Liste wächst weiter.

Weitere zentrale Anwendungsfälle für MCP können die Prüfung von Zugriffsprotokollen durch KI-Agenten, die Analyse von Berechtigungen oder das Durchsetzen und Auditieren von Regeln durch verfügbare Plattformen und Anwendungen sein. Hierbei dürften Sicherheitsverantwortliche aber sicher schon hellhörig werden, da man beim automatischen Ändern von Zugriffsregeln (über Tools) strenge Freigabeprozesse einhalten sollte.

Generell hängen Sicherheit und Effektivität stark von der Qualität und Absicherung der eingesetzten MCPServer ab (siehe auch [2]). Ein verwundbarer MCP-Server für EDR oder eine Firewall kann schließlich ein erhebliches Risiko und ein Einfallstor für Angreifer darstellen.

Alternativen zu MCP

Neben bereits bestehenden herstellerabhängigen, proprietären Anwendungsschnittstellen (APIs) und Integrations-Frameworks, die unter Umständen mit einem hohem Integrationsaufwand verbunden sind, haben im dynamischen KI-Markt kürzlich weitere MCP-Alternativen das Licht der Welt erblickt:

Google und einige Partner haben das Agentto-Agent-Protocol (A2A) veröffentlicht, bei dem der Fokus eher auf Interoperabilität zwischen Agenten in einer Multi-Agent-Umgebung liegt und das als universelle Sprache für Agenten positioniert wird. Für einen Vergleich siehe etwa https://a2a-mcp.org/.

In Entwicklungsplattformen für KI-Agenten (z.B. LangChain), die besonders im LLM-Ökosystem verbreitet sind, finden sich ähnliche integrierte Funktionen, aber meist mit weniger standardisierter Interoperabilität als bei MCP. Anbieter großer Sprachmodelle (bspw. OpenAI) liefern zudem ebenfalls Plug-ins und eigene Schnittstellen.

Parallel wird bereits an weiteren experimentellen Protokollen und Standards gearbeitet – zum Beispiel dem „Multi-Agent Collaboration Protocol“.

Momentan gewinnt MCP allerdings rasch an Verbreitung und Support.

Ablösung der „Plattformisierung“

Sicherheitsverantwortliche haben in der Vergangenheit oft den Ansatz der Konsolidierung durch die Nutzung eines vereinheitlichten Stacks größerer Anbieter gewählt. Dabei verzichteten sie gegebenenfalls auch auf sogenannte Best-of-Breed-Funktionen und argumentierten wirtschaftlich: Tools konsolidieren, Anbieter reduzieren, Abläufe vereinfachen, Kosten senken. Zum Teil wurde auch eine bessere Wirksamkeit angeführt, aber selten bewiesen. Ganz im Gegenteil war doch der Aufwand sehr groß, Daten angemessen zu zentralisieren und die Integrationen zu skalieren – gleichzeitig stieg die Gefahr eines „Vendor-Lock-in“, also die Abhängigkeit von einem Lieferanten (und seinem Preismodell).

MCP-Apologeten rufen nun das Ende dieser Ära aus: Sie beschreiben eine Welt, in der MCP-Schnittstellen in verschiedenster Sicherheitstechnologie (EDR, NDR, IAM, CNAPP etc.) sowie im IT-Service-Management dazu dienen kann, um Workflow-Daten unterschiedlicher Tools ohne Integration zu nutzen, zentrale Data-Lakes obsolet zu machen und die Verantwortlichkeiten zwischen Agenten sowie Datenlieferanten zu trennen.

So soll an die Stelle der Aggregierung von Telemetriedaten eher die Orchestrierung der Werkzeuge treten. MCP soll als „Bindegewebe“ (Fabric) die einfache Integration und in einem föderierten Sicherheitsgeflecht Analyse, Richtlinienmanagement und Automatisierung oberhalb der Anbieter-Ebene ermöglichen. Gleichzeitig würde dies das Ende von zumindest reinen Aggregationslösungen wie XDR, SIEM und SOAR bedeuten. Ob es so weit kommen kann, wird sich zeigen.

Gefahrenpotenzial

Was klar sein sollte: Ein unkontrollierter Einsatz von MCP wird die Sicherheit nicht erhöhen, sondern neue Sicherheitsprobleme schaffen und die Angriffsfläche vergrößern. Dabei kann vieles, wenn nicht sogar „alles“ schiefgehen.

Wie bei allen hochkomplexen und integrierten Systemen kann es zu einem Kontrollverlust über Datenflüsse und Aktionen kommen. Durch die Ausnutzung unbeachteter Sicherheitslücken an einer Stelle erhöht eine umfassende Integration zudem die Gefahr der Eskalation zu einem systemübergreifenden Angriff. Missbrauchspotenzial besteht auch durch die automatisierte Verkettung von Aktionen mit externen Tools (z.B. Massen-E‑MailVersand oder Eskalation von Rechten). All dies zeigt die Notwendigkeit automatisierter Monitoring- und Regelsysteme zur Begrenzung von Risiken, da sonst ein Vertrauensverlust in KI-Systeme und regulatorische Probleme (z.B. mit dem EU-AI Act) drohen.

Im Bereich der generativen KI gibt es bei LLMs und Agenten bereits viele neue Angriffsvektoren – gerade die Prompt-Injection hat es bereits zu einiger Berühmtheit gebracht (vgl. S. 11 und S. 20). Direkte oder über externe Schnittstellen durchgeführte Angriffe haben bereits zu etlichen Schäden (u. a. Datenabfluss und unberechtigter Zugriff) geführt; schlecht gesicherte MCP-Server erhöhen hier die Probleme dramatisch, da meist mehr Möglichkeiten eines Eingriffs und für Manipulationen bestehen. Risiken durch zu weit gefasste Berechtigungen oder unsichere Kontextnachlieferung sind ebenfalls real (z.B. Exponierung sensibler Daten oder Seiteneffekte durch Kontextmanipulation). Bislang fehlende oder unausgereifte Sicherheitsmechanismen in vielen Implementierungen verschärfen die Lage noch – besonders bei der Umsetzung von Authentifizierung und Autorisierung.

Schwachpunkte, bekannte und mögliche Angriffe

Bei einer versteckten Prompt-Injection nutzen Angreifer (z.B. bei Anfragen an Support-Mitarbeiter) spezielle Anweisungen im Text, die nur eine KI „versteht“. KI-Assistenten, die hier unterstützen und über einen MCP-Server auf sensible Daten und Geschäftsprozesse zugreifen können, ermöglichen so unter Umständen den unerwünschten Zugriff auf sensible Daten. Diese Schwachstelle kann man gegebenenfalls schließen, indem man für KI-Interaktionen das Least-Privilege-Prinzip durchsetzt, Prompts in Echtzeit auf verdächtige Inhalte analysiert und Audit-Protokolle aller MCP-Aktivitäten führt.

KI-Agenten gaben jedoch auch schon Daten preis oder führten Schadcode über bösartige Prompts aus, die alles andere als versteckt waren. Die Prompt-Injection wurde dazu auf andere verfügbare Plattformen ausgelagert: Sicherheitsforscher haben dies am Beispiel eines GitHub-MCP-Servers demonstriert [3], die Prompt-Injection erfolgt dabei über ein maliziöses „Issue“ in einem öffentlichen Repository. Agenten, die auf dieses Repository zugreifen, werden dann getäuscht und verarbeiten den bösartigen Prompt, der beispielsweise die KI auffordert, andere Daten bereitzustellen, auf die ein MCP-Server Zugriff hat. Man könnte zwar sämtliche Tool-Aufrufe durch menschliche Benutzer bestätigen lassen, aber wahrscheinlich ist solche Vorsicht in realen Umgebungen eher nicht anzutreffen.

Command-Injections können ebenso stattfinden: Findet keine Validierung eines Inputs durch den MCPServer statt und dieser wird ohne Prüfung an andere Systeme weitergeleitet, können dort Befehle eingeschleust werden (ähnlich wie bei einer SQL-Injection über ein Web-Frontend). MCP-Server sollten also so eingestellt sein, dass sie keinesfalls Benutzereingaben beispielsweise direkt an eine Shell weiterleiten – Inputs müssen validiert und parametrisierte Befehle verwendet werden.

Ähnlich wie bei schlecht gesicherten Cloud-Infrastrukturen und Cross-Site-Scripting (CSS) kann es außerdem zu einem Datenleck von einem Tenant auf einen oder mehrere andere kommen, sodass eine Gruppe von Benutzern auf Daten anderer User zugreifen kann. Eine derartige Schwachstelle wurde bereits in der MCP-Server-Implementierung von Asana entdeckt [4]. Es gilt also sicherzustellen, dass MCP-Server eine strikte Mandantentrennung durchsetzen. Außerdem sollte beim Zugriff auch hier das Least-Privilege-Prinzip angewendet werden.

Wie in anderen Sicherheitsbereichen, besteht auch im Bereich MCP-Server die Gefahr einer Supply-ChainAttacke: Frei zum Download verfügbare MCP-Server können etwa (auch nachträglich) infiziert und manipuliert werden, um beispielsweise Daten aus anderen Systemen zu extrahieren. Sämtliche Informationen, die MCP-Server generieren, könnten auf diese Weise zur Beute von Angreifern werden. Daher ist unbedingt zu prüfen, ob die Bezugsquelle für einen MCP-Server vertrauenswürdig ist. Hier helfen Listen mit Informationen zu MCP-Servern und deren bekannten Schwachstellen.

Des Weiteren sollten die Berechtigungen (z.B. Zugriffe auf ein Dateisystem) für den MCP-Server überprüft und angepasst werden. Fun-Fact – oder vielleicht auch weniger „lustig“ – ist an dieser Stelle, dass Sicherheitsforscher bereits eine kritische Sicherheitslücke in einem Debugging-Tool für MCP-Server (MCP Inspector von Anthropic) gefunden haben, mittels derer Angreifer ohne vorherige Anmeldung Schadcode auf verwundbaren Systemen ausführen konnten (vgl. [5]).

Probleme tauchen auch durch das Verketten von MCP-Servern auf, bei dem vermeintlich legitime Outputs mit bösartigen Prompts von einem MCP-Server zum nächsten geliefert werden. Sollte ein Agent mehrere Server verwenden, könnte es dazu kommen, dass ein Server den Agenten dazu „verleitet“, einen anderen Server zu missbrauchen.

Grundsätzlich spielen natürlich auch klassische Angriffsvektoren eine bedeutende Rolle: MCP-Server mit keiner oder unzureichender Identitäts- und Rechteprüfung, die womöglich noch für Dritte offen sind, könnten es Angreifern ermöglichen, durch Privilege-Escalation große Schäden anzurichten. Die unzureichende Sicherung von Authentifizierungstoken auf MCP-Servern, die so zur leichten Beute für Angreifer werden, ließen sich dann zum „legitimen“ Zugriff auf andere Systeme (z.B. E-Mail-Konten) missbrauchen.

Die Liste der Schwachstellen und ihrer (möglichen) Ausnutzung füllt sich weiterhin Woche um Woche – so lassen sich an dieser Stelle nicht alle aufführen und beschreiben. Offensichtlich ist, dass der Einsatz von MCP-Servern die eigene Angriffsfläche signifikant vergrößern kann.

Fazit und Ausblick

MCP ist Open Source, erfreut sich zunehmender Beliebtheit und verbreitet sich schnell. Neben vielen Chancen durch den verbesserten Einsatz von Agentic AI – nicht nur, aber auch in der Cybersicherheit – bringt es auch große Herausforderungen in Bezug auf die Sicherheit von Daten und Systemen mit sich. Sicherheitsrisiken wie angreifbare MCP-Server, gestohlene Zugangsdaten, Prompt-Injections oder unzureichende Zugriffskontrollen dürfen keinesfalls ignoriert werden.

Im Bereich der Cybersicherheit wird MCP nur dann sein volles Potenzial entfalten können, wenn man die folgenden Maßnahmen proaktiv angeht:

• sorgfältige Prüfung der Server
• lückenloses Monitoring
• starke Authentifizierung und Input-Validierung
• strikte Nutzerfreigaben für Aktionen
• Nutzung von Sicherheitskonzepten wie MCPPAM [6], die speziell für das KI-Agenten-Zeitalter entwickelt werden
• Durchsetzung von Vorgaben, Leitplanken und Richtlinien für Aktionen des gesamten KI-Systems

Momentan werden immer mehr MCP-Server und mehr Entwicklungsumgebungen (SDKs) in verschiedenen Sprachen verfügbar – große KI- und Cybersicherheitsunternehmen steigen ein. Die Autoren sehen daher folgende mögliche Entwicklungen:

• Mit besseren LLMs übernehmen KI-Agenten komplexere Sicherheitsaufgaben – mit weniger direktem menschlichen Eingriff.
• Der KI-Security-Markt wächst und spezielle Lösungen wie MCP-PAM oder AI-Security-Posture-Management (AI-SPM) werden speziell für die Verwaltung von KI-Agenten über MCP entwickelt – alle größeren Anbieter haben mittlerweile schon kleinere Nischenanbieter aufgekauft.
• Es könnten zertifizierte Server, standardisierte Protokolle und vertrauenswürdige „App-Stores“ für MCP-Server entstehen, um die Sicherheit und Zuverlässigkeit zu steigern.
• MCP könnte sich als De-facto-Standard durchsetzen, um KI und (Sicherheits-) Tools zu verbinden – mit der Möglichkeit, in natürlicher Sprache Fragen zu stellen und Befehle zu erteilen.

Wie fast immer, hat auch diese neue „Technologie-Medaille“ zwei Seiten und liefert einmal mehr eine Übung in Ambiguitätstoleranz. Um allerdings einen wirklichen Mehrwert in der Cybersicherheit durch den Einsatz von MCP zu schaffen, ist es unerlässlich, die Sicherheitsprobleme von MCP zu adressieren und zu beheben.

Paula Hemker (CC, CSA) ist Presales Consultant bei der genua GmbH – ihren Einstieg in die Security-Branche fand sie als Fachinformatikerin für Anwendungsentwicklung und als SOC-Analystin.

Thomas Hemker (CISSP, CISM, CISA, CDPSE) ist bei der DCSO Deutsche Cyber-Sicherheitsorganisation GmbH verantwortlich für den Threat Intelligence Service und Mitglied im Expertenkreis Cybersicherheit des BSI.

Literatur

_{[1] Anthropic / Model Context Protocol Community, MCP-Specification, Juni 2025, https://modelcontextprotocol.io/specification/2025-06-18/}

_{[2] Backslash, MCP Server Security Hub, Model Context Protocol (MCP) Risk Database, fortlaufend, https://mcp.backslash.security}  

_{[3] Marco Milanta, Luca Beurer-Kellner, GitHub MCP Exploited: Accessing private repositories via MCP, Invarianlabs Blog, Mai 2025, https://invariantlabs.ai/blog/mcp-github-vulnerability}  

_{[4] Howard Solomon, MCP-Bug bei Asana könnte Unternehmensdaten offengelegt haben, News-Analyse, CSO online, Juni 2025, www.csoonline.com/article/4011023/}

_{[5] Avi Lumelsky, Critical RCE Vulnerability in Anthropic MCP Inspector – CVE-2025-49596, Oligo Security Research Blog, Juni 2025, www.oligo.security/blog/critical-rce-vulnerability-in-anthropic-mcp-inspector-cve-2025-49596}  

_{[6] Kenny Park, MCP PAM as the Next Step Beyond Guardrails, QueryPie Whitepaper, April 2025, www.querypie.com/features/documentation/white-paper/16/next-step-mcp-pam}   

_{[7] Zac Bowden, Microsoft has issued an urgent warning to Windows 11 users: The new agentic OS features that allow AI agents to operate also open the door to malware, Windows Central, November 2025, www.windowscentral.com/microsoft/windows-11/microsoft-warns-security-risks-agentic-os-windows-11-xpia-malware}