Authentifizierung prüft, wer Sie sind; Autorisierung entscheidet, was Sie tun dürfen. Eine wachsende Zahl von KI-gestützten Anwendungen verifiziert die Identität eines Benutzers einmal beim Login und überlässt dem zugrunde liegenden Agenten dann für den Rest der Sitzung die Handhabung jeglicher Ressourcen – was ihm effektiv einen „Blankoscheck“ ausstellt. Dieses Design öffnet die Tür für versehentliche Datenlecks, unerwünschte E-Mails oder sogar zerstörerische Datenbank-Updates, und das Risiko steigt jedes Mal, wenn ein KI-Assistent mehrere Tools mit einer Latenz von Millisekunden aufrufen kann.

Warum der Fehler immer wieder passiert

Die meisten KI-Entwickler betrachten den Login-Bildschirm als die einzige Sicherheitsbarriere. Der Code fragt nach einem Passwort oder einem Token, markiert die Sitzung als „authentifiziert“ und nimmt dann an, dass jede nachfolgende Anfrage sicher ist. In einer herkömmlichen Web-App bieten die langsamen Klicks eines menschlichen Benutzers einen natürlichen Drosselungspunkt; ein Mensch wird innehalten, bevor er auf „Löschen“ klickt. Ein KI-Agent hingegen kann innerhalb von Sekunden Dutzende von Tool-Aufrufen ausführen. Wenn die Plattform nur fragt: „Ist der Benutzer eingeloggt?“, erbt jeder Aufruf dieselben uneingeschränkten Berechtigungen.

Die Ursache liegt in der Bequemlichkeit. Teams stellen oft einen einzigen, langlebigen Service-Account für die gesamte Anwendung bereit, damit der Code nicht mehrere Token oder Scopes verwalten muss. Dieses Konto verfügt in der Regel über weitreichende Berechtigungen – Lesen, Schreiben, Löschen – über alle Projekte hinweg. Wenn ein KI-Assistent innerhalb dieser Sitzung läuft, erbt er automatisch diese Rechte, unabhängig davon, ob die aktuelle Aufgabe sie tatsächlich erfordert.

Was auf dem Spiel steht

  • Datenexposition – Ein Agent, der nach dem Login eines Benutzers jede Datei lesen kann, könnte versehentlich vertrauliche Dokumente in eine Antwort ziehen, die später außerhalb der Organisation geteilt wird.
  • Unbeabsichtigte Aktionen – Der KI-Helfer eines Support-Ingenieurs könnte eine SQL-Abfrage direkt gegen Produktionsdatenbanken ausführen, nur weil die Sitzung des Ingenieurs noch aktiv ist, selbst wenn die Abfrage nichts mit dem bearbeiteten Ticket zu tun hat.
  • Einhaltung gesetzlicher Vorschriften (Compliance) – Viele Datenschutzregeln erfordern, dass der Zugriff auf das absolut notwendige Minimum beschränkt wird. Ein pauschales Berechtigungsmodell kann gegen diese Prinzipien verstoßen und Audits oder Bußgelder nach sich ziehen.
  • Betriebskosten – Fehler, die Datensätze löschen oder ändern, zwingen Teams dazu, Änderungen rückgängig zu machen, Ursachen zu untersuchen und das Vertrauen der Nutzer wieder aufzubauen – all das kostet Zeit und Geld.

Der fehlende Schritt: Aktionsbasierte Autorisierung

Die Autorisierung sollte an jeder „Tür“ innerhalb des Systems überprüft werden, nicht nur am Haupteingang. Die Frage ändert sich von „Wer ist das?“ zu „Darf diese spezifische Aktion an dieser spezifischen Ressource genau jetzt ausgeführt werden?“. Die Implementierung dieser Prüfung erfordert keine komplette Neugestaltung; es ist lediglich ein Wechsel von einem einzelnen Sitzungs-Flag hin zu kurzlebigen, scoped Token erforderlich.

Die praktische Umsetzung

  1. Token mit definiertem Scope anfordern – Wenn der KI-Agent ein Tool aufrufen muss, erhält er zuerst ein Token, das die exakt benötigten Berechtigungen auflistet (z. B. read:ticket, execute:sql_query).
  2. Token für jeden Aufruf validieren – Bevor das Tool ausgeführt wird, prüft der Dienst, ob das Token den benötigten Scope enthält und ob das Token nicht abgelaufen ist.
  3. Ressource mit Scope abgleichen – Wenn sich die Anfrage auf ein bestimmtes Projekt oder eine bestimmte Datenbank bezieht, muss das Token explizit den Zugriff auf diese Kennung gewähren.
  4. Ablehnen oder zulassen – Wenn eine Prüfung fehlschlägt, wird der Aufruf verweigert und der Agent erhält eine Fehlermeldung, die er dem Benutzer anzeigen kann.

Der Unterschied im Code ist unkompliziert. Ein „schlechter“ Ansatz könnte so aussehen:

if session.is_authenticated():
    tool.run(params)

Ein „guter“ Ansatz erweitert die Prüfung:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

Das zweite Muster fügt nur wenige Zeilen hinzu, zwingt das System aber dazu, bei jeder Operation die richtige Frage zu stellen.

Standards, die es einfacher machen

OAuth 2.0-Scopes bieten bereits eine weit verbreitete Methode, um einzuschränken, was ein Token tun kann. Durch die Ausgabe kurzlebiger Access-Token, die Scopes wie project:1234:write oder email:send kodieren, können sich Entwickler auf bestehende Bibliotheken verlassen, um den Verifizierungsschritt durchzuführen.

Die neueren Rich Authorization Requests (RFC 9396) erweitern diese Idee und ermöglichen es einem Client, zur Laufzeit granulare Berechtigungen anzufordern, anstatt eine statische Liste vorab zu definieren. Diese Flexibilität ist nützlich, wenn ein KI-Workflow je nach Benutzerabsicht Funktionen on the fly hinzufügen oder entfernen muss.

Gegenargument: Einfachheit versus Sicherheit

Einige Teams argumentieren, dass Prüfungen pro Aktion die Latenz und die Code-Komplexität erhöhen, insbesondere wenn der KI-Assistent viele Tools in schneller Folge aufrufen muss. Sie weisen darauf hin, dass ein einzelnes Sitzungstoken den Overhead beim Abrufen und Validieren eines neuen Tokens für jeden Aufruf vermeidet. Der Kompromiss ist jedoch eine drastisch höhere Anfälligkeit für Missbrauch. Moderne Token-Validierungsdienste sind darauf ausgelegt, in Mikrosekunden zu arbeiten, und der zusätzliche Netzwerk-Roundtrip kann gebündelt oder zwischengespeichert werden, ohne das Prinzip der geringsten Berechtigung (Principle of Least Privilege) zu opfern. In Umgebungen, in denen Datenintegrität und Compliance nicht verhandelbar sind, überwiegt die Risikominimierung die moderaten Leistungskosten.

Worauf man als Nächstes achten sollte

  • Einführung von Scoped Tokens in KI-SDKs – Behalten Sie Updates der wichtigsten KI-Plattform-Toolkits im Auge; viele beginnen damit, Hilfsfunktionen für OAuth-basierte Scopes bereitzustellen.
  • Policy-as-Code-Frameworks – Neue Lösungen ermöglichen es Teams, Autorisierungsregeln in einer deklarativen Datei festzulegen und diese automatisch zur Laufzeit durchzusetzen.
  • Audit-Logs, die Entscheidungen pro Aktion offenlegen – Da immer mehr Plattformen jede Autorisierungsprüfung protokollieren, erhalten Unternehmen Einblick darin, welche KI-Aktionen erlaubt oder blockiert werden, was künftige Anpassungen der Richtlinien ermöglicht.

Fazit

Eine angemeldete Sitzung als pauschale Erlaubnis für alles zu behandeln, ist ein Rezept für unbeabsichtigte Folgen. Indem die Autorisierungsentscheidung vom Zeitpunkt des Logins auf jeden einzelnen Tool-Aufruf verlagert wird – und durch die Nutzung kurzlebiger, Scoped Tokens – können KI-Anwendungen den Komfort autonomer Agenten beibehalten und gleichzeitig Daten schützen, Vorschriften einhalten und kostspielige Missgeschicke vermeiden. Die zusätzlichen Codezeilen sind ein kleiner Preis für ein System, das bei jedem Versuch einer Aktion die richtige Frage stellt.