MCP macht alte Rechteprobleme deutlich gefährlicher
Das Model Context Protocol, kurz MCP, verbindet KI-Agenten mit Werkzeugen und Datenquellen. Anthropic veröffentlichte den Standard Ende 2024. Inzwischen wird MCP von der Linux Foundation gepflegt und von Microsoft, Google sowie OpenAI unterstützt.
Damit entwickelt sich MCP zu einer verbreiteten Integrationsschicht für KI-Anwendungen. Das grundlegende Sicherheitsproblem liegt jedoch häufig nicht im Protokoll selbst. Entscheidend ist, mit welchen Zugangsdaten ein Agent arbeitet und welche Systeme er damit erreichen kann.
Die zentrale Erkenntnis lautet sinngemäß: Das Problem steckt weniger in der Infrastruktur als in den darunterliegenden Berechtigungen.
Viele Implementierungen behandeln einen KI-Agenten wie eine klassische Software-Integration. Ein OAuth-Token oder Personal Access Token wird einmal eingerichtet und anschließend dauerhaft verwendet. Für autonome Systeme ist dieses Modell riskant, weil sie Aktionen ohne fortlaufende menschliche Kontrolle ausführen können.
Dauerhafte Zugangsdaten sind weit verbreitet
Der SANS 2026 Identity Threats Survey basiert auf Angaben von mehr als 500 Sicherheitsexperten. Die Ergebnisse zeigen, wie schnell sogenannte nicht-menschliche Identitäten zunehmen. Dazu gehören technische Konten, Dienste und KI-Agenten, die selbstständig auf Unternehmenssysteme zugreifen.
| Kennzahl | Anteil der Unternehmen |
|---|---|
| Anstieg nicht-menschlicher Identitäten | 76 % |
| KI-Systeme mit dauerhaften Zugangsdaten | 74 % |
| Einsatz einzelner Schutzmaßnahmen wie Logging, Sandboxing oder Freigaben | jeweils unter 40 % |
Die Kombination ist problematisch. Immer mehr Agenten erhalten Zugriff auf produktive Daten, während Protokollierung, abgeschottete Ausführungsumgebungen und Freigabeprozesse nicht im gleichen Tempo eingeführt werden. Bei einem Vorfall fehlt dann häufig die belastbare Zuordnung, welche Aktion durch einen Menschen und welche durch einen Agenten ausgelöst wurde.
GitHub und Asana zeigen das eigentliche Risiko
Im Mai 2025 führte eine Prompt Injection beim GitHub-MCP-Server zum Abfluss privater Repository-Daten. Bei einer Prompt Injection werden versteckte Anweisungen in Inhalte eingeschleust, die ein KI-System verarbeitet. Entscheidend war in diesem Fall, dass das verwendete Personal Access Token mehr Rechte besaß, als für die konkrete Aufgabe erforderlich waren.
Ein ähnliches Grundproblem zeigte sich kurz darauf bei einer Asana-MCP-Integration. Ein Logikfehler ermöglichte mandantenübergreifenden Zugriff, auch Cross-Tenant-Zugriff genannt. Die Berechtigungsebene setzte die notwendige Trennung zwischen Kunden nicht durch.
Beide Fälle lassen sich nicht allein durch bessere Modellfilter lösen. Ein Agent, der kompromittiert oder fehlgeleitet wird, sollte technisch gar nicht auf fachfremde Repositories, Arbeitsbereiche oder Kundendaten zugreifen können. Wie Webseiten über manipulierte Inhalte Aktionen in Agenten auslösen können, zeigt auch die bekannte Prompt-Injection-Gefahr bei Claude Code.
Tool Poisoning und Confused Deputy
Sicherheitsforscher beobachten bei MCP vor allem zwei Angriffsmuster. Beim Tool Poisoning enthält die Beschreibung eines Werkzeugs versteckte Anweisungen, die das Verhalten des Agenten beeinflussen. Das Werkzeug wird damit selbst zum Träger des Angriffs.
Beim Confused-Deputy-Problem handelt ein Agent mit geerbten Rechten, obwohl die aktuelle Aufgabe diesen Zugriff nicht benötigt. Ein beschränktes Anliegen wird dadurch mit den umfangreichen Berechtigungen eines menschlichen Kontos ausgeführt. Der mögliche Schaden richtet sich dann nicht nach der Aufgabe, sondern nach dem gesamten Rechteumfang des Tokens.
Agenten brauchen eine eigene Identität
Aktuelle KI-Agenten besitzen häufig keine eigenständige technische Identität. Stattdessen übernehmen sie das OAuth-Token der Person, die eine Integration eingerichtet hat. Das lässt sich sinngemäß als menschliches OAuth-Token im Trenchcoat beschreiben.
Dieses Verfahren vermischt Verantwortlichkeiten. Der Agent erbt den Zugriffsumfang, die potenzielle Schadensreichweite und teilweise sogar die konkreten Zugangsdaten eines Menschen. Gleichzeitig lässt sich im Protokoll nur schwer erkennen, ob eine Handlung vom Nutzer oder von einem automatisierten Prozess stammt.
Besonders kritisch wird das bei langlebigen Agenten. Ein Prozess, der wenige Minuten arbeitet, benötigt ein anderes Risikomodell als ein Agent, der über Wochen oder Monate aktiv bleibt. Je länger die Laufzeit, desto enger sollten die Rechte gefasst und desto häufiger sollte ihre Notwendigkeit überprüft werden.
Die IETF arbeitet an ersten Entwürfen, die Token-Laufzeiten an die tatsächliche Lebensdauer einer Aufgabe binden und Agenten stabile, vom Menschen getrennte Identitäten geben sollen. Wann daraus verabschiedete und breit eingesetzte Standards entstehen, ist bislang offen.
Drei Eigenschaften müssen gemeinsam gesteuert werden
Ein tragfähiges Rechtemodell behandelt Berechtigungsumfang, Identität und Laufzeit nicht als getrennte Prüfungen. Ein eng begrenztes Token hilft wenig, wenn es unbegrenzt gültig bleibt. Eine eigene Agentenidentität reicht ebenfalls nicht aus, wenn sie pauschalen Zugriff auf eine gesamte Organisation erhält.
| Kontrollebene | Prüffrage | Sinnvolle Ausgestaltung |
|---|---|---|
| Identität | Wer führt die Aktion tatsächlich aus? | Eigene Identität für jeden Agenten und jede Instanz |
| Umfang | Welche Daten und Aktionen sind erforderlich? | Zugriff pro Repository, Mandant, Arbeitsbereich oder Aktion |
| Laufzeit | Wie lange wird der Zugriff benötigt? | Dynamische, kurzlebige Zugangsdaten statt dauerhafter Tokens |
| Nachweis | Werden Agentenaktionen vollständig erfasst? | Zurechenbare Protokolle und überprüfbare Freigabeschritte |
Die praktische Empfehlung lautet sinngemäß: Feste und dauerhafte Tokens sollten durch dynamische, temporäre Zugangsdaten ersetzt werden, die bei Bedarf erzeugt werden.
Änderungen an produktiven Systemen sollten zudem nicht automatisch wirksam werden. Entwürfe, separate Branches und Freigabewarteschlangen begrenzen die Folgen fehlerhafter Agentenaktionen. Bestehende Kontrollmechanismen für menschliche Administratoren lassen sich damit auf KI-Agenten übertragen.
Was Unternehmen bei MCP-Integrationen prüfen sollten
Vor einer produktiven Anbindung ist zu klären, welche Ressourcen ein Token tatsächlich erreichen kann. Maßgeblich ist nicht der ursprünglich geplante Zweck, sondern der aktuelle technische Zugriff. Berechtigungen wachsen häufig schleichend, während eine regelmäßige Überprüfung ausbleibt.
All-or-Nothing-Zugriff auf eine komplette Organisation ist ein Warnsignal. Eine Integration sollte Rechte auf einzelne Repositories, Websites, Mandanten, Arbeitsbereiche oder Aktionen beschränken können. Fehlt diese Granularität, liegt bereits ein relevanter Sicherheitsmangel vor.
Auch bei fachlich sinnvollen MCP-Anwendungen bleibt dieses Prinzip entscheidend. So kann MCP in OpenProject Arbeitspakete automatisiert bearbeiten. Für den sicheren Betrieb muss jedoch nachvollziehbar bleiben, welcher Agent welche Änderungen mit welchen Rechten durchgeführt hat.
DSGVO und Mandantentrennung im DACH-Raum
Für Unternehmen im DACH-Raum berührt ein zu weit gefasster Agentenzugriff unmittelbar die Datenminimierung und Mandantentrennung. Ein Token, das mehr personenbezogene oder vertrauliche Daten erreicht als für die Aufgabe erforderlich, erschwert eine datenschutzkonforme Begründung des Zugriffs. Fehlendes Logging behindert zudem die Aufklärung und Dokumentation von Sicherheitsvorfällen.
Proprietäre SaaS-Konnektoren versprechen eine schnelle Integration, bieten aber nicht immer ausreichend granulare Rechte. Dadurch verlagert sich die Abhängigkeit vom Anbieter auf eine sicherheitskritische Ebene. Unternehmen sind darauf angewiesen, dass der Dienst passende Token-Laufzeiten, Mandantengrenzen und Protokolle bereitstellt.
Eigene oder selbst gehostete MCP-Server und vorgeschaltete Middleware bieten mehr Kontrolle. Damit lassen sich kurzlebige Einmal-Tokens, strikte Ressourcengrenzen und eigene Freigabeprozesse umsetzen. Diese Freiheit reduziert den Vendor-Lock-in, erfordert aber zusätzliches Know-how für Identitätsverwaltung, Schlüsselrotation, Überwachung und Absicherung.
MCP sollte deshalb nicht nur als Schnittstellenprojekt behandelt werden. Vor dem produktiven Einsatz braucht es ein belastbares Modell für Agentenidentitäten, minimale Rechte und begrenzte Laufzeiten. Erst diese Ebene entscheidet, ob eine komfortable KI-Integration kontrollierbar bleibt oder zum dauerhaften Zugang in sensible Unternehmenssysteme wird.