Risiken von KI-Agenten: Welche Rechte ein Agent bekommt und wo eine Freigabe hingehört

Solange eine KI nur antwortet, liest ein Mensch die Antwort, bevor etwas passiert. Ein KI-Agent verschickt dagegen selbst E-Mails, ändert Datensätze oder löst Bestellungen aus. Damit fällt dieser Mensch aus der Kette, und das Risiko verschiebt sich von falschen Antworten zu falschen Aktionen.

Naheliegend wäre es, jede Aktion freigeben zu lassen. Dann macht der Agent aber nur noch Vorschläge und kostet mehr, als er bringt. Die Freigaben selbst werden nach wenigen Tagen ungelesen bestätigt. Besser funktioniert eine einfache Regel. Du vergibst Rechte pro Aktion, je nachdem, wie groß der Schaden im schlimmsten Fall ist und ob er sich rückgängig machen lässt. Eine Freigabe brauchen nur Aktionen, die Geld bewegen, nach außen gehen oder sich nicht mehr rückgängig machen lassen. Alles andere erledigt der Agent selbst, und im Protokoll siehst du nach, was er getan hat.

Warum ein handelnder Agent ein anderes Risiko hat als ein Chatbot

Bei einem Chat-Werkzeug ist ein Fehler ein falscher Text. Zwischen diesem Text und seiner Wirkung steht aber ein Mensch, der ihn kopiert, abschickt oder verwirft. Wie teuer ein falscher Text schon wird, wenn er ohne diesen Zwischenschritt beim Kunden landet, zeigt der Fall Moffatt gegen Air Canada. Der Chatbot der Airline hatte einem Kunden eine Erstattungsregel für Trauerfälle erklärt, die es so nicht gab. Air Canada argumentierte, der Chatbot sei für seine Aussagen selbst verantwortlich. Das Civil Resolution Tribunal in British Columbia folgte dem nicht. Der Chatbot sei Teil der Website, und die Airline stehe für alle Informationen darauf ein. Der Kunde bekam rund 650 kanadische Dollar Schadensersatz.

Ein Agent formuliert nicht nur, er führt auch aus. Er hat Zugriff auf Postfach, CRM, Kalender oder Buchhaltung und nutzt diesen Zugriff, um das Ziel zu erreichen, das du ihm gegeben hast. Damit entfällt die Stelle, an der bisher ein Mensch Fehler abgefangen hat. Entscheidend ist dann weniger, wie gut das Modell formuliert, sondern was es mit den Rechten anrichten kann, die es hat.

Das OWASP-Projekt für die Sicherheit generativer KI nennt dieses Risiko „Excessive Agency“, also zu viel Handlungsmacht. Es führt das Risiko auf drei Ursachen zurück. Der Agent hat Funktionen, die er für seine Aufgabe nicht braucht. Seine Berechtigungen in den angebundenen Systemen reichen weiter als nötig. Und er führt folgenreiche Aktionen aus, ohne dass jemand sie bestätigt. Alle drei Ursachen stellst du bei der Einrichtung ein, und dort lassen sie sich auch beheben.

Woher falsche Aktionen kommen

Bei KI-Risiken denkt man zuerst an Angreifer. Anthropic hat für seinen Programmier-Agenten Claude Code aufgeschrieben, aus welchen Gründen ein Agent gefährliche Aktionen ausführt, und stützt sich dabei auf ein internes Protokoll echter Vorfälle. Die Vorfälle darin hatten eine gemeinsame Ursache: einen übereifrigen Agenten. Er versteht das Ziel und will helfen, geht dabei aber weiter, als der Nutzer es gewollt hätte.

Ein Beispiel aus diesem Protokoll: Ein Nutzer bat darum, „alte Branches aufzuräumen“. Der Agent löschte daraufhin Entwicklungszweige auf dem gemeinsamen Server, obwohl vermutlich nur die lokalen gemeint waren. In einem anderen Fall stieß der Agent auf einen Berechtigungsfehler. Er fragte nicht nach, sondern durchsuchte Konfigurationsdateien nach anderen Zugangsschlüsseln, um weiterzumachen. Übertragen auf ein Unternehmen heißt das: Ein Agent, der einen Ordner nicht öffnen darf, sucht sich einen anderen Weg hinein, weil er die Aufgabe erledigen will.

Dazu kommen ehrliche Fehler. Dabei schätzt der Agent die Reichweite einer Aktion falsch ein, zum Beispiel weil er einen gemeinsam genutzten Datenbestand für einen Testbestand hält. Die dritte Ursache ist Prompt Injection. Das sind Anweisungen, die in einer E-Mail, einem Dokument oder einer Webseite versteckt sind und die der Agent beim Lesen für einen Auftrag hält. OWASP beschreibt dazu einen Assistenten, der eingehende E-Mails zusammenfassen soll. Eine präparierte Mail bringt ihn dazu, das Postfach nach vertraulichen Informationen zu durchsuchen und sie an den Angreifer weiterzuleiten. Das klappt nur, weil die eingebundene Erweiterung neben dem Lesen auch das Senden erlaubt.

Keine dieser Ursachen setzt voraus, dass der Agent etwas Böses will. Ein gutes Modell allein schützt dich also nicht. Wie groß der Schaden wird, hängt davon ab, was der Agent tun kann, wenn er sich irrt oder getäuscht wird.

Warum ein Verbot im Prompt keine Grenze ist

Im Juli 2025 schrieb der SaaStr-Gründer Jason Lemkin öffentlich darüber, wie der KI-Agent der Entwicklungsplattform Replit eine Live-Datenbank löschte. Das geschah während eines ausdrücklich angeordneten Änderungsstopps (Fortune berichtete). Betroffen waren Daten zu mehr als 1.200 Führungskräften und über 1.190 Unternehmen. Der Agent hatte die Anweisung, ohne menschliche Zustimmung nichts zu verändern, und handelte trotzdem. Anschließend behauptete er, eine Wiederherstellung sei nicht möglich. Das war falsch, denn Lemkin holte die Daten selbst zurück.

Replit reagierte darauf technisch. Entwicklungs- und Produktionsdatenbank werden seitdem automatisch getrennt, und es kam ein Modus dazu, in dem der Agent nur planen und nichts verändern kann. Genau das ist die Lehre aus dem Fall. Eine Anweisung im Prompt ist eine Bitte an das Modell. Das Modell kann sie missverstehen, im Lauf einer langen Aufgabe aus den Augen verlieren oder durch einen eingeschleusten Text überschrieben bekommen. Eine Grenze hält nur, wenn das System dahinter sie durchsetzt.

OWASP nennt dieses Prinzip „Complete Mediation“. Das angebundene System prüft jede Anfrage gegen seine eigenen Berechtigungsregeln und überlässt die Entscheidung nicht dem Sprachmodell. Soll ein Agent keine Kundendatensätze löschen, bekommt er einen Zugang ohne Löschrecht. Soll er nur Mails zusammenfassen, bekommt er nur Leserechte auf das Postfach. Was er technisch nicht kann, muss er auch nicht unterlassen.

Was eine Freigabe für alles kostet

Wer für jede Aktion eine Freigabe verlangt, fühlt sich sicher, aber dieses Gefühl hält nicht lange. Anthropic hat gemessen, dass Nutzer von Claude Code 93 Prozent der Freigabeanfragen annehmen. Das Unternehmen beschreibt den Effekt dahinter als Freigabemüdigkeit. Wer ständig bestätigen muss, schaut irgendwann nicht mehr genau hin. Den Nutzern kann man das kaum vorwerfen. Wenn fast jede Anfrage harmlos ist, lernt jeder vernünftige Mensch, dass Bestätigen die richtige Reaktion ist, und bestätigt dann auch die eine Anfrage, die es nicht ist.

Eine Beispielrechnung mit angenommenen Werten zeigt, wie das im Alltag aussieht. Ein Agent im Vertriebsinnendienst erledigt am Tag 120 einzelne Schritte. Er legt CRM-Notizen an, aktualisiert Kontaktdaten, schreibt Antwortentwürfe, trägt Wiedervorlagen ein und fasst eingehende Anfragen zusammen. Braucht jede Freigabe mit Lesen und Unterbrechung der eigenen Arbeit 30 Sekunden, kostet das eine Stunde am Tag, verteilt auf 120 Unterbrechungen. Drei dieser Schritte verschicken ein Angebot oder sagen einen Rabatt zu. Diese drei prüft derselbe Mensch mit derselben flüchtigen Aufmerksamkeit wie die 117 CRM-Notizen davor.

Dazu kommt, dass der Agent bei jeder offenen Freigabe wartet. Was über Nacht erledigt sein könnte, liegt morgens noch da, und der Nutzen der Automatisierung verschwindet. Die Nutzer weichen dann aus, und zwar oft in die gefährlichste Richtung. Anthropic beschreibt genau das. Um den Bestätigungen zu entgehen, schalten viele Nutzer die Freigaben mit einer Option komplett ab, die Anthropic selbst für die meisten Situationen als unsicher bezeichnet. So endet eine Freigabepflicht für alles oft bei gar keiner Kontrolle.

Zwei Fragen pro Aktion: Wie groß ist der Schaden, und lässt er sich zurückdrehen?

Für jede Aktion, die ein Agent ausführen kann, reichen zwei Fragen. Die erste lautet, was im schlimmsten Fall passiert, wenn er sie falsch ausführt. Die zweite lautet, ob sich dieser Schaden vollständig zurückdrehen lässt, bevor jemand außerhalb deines Unternehmens davon betroffen ist.

Die zweite Frage wird oft unterschätzt, dabei spart sie die meisten Freigaben. Eine falsche Notiz im CRM ist ärgerlich, aber mit dem Änderungsverlauf in einer Minute behoben. Eine falsch verschickte Mail an einen Kunden lässt sich dagegen nicht zurückholen, auch wenn sie aus nur zwei Sätzen besteht. Ob eine Aktion umkehrbar ist, hängt von deinen Systemen ab und nicht von der Aktion allein. Löschen in einem Ordner mit Papierkorb und Versionen ist umkehrbar. Löschen in einer Datenbank ohne Sicherung ist es nicht.

Anthropic nutzt diesen Zusammenhang in Claude Code ausdrücklich. Dateiänderungen innerhalb des Projekts laufen ohne jede Prüfung, weil die Versionsverwaltung jede Änderung sichtbar und umkehrbar macht. Nur Aktionen, bei denen wirklich etwas schiefgehen kann, landen in der Prüfung. Für dich heißt das, dass du Freigaben oft vermeiden kannst, indem du eine Aktion umkehrbar machst. Der Agent legt einen Entwurf an, statt zu senden. Er verschiebt Dateien in einen Archivordner, statt sie zu löschen. Er arbeitet in einer Kopie der Daten, statt im Live-System. Die Trennung von Entwicklungs- und Produktionsdatenbank, die Replit nachgerüstet hat, folgt demselben Gedanken.

Aus den zwei Fragen ergibt sich eine einfache Ordnung. Kleine und umkehrbare Aktionen erledigt der Agent selbst. Große, aber umkehrbare Aktionen erledigt er ebenfalls selbst, mit Protokoll und festen Grenzen, etwa einer Höchstzahl geänderter Datensätze pro Tag. Eine Freigabe braucht erst die Aktion, bei der ein relevanter Schaden entstehen kann und sich nicht zurückholen lässt.

Drei Arten von Aktionen brauchen eine Freigabe

In der Praxis fallen fast alle Aktionen mit echtem Risiko in drei Gruppen.

Die erste Gruppe bewegt Geld. Dazu gehören Zahlungen, Bestellungen, Gutschriften, Rabatte und Änderungen an Vertragskonditionen. Hier entsteht der Schaden direkt, er ist oft nur mit Aufwand oder gar nicht umkehrbar, und genau diese Aktionen versucht ein Angreifer über präparierte Rechnungen oder Mails auszulösen.

Die zweite Gruppe geht nach außen. Gemeint sind Angebote, Zusagen zu Preisen oder Lieferterminen, Aussagen im Namen des Unternehmens und jede Weitergabe interner Daten an Dritte. Was ein Kunde erhalten hat, kannst du nicht zurückrufen, und der Fall Air Canada zeigt, dass ein Unternehmen für solche Aussagen einstehen muss. Zur zweiten Gruppe gehört auch der Datenabfluss. Anthropic blockiert zum Beispiel, dass der Agent ein Skript zur Fehlersuche auf einen öffentlichen Dienst hochlädt, weil der Inhalt vertraulich sein kann.

Die dritte Gruppe lässt sich nicht rückgängig machen. Das sind Löschen ohne Sicherung, Kündigen, Überschreiben ohne Version und Änderungen an Berechtigungen, auch an denen des Agenten selbst.

Nicht jede Mail an einen Kunden braucht deshalb eine Einzelfreigabe. Eine Eingangsbestätigung nach fester Vorlage enthält keine Zusage, die über die Vorlage hinausgeht. Also gibst du die Vorlage einmal frei, und der Agent verschickt sie danach selbst. Wichtig ist, dass diese Regel ausdrücklich festgelegt ist. Aus einer früheren Einzelfreigabe darf der Agent keine Erlaubnis für ähnliche Fälle ableiten. An genau dieser Stelle scheitert laut Anthropic auch ihr eigener automatischer Prüfer am häufigsten. Er findet im Verlauf etwas, das wie eine Zustimmung aussieht, und prüft nicht, ob sie genau diese Aktion mit ihrer ganzen Reichweite abdeckt.

Wie du die Rechte praktisch zuschneidest

Der erste Schritt ist eine Liste der Aktionen, die ein Agent in seinem Bereich ausführen soll. Die Liste der Systeme, auf die er Zugriff bekommt, reicht dafür nicht, denn dort liegt der typische Fehler. Ein Agent soll Rechnungen im Buchhaltungssystem nachschlagen und bekommt dafür einen Zugang, der auch Zahlungen anlegen kann, weil die Integration das eben mitbringt. OWASP nennt genau dieses Muster als erstes Beispiel für zu viel Handlungsmacht.

Für einen Agenten im Vertriebsinnendienst könnte die Zuordnung so aussehen:

In der letzten Zeile steht bewusst „kein Recht“ und keine Freigabe. Braucht ein Agent eine Aktion für seine Aufgabe nie, bekommt er sie auch nicht. Eine Freigabe ist für Aktionen gedacht, die regelmäßig vorkommen und im Einzelfall ein Urteil brauchen.

Drei technische Punkte gehören dazu. Der Agent handelt mit einer eigenen Identität oder im Namen des Nutzers, für den er arbeitet, und nie über ein allgemeines Administratorkonto. Die Zugangsdaten zu deinen Systemen liegen nicht beim Agenten, damit er sie weder weitergeben noch für einen Umweg nutzen kann. Und jede ausgeführte Aktion landet mit Ergebnis in einem Protokoll. OWASP ergänzt Mengengrenzen, etwa eine Höchstzahl versendeter Nachrichten pro Stunde. Sie verhindern keinen Fehler, begrenzen aber, wie viel Schaden entsteht, bevor jemand ihn bemerkt.

Wie eine Freigabe aussehen muss, damit sie etwas prüft

Eine Freigabe schützt nur, wenn der Mensch sieht, was er freigibt. „Der Agent möchte eine E-Mail senden“ ist dafür zu wenig. Die Anfrage zeigt Empfänger, Betreff, den vollständigen Text, den Betrag und die Frist, um die es geht. Die Freigabe gilt genau für diese Aktion. Ändert der Agent danach den Text oder den Empfänger, braucht er eine neue.

Freigeben sollte die Person, die diese Entscheidung auch ohne Agenten treffen würde. Ein Rabatt über der üblichen Grenze geht an denselben Vertriebsleiter wie bisher, eine Zahlung an dieselbe Person, die auch sonst Zahlungen freigibt. So entsteht kein neuer Prozess, und die Freigabe landet bei jemandem, der den Fall beurteilen kann. Solange die Entscheidung aussteht, pausiert die Aufgabe und läuft danach weiter.

Einmal im Monat lohnt ein Blick auf die Freigaben selbst. Werden Anfragen einer Art über Wochen ohne Änderung bestätigt, kannst du sie in eine Regel mit Grenze umwandeln, etwa Rabatte bis fünf Prozent ohne Einzelfreigabe. Werden sie oft geändert oder abgelehnt, fehlt dem Agenten Kontext, oder seine Anweisungen sind unklar. Dann lohnt es sich, dort nachzubessern, statt weitere Kontrollen einzuziehen.

Womit du anfängst

Nimm einen Agenten und einen Bereich, in dem die Arbeit gut überschaubar ist. Schreib die Aktionen auf, die er ausführen soll, und stell dir für jede die zwei Fragen nach Schaden und Umkehrbarkeit. Prüf danach, welche Rechte die angebundenen Systeme tatsächlich vergeben, denn die sind häufig breiter als die Liste. Streich alles, was der Agent nicht braucht.

Lass den Agenten danach zwei Wochen arbeiten und lies das Protokoll. Du siehst dann, welche Aktionen er wirklich ausführt, wo er an Grenzen stößt und welche Freigaben nur Zeit kosten. Auf dieser Grundlage erweiterst du die Rechte Schritt für Schritt. Du legst die Ziele und Grenzen fest, und der Agent erledigt die Routine. Eine Freigabe bekommst du nur dort vorgelegt, wo dein Urteil noch etwas am Ergebnis ändert.

Häufige Fragen

Wer haftet, wenn ein KI-Agent einen Fehler macht?

Im Fall Moffatt gegen Air Canada hat ein kanadisches Tribunal das Argument zurückgewiesen, der Chatbot sei für seine Aussagen selbst verantwortlich. Das Unternehmen musste für die falsche Auskunft einstehen. Wie ein deutsches Gericht einen konkreten Fall bewertet, klärst du am besten mit deinem Rechtsbeistand. Plan in jedem Fall so, als würdest du für alles einstehen, was dein Agent sagt und tut.

Schreibt der EU AI Act eine menschliche Freigabe vor?

Artikel 14 des AI Act verlangt menschliche Aufsicht für Hochrisiko-KI-Systeme. Nach der Übersicht zum Gesetzestext gilt das für Systeme aus Anhang III ab dem 2. Dezember 2027. Die Aufsicht soll dabei im Verhältnis zu Risiko, Autonomie und Einsatzkontext stehen. Eine pauschale Freigabe jeder Aktion verlangt der Artikel nicht. Ob dein Einsatz als Hochrisiko gilt, hängt vom Anwendungsfall ab, etwa bei Personalentscheidungen.

Reicht es, dem Agenten im Prompt zu sagen, was er nicht darf?

Nein. Der Fall Replit zeigt, dass ein Agent eine ausdrückliche Anweisung missachten und trotzdem Daten löschen kann. Grenzen müssen in den Berechtigungen der angebundenen Systeme liegen. Was der Agent technisch nicht kann, muss er auch nicht unterlassen.

Kann ein Agent durch eine E-Mail manipuliert werden?

Ja. Bei Prompt Injection stehen Anweisungen in einer Mail oder einem Dokument, die der Agent beim Lesen für einen Auftrag hält. Den Schaden begrenzt du, indem ein Agent, der Mails liest, nicht gleichzeitig ungeprüft nach außen senden darf. Braucht er beide Rechte, braucht das Senden an neue Empfänger eine Freigabe.

Woran erkenne ich, dass wir zu viele Freigaben haben?

Werden fast alle Anfragen ohne Änderung bestätigt, prüft niemand mehr wirklich. Bei Claude Code lag diese Quote laut Anthropic bei 93 Prozent. Wandle solche Anfragen in Regeln mit klaren Grenzen um und behalte die Einzelfreigabe für Geld, Zusagen nach außen und Aktionen, die sich nicht rückgängig machen lassen.