Ihr KI-Agent handelt unter fremdem Namen — und Ihr Protokoll behauptet etwas Falsches

Wer einen Agenten baut, steht früh vor einer praktischen Frage: Womit greift er auf die Systeme zu, mit denen er arbeiten soll?

Die Antwort, die am schnellsten funktioniert, ist das Token des Benutzers, der den Agenten gerade verwendet. Aus Sicht der Entwicklung hat sie nur Vorteile. Die Berechtigungen stimmen bereits, denn der Benutzer darf, was der Agent tun soll. Es muss nichts beantragt und nichts freigegeben werden. Und die Zielsysteme funktionieren ohne jede Anpassung, weil für sie gar nichts Neues passiert.

Genau das ist das Problem. Für die Zielsysteme passiert nichts Neues.

Ein Protokolleintrag, der etwas Falsches behauptet

Ein Serviceteam betreibt einen Assistenten, der Kundenanfragen vorbereitet: Vorgang zusammenfassen, Historie prüfen, Antwortentwurf schreiben. Er läuft unter dem Token der Mitarbeiterin, die ihn gerade nutzt.

Eine der Anfragen enthält, eingebettet in einen weitergeleiteten E-Mail-Verlauf, eine Anweisung. Der Assistent führt sie aus und gibt eine Rückerstattung frei. Die Funktion stand ihm zur Verfügung, weil die Mitarbeiterin sie hat. Für seine Aufgabe gebraucht hat er sie nie.

Im Protokoll des Abrechnungssystems steht:

2026-06-03T14:22:07Z   refund.approve
  amount     4.812,00 EUR
  actor      s.weber@example.com
  channel    web-api

Diese Zeile ist vollständig, korrekt formatiert und inhaltlich falsch. Sie behauptet, ein Mensch habe eine Freigabe erteilt. Was daraus folgt, ist unangenehmer als der Betrag:

• Die Revision sieht eine Freigabe ohne Vier-Augen-Prinzip durch eine namentlich benannte Person.
• Die Mitarbeiterin bestreitet die Handlung. Sie hat recht. Beweisen kann sie es nicht.
• Es gibt keinen technischen Weg, den Assistenten zu stoppen, ohne ihren Zugang zu sperren.
• Und ob weitere Freigaben denselben Ursprung haben, lässt sich nicht beantworten. Es gibt kein Merkmal, nach dem man suchen könnte.

Der Schaden liegt nicht in den 4.812 Euro. Er liegt darin, dass das Unternehmen über die eigene Historie keine belastbare Aussage mehr treffen kann.

Die drei Verluste

Zurechenbarkeit

Im Protokoll steht der Name des Menschen, ausgewiesen als Handelnder. Nach einem Vorfall lässt sich nicht mehr feststellen, ob der Mensch die Aktion ausgelöst hat oder ein System in seinem Namen. Ein Protokolleintrag, der einen Menschen nennt, der nicht gehandelt hat, ist nicht wertlos. Er ist falsch.

Rechteminimierung

Der Agent erbt alle Rechte des Menschen, auch die, die er für seine Aufgabe nie braucht. Ein Agent, der Angebote vergleichen soll, kann Rückerstattungen freigeben, wenn sein Auftraggeber das darf.

Widerruf

Es gibt keinen Schalter, der den Agenten stoppt und den Menschen weiterarbeiten lässt. Wer den Zugang sperrt, sperrt beide. In einem Vorfall ist das die Entscheidung zwischen „Agent läuft weiter“ und „Fachbereich steht still“.

Warum die üblichen Gegenvorschläge nicht greifen

Die Reaktion auf das Benutzer-Token ist meist eines von drei bekannten Mustern. Jedes löst einen Teil und lässt einen anderen offen.

Das gemeinsame Muster: Alle drei behandeln Identität als Eigenschaft. Bei einem Agenten ist Identität aber eine Beziehung zwischen dem, was das System ist, und dem, wofür es gerade handelt. Diese Beziehung wechselt, während das System dasselbe bleibt.

Ein Service Account, der morgens Angebote vergleicht und nachmittags Rechnungen prüft, ist in beiden Fällen derselbe Principal mit denselben Rechten. Ein Agent, der dasselbe tut, sollte in beiden Fällen unterschiedlich befugt sein, weil er einen anderen Auftrag hat.

Vier Fragen, die in einem Token verschmelzen

In klassischen Systemen fielen die ersten beiden dieser Fragen zusammen. Ein Batchjob ist, was er ist, und handelt immer im selben Auftrag. Ein Benutzer ist, wer er ist, und handelt für sich selbst. Ein Agent ist das erste System, bei dem beides regelmäßig auseinandergeht: dieselbe Laufzeit, wechselnde Auftraggeber, wechselnde Aufgaben.

Wer diese vier Fragen mit einem Token beantwortet, hat das Benutzer-Token nur umbenannt.

Der Standard, den kaum jemand nutzt

Für die Darstellung von Delegation existiert seit 2020 ein Standard: RFC 8693, OAuth 2.0 Token Exchange, mit dem act-Claim.

{
  "sub":   "s.weber@example.com",
  "act":   { "sub": "agent://service-assistant/prod-7" },
  "aud":   "billing-api",
  "scope": "read:case write:case_note"
}

Die Leserichtung ist die, an der die meisten Implementierungen scheitern: sub benennt denjenigen, in dessen Auftrag gehandelt wird, act den, der tatsächlich handelt. Nicht umgekehrt. Das Protokoll aus dem Beispiel oben hätte damit den Agenten als Handelnden ausgewiesen, im Auftrag der Mitarbeiterin. Und der fehlende Scope write:refund hätte die Aktion ohnehin verhindert.

Dass delegiert wurde, ist eine Tatsache. Dass delegiert werden durfte, ist eine Entscheidung. Derselbe Standard kennt dafür einen zweiten, meist übersehenen Claim: may_act benennt, wer überhaupt berechtigt ist, für ein Subjekt als Actor aufzutreten. Sicherheit entsteht daraus allerdings erst, wenn der Authorization Server diese Beziehung bei der Ausstellung tatsächlich prüft. Ein Claim ist zunächst nur eine Behauptung seines Ausstellers.

Was weder scope noch act sagen, ist, wozu delegiert wurde. Ein Scope wie write:case_note gilt für jeden Vorgang; die Delegation sollte für genau einen gelten. Dafür gibt es RFC 9396 mit authorization_details: „darf Vorgang 88429 lesen und kommentieren, bis 15 Uhr“. Der Unterschied ist der zwischen einer Rolle und einem Auftrag.

Autorität schrumpft, oder die Kette ist gebrochen

Ruft ein Agent einen anderen auf, entsteht eine Kette. RFC 8693 bildet sie durch Schachtelung ab: Der äußerste act ist der aktuelle Actor, tiefer geschachtelte sind frühere. Für die Kette gilt eine Regel, die in der Praxis regelmäßig verletzt wird.

In der Praxis wird diese Regel regelmäßig verletzt, weil der zweite Agent seine Befugnisse aus seiner eigenen Konfiguration bezieht. Dann sieht die Kette im Protokoll vollständig aus, während der letzte Sprung sie faktisch ersetzt hat.

Zwei Grenzen gehören dazu. Die Kettentiefe gehört begrenzt: Jenseits von zwei bis drei Sprüngen ist eine Delegationskette weder prüfbar noch im Störfall auflösbar, und eine harte Obergrenze ist billiger als jedes Auditwerkzeug. Und die Laufzeit verkürzt sich mit jedem Sprung, denn eine weitergereichte Befugnis darf ihren Ursprung nicht überleben.

Was Identität nicht leistet

Vier Grenzen sollte man kennen, bevor man sich auf die Identitätsebene verlässt.

Attestierung belegt Herkunft, nicht Absicht. Ein Nachweis, dass eine Laufzeit unverändert und echt ist, sagt nichts darüber, was sie als Nächstes tun wird. Identität ist die Voraussetzung für Autorisierung, kein Ersatz dafür.

Widerruf wirkt nicht sofort. Ein Agent mit gültigem Token arbeitet bis zum Ablauf weiter, auch wenn die Delegation zurückgezogen wurde.

Die Delegation ist nur so gut wie ihr Zustandekommen. Eine Einwilligung, die jemand in einem Dialogfeld weggeklickt hat, trägt keine Kette. Sie gilt lange und wird selten überprüft.

Und Ketten sind schwerer zu prüfen als zu bauen. Eine dreistufige Delegation ist technisch schnell aufgesetzt und im Störfall kaum aufzulösen.

Was danach kommt

Identität und Delegation klären, wer handelt und in wessen Auftrag. Sie klären nicht, was der Agent dabei darf. Diese Frage ist die nächste, und sie fällt nicht mit den Berechtigungen des Auftraggebers zusammen: Ein Agent, der alles darf, was sein Mensch darf, ist weder aufgabengenau befugt noch begrenzt.

Wie die fünf Schichten einer Agentenidentität zusammenhängen, warum Policies an die logische Identität und Protokolle an die Laufzeitinstanz binden müssen und was in einen Protokolleintrag gehört, damit der Fall aus dem Beispiel oben nicht wieder passiert, steht im Whitepaper „Identität und Delegation für KI-Agenten“.

Häufige Fragen

Warum reicht ein Service Account nicht?

Er beantwortet, wer handelt, aber nicht, für wen. Damit gehen die Aufgabenbindung und die Rechteminimierung verloren: Seine Rechte werden statisch auf das Maximum aller Aufgaben gesetzt, die er jemals übernehmen soll.

Was bedeutet der act-Claim in RFC 8693?

act benennt den aktuellen Actor, also den, der tatsächlich handelt. Das Top-Level-sub benennt das Subjekt, in dessen Auftrag gehandelt wird. Bei mehrstufiger Delegation ist der äußerste act der aktuelle Actor, tiefer geschachtelte sind frühere Stationen. Ein Konsument darf für seine Zugriffsentscheidung nur die Top-Level-Claims und den aktuellen Actor heranziehen.

Was ist der Unterschied zwischen Delegationstatsache und Delegationsberechtigung?

Der act-Claim hält fest, dass delegiert wurde. Der Claim may_act drückt aus, dass delegiert werden durfte. Wirksam wird das aber erst, wenn der Authorization Server diese Beziehung bei der Ausstellung prüft, etwa gegen das Agentenregister und die Freigabe des verantwortlichen Owners.

Wirkt ein Widerruf sofort?

Nein. Ein Agent mit gültigem Token arbeitet bis zum Ablauf weiter. Wer sofortige Wirkung braucht, muss den durchsetzenden Punkt bei jeder Aktion fragen lassen, statt sich auf Token-Gültigkeit zu verlassen, oder die Laufzeiten so kurz halten, dass Ablauf und Widerruf praktisch zusammenfallen. Beides hat Kosten, und die Entscheidung gehört bewusst getroffen.

Wie tief darf eine Delegationskette sein?

Zwei bis drei Sprünge sind eine brauchbare harte Grenze. Jenseits davon ist die Kette im Störfall kaum noch aufzulösen: Welche Instanz hat sie begonnen, welche hat sie verengt, welche hat sie ersetzt? Wer darauf keine Antwort hat, sollte die Tiefe begrenzen statt das Auditwerkzeug zu verbessern.