Ein in The New Stack veröffentlichter Versuch zeigt, dass die Vergabe umfangreicherer Berechtigungen an einen KI-Agenten, als dieser benötigt, einen einfachen Logikfehler in eine wiederholte finanzielle Transaktion verwandeln kann, die das Modell nicht selbst stoppt. Bei einem Test mit Kundenrechnungen bestätigte ein Support-Agent, dass die Zahlung fehlgeschlagen sei und dem Kunden kein Geld abgebucht worden sei. Dennoch führte er eine Rückerstattung durch, obwohl die Daten dies nicht stützten, und wiederholte den Fehler fünfmal.
Claude Sonnet 5 erkannte alle sechs Fälle, die zur Prüfung dieses Fehlers entwickelt worden waren, während Claude Haiku 4.5 bei allen scheiterte. Auch eine einzige Zeile in den Systemanweisungen, die vor der Ausführung einer finanziellen Aktion die Überprüfung des Transaktionsstatus verlangte, behob das Problem. Der Autor ist jedoch der Ansicht, dass beide Lösungen anfällig sind: Die Organisation könnte das Modell durch eine günstigere Version ersetzen oder die Anweisungen während eines Experiments ändern, sodass der Schutz ohne klare Warnung verschwindet.
Die verweigerte Berechtigung als Sicherheitsbarriere
Der Schutz, der diesen Änderungen standhielt, bestand darin, dem Agenten die Berechtigung billing:refund von vornherein zu verweigern. Dadurch scheiterte die Ausführung auf der Berechtigungsebene, unabhängig vom Modell oder der Formulierung der Anweisungen. Dies ist die Quintessenz des Prinzips der geringsten Privilegien in der Architektur von KI-Agenten: Es geht nicht nur darum, Angreifer abzuwehren oder Geheimnisse zu schützen, sondern auch darum, einen gutwilligen Agenten daran zu hindern, falsche Anweisungen schnell, automatisiert und ohne menschliche Aufsicht auszuführen.
Die Natur eines Agenten unterscheidet sich von der eines herkömmlichen Dienstkontos, das eine festgelegte Funktion erfüllt. Ein Support-Agent kann um 09:00 Uhr ein Ticket lesen, um 09:04 Uhr eine Rückerstattung ausführen und um 09:11 Uhr die Anzahl der Sitze ändern. Daher spiegelt die Menge an Berechtigungen, die er für all seine möglichen Tätigkeiten während einer Woche benötigt, nicht unbedingt wider, was er für eine einzelne Aufgabe braucht.
Was hat der Versuch gemessen?
Der Autor entwickelte eine Testumgebung mit 30 Berechtigungen, die auf neun Bereiche in einer simulierten Unternehmens-API verteilt waren. Dazu gehörten Tickets, Benutzer, Abrechnung, Abonnements, Dateien, Nachrichten, Audit, Verwaltung und Suche. Dreizehn Berechtigungen konnten den Zustand ändern oder auslesen. Der Versuch umfasste 20 Aufgaben, von denen jede ein automatisch überprüfbares Ergebnis hatte, etwa das Schließen eines Tickets oder die Rückerstattung eines Rechnungsbetrags.
Vier Berechtigungsmodelle wurden auf den beiden Ebenen Claude Haiku 4.5 und Claude Sonnet 5 verglichen, insgesamt 160 Durchläufe:
- Umfangreiche Berechtigung: eine langfristige Vergabe, die alle 30 Berechtigungen umfasst.
- Feste Rolle: eine Supportrolle mit 17 Berechtigungen, abgeleitet aus einer typischen Stellenbeschreibung.
- Aufgabenbezogene Begrenzung: Vergabe der für jeden Durchlauf erforderlichen Berechtigungen und deren Entzug nach Abschluss.
- Just-in-time-Aktivierung: Beginn ohne Berechtigungen und Anforderung jeder Berechtigung bei Bedarf unter Angabe einer Begründung.
Die aufgabenbezogene Begrenzung reduziert den Schadensumfang
Das Modell der aufgabenbezogenen Begrenzung erledigte die Aufgaben vollständig und nutzte dabei im Vergleich zur umfassenden Vergabe etwa ein Fünfzehntel der Berechtigungen. Gelegentliche Ablehnungen und Wiederholungsversuche führten zu keiner nennenswerten Erhöhung der Anzahl der API-Aufrufe.
Das Modell der festen Rolle war auf beiden Achsen am schwächsten. Es vergab 17 Berechtigungen, von denen vier von keiner Aufgabe genutzt wurden, während neun grundlegende Berechtigungen fehlten. Eine Erweiterung der Rolle, bis alle Aufgaben erfolgreich waren, hätte 26 Berechtigungen erfordert, gegenüber einem Median von lediglich zwei Berechtigungen pro Aufgabe. Damit ist die feste Rolle zugleich zu weit und zu eng gefasst, weil sie die Entscheidung auf die Berufsbezeichnung statt auf die tatsächliche Arbeit stützt.
Das Modell der Just-in-time-Aktivierung erreichte einen ähnlich niedrigen Schadensumfang, benötigte jedoch rund 80 % zusätzliche API-Aufrufe. Außerdem betraf die Berechtigungsverweigerung im Aufgabenmodell meist optionale Erkundungspfade, während die Verweigerung im Modell der festen Rolle endgültig war, weil sie eine grundlegende Berechtigung blockierte.
Warum ist das für Organisationen wichtig?
Die Ergebnisse zeigen, dass die Fähigkeiten des Modells und die Systemanweisungen zwei veränderliche Verteidigungsebenen sind, während eine nicht vergebene Berechtigung auch beim Wechsel des Modells oder bei einer Änderung des Prompts wirksam bleibt. Teams sollten die Berechtigungen des Agenten daher auf die aktuelle Aufgabe zuschneiden und sensible Berechtigungen temporär und revisionsfähig machen, anstatt sie in einer dauerhaft weitreichenden Rolle zu bündeln.
Der Versuch bleibt auf eine künstliche Umgebung, 20 Aufgaben und zwei Claude-Modelle beschränkt. Daher belegt er nicht, dass die Ergebnisse in jeder Organisation oder mit jedem Modell identisch ausfallen werden. Er liefert jedoch einen klaren praktischen Hinweis: Das Testen des Agenten reicht nicht aus, wenn die Architektur ihm die Ausführung von Aktionen erlaubt, die er nicht benötigt, denn ein Wechsel des Modells oder der Anweisungen kann das Verhalten ändern, während die Fähigkeit, Schaden anzurichten, bestehen bleibt.