Warum KI-Assistenten Ihre Berechtigungen umgehen - und warum die Frage "MCP oder API?" die falsche ist
Ein Erfahrungsbericht über eine Architekturentscheidung, die wichtiger ist als die Wahl des Protokolls.
Ich habe einen KI-Assistenten gebaut. Nicht als Spielerei, sondern als Arbeitswerkzeug: Ein Bot in Mattermost, der auf unsere Projektinfrastruktur zugreift - Notion für Dokumentation, YouTrack für Tickets, OpenProject für Projektplanung, Git für Code.
Der Bot funktioniert. Er beantwortet Fragen zum Projektstatus, findet Dokumente, fasst Diskussionen zusammen.
Und dann hat er angefangen, im Kanal von Projekt A Informationen aus Projekt B zu teilen.
Was passiert ist
Der Aufbau war sauber: Jeder Mattermost-Kanal hat seine eigene Konversationshistorie. Der Bot bekommt nur den Chatverlauf des aktuellen Kanals. Zusammenfassungen werden nachts erstellt, getrennt nach Kanal. So weit, so korrekt.
Das Problem lag nicht in der Konversation. Es lag in den Werkzeugen.
Wenn jemand im Kanal von Projekt A fragt: "Wie ist der aktuelle Status der Migration?", dann durchsucht der Bot Notion. Und Notion liefert alles zurück, was zum Suchbegriff "Migration" passt - auch Dokumente aus Projekt B, Projekt C und dem internen Strategiepapier zur Unternehmensreorganisation.
Das LLM hat keine böse Absicht. Es hat nicht einmal ein Konzept von "Projektgrenzen". Es bekommt eine Frage und eine Liste von Suchergebnissen und baut daraus die bestmögliche Antwort. Dass manche dieser Ergebnisse nicht in diesen Kanal gehören, weiß es nicht. Und es kann es auch nicht wissen, weil niemand es ihm mitteilt - und weil "mitteilen per Prompt" keine Sicherheitsmaßnahme ist.
Warum das kein Komfortproblem ist
Man könnte meinen: Projektinformationen landen im falschen Kanal, das ist unschön, aber nicht dramatisch. Das stimmt nicht. Ein konkretes Szenario:
Im Kanal "Projekt Beta" arbeiten ein Projektleiter und ein Teamleiter. Der Projektleiter hat Zugriff auf Projekt Alpha und Projekt Beta. Der Teamleiter hat nur Zugriff auf Projekt Beta. So sieht es die Berechtigungsmatrix vor.
Der Projektleiter fragt im Kanal: "Gibt es Abhängigkeiten zur Migration in Projekt Alpha?" Der Bot durchsucht Notion, findet die relevanten Dokumente aus Projekt Alpha und antwortet - im Kanal, sichtbar für beide.
Der Teamleiter hat jetzt Informationen aus Projekt Alpha. Nicht weil jemand einen Fehler gemacht hat. Nicht weil ein System gehackt wurde. Sondern weil der Bot genau das getan hat, wofür er gebaut wurde: die bestmögliche Antwort auf eine Frage geben.
Das ist eine Zugriffsverletzung durch einen Intermediär. Der Bot hat die Berechtigungsgrenzen des Kanals umgangen - nicht durch einen Exploit, sondern durch seine normale Funktion.
Bei einem menschlichen Projektleiter gibt es eine soziale Kontrolle. Er weiß, dass der Teamleiter keinen Zugriff auf Projekt Alpha hat, und formuliert entsprechend vorsichtig. Der Bot hat dieses Bewusstsein nicht. Und es wird noch unangenehmer: Der Teamleiter merkt vermutlich nicht einmal, dass er gerade Informationen sieht, die nicht für ihn bestimmt sind. Es steht ja nicht "VERTRAULICH" drüber. Es steht da als Teil einer hilfreichen Bot-Antwort.
Das Problem in drei Schichten
Was auf den ersten Blick wie eine Konfigurationslücke aussieht, entpuppt sich bei näherer Betrachtung als architektonisches Problem auf drei Ebenen:
Tool-Sichtbarkeit. Welche Werkzeuge darf der Bot in einem bestimmten Kanal überhaupt verwenden? Das ist die einfachste Ebene. Es gibt Gateways und Proxies, die das filtern können. Für viele Szenarien ist es allerdings zu grob - man will Notion nicht komplett sperren, sondern den Zugriff auf bestimmte Bereiche einschränken.
Daten innerhalb der Tools. Der Bot darf Notion nutzen - aber welche Datenbanken, welche Seiten? Er darf YouTrack abfragen - aber welche Projekte? Diese Einschränkung muss pro Tool und pro Kontext unterschiedlich sein.
Das Wissen des LLM. Selbst wenn die Werkzeuge korrekt gefiltert sind - wenn das LLM in einer früheren Nachricht Informationen aus einem anderen Kontext gesehen hat, kann es diese reproduzieren. Die Information ist im Modellkontext, und kein nachträglicher Filter holt sie dort wieder heraus.
Die falsche Frage: MCP oder API?
Mein erster Reflex war: Das Problem liegt am Protokoll. MCP - das Model Context Protocol, das sich gerade als Standard für die Anbindung von KI-Assistenten an externe Werkzeuge etabliert - kennt Authentication und Authorization, aber keinen Kontext-Scope. Es kann fragen "Wer bist du?" und "Was darfst du?", aber nicht "In welchem Kontext arbeitest du gerade?".
Also dachte ich: Dann gehen wir über direkte API-Aufrufe. Da haben wir volle Kontrolle, können den Scope selbst injizieren, müssen nicht auf ein Protokoll warten, das die nötige Dimension nicht hat.
Aber das war die falsche Abzweigung. Denn das Problem ist nicht MCP vs. API. Das Problem ist fundamentaler.
Die richtige Frage: Wer ruft das Tool auf?
Ob ein KI-Assistent über MCP oder über Function-Calling mit direkten APIs auf Werkzeuge zugreift - in beiden Fällen entscheidet das LLM, welches Tool es aufruft und welche Parameter es mitgibt. Das Protokoll ist austauschbar, aber die Architektur ist identisch: Das LLM ist der Agent, die Tools sind seine Werkzeuge, und die Ergebnisse fließen ungefiltert in seinen Kontext.
Man kann einen Proxy davorschalten, der den Scope erzwingt - also die Suchparameter manipuliert oder die Ergebnisse filtert, bevor sie das LLM erreichen. Das funktioniert, aber es bleibt ein nachgelagerter Schutzmechanismus. Das LLM hat weiterhin die Initiative, und der Proxy muss für jedes Tool wissen, wie "Scope" in dessen spezifischer API aussieht.
Die eigentlich relevante Unterscheidung ist nicht das Protokoll. Es ist die Frage, wer die Kontrolle über den Tool-Aufruf hat: die KI oder die Infrastruktur.
Drei Architekturen, drei Reifegrade
Daraus ergeben sich drei grundsätzlich verschiedene Ansätze, die in der Praxis unterschiedlichen Sicherheitsanforderungen entsprechen:
Das LLM als Agent. Das Modell bekommt eine Liste verfügbarer Werkzeuge - ob über MCP oder Function-Calling - und entscheidet selbst, was es aufruft. Das ist flexibel und schnell aufgesetzt. Es ist auch der Ansatz, den die meisten Tutorials zeigen und den die meisten Teams zuerst implementieren. Die Kontext-Isolation ist dabei ein ungelöstes Problem. Für interne, nicht-sensible Anwendungen kann das ausreichend sein. Für alles andere ist es ein offenes Scheunentor - und wie das Szenario mit dem Teamleiter zeigt, reicht bereits eine einzige Frage im falschen Kanal, um Berechtigungsgrenzen zu durchbrechen.
Das LLM mit Policy-Proxy. Zwischen dem Modell und den Werkzeugen sitzt ein Enforcement-Layer, der den Kontext kennt und jeden Tool-Aufruf entsprechend einschränkt. Das LLM ruft weiterhin die Tools auf, aber der Proxy manipuliert die Anfrage - er injiziert Scope-Filter in die Suchparameter, er filtert die Ergebnisse, bevor sie das Modell erreichen. Bessere Kontrolle, aber der Proxy braucht tool-spezifische Konfiguration für jedes angebundene System. Und theoretisch kann das LLM den Proxy durch kreative Parameterwahl herausfordern, wenn die Filterung nicht wasserdicht ist.
Das orchestrierte Backend. Das LLM hat keinen Werkzeugzugriff. Es ist eine Sprachschicht, keine Entscheidungsinstanz. Die Geschäftslogik sitzt in einem Orchestrator, der den Kontext kennt, die richtigen APIs mit dem richtigen Scope aufruft, die Ergebnisse aufbereitet und dem Modell nur das übergibt, was es für die Antwort braucht. Das LLM formuliert aus vorbereiteten, gefilterten Daten eine Antwort - und kann nur das verwenden, was der Orchestrator ihm gegeben hat. Der Scope wird architektonisch erzwungen, nicht per Policy. Das ist die sicherste Variante. Es ist auch die mit dem meisten Entwicklungsaufwand.
Was das für Unternehmen bedeutet
Diese drei Reifegrade sind keine akademische Unterscheidung. Sie haben unmittelbare Konsequenzen für jedes Unternehmen, das KI-Assistenten in seine Projektinfrastruktur integriert.
In der klassischen Zugriffskontrolle kennt man das Konzept als "Environment" in ABAC-Modellen. Ein Mitarbeiter hat Zugriff auf Projekt A und Projekt B. Aber wenn er im Kontext von Projekt A arbeitet, sollen Informationen aus Projekt B nicht in seinen Arbeitsbereich einfließen - nicht weil er keinen Zugriff hat, sondern weil der Kontext es nicht erfordert und die Vermischung ein Risiko darstellt.
Need-to-Know-Prinzipien, Chinese Walls im Finanzbereich, Mandantentrennung bei kritischer Infrastruktur - all das verlangt nicht nur Zugangsschutz, sondern Kontexttrennung. Und genau diese Kontexttrennung fehlt in den ersten beiden Reifegraden.
Man könnte einwenden: Dann lasst den Bot mit den Credentials des jeweiligen Nutzers agieren. Dann filtern die Backend-Systeme automatisch. In der Praxis scheitert das regelmäßig - nicht jedes System unterstützt OAuth-Delegation, nicht jede Firmen-Policy erlaubt es, und die Benutzergrenze ist nicht identisch mit der Kontextgrenze. Ein Projektleiter hat Zugriff auf alle seine Projekte, erwartet aber im Kanal von Projekt A eine Antwort im Kontext von Projekt A. Und selbst wenn die Antwort für den Projektleiter korrekt ist - sie ist sichtbar für alle anderen im Kanal, die möglicherweise weniger Berechtigungen haben.
Die Fragen, die beantwortet werden müssen
Wer gerade KI-Assistenten in seine Projektinfrastruktur integriert, sollte drei Dinge klären können:
Welche Informationen sieht der Assistent, wenn er eine Anfrage bearbeitet? Nicht welche er sehen darf - welche er tatsächlich sieht.
Wer entscheidet, welches Werkzeug mit welchen Parametern aufgerufen wird - die KI oder die Infrastruktur?
Und: Wer kann die Antwort lesen - und hat jeder dieser Leser die Berechtigung, die darin enthaltenen Informationen zu sehen?
Die letzte Frage ist die, die am häufigsten vergessen wird. Denn bei einem KI-Assistenten in einem Gruppenchat bestimmt nicht die Frage, wer die Antwort sieht. Das bestimmt der Kanal. Und der Kanal kennt keine Berechtigungsmatrix.
Andre Jahn ist freiberuflicher Solution Architect mit Schwerpunkt Legacy-Modernisierung und KI-Integration. Er baut die Dinge, über die er schreibt - und schreibt über die Dinge, die dabei schiefgehen.