Jahrelang liefen Automatisierungen im Unternehmen unter einer Identität, die es eigentlich nicht geben dürfte: dem geteilten Service-Account. Ein technischer Benutzer, angelegt für „den Bot", mit Passwort im Tresor, Rechten nach Bedarf erweitert und nie wieder zurückgebaut. Solange der Bot nur Masken abtippte, war das ein Risiko, das man kannte. Mit Agenten, die selbstständig Werkzeuge aufrufen, Daten lesen und Buchungen auslösen, wird es zur Haftungsfrage.

Was sich geändert hat

Die Identitätsanbieter haben das Problem erkannt — und produktisiert. Okta, Microsoft Entra und andere bieten inzwischen Bausteine, mit denen ein Agent eine eigene, vollwertige Identität bekommt: Registrierung wie ein Benutzer, Single Sign-on in die Anwendungen, die er braucht, und Zugriffe zwischen Anwendungen, die nicht mehr über gespeicherte Passwörter, sondern über kurzlebige, gescopte Tokens laufen. Das ist keine Nische mehr, sondern die Richtung, in die das Identitätsmanagement gerade läuft.

Damit verschiebt sich die Frage. Bisher hieß sie: Wie kriegen wir den Bot ins System? Jetzt heißt sie: Welche Rechte hat dieser Agent, wer hat sie ihm gegeben, und wann laufen sie ab? Genau die Fragen, die eine Revision an einen menschlichen Mitarbeiter stellt.

Warum der Service-Account gehen muss

  • Keine Zurechenbarkeit. Teilen sich drei Agenten einen Account, sagt das Audit-Log „der Bot hat gebucht" — aber nicht, welcher, warum und mit welchem Ziel.
  • Stehende Rechte. Service-Accounts sammeln über Jahre Berechtigungen an. Ein kompromittierter Zugang ist ein Generalschlüssel.
  • Kein Ablauf. Passwörter in Tresoren rotieren selten. Ein Token mit 60 Minuten Lebensdauer verfällt von allein.
  • Keine Access-Reviews. Menschen werden regelmäßig überprüft, Service-Accounts fast nie. Ein Agent mit Identität landet automatisch im selben Prozess.

Was das für euch heißt

Wer heute einen Agenten in Betrieb nimmt, sollte drei Dinge vor dem ersten produktiven Aufruf geklärt haben. Erstens: Der Agent ist im Identitätssystem als eigener Akteur angelegt — mit Besitzer, Zweck und Ablaufdatum. Zweitens: Seine Rechte sind Least Privilege und als Policy dokumentiert, nicht als Klick-Historie im Admin-Panel. Drittens: Jede seiner Aktionen trägt seinen Namen im Log. Das ist kein Sicherheits-Extra, das man nachrüstet, sondern die Grundlage, auf der Autonomie überhaupt vertretbar wird.

Für bestehende Bot-Flotten lohnt ein Inventar: Welche Service-Accounts existieren, wer nutzt sie, welche Rechte haben sie? In den meisten Häusern ist die ehrliche Antwort unbequem — und genau deshalb der richtige Startpunkt.