MCP-Server: Wenn KI-Agenten Unternehmensgeheimnisse preisgeben : Konfigurationsdateien, zu viele Rechte und Prompt Injection machen MCP zur neuen Angriffsfläche
KI-Agenten greifen längst nicht mehr nur auf Informationen zu: Sie öffnen Dateien, rufen APIs auf und verändern Daten in produktiven Systemen. Möglich macht das häufig das Model Context Protocol. Doch damit wandern API-Schlüssel, Tokens und Service-Accounts an eine neue Stelle – und geraten dort leicht aus dem Blick der Security-Teams.
Das Model Context Protocol (MCP) ist ein ursprünglich von Anthropic vorgestellter offener Standard, mit dem KI-Assistenten auf externe Datenquellen und Werkzeuge zugreifen können. Ein KI-Agent kann darüber beispielsweise Informationen aus einer Datenbank abrufen, Dateien öffnen oder Funktionen über Programmierschnittstellen anstoßen. Die Verbindung zwischen dem Agenten und dem jeweiligen Zielsystem übernimmt ein MCP-Server. Er stellt dem Agenten genau die Funktionen zur Verfügung, die für dessen Aufgabe vorgesehen sind.
Damit wird der MCP-Server zu einem sicherheitskritischen Vermittler. Soll er beispielsweise auf einen Cloud-Dienst, eine Datenbank oder eine interne Anwendung zugreifen, benötigt er dafür entsprechende Zugangsdaten. Dazu zählen etwa API-Schlüssel, Service-Account-Schlüssel oder Zugriffstokens. Diese Secrets liegen damit häufig direkt beim MCP-Server oder müssen von ihm zur Laufzeit abgerufen werden.
KI-Agenten treten dadurch zunehmend wie eigenständige technische Benutzer auf. Solche maschinellen Identitäten werden als Non-Human Identities (NHI) bezeichnet. Sie authentifizieren sich gegenüber Anwendungen und Infrastrukturen mit den ihnen zugewiesenen Zugangsdaten und Berechtigungen. Wird eines dieser Secrets gestohlen, erhält ein Angreifer deshalb möglicherweise nicht nur Zugriff auf Informationen. Er kann je nach Berechtigungsumfang auch im Namen des Agenten Aktionen ausführen – etwa Daten verändern, Dateien abrufen oder Funktionen in angebundenen Systemen auslösen.
Klartext-Secrets in Konfigurationsdateien
Viele MCP-Server erhalten ihre Zugangsdaten über lokale Konfigurationsdateien oder Umgebungsvariablen. Gerade bei schnell aufgebauten Installationen werden Tokens oder API-Schlüssel direkt in Konfigurationsstrings eingetragen und im Klartext gespeichert. Solche Dateien geraten leicht aus dem Blick: Sie werden auf andere Rechner kopiert, in Backups übernommen oder versehentlich in ein Git-Repository eingecheckt. Verschafft sich ein Angreifer Zugriff auf das betreffende System, können damit zugleich sämtliche dort abgelegten Zugangsdaten kompromittiert werden.
Ein weiteres Problem ist Credential Sprawl. Verwaltet jeder Agent seine Secrets selbst, entstehen Kopien derselben Schlüssel in Entwicklungs-, Test- und Produktionsumgebungen. Eine zentrale Übersicht fehlt häufig. Die Folge: Zugangsdaten werden selten gewechselt und bleiben teilweise über lange Zeit gültig.
Prompt Injection missbraucht die Rechte des Agenten
Für einen Angriff muss der MCP-Server nicht einmal direkt kompromittiert werden. KI-Agenten verarbeiten Dokumente, Webseiten, Support-Tickets oder andere externe Inhalte. Darin lassen sich versteckte Anweisungen platzieren, die der Agent als legitime Instruktionen interpretiert. Bei einer solchen Prompt Injection kann ein Angreifer versuchen, den Agenten zur missbräuchlichen Nutzung seiner Werkzeuge zu bewegen. Je nach verfügbaren Berechtigungen kann er dadurch Daten abrufen, Aktionen anstoßen oder sogar Zugangsdaten offenlegen.
Das Risiko steigt, wenn MCP-Server mehr Zugriffsrechte erhalten, als für ihre eigentliche Aufgabe notwendig sind. In der Entwicklungsphase vergeben Entwickler häufig bewusst weitreichende Berechtigungen, damit Tests nicht an fehlenden Rechten scheitern. Werden diese Einstellungen später unverändert in die Produktivumgebung übernommen, kann ein KI-Agent auf zusätzliche Systeme, Datenbanken oder Funktionen zugreifen. Wird der Agent oder der MCP-Server kompromittiert, stehen damit auch dem Angreifer diese erweiterten Rechte zur Verfügung – und der mögliche Schaden fällt entsprechend größer aus.
Öffentliche MCP-Server schaffen Supply-Chain-Risiken
Auch die Herkunft eines MCP-Servers ist sicherheitsrelevant. Da solche Server von praktisch jedem entwickelt und veröffentlicht werden können, besteht das Risiko, unsichere oder manipulierte Komponenten in die eigene Umgebung einzubinden. Damit wird MCP auch zu einem möglichen Einfallstor für Supply-Chain-Angriffe: Die Schwachstelle liegt dann nicht in der eigenen Anwendung, sondern in einer verwendeten Drittanbieter-Komponente.
Wie gefährlich das werden kann, zeigte CVE-2025-6514 in mcp-remote. Der mehr als 400.000-mal heruntergeladene OAuth-Proxy läuft auf dem Rechner des Anwenders und stellt die Verbindung zu entfernten MCP-Servern her. Ein speziell präparierter Server konnte dem Proxy jedoch Befehle unterschieben, die dieser auf dem lokalen Betriebssystem ausführte. Dadurch war Remote Code Execution (RCE) möglich. Ein Angreifer konnte somit im schlimmsten Fall Programme starten, Dateien auslesen oder lokal gespeicherte Zugangsdaten und Tokens stehlen.
So lassen sich Secrets besser schützen
Unternehmen sollten die Sicherheitsmechanismen klassischer Produktivsysteme deshalb auch auf die MCP-Schicht übertragen:
- Secrets nicht fest eintragen, sondern zentral verwalten. Zugangsdaten gehören aus Konfigurationsdateien, Umgebungsvariablen und Quellcode in einen zentral kontrollierten Secret Store. Agenten rufen sie erst zur Laufzeit ab.
- Kurzlebige Zugangsdaten einsetzen und automatisch rotieren. Dynamisch erzeugte Credentials verkürzen das Zeitfenster, in dem gestohlene Schlüssel nutzbar bleiben.
- Least Privilege erzwingen. Jeder Agent sollte ausschließlich auf die Systeme und Daten zugreifen dürfen, die seine konkrete Aufgabe benötigt.
- Menschen bei sensiblen Aktionen einbeziehen. Das Anzeigen eines unmaskierten Secrets, das Löschen von Datensätzen oder Zugriffe auf Produktionssysteme sollten eine ausdrückliche Freigabe verlangen.
- Secrets nach Zero-Trust- und Zero-Knowledge-Prinzipien verschlüsseln. Zugangsdaten sollten Ende-zu-Ende verschlüsselt und möglichst erst im Moment ihrer Nutzung verfügbar werden. Auch der speichernde Dienst sollte die Werte nicht im Klartext lesen können.
- Alle Agentenaktionen protokollieren und auditieren. Unternehmen benötigen nachvollziehbare Informationen darüber, welcher Agent wann auf welche Ressourcen zugegriffen und welche Aktionen ausgeführt hat.
- Sämtliche MCP-Server inventarisieren. Nur bekannte Systeme lassen sich kontrollieren. Eine vollständige Übersicht verhindert, dass vergessene oder inoffiziell betriebene MCP-Server dauerhaft gültige Zugangsdaten als Schatten-KI verwalten.
Secrets Management muss KI-Agenten einbeziehen
MCP schafft eine neue Vermittlungsschicht zwischen KI-Agenten und geschäftskritischen Anwendungen. Genau dort konzentrieren sich zunehmend die Schlüssel, mit denen Datenbanken, Cloud-Dienste und interne Systeme erreichbar sind. Damit wird Secrets Management zu einem zentralen Bestandteil der Absicherung agentischer KI. Zugangsdaten müssen zentral verwaltet, Berechtigungen begrenzt, sensible Aktionen kontrolliert und MCP-Server vollständig inventarisiert werden. Andernfalls kann aus dem praktischen Bindeglied zwischen KI und Unternehmens-IT unbemerkt ein hochprivilegierter Zugangspunkt für Angreifer werden.
Autoren
Ashley D’Andrea, Keeper Security/THN/Stefan Mutschler