Was ist MCP Security: Der vollständige Leitfaden zu Zero Trust für agentische KI-Systeme

Es begann mit einer Idee: Ein KI-Agent sollte eine mehrstufige Rechercheaufgabe übernehmen. Verbinden Sie ihn über MCP mit einigen Tools, gewähren Sie ihm Zugriff auf die richtigen Datenquellen und lassen Sie ihn arbeiten.

Was tatsächlich passierte, war lehrreicher. Der Agent hatte mehr Zugriff, als die Aufgabe erforderte. Er rief Tools in Sequenzen auf, die niemand vorhergesehen hatte, und es gab keine Logs, die erklärten, was er berührt hatte oder warum.

Dasselbe Token, das die Demo zum Laufen brachte, hätte das gemeinsame Laufwerk des Unternehmens löschen können, wenn das Modell halluziniert hätte oder auf einen bösartigen Prompt gestoßen wäre, der in das zu lesende Dokument eingebettet war.

Dies ist die grundlegende Herausforderung der MCP Security. Da das Model Context Protocol zum Standard für die Verbindung von LLMs mit externen Tools und Datenbanken wird, erfordert die Sicherung dieser Verbindungen strikte Sicherheitsmaßnahmen.

Dieser Leitfaden erklärt, warum herkömmliche API-Sicherheit bei KI-Agenten versagt, wie die realen Angriffsvektoren aussehen und was Zero Trust in diesem Kontext bedeutet. Er veranschaulicht auch, wie einige Plattformen einen Aufpreis für Sicherheitskontrollen verlangen, die eigentlich Standard sein sollten.

Warum KI-Agenten eine andere Klasse von Sicherheitsproblemen darstellen

Im Gegensatz zu traditioneller Software, die deterministische Workflows ausführt, treffen KI-Agenten dynamische Entscheidungen darüber, welche MCP-Tools sie wie verwenden. Diese Autonomie verändert die Art und Weise, wie sich Risiken in MCP-Umgebungen ausbreiten, und führt zu neuen Arten von Risiken, die Ihre Sicherheitsausrichtung beeinflussen.

Die KI-Agenten stellen eine neue Art von Risiko dar, die sich grundlegend von traditionellen Softwaresystemen unterscheidet. Ihre einzigartige Kombination aus Autonomie, Zugriff und Geschwindigkeit schafft spezifische Sicherheitsrisiken, insbesondere in MCP-basierten Systemen.

1. Von Nur-Lese- zu Lese-Schreib-Systemen: Im Gegensatz zu früheren KI-Systemen, die hauptsächlich zur Generierung von Ausgaben über natürliche Sprache verwendet wurden, können KI-Agenten bösartigen Code ausführen, E-Mails senden, Datenbanken ändern und Daten löschen. Diese grundlegende Änderung des Tool-Verhaltens von passiv zu aktiv vergrößert den Schadensradius eines jeden Fehlers oder Missbrauchs.

2. Das Problem überprivilegierter Tokens: KI-Agenten erhalten häufig Zugriff über Service-Accounts oder API-Tokens, die weitreichende Privilegien für Unternehmensressourcen gewähren. Dies steht im Gegensatz zu traditioneller Software, bei der das Prinzip der minimalen Rechtevergabe (Least Privilege) üblich ist. KI-Agenten werden überprivilegierte Tokens gewährt, die für bösartige Akteure äußerst wertvoll und anfällig für Ausnutzung sind.

3. Das Problem der Black-Box-Ausführung: KI-Agenten, insbesondere LLMs, sind dynamisch. Sie entscheiden, welche API-Aufrufe getätigt werden, legen Parameter fest und führen Code auf eine nicht-deterministische, nicht-transparente Weise aus. Dies birgt ein Risiko, da es schwierig ist, ein solches Verhalten vorherzusehen oder zu überprüfen, was eine effektive Cloud-Sicherheit behindert.

4. Die Geschwindigkeit der Ausnutzung: Im Falle eines Fehlers oder bösartigen Missbrauchs können KI-Agenten innerhalb von Sekunden mehrere Tool-Aufrufe auslösen und Code ausführen, was zu schweren Schäden führen kann.

Die Angriffsvektoren, die MCP tatsächlich einführt

Das Model Context Protocol ermöglicht eine leistungsstarke Tool-Orchestrierung, schafft aber auch neue Angriffsflächen über Prompts, Tool-Metadaten und Agenten-Ausführungsabläufe hinweg. Im Gegensatz zu traditionellen APIs interpretieren Agenten Anweisungen und Metadaten dynamisch, was subtile Manipulationen weitaus gefährlicher macht. 

Die folgenden Abschnitte beschreiben die primären Angriffsvektoren, die durch MCP-fähige Systeme eingeführt werden.

Indirekte Prompt-Injection

Prompt-Injection ist nicht neu, aber MCP hebt sie auf eine breitere Ebene. Da sich der Agent mit Live-Tools verbindet, können bösartige Prompts – selbst innerhalb externer Inhalte – reale Aktionen auslösen. Der Angreifer fügt bösartige Anweisungen in ein Dokument, eine Webseite oder eine API-Antwort ein, die der Agent verarbeitet.

Der Agent verarbeitet die Anweisungen als legitim und führt sie aus, ohne zu wissen, dass sie aus einer bösartigen Quelle stammen. Diese indirekte Prompt-Injection stellt eine ernsthafte Bedrohung für MCP-Implementierungen dar.

Tool-Poisoning und Schema-Manipulation

Während sich Teams auf die Sicherung der Datennutzung des Agenten konzentrieren, achten nur wenige auf die Sicherung des Tools selbst. Tool-Poisoning findet auf der Ebene statt, der der Agent am meisten vertraut. Der Angreifer manipuliert die Tool-Beschreibungen, Parameterschemata oder Tool-Manifeste, was dazu führt, dass der Agent bösartige Funktionsaufrufe tätigt, die als legitim getarnt sind.

Der Agent vertraut den Tool-Metadaten, und genau dort findet die Ausnutzung statt, was erhebliche Sicherheitsrisiken für das Unternehmen schafft.

Unbefugte Datenexfiltration durch Tool-Chaining

Das Risiko besteht nicht nur im bösartigen Tool-Aufruf selbst, sondern in der Verkettung von Tool-Aufrufen (Tool-Chaining). Agenten verketten mehrere Tools miteinander, um eine bestimmte Aufgabe auszuführen, wobei Datenexfiltration bei offenen Berechtigungen auftreten kann. 

Ein Agent mit direktem Zugriff auf interne Kundendaten und externer Websuchfunktionalität kann ausgenutzt werden, um interne Daten zusammenzufassen und über Suchanfragen nach außen zu übertragen.

Es ist kein spezifischer Befehl "Daten nach außen senden" erforderlich; der Agent wird durch legitime Tool-Kombinationen ausgenutzt, was sensible Systeme gefährdet.

Kontext-Poisoning in Multi-Agenten-Pipelines

Die Vertrauensgrenze hat sich mit orchestrierten Multi-Agenten-Systemen erweitert. Jede Interaktion zwischen Agenten ist ein potenzieller Angriffspunkt für Injection-Angriffe, da der Kontext von einem Agenten zum anderen weitergegeben wird. 

In Systemen, in denen Agenten Informationen weitergeben, gibt ein kompromittierter Upstream-MCP-Client falschen Kontext an den gemeinsamen Zustand weiter.

Der Downstream-Agent behandelt den kompromittierten Kontext als vertrauenswürdig und setzt die Ausbreitung ohne Interaktion mit dem ursprünglichen Benutzer fort, was den Geschäftsbetrieb schädigt.

Statische Tokens in Konfigurationsdateien

Während Zugriffsdaten-Hygiene ein bekanntes Problem ist, führen MCP-Systeme zu neuen Belastungspunkten. Die Geschwindigkeit des Agenten-Prototypings überholt die Sicherheitspraktiken, und statische Tokens in Konfigurationsdateien werden zu Opfern. 

MCP-Systeme enthalten häufig hartcodierte Cloud-Zugriffsdaten in Konfigurationsdateien, die sich in Versionskontrollsysteme und Umgebungen verbreiten.

Statische Tokens ohne Rotation und ohne Scoping gehören zu den am häufigsten dokumentierten Schwachstellen in der MCP-Architektur.

Die auf MCP angewandten Prinzipien von Zero Trust

• Identitätsbewusste On-Behalf-Of-Ausführung: Agenten dürfen niemals globale Service-Accounts verwenden. Jede Tool-Nutzung sollte mit den exakten Berechtigungen des initiierenden Benutzers ausgeführt werden, um unbefugten Zugriff zu verhindern.
• Least Privilege auf Serverebene: Ein MCP-Server sollte eng begrenzt sein, sodass Agenten nur auf die Tools zugreifen, die ihre spezifische Rolle für die Funktion wirklich benötigt – nicht mehr.
• Human-in-the-Loop-Kontrollen für destruktive Aktionen: Jedes Tool, das den Systemzustand ändern kann, muss vor der Ausführung eine synchrone menschliche Genehmigung erfordern, was eine harte Stoppgrenze für irreversible Aktionen schafft und die Angriffsfläche verringert.

Zero Trust vs. Traditionelle Sicherheit für MCP — Gegenüberstellung

Herkömmliche API-Sicherheitsmodelle stützen sich stark auf Perimeter-Abwehr und vertrauenswürdige interne Akteure. MCP-fähige Agenten arbeiten anders: Sie rufen Tools dynamisch auf und verketten Aktionen über Systeme hinweg. Dieser Wandel erfordert ein Zero Trust-Sicherheitsmodell, bei dem Identität, Zugriff und Ausführung kontinuierlich überprüft werden.

Wie Mitbewerber MCP Security in eine Einnahmequelle verwandeln

Mit der zunehmenden Verbreitung von MCP ist eine neue Kategorie von Werkzeugen entstanden, die den Zugriff von Agenten auf Tools und Daten sichern soll. Viele Anbieter verpacken jedoch grundlegende Sicherheitsfunktionen als Premium-Funktionen, was betriebliche und finanzielle Hürden für Teams schafft, die KI-Systeme in der Produktion bereitstellen.

• Identitätsbewusste On-Behalf-Of-Ausführung: Agenten dürfen niemals globale Service-Accounts verwenden. Jeder Tool-Aufruf muss mit den exakten Berechtigungen des initiierenden Benutzers ausgeführt werden, anstatt mit geteilten Anmeldedaten.
• Least Privilege auf Serverebene: MCP-Server müssen im Umfang eingeschränkt sein, sodass Agenten nur auf die Tools zugreifen können, die für die von ihnen ausgeführte spezifische Rolle erforderlich sind, und sonst nichts.
• Human-in-the-Loop-Kontrollen für destruktive Aktionen: Jedes Tool mit destruktivem Potenzial muss vor der Ausführung von einem Menschen genehmigt werden, um eine klare Grenze für solche Aktionen zu setzen.

Wie TrueFoundry Zero Trust MCP Security ohne Enterprise-Aufschlag bietet

TrueFoundry ist eine Enterprise-KI-Plattform, die Sicherheitsteams beim sicheren Aufbau, der Bereitstellung und dem Betrieb von Produktions-KI-Systemen unterstützt. Bei der Einführung MCP-basierter Agenten bietet TrueFoundry die erforderliche Infrastruktur, um Governance, Identitäts- und Zugriffskontrolle über alle Interaktionen hinweg durchzusetzen.

Die Plattform bettet Zero Trust MCP Security direkt in die Ausführungsebene ein, sodass Teams Agenten bereitstellen können, ohne separate Sicherheits-Gateways oder Enterprise-Add-ons hinzufügen zu müssen.

• Ein zentrales MCP Gateway: Das MCP Gateway von TrueFoundry fungiert als einziger verwalteter Zugangspunkt für den gesamten Agenten-zu-Tool-Datenverkehr und verhindert unbefugte, unbeabsichtigte Aktionen. Jeder MCP-Server muss in einer verifizierten Registry registriert sein, bevor Agenten ihn erreichen können, was Schwachstellen durch verstreute Konfigurationen eliminiert.
• Native On-Behalf-Of-Ausführung: Agenten erben die exakten Berechtigungen des Benutzers, der die Aufgabe initiiert hat. Die integrierte Okta- und Azure AD-Integration gewährleistet eine konsistente, überprüfbare Durchsetzung über Workflows hinweg.
• Pre- und Post-Call Guardrails: TrueFoundry validiert jeden Tool-Aufruf vor der Ausführung gegen definierte Schemata und prüft die Ausgaben im Anschluss. Dies setzt Zero Trust auf Protokollebene durch und vermeidet schwerwiegende MCP-Sicherheitsrisiken.
• Vollständige Observability und Sicherheitsfunktionen standardmäßig enthalten: Jeder Tool-Aufruf und jede Agentenaktion wird mit strukturierten Metadaten in Ihrer eigenen VPC protokolliert, was große Sicherheitsbedenken ausräumt. Audit-Logs und RBAC gehören zum Standard und sind nicht hinter teuren Enterprise-Upgrade-Stufen verborgen, was eine sichere Lieferkette gewährleistet.

Fazit: Lassen Sie Agenten nicht ihre eigenen Hausaufgaben benoten

Die Geschwindigkeit der MCP-Einführung ist so hoch, dass die meisten Teams unter Druck arbeiten – und unter Druck geht man Abkürzungen ein. Eine Demo funktioniert, der Agent ist einsatzbereit, und Governance wird als Funktion betrachtet, die später hinzugefügt wird, was selten kostenlos ist.

Das Problem ist struktureller Natur. Wenn ein Agent autonom Aufrufe zwischen internen Systemen und externen APIs tätigen kann, kann selbst die beste Governance auf Prompt-Ebene ein Gateway nicht kompensieren, das nie für eine solche Realität entwickelt wurde. Sie sichern nicht nur eine Anfrage; Sie sichern einen Entscheidungsprozess, der Dutzende von Aktionen ausführen kann, bevor einem Menschen überhaupt ein Ergebnis präsentiert wird.

Die Teams, die ihre MCP-Einführung bereuen werden, sind nicht diejenigen, die zu schnell vorgegangen sind. Es sind die Teams, die glauben, dass sich ihre bestehende Sicherheitsarchitektur ohne erhebliche Änderungen anpassen lässt. API Gateways verstehen von Haus aus keine Tool-Schemata. Authentifizierungsmodelle wurden klassischerweise nicht für On-Behalf-Of-Szenarien entwickelt, an denen autonome Agenten beteiligt sind. Und Paywalls für Unternehmen, bei denen eine grundlegende rollenbasierte Zugriffskontrolle ein Premium-Feature ist, sind kein Sicherheitsmodell – sie sind ein Einnahmemodell.

Zero Trust für MCP ist kein Häkchen auf einer Checkliste, sondern eine Verpflichtung. Jeder einzelne Tool-Aufruf wird überprüft, jede einzelne Agentenaktion wird aufgezeichnet und jede einzelne Berechtigung basiert auf dem Benutzer, der den Workflow initiiert hat. Der Unterschied zwischen Teams, die dies von Anfang an richtig machen, und solchen, die es erst nach einer Sicherheitsverletzung tun, liegt einfach darin, ob Governance vom ersten Tag an ein Kernbestandteil des Gateways war. TrueFoundry macht dies zum Standard, nicht zu einem Zusatzfeature.

Häufig gestellte Fragen (FAQ)

Was ist MCP Security? 

MCP Security umfasst Mechanismen, die regeln, wie KI-Agenten unter Verwendung des Model Context Protocol auf Tools zugreifen. Da MCP einen dynamischen Tool-Zugriff ermöglicht, muss die Sicherheit über den grundlegenden API-Schutz hinausgehen. Sie umfasst Identitätsweitergabe, Schemavalidierung und Audit-Trails. TrueFoundry bietet dies über ein zentrales Gateway, das Identität, Sicherheitskontrollen und Ausführungsprotokolle verwaltet.

Welche Sicherheitsrisiken birgt MCP? 

MCP Security birgt Risiken, da Agenten dynamisch mit APIs interagieren. Zu den Sicherheitsrisiken gehören Prompt-Injection-Angriffe, Tool-Schema-Manipulationen und überprivilegierte Service-Tokens. Multi-Agenten-Pipelines können kompromittierten Kontext über sensible Systeme hinweg verbreiten. Um diese Bedrohungen zu mindern, müssen Tool-Aufrufe validiert und identitätsbasierte Berechtigungen durchgesetzt werden. TrueFoundry bietet ein sicheres Gateway zur Steuerung dieser Interaktionen.

Ist das Model Context Protocol sicher in der Anwendung? 

MCP ist ein neutrales Protokoll, das die Interaktion von KI-Modellen mit Tools standardisiert. Ob es sicher ist, hängt von den angewendeten Sicherheitsmaßnahmen ab. Agenten können erweiterte Berechtigungen erhalten und auf private Datenbanken zugreifen. Durch die Bereitstellung einer robusten Sicherheitsinfrastruktur, wie sie das Gateway von TrueFoundry bietet, kann das Protokoll jedoch sicher implementiert werden, ohne Unternehmensressourcen zu gefährden.

Wie lässt sich Zero Trust auf KI-Agenten anwenden, die MCP nutzen? 

Zero Trust geht davon aus, dass keine Entität vertrauenswürdig ist. Für einen KI-Agenten, der MCP nutzt, bedeutet dies, dass alle Tool-Aufrufe vor der Ausführung authentifiziert und validiert werden müssen, um einen bösartigen Server zu stoppen. Agenten müssen mit denselben Berechtigungen wie der initiierende Benutzer ausgeführt werden. TrueFoundry setzt Zero Trust durch, indem es die Identitätsweitergabe vorschreibt und alle Tool-Aufrufe überwacht.

Was ist ein Confused-Deputy-Angriff in Bezug auf einen KI-basierten Agenten? 

Ein Confused-Deputy-Angriff liegt vor, wenn ein KI-Agent mit hohen Privilegien dazu verleitet wird, Aktionen im Namen eines bösartigen Akteurs auszuführen, was zu Datenlecks führen kann. Da der KI-Agent über gültige Privilegien verfügt, erkennt das System den Angriff möglicherweise nicht. Um dies zu verhindern, müssen die Agentenberechtigungen eingeschränkt und die Ausgaben von Tool-Aufrufen validiert werden.

Warum reicht ein Standard-API-Gateway für ein MCP-System nicht aus? 

Herkömmliche API-Gateways verarbeiten deterministische Aufrufe mit bekannten Endpunkten. MCP-basierte Agenten verhalten sich anders: Sie entdecken Tools und erstellen Parameter dynamisch. Die Sicherheit muss auf Tool-Schema-Ebene durchgesetzt werden, nicht nur auf Netzwerkebene, um bösartigen Code zu blockieren. TrueFoundry erweitert traditionelle Gateways, um den neuen Sicherheitsanforderungen im Zusammenhang mit MCP gerecht zu werden.