Angriffsfläche KI-Schnittstellen Warum das Model Context Protocol neue Angriffsflächen schafft

Anbieter zum Thema

Darktrace Deutschland

Fivetran Germany GmbH

Das Model Context Protocol (MCP) erleichtert die Verbindung von KI-Agenten mit Unternehmenssystemen. Dadurch lassen sich neue Funktionen schneller bereitstellen. Mit jedem angebundenen Dienst wächst allerdings der Bereich, den Unternehmen technisch überwachen und organisatorisch absichern müssen. Entscheidend ist deshalb nicht die einmalige Freigabe, sondern die dauerhafte Kontrolle im Betrieb.

Ein KI-Agent liest interne Tickets, sucht passende Einträge in einer Wissensdatenbank und aktualisiert anschließend einen Vorgang im Servicemanagement. Dafür benötigt die KI-Anwendung Zugriff auf externe Systeme und deren Funktionen. Das Model Context Protocol (MCP) soll solche Verbindungen vereinheitlichen.

Als offenes Protokoll schafft MCP eine gemeinsame Schnittstelle, sodass Teams nicht für jede Kombination eine eigene Integration entwickeln müssen. Diese Vereinfachung beeinflusst die Sicherheitslage. Abhängig von seinen Rechten kann ein Agent vertrauliche Informationen lesen oder Änderungen in einem produktiven System anstoßen. Für die Absicherung zählt daher die gesamte Verarbeitungskette zwischen KI-Anwendung, MCP-Server und angebundenem Dienst.

MCP verbindet Agenten mit Unternehmenssystemen

Technisch arbeitet MCP mit einer Host-Client-Server-Architektur. Die KI-Anwendung bildet den Host und erzeugt für jeden angebundenen MCP-Server einen eigenen Client, der die jeweilige Verbindung verwaltet. Der Server stellt darüber beispielsweise Werkzeuge, Datenressourcen oder Prompt-Vorlagen bereit, die der Host in den KI-Workflow einbinden kann. Das fördert die Wiederverwendbarkeit. Ein bestehender MCP-Server kann mit mehreren kompatiblen Anwendungen genutzt werden, was den Entwicklungsaufwand spürbar senkt. Gleichzeitig erweitert jeder neue Server die Vertrauensgrenze und potenziell die Angriffsfläche.

Daher reicht es nicht, nur den Namen eines Tools zu prüfen. Interessanter ist die dahinterliegende Funktion und auf welche Informationen sie zugreifen kann. So kann eine scheinbar harmlose Suche Zugriff auf sensible Inhalte erhalten. Auch manipulierte Anweisungen können in Beschreibungen oder Antworten eines Servers verborgen sein. Gelangen sie in den Modellkontext, können sie das Verhalten des Agenten beeinflussen.

Versteckte Anweisungen beeinflussen Werkzeugaufrufe

OWASP bezeichnet manipulierte MCP-Tool-Beschreibungen als Tool Poisoning. Dabei stellt ein kompromittierter oder manipulierter MCP-Server ein scheinbar legitimes Werkzeug bereit, dessen Metadaten oder Ausgaben manipulative Anweisungen für das Sprachmodell enthalten. Ähnliche Anweisungen können auch über manipulierte Antworten als indirekte Prompt Injection eingebracht werden.

Solche Inhalte können den Agenten dazu bringen, zusätzliche Tools aufzurufen. Mit weitreichenden Rechten wäre es möglich, interne Informationen abzurufen und anschließend über einen anderen Dienst weiterzugeben. Für sich betrachtet kann jeder einzelne Aufruf formal berechtigt wirken. Erst aus der Reihenfolge und dem Kontext wird ersichtlich, dass der Agent seinen ursprünglichen Auftrag überschreitet.

Token gehören zu genau einem Ziel

Ähnlich sorgfältig sollte die Autorisierung umgesetzt werden. Zugriffstoken müssen für einen bestimmten Dienst ausgestellt sein und von diesem validiert werden. Ein MCP-Server sollte weder Token akzeptieren, die für eine anderes Ziel bestimmt sind, noch sie ohne einen geeigneten Token-Austausch an einen weiteren Dienst weiterreichen.

Andernfalls könnte der Server seine vertrauenswürdige Position nutzen, um auf Ressourcen zurückzugreifen, die über die vom Nutzer beabsichtigte Autorisierung hinausgehen. Dadurch entsteht das Risiko eines sogenannten Confused-Deputy-Problems.

Ein plausibles Missbrauchsszenario

Ein Entwicklungsteam bindet einen externen MCP-Server an einen internen Assistenten an. Der Dienst soll Vorgänge aus dem Ticketsystem zusammenfassen und dazu passende Einträge in einer Wissensdatenbank finden. Zunächst erfüllt die Integration ihre Aufgabe wie vorgesehen. Doch der Server wird kompromittiert und liefert über eine Tool-Antwort eine versteckte Anweisung an das Modell. Daraufhin ruft der Agent weitere Dokumente ab und übermittelt deren Inhalte über ein freigegebenes Tool an einen externen Dienst. Für sich betrachtet erscheint jede einzelne Aktion autorisiert. Problematisch wird ihr Zusammenspiel, wenn der Agent den vorgesehenen Arbeitsablauf verlässt. Das Beispiel zeigt, warum eine einmalige Prüfung vor der Freigabe nicht ausreicht.

KI im laufenden Betrieb absichern

KI abzusichern bedeutet, ihre tatsächliche Nutzung im Betrieb zu schützen. Eine einmalige Prüfung ist nicht ausreichend. Unternehmen müssen jederzeit nachvollziehen können, welche Agenten aktiv sind, über welche Berechtigungen sie verfügen und wie sie sich im laufenden Betrieb verhalten.

Vor der Anbindung eines MCP-Servers sollte feststehen, wer ihn betreibt und welche Funktionen er bereitstellt. Die Berechtigungen sollten sich aus dem konkreten Auftrag ergeben. Schreibrechte benötigen engere Grenzen als reine Lesezugriffe und ein Agent für die Dokumentensuche braucht keinen Zugang zu administrativen Funktionen. Bei sensiblen Aktionen kann eine zusätzliche Freigabe das Risiko verringern, dass das System eigenständig weitreichende Änderungen ausführt. Zugangsdaten gehören in eine dafür vorgesehene Verwaltung und nicht in den Prompt.

Ebenso wenig reicht es bei der Protokollierung aus, einzelne API-Aufrufe isoliert zu betrachten. Sobald ein Agent mehrere Systeme verbindet, muss nachvollziehbar bleiben, welche Anfrage den Ablauf ausgelöst hat und welche Schritte daraus folgten. Erst dieser Kontext macht ungewöhnliche Aktionsketten sichtbar. Auch ein geprüfter Agent kann zum Risiko werden, wenn sich sein Kontext verändert oder ein angebundener Dienst manipuliert wurde. Folgerichtig ist Secure AI also keine einmalige Freigabe, sondern eine kontinuierliche Betriebsaufgabe.

Wer diese Anforderungen früh in die Entwicklung einbezieht, kann MCP kontrolliert einsetzen. Die Integration bleibt flexibel, während sensible Systeme besser vor unerwünschten Zugriffen geschützt sind.

Über den Autor

Max Heinemeyer ist Global Field CISO bei Darktrace und hat über zehn Jahren Erfahrung in diesem Bereich. Seine Schwerpunkte liegen unter anderem in den Bereichen Penetrationstests, Red Teaming, SIEM- und SOC-Beratung sowie in der Jagd auf Advanced Persistent Threats (APT).

(ID:50920225)