Vezirov Consulting

Der Agent, der mehr darf, als er soll

Wenn ein KI-Assistent verspricht, nur zu lesen, sich aber das Recht zum Löschen holt, ist das kein Detail für die IT. Es ist ein Kontrollversagen — und niemand misst es.

Ein Befund, der unangenehm konkret ist

Ein Team der UC Berkeley und von IBM Research hat sich angesehen, welche Rechte KI-Assistenten tatsächlich anfordern, wenn man sie an Gmail, Notion, Dropbox oder Google Drive anschließt. Nicht theoretisch — sondern in den ausgelieferten Konnektoren von ChatGPT und Claude.

Das Ergebnis: sechs überprivilegierte Konfigurationen.

GmailChatGPT fordert Rechte für 50 API-Methoden an. Nötig wären 32 — und der Umfang schließt Ändern und Löschen ein, obwohl die Oberfläche „nur lesen" verspricht.
Notion32 statt 13 Methoden.
Dropbox44 statt 25 Methoden.
DriveClaudes Google-Storage-Integration: 45 statt 27 Methoden.

Das ist kein Bug. Das ist die Voreinstellung.

Warum das passiert

Man könnte schlampige Entwicklung vermuten. Die Untersuchung zeigt etwas Interessanteres.

Berechtigungsstrukturen sind kontraintuitiv. Man würde annehmen, dass ein Scope namens calendar.events.readonly weiter gefasst ist als calendar.events.owned.readonly — der Name ist ja allgemeiner. Tatsächlich ist es umgekehrt: Der spezifischere Scope schaltet mehr Methoden frei. Wer Rechte nach Namensähnlichkeit vergibt, liegt systematisch falsch. Dasselbe Muster steckt in Microsofts Mail.Read / Mail.ReadWrite.

Das Minimum ist kein Bauchgefühl, sondern ein Optimierungsproblem. Bei Google Calendar sind 24 von 37 API-Methoden über mehrere Berechtigungspfade erreichbar. Die naheliegende Faustregel — für jede Methode den engsten Scope wählen und alle vereinigen — liefert nachweislich nicht das Minimum. Die Autoren lösen das stattdessen als ganzzahliges Optimierungsproblem und bekommen damit eine garantiert minimale Rechtemenge.

Und man kann die Aufgabe nicht an ein Sprachmodell delegieren. Die Autoren haben genau das getestet: ein zweites LLM als „Berechtigungsexperte", das entscheidet, welche Rechte eine Aufgabe braucht. Ergebnis: 70 bis 83 Prozent Optimalität mit teuren proprietären Modellen, 20 bis 34 Prozent mit Open-Source-Modellen. Der Überprivilegierungsfaktor erreicht 1,04 bis 2,19 — der Agent bekommt also bis zu doppelt so viele Rechte wie nötig. Dazu spürbare Latenz und rund 6 Cent Zusatzkosten pro Anfrage.

Ein Modell zu bitten, sich an Least Privilege zu halten, ist keine Kontrolle. Es ist nur eine Bitte, die selten erfüllt wird.

Was mir daran auffällt

Ich habe Jahre damit verbracht, Modelle zu validieren — Marktpreisrisiko, Liquiditätsrisiko, und vieles mehr. Die Frage war immer dieselbe: Ist die Annahme im Modell noch tragfähig, und wer merkt es, wenn nicht?

Bei KI-Agenten wird gerade dieselbe Frage gestellt — aber am falschen Objekt. Wir prüfen das Modell: Halluzinationsraten, Bias, Output-Qualität. Was wir nicht prüfen, ist der Berechtigungsumfang. Er taucht in keinem Modellinventar auf, in keiner Risikoklassifizierung, in keiner Freigabe.

Ein halluzinierendes Modell mit Lesezugriff produziert einen falschen Text. Dasselbe Modell mit Schreib- und Löschrechten produziert einen Vorfall.

Drei Konsequenzen, die ich für praktisch halte:

  • Berechtigungsumfang gehört ins Modellinventar. Nicht als Freitext, sondern als Kennzahl: Wie viele Operationen kann dieses System auslösen, und wie viele bräuchte es? Das Verhältnis ist messbar, wie die Studie zeigt. Wer ein OpRisk-Framework betreibt, hat die Maschinerie dafür bereits.
  • Artikel 14 EU AI Act läuft leer, wenn der Mensch die falsche Frage bestätigt. Menschliche Aufsicht bedeutet in der Praxis: Der Nutzer gibt eine Aufgabe frei. Er gibt keine Rechte frei. Die Freigabe der Rechte ist einmalig bei der Einrichtung passiert, meist mit einem Klick, oft auf Basis einer Beschreibung, die — siehe Gmail — nicht stimmt.
  • Kontrolle darf nicht vom Kontrollierten ausgeführt werden. Das ist kein neuer Gedanke, das ist Prüfungsstandard. Trotzdem ist „Least Privilege per System-Prompt" gerade die verbreitetste Umsetzung in Agentenarchitekturen. In einer § 44-Prüfung wäre das der erste Befund.

Und nicht jedes Problem braucht ein Sprachmodell

Das ist für mich der eigentliche Nebenbefund dieser Studie, und er geht weit über Berechtigungen hinaus. Die Autoren haben die Frage „Welche Rechte sind minimal nötig?" nicht an ein LLM gegeben, sondern als ganzzahliges lineares Optimierungsproblem formuliert — eine Methode aus den Sechzigern. Sie ist exakt, sie ist beweisbar optimal, sie kostet 1 bis 6 Prozent Laufzeit. Die LLM-Variante ist ungenauer, langsamer, teurer und liefert keine Garantie.

Seit KI in aller Munde ist, wird reflexhaft alles mit einem Sprachmodell gelöst. Dabei sind viele der Probleme, die dabei entstehen, sauber definierte Optimierungs-, Klassifikations- oder Regelprobleme — genau die Klasse, für die wir seit Jahrzehnten Verfahren haben, die deterministisch, prüfbar und um Größenordnungen billiger sind. Ein Gradient-Boosting-Modell auf tabellarischen Daten schlägt ein LLM immer noch regelmäßig. Ein Solver liefert ein Optimum, wo ein Prompt eine Schätzung liefert.

Für Governance ist das kein Nebenthema, sondern der Kern: Wo ein deterministisches Verfahren dieselbe Aufgabe löst, ist der Einsatz eines Sprachmodells nicht nur teurer — er erzeugt zusätzlich Nachweispflichten, die man sich hätte sparen können. Die erste Frage vor jedem Agenten-Projekt sollte deshalb lauten: Ist das hier wirklich ein Sprachproblem?

Wer also gerade Agenten in produktive Prozesse bringt: Die Frage ist nicht, ob das Modell zuverlässig genug ist. Die Frage ist, was passiert, wenn es das nicht ist. Und diese Antwort steht unter anderem in der Berechtigungskonfiguration, nicht nur im Modellsteckbrief.

Quelle: Zhu, J.; Tseng, K.; Vernik, G.; Huang, X.; Patil, S.; Fang, V.; Popa, R. A. (2025): MiniScope: A Least Privilege Framework for Authorizing Tool Calling Agents. UC Berkeley / IBM Research, arXiv:2512.11147

Dazu eine Meinung — oder eine Frage?

Gespräch anfragen