MCP Security: Risiken und Best Practices für sichere KI-Agenten

MCP Security wird für Unternehmen relevant, sobald KI-Agenten nicht mehr nur Texte erzeugen, sondern mit Dateien, APIs, Datenbanken, Ticketsystemen, Cloud-Ressourcen oder Entwicklungsumgebungen arbeiten. Das Model Context Protocol standardisiert genau diese Verbindung zwischen KI-Anwendungen und externen Systemen. Anthropic hat MCP im November 2024 als offenen Standard vorgestellt, um isolierte KI-Assistenten besser mit den Datenquellen und Tools zu verbinden, die sie für nützliche Arbeit brauchen.

Für eine technische Einordnung, wie ein MCP-Server grundsätzlich aufgebaut ist, lohnt sich zuerst die technische Einführung in MCP-Server. Dieser Beitrag baut darauf auf und betrachtet MCP aus Security-Perspektive: Welche neuen Angriffsflächen entstehen, welche Fehler sind in produktiven Umgebungen besonders gefährlich und welche Kontrollen sollten Unternehmen vor dem Rollout einziehen?

Warum MCP Security wichtig ist

MCP löst ein echtes Integrationsproblem. Statt für jedes Modell und jedes Tool eine eigene Verbindung zu bauen, können Anwendungen über MCP mit standardisierten Servern sprechen. Die aktuelle Spezifikation beschreibt dafür Hosts, Clients und Server sowie JSON-RPC, stateful connections und Capability Negotiation. Server können unter anderem Resources, Prompts und Tools bereitstellen.

Sicherheitstechnisch ist genau das der spannende Punkt: Ein MCP-Server ist nicht nur ein Datenlieferant. Er kann dem Modell Kontext geben, Tools anbieten, Aktionen auslösen und mit Systemen sprechen, die außerhalb des Modells liegen. In agentischen Szenarien wird daraus schnell eine Kette aus Nutzeranfrage, Modellentscheidung, Tool-Aufruf, externer Datenquelle und weiterer Aktion.

Das macht MCP nicht per se unsicher. Es bedeutet aber: MCP muss wie eine produktive Integrationsschicht behandelt werden, nicht wie ein harmloses Chatbot-Plugin. Wer MCP-Server ungeprüft installiert, mit breiten Tokens ausstattet oder ohne Monitoring in produktive Workflows einbindet, verschiebt klassische AppSec-, Identity-, Cloud- und Supply-Chain-Risiken direkt in den KI-Agenten.

MCP-Architektur kurz erklärt

Ein typisches MCP-Setup besteht aus drei Rollen. Der Host ist die KI-Anwendung, zum Beispiel eine IDE, ein Desktop-Client oder ein internes Agentensystem. Innerhalb des Hosts läuft ein MCP-Client, der eine Verbindung zu einem konkreten MCP-Server hält. Dieser Server stellt Kontext, Tools oder Prompt-Vorlagen bereit.

Bei den Transporten sind besonders stdio und Streamable HTTP relevant. stdio ist typisch für lokale Prozesse, bei denen ein Client einen MCP-Server als Subprozess startet. Streamable HTTP ist für Remote-Szenarien wichtig und passt besser zu API-Gateways, Authentifizierung und skalierbaren Deployments. Die Sicherheitsgrenzen unterscheiden sich deutlich: Ein lokaler Prozess braucht Prozess- und Dateisystemisolation, ein Remote-Server braucht starke Netzwerk-, Auth- und Session-Kontrollen.

Die wichtigsten MCP-Sicherheitsrisiken

Die OWASP MCP Top 10 ordnen die wichtigsten Risikoarten in Kategorien wie Token Mismanagement, Scope Creep, Tool Poisoning, Supply-Chain-Angriffe, Command Injection, fehlende Authentifizierung und Shadow MCP Servers ein. Diese Taxonomie ist hilfreich, weil sie zeigt: MCP Security ist kein einzelnes Tool-Problem, sondern ein Zusammenspiel aus Identität, Kontext, Ausführung, Berechtigungen und Governance.

Auch Security-Teams aus der Praxis beschreiben MCP vor allem als neue Integrations- und Vertrauensschicht. Palo Alto Networks hebt insbesondere Prompt Injection, Credential Exposure und ungeprüfte Drittanbieter-Tools als naheliegende Risikoklassen hervor. Diese Einordnung passt gut zur operativen Realität: Sobald MCP-Server produktive Systeme anbinden, geht es nicht mehr nur um Modellverhalten, sondern um echte Daten- und Aktionsrechte.

Tool Poisoning und Prompt Injection

Tool Poisoning ist eine der MCP-spezifischsten Angriffsklassen. Invariant Labs zeigte 2025, dass schädliche Anweisungen in Tool-Beschreibungen für Nutzer kaum sichtbar sein können, vom Modell aber verarbeitet werden. Ein harmlos wirkendes Tool kann das Modell beispielsweise dazu bringen, lokale Konfigurationsdateien oder Secrets zu lesen und über Tool-Parameter weiterzugeben.

Prompt Injection ist breiter. Dabei enthalten externe Daten – etwa Tickets, GitHub-Issues, Webseiten, Dokumente oder Datenbankeinträge – versteckte Instruktionen. Ein Agent soll eigentlich Informationen auswerten, interpretiert den eingebetteten Text aber als Handlungsanweisung. Red Hat beschreibt genau dieses Muster bei einem GitHub-MCP-Szenario: Ein manipuliertes Issue kann einen Agenten dazu bringen, Daten aus einem anderen Kontext zu exfiltrieren. Für eine allgemeinere Einordnung dieser Angriffsklasse siehe auch den Threat Guide zu Prompt Injection.

Eng verwandt ist Memory and Context Poisoning: Dabei wird nicht nur ein einzelner Prompt manipuliert, sondern der Kontext, die Erinnerung oder der Arbeitszustand eines Agenten vergiftet. Bei MCP ist das besonders relevant, weil Resources, Tool-Ausgaben und persistente Workflows in späteren Schritten wieder als Kontext auftauchen können. Wenn dieser Kontext ungeprüft geteilt, wiederverwendet oder gespeichert wird, kann eine einmal eingeschleuste Instruktion spätere Tool-Entscheidungen beeinflussen.

Die wichtigste Lektion: Externe Inhalte, Tool-Beschreibungen und Tool-Ausgaben dürfen nicht als vertrauenswürdige Instruktionen behandelt werden. Sie sind Input. Input braucht Grenzen, Validierung, Kontexttrennung und im Zweifel explizite Nutzerfreigabe.

Command Injection, RCE und STDIO-Risiken

Bei lokalen MCP-Setups ist stdio praktisch, weil ein MCP-Server als lokaler Prozess gestartet wird und der Client über Standard Input und Output kommuniziert. Genau diese Bequemlichkeit kann gefährlich werden, wenn benutzerkontrollierte Konfigurationen oder Tool-Parameter in Prozessstarts, Shell-Kommandos oder Adapter-Logik gelangen.

OX Security veröffentlichte am 15. April 2026 eine technische Analyse zu STDIO-basierten Command-Execution-Risiken im MCP-Ökosystem. Die Researcher beschreiben eine breite Angriffsfläche in SDKs, Frameworks und Plattformen, wenn MCP-Konfigurationen unzureichend validiert werden und lokale oder serverseitige Prozesse beliebige Kommandos starten können.

Für Unternehmen ist die Einordnung wichtiger als die Schlagzeile: Sobald ein Agent lokale Tools starten, Konfigurationsdateien ändern oder Adapter mit weitreichenden Rechten verwenden darf, ist MCP Teil der Code-Ausführungskette. Dann reichen klassische Prompt-Regeln nicht aus. Es braucht Allowlisting, Prozessisolation, sichere Defaults, Review von MCP-Konfigurationen und technische Kontrollen außerhalb des Modells.

Authentifizierung, Autorisierung und Secrets

MCP Security steht und fällt mit Identität. Der Agent sollte nicht mehr dürfen als der Nutzer oder Prozess, in dessen Auftrag er handelt. Die offizielle MCP Authorization Specification beschreibt für HTTP-basierte Transporte OAuth-nahe Muster. Gleichzeitig ist Authorization optional, und stdio-Setups folgen nicht demselben HTTP-Autorisierungsmodell, sondern müssen über Prozess-, Benutzer- und Umgebungsgrenzen abgesichert werden.

Typische Fehler sind breite Tokens, lange Laufzeiten, statische Secrets in Konfigurationsdateien, fehlende Scope-Trennung und Tool-Endpunkte, die nur dem Client vertrauen. Die MCP Security Best Practices empfehlen unter anderem, Sessions nicht als Authentifizierung zu behandeln, eingehende Requests zu prüfen, Session-IDs sicher zu erzeugen und Berechtigungen progressiv zu minimieren.

Gute MCP-Autorisierung ist deshalb granular. Ein Agent, der ein Ticket lesen darf, braucht nicht automatisch Schreibrechte. Ein Tool, das Repository-Metadaten abfragt, braucht nicht automatisch Zugriff auf private Repositories. Und ein lokaler Filesystem-Server sollte niemals pauschal das gesamte Home-Verzeichnis sehen.

MCP Security Checkliste für Unternehmen

Die folgende Checkliste eignet sich als pragmatischer Startpunkt für Teams, die MCP bereits testen oder erste produktive Workflows planen. Sie ersetzt kein Threat Modeling, hilft aber, die größten blinden Flecken schnell sichtbar zu machen.

Best Practices für sichere MCP-Server

OWASP beschreibt sichere MCP-Server-Entwicklung als Kombination aus Architektur, starker Authentifizierung, Autorisierung, Validierung, Session-Isolation und gehärtetem Deployment. Besonders wichtig ist dabei, MCP nicht als reine Entwicklerfunktion zu betrachten. Ein MCP-Server ist eine produktive Integrationskomponente mit Zugriff auf Daten und Aktionen.

Least Privilege als Default

Jeder Server und jedes Tool sollte nur die minimal nötigen Rechte bekommen. Das gilt für OAuth-Scopes, API-Keys, Dateisystempfade, Netzwerkzugriffe und Datenbankrechte. Wenn ein Tool nur lesen soll, darf es nicht schreiben. Wenn ein Agent nur ein Projekt bearbeiten soll, darf er nicht automatisch alle Projekte sehen.

Tool-Design mit klaren Sicherheitsgrenzen

Tools sollten kleine, klar benannte Funktionen haben. Ein Tool namens run_command oder execute_query ist riskanter als ein Tool, das eine eng begrenzte, validierte Aktion ausführt. Je generischer ein Tool ist, desto mehr Verantwortung wandert in das Modell – und genau dort ist die Grenze schwerer kontrollierbar.

Transparenz für Nutzerinnen und Nutzer

Wenn ein Agent eine E-Mail sendet, eine Datei ändert oder ein Deployment anstößt, sollte die Oberfläche nicht nur einen freundlichen Tool-Namen zeigen. Nutzer brauchen sichtbare Zielsysteme, Parameter, Empfänger, Datenumfang und Konsequenzen. Das reduziert das Risiko, dass versteckte Instruktionen oder manipulierte Tool-Beschreibungen unbemerkt durchrutschen.

Defense in Depth statt Prompt-Vertrauen

Prompt-Regeln sind nützlich, aber sie sind keine Sicherheitsgrenze. Eine robuste MCP-Architektur kombiniert Modellvorgaben mit technischen Kontrollen: serverseitige Autorisierung, Datenflussregeln, Netzwerkgrenzen, Dateisystem-Sandboxing, Secret Management, Rate Limits und Audit-Logs.

Governance und Betrieb

Viele MCP-Risiken entstehen nicht, weil Teams leichtsinnig sind, sondern weil die Technologie schnell in Tools, IDEs und Agentenplattformen auftaucht. Ein Entwickler installiert einen nützlichen Server für GitHub, ein anderes Team testet einen Datenbank-Connector, ein drittes Team verbindet eine interne Wissensbasis. Ohne Inventar entsteht daraus Shadow MCP.

Ein pragmatisches Governance-Modell muss nicht schwerfällig sein. Sinnvoll sind ein freigegebener MCP-Katalog, Mindestanforderungen für neue Server, ein Review für schreibende oder ausführende Tools, zentrale Secret-Vorgaben und klare Regeln für lokale Entwicklerumgebungen. Für produktive Workflows sollten MCP-Server zudem in bestehende Prozesse für Vulnerability Management, Logging, Incident Response und Berechtigungsreviews aufgenommen werden.

Wenn Sie bereits AI-Agenten, Flowise, Langflow, Claude Code, Cursor oder eigene MCP-Integrationen einsetzen, lohnt sich ein Blick auf verwandte Risiken. Unsere Einordnungen zu Flowise CVE-2025-59528 und Claude Code RCE und API-Key-Exfiltration zeigen, wie schnell AI-Agent-Workflows klassische RCE-, Secret- und Supply-Chain-Themen berühren können.

Fazit: MCP produktiv nur mit Sicherheitsrahmen

MCP ist ein wichtiger Baustein für nützliche KI-Agenten. Der Standard macht es einfacher, Modelle mit realen Tools und Daten zu verbinden. Für Unternehmen ist das produktiv interessant – aber nur, wenn MCP-Server wie sicherheitsrelevante Integrationskomponenten behandelt werden.

Die wichtigste Frage lautet nicht: Ist MCP sicher oder unsicher? Die bessere Frage lautet: Welche Daten, Rechte und Aktionen geben wir welchem Agenten unter welchen Kontrollen? Wer diese Frage sauber beantwortet, kann MCP sicherer einsetzen. Wer sie ignoriert, baut eine neue, schwer sichtbare Angriffsfläche zwischen Modell, Nutzer, Tools und Unternehmenssystemen.

FAQ zu MCP Security