Die Berechtigungskonzepte der meisten Unternehmen sind über Jahre gewachsen und folgen einem einfachen Bild: Ein Mensch meldet sich an einer Anwendung an und darf dort tun, was seine Rolle erlaubt. Die Buchhaltung sieht die Rechnungen, der Vertrieb die Kundenkontakte, die IT verwaltet die Zugänge. Wer etwas tut, ist klar, weil es immer eine angemeldete Person ist.
Ein KI-Agent passt nicht in dieses Bild. Er liest eine Anfrage im Postfach, schlägt im Warenwirtschaftssystem nach, holt ein Dokument aus der Ablage und schreibt einen Eintrag ins Ticketsystem. Er bewegt sich also über mehrere Systeme hinweg, und was er im einen liest, beeinflusst, was er im nächsten tut. Damit stellt sich eine Frage, die bisher selten gestellt werden musste: In wessen Namen handelt dieser Agent, und was genau darf er?
Das übliche Vorgehen und sein Problem
In vielen ersten Projekten wird die Frage pragmatisch gelöst. Der Agent bekommt einen technischen Zugang mit weitreichenden Rechten, oft ein Konto, das ursprünglich für eine Schnittstelle oder einen Administrator angelegt wurde. So funktioniert der Prototyp schnell, und niemand muss Rechte einzeln beantragen.
Im Betrieb führt das zu drei Schwierigkeiten:
- Der Agent kann mehr, als seine Aufgabe verlangt. Ein Agent, der Lieferstatus beantworten soll, braucht keinen Schreibzugriff auf Preise oder Kundenkonten. Hat er ihn trotzdem, genügt ein Fehler oder eine manipulierte Eingabe, um ihn zu nutzen.
- Eingaben von außen werden zu Anweisungen. Ein Agent liest E-Mails, Dokumente und Websites. Steht darin eine versteckte Aufforderung, etwa Daten an eine bestimmte Adresse zu senden, kann ein Sprachmodell sie als Teil seiner Aufgabe missverstehen. Je mehr Rechte der Agent hat, desto größer ist der mögliche Schaden.
- Niemand kann einen Schritt einer Person zuordnen. Wenn alle Agenten über dasselbe technische Konto arbeiten, steht im Protokoll nur, dass dieses Konto etwas geändert hat. Ob ein Agent für die Buchhaltung oder einer für den Kundendienst dahinterstand und in wessen Auftrag, bleibt offen.
Keines dieser Probleme ist neu. Neu ist, dass ein Agent selbst entscheidet, welche Schritte er ausführt, und dabei Inhalte verarbeitet, die niemand vorher geprüft hat.
Drei Fragen vor jedem Zugang
Bevor ein Agent Zugriff auf ein System bekommt, sollten drei Fragen beantwortet sein. Sie lassen sich ohne technische Detailkenntnis klären und gehören in die Abgrenzung der Aufgabe, nicht erst in die Umsetzung.
Handelt der Agent für sich oder für eine Person? Ein Agent, der nachts Produktdaten abgleicht, handelt im Auftrag des Unternehmens und braucht ein eigenes, klar benanntes Konto. Ein Agent, der einer Mitarbeiterin beim Beantworten ihrer Anfragen hilft, sollte dagegen höchstens das dürfen, was sie selbst darf, und im Protokoll als in ihrem Auftrag handelnd erscheinen.
Was muss er lesen, und was muss er ändern? Lesen und Schreiben sind getrennte Rechte und sollten auch getrennt vergeben werden. Viele Agenten müssen in einem System nur lesen und in genau einem anderen schreiben. Diese Unterscheidung allein schließt die meisten unerwünschten Wege aus.
Welche Schritte darf er allein ausführen? Manche Aktionen lassen sich leicht rückgängig machen, etwa ein Entwurf oder eine interne Notiz. Andere nicht: eine versendete E-Mail, eine ausgelöste Zahlung, eine gelöschte Datei. Für diese zweite Gruppe sollte vor der Ausführung eine Freigabe durch einen Menschen stehen.
Ein Raster für die Vergabe
Aus diesen Fragen ergibt sich ein einfaches Raster, mit dem sich für jeden Agenten und jedes System festhalten lässt, was erlaubt ist:
| Art der Aktion | Beispiel | Empfehlung |
|---|---|---|
| Lesen, intern | Bestellung nachschlagen | Erlaubt, eingeschränkt auf die nötigen Daten |
| Schreiben, umkehrbar | Entwurf anlegen, Ticket kommentieren | Erlaubt, protokolliert |
| Schreiben, schwer umkehrbar | Kundendaten ändern, Datensatz löschen | Nur mit Freigabe durch einen Menschen |
| Nach außen wirken | E-Mail versenden, Zahlung auslösen | Nur mit Freigabe, mit festen Obergrenzen |
Das Raster ersetzt kein Berechtigungskonzept, aber es macht sichtbar, wo ein Agent mehr Rechte hat, als seine Aufgabe braucht. Die Durchsetzung gehört dabei nicht in die Anweisung an das Modell, sondern in die Software um den Agenten herum. Ein Sprachmodell hält sich meistens an Regeln, aber nicht verlässlich. Ein Zugang, der eine Aktion technisch nicht erlaubt, hält sich immer daran. Dieser Gedanke zieht sich auch durch unseren Beitrag KI-Agenten als Bausteine: Der Ablauf gehört nicht dem Modell.
Ein Beispiel aus dem Einkauf
Ein Industriebetrieb möchte einen Agenten einsetzen, der eingehende Auftragsbestätigungen von Lieferanten prüft. Er liest die E-Mail mit dem angehängten Dokument, vergleicht Mengen, Preise und Liefertermine mit der Bestellung im Warenwirtschaftssystem und meldet Abweichungen.
Im ersten Entwurf soll der Agent Abweichungen gleich selbst korrigieren und dem Lieferanten antworten. Dafür bräuchte er Schreibrechte auf alle Bestellungen und das Recht, im Namen des Einkaufs E-Mails zu versenden. Eine präparierte Auftragsbestätigung mit einer versteckten Anweisung im Dokument hätte damit einen direkten Weg in die Bestelldaten und in die Kommunikation mit Lieferanten.
Die überarbeitete Fassung trennt die Rechte: Der Agent liest das Postfach für Auftragsbestätigungen und die zugehörigen Bestellungen, mehr nicht. Er schreibt ausschließlich in ein eigenes Feld für Prüfvermerke und legt bei Abweichungen einen Antwortentwurf an, den eine Person aus dem Einkauf prüft und selbst versendet. Er arbeitet über ein eigenes Konto, sodass im Protokoll jeder Vermerk ihm zugeordnet ist. Der Nutzen bleibt fast gleich, denn die eigentliche Arbeit, das Abgleichen, übernimmt weiterhin der Agent. Der mögliche Schaden einer manipulierten Eingabe beschränkt sich auf einen falschen Vermerk, den ein Mensch vor jeder Wirkung nach außen sieht.
Wie man festlegt, wer solche Entwürfe prüft und wann eine Prüfung reicht, beschreiben wir in KI-Entwürfe im Team: Wer prüft, was die Maschine schreibt?.
Was im Betrieb dazugehört
Zugriffsrechte sind keine einmalige Entscheidung. Damit sie im Alltag wirken, braucht es einige Gewohnheiten, die aus dem Umgang mit Menschen und Schnittstellen bekannt sind:
- Ein Konto pro Agent und Zweck. Getrennte Zugänge machen Protokolle lesbar und erlauben, einen einzelnen Agenten zu sperren, ohne alle anderen anzuhalten.
- Kurzlebige Schlüssel. Zugangsdaten, die regelmäßig erneuert werden und nicht im Quelltext oder in Konfigurationsdateien liegen, verlieren ihren Wert, falls sie doch einmal nach außen gelangen.
- Protokolle mit Auftraggeber. Jeder Schritt sollte festhalten, welcher Agent ihn ausgeführt hat, in wessen Auftrag und auf Grundlage welcher Eingabe.
- Regelmäßige Durchsicht. Wenn sich die Aufgabe eines Agenten ändert, ändern sich oft auch seine Rechte. Überzählige Rechte sollten dann ebenso entzogen werden wie bei einem Rollenwechsel im Team.
Diese Punkte planen wir beim Bau von KI-Agenten von Anfang an ein, weil sie sich nachträglich nur mit deutlich mehr Aufwand einziehen lassen.
Fazit
Ein KI-Agent ist weder eine Person noch eine gewöhnliche Schnittstelle. Er entscheidet selbst über seine Schritte und verarbeitet dabei Inhalte, die niemand vorher geprüft hat. Deshalb sollte er nur die Rechte bekommen, die seine Aufgabe tatsächlich verlangt: lesen, wo er lesen muss, schreiben, wo es umkehrbar ist, und alles, was nach außen wirkt, erst nach Freigabe durch einen Menschen. Wer vor dem ersten Zugang klärt, in wessen Namen der Agent handelt, ihm ein eigenes Konto gibt und jeden Schritt zuordenbar protokolliert, kann Agenten in mehreren Systemen arbeiten lassen, ohne die Kontrolle darüber zu verlieren, wer was getan hat.