7 Fragen für sichere KI-Agenten im IAM

KI-Agent #132 ist aktiv. Wem gehört er?

KI-Agent #132 meldet sich jeden Tag an IhremIdentity Provider an. Er holt sich Tokens, ruft APIs auf und liest Daten ausmehreren Systemen. Er hat vier Rollen, ein Client-Secret und Zugriff auf Bereiche, die ein Team vor mehreren Monaten für ein Pilotprojekt freigegeben hat.

Das Pilotprojekt ist längst abgeschlossen. Die Person, die den Agenten angelegt hat, arbeitet inzwischen in einer anderen Abteilung. Das Secret wurde seit der Einrichtung nie getauscht. Und niemand im Unternehmen könnte auf Anhieb sagen, wer für diesen Agenten verantwortlich ist.

Das ist kein konstruiertes Extrembeispiel. Solche Fälle entstehen überall dort, wo KI-Agenten schneller eingeführt werden, als Identitätsprozesse mitwachsen. Dieser Artikel zeigt, welche sieben Fragen Sie für jeden Agenten in Ihrem IAM stellen sollten und wie die Antworten aussehen, wenn alles in Ordnung ist.

‍

‍

KI-Agenten sind Identitäten, keine Konfigurationsdetails

Non-Human Identities (NHIs) sind alle Identitäten, die sich authentifizieren und autorisiert werden, ohne ein Mensch zu sein. Dazu gehören klassische Service-Accounts, API-Clients,CI/CD-Pipelines, RPA-Bots und Workloads. KI-Agenten sind die jüngste und am schnellsten wachsende Gruppe darunter.

Von klassischen technischen Konten unterscheidensich Agenten in drei Punkten:

• Sie entscheiden selbst, welche Schnittstellen sie aufrufen. Ein Integrations-Client macht immer dasselbe. Ein Agent wählt je nach Aufgabe unterschiedliche Tools und Datenquellen.
• Sie handeln in zwei Modi. Manche Agenten arbeiten autonom mit eigener Identität, typischerweise über den OAuth-2.0-Client-Credentials-Flow. Andere handeln im Auftrag eines Nutzers: Der Nutzer autorisiert den Agenten, etwa über den Authorization Code Flow, und der Agent erhält ein Token mit den Rechten dieses Nutzers. Muss der Agent die Anfrage an weitere Dienste weiterreichen, kommt häufig OAuth 2.0 Token Exchange (RFC 8693) zum Einsatz. Viele Agenten tun beides.
• Sie entstehen dezentral. Fachbereiche richten Agenten oft selbst ein, ohne dass die zentrale IT jeden einzelnen kennt.

Daraus folgt ein Grundsatz: Jeder Agent braucht eine eigene, eindeutige Identität. Teilt er sich die Zugangsdaten mit einem Menschen oder einem Sammelkonto, lässt sich in Audit-Logs von Anwendungen nicht mehr unterscheiden, wer eine Aktion ausgelöst hat.

‍

Das Kernproblem: Agenten haben keinen Lifecycle-Auslöser

Für menschliche Identitäten gibt es eingespielte Prozesse. Eintritt, Abteilungswechsel und Austritt werden im HR-System erfasst und das IAM reagiert darauf: Konto anlegen, Rollen anpassen, Zugang entziehen. Dieses Joiner-Mover-Leaver-Modell funktioniert, weil es einen verlässlichen Auslöser gibt.

Bei Agenten fehlt dieser Auslöser. Kein HR-System meldet, dass ein Pilotprojekt beendet ist oder ein Agent nicht mehr gebraucht wird. Ohne bewusst gesetzten Prozess wird ein Agent einmal angelegt und danach nie wieder angefasst. Rechte kommen hinzu, werden aber selten entzogen.

Dass genau hier das größte Risiko liegt, bestätigt die OWASP Non-Human Identities Top 10 (2025). Auf Platz 1 steht dort Improper Offboarding, also NHIs, die nicht deaktiviert werden, obwohl sie nicht mehr gebraucht werden. Auf den weiteren Plätzen folgen unteranderem unsichere Authentifizierung, überprivilegierte NHIs und langlebige Secrets. Alle vier Punkte lassen sich mit den folgenden Fragen prüfen.

‍

Sieben Fragen, die jeder Agent beantworten muss

Die folgenden Fragen gelten unabhängig davon,welchen Identity Provider Sie einsetzen. Die Übersicht am Ende des Abschnittsfasst Warnsignal und Zielzustand zusammen.

1. Wer ist verantwortlich?

Ein Agent ohne Verantwortlichen wird von niemandem überprüft. Niemand bemerkt, wenn er überflüssig wird, und niemand reagiert, wenn er sich auffällig verhält.

Zielzustand: Für jeden Agenten ist ein Verantwortlicher hinterlegt, am besten ein Team mit einer benannten Ansprechperson. Wechselt diese Person die Rolle oder verlässt das Unternehmen, wird der Agent automatisch zur Überprüfung vorgelegt. So hängt sich das Offboarding von Agenten an den bestehenden Leaver-Prozess für Menschen an.

2. Wird der Agent überhaupt noch genutzt?

Ein aktivierter, aber ungenutzter Agent ist reine Angriffsfläche. Seine Zugangsdaten sind gültig, seine Rechte bestehen weiter, aber niemand braucht ihn mehr.

Zielzustand: Die letzte Aktivität jedes Agenten ist sichtbar. Nach einer definierten Inaktivitätsfrist, etwa 90 Tagen, wird der Verantwortliche informiert und der Agent anschließend deaktiviert. Gelöscht wird erst nach einer weiteren Frist, damit eine versehentliche Deaktivierung rückgängig gemacht werden kann.

3. Wann wurde das Secret zuletzt rotiert?

Secrets landen erfahrungsgemäß an Orten, an die sie nicht gehören: in Konfigurationsdateien, Repositories, Tickets oder Logs. Je älter ein Secret ist, desto mehr Kopien existieren in der Regel davon und desto wahrscheinlicher ist ein Leak.

Zielzustand: Secrets werden regelmäßig rotiert, mit einer kurzen Übergangsphase, in der altes und neues Secret parallel gelten. So läuft der Agent während der Umstellung ohne Unterbrechung weiter. Noch besser ist es, auf geteilte Secrets ganz zu verzichten. Das führt zur nächsten Frage.

4. Wie authentifiziert sich der Agent?

Bei einem Shared Secret (Client-Secret) kennen Agent und Identity Provider denselben Schlüssel. In den gängigen Verfahren client_secret_basic und client_secret_post überträgt der Agent ihn bei jeder Token-Anfrage. Wer das Secret abgreift, kann sich als Agent ausgeben.

Zielzustand: Asymmetrische Verfahren, wie sie bei Human Identities schon lange der Standard zur Authentifizierung sind. Bei Private Key JWT (RFC 7523, in OpenID Connect als private_key_jwt definiert) signiert der Agent bei jeder Token-Anfrage eine kurzlebige JWT-Assertion mit seinem privaten Schlüssel. Der Identity Provider kennt nur den öffentlichen Schlüssel, der private Schlüssel verlässt den Agenten nie. Alternativ authentifiziert sich der Agent per mTLS mit einem Client-Zertifikat (RFC 8705). RFC 8705 erlaubt zusätzlich, ausgestellte Tokens an das Zertifikat zu binden. Prüft die API diese Bindung, ist ein abgefangenes Token ohne den passenden privaten Schlüssel nicht nutzbar. Einen vergleichbaren Schutz ohne mTLS bietet DPoP (RFC 9449).

5. Wie lange leben seine Tokens?

Access Tokens sind in der Regel Bearer Tokens: Wer das Token besitzt, kann es nutzen. Selbsttragende JWTs werden von APIs meist lokal geprüft, ohne Rückfrage beim Identity Provider. Ein Entzug wirkt dann erst, wenn das Token abläuft. Bei einer Laufzeit von 24 Stunden bleibt eingestohlenes Token also bis zu einen Tag gültig.

Zielzustand: Kurze Laufzeiten im Minutenbereich, zum Beispiel 5 Minuten. Für Agenten im Client-Credentials-Flow kostet das kaum etwas, denn sie fordern bei Bedarf einfach ein neues Token an. Bei kritischen Systemen, wo ein sofortiger Entzug im Zweifelsfall nötig ist, sollten APIs die ihnen präsentierten Tokens bei jedem Zugriffsversuch zusätzlich per Token Introspection (RFC 7662) beim Identity Provider prüfen.

6. Sind seine Berechtigungen befristet?

Agenten sammeln Rechte an. Für ein Projekt kommt eine Rolle hinzu, für einen Test eine weitere. Entzogen wird selten, weil niemand riskieren will, dass der Agent danach nicht mehr funktioniert. Das Ergebnis sind überprivilegierte Identitäten, die weit mehr dürfen als nötig.

Zielzustand: Jede Rollen- und Gruppenzuweisung hat ein Enddatum. Eine Verlängerung ist eine bewusste Entscheidung des Verantwortlichen, keine Voreinstellung. Zusätzlich sind die Scopes und die Zielgruppe (Audience) der Tokens auf die APIs beschränkt, die der Agent tatsächlich braucht.

7. Gibt es auffällige Fehlversuche?

Häufige fehlgeschlagene Authentifizierungen haben meist eine von zwei Ursachen. Entweder ist die Konfiguration fehlerhaft, etwa weil ein rotiertes Secret nicht beim Agenten angekommen ist. Oder jemand versucht, sich mit falschen oder gestohlenen Zugangsdaten als Agent anzumelden. Beides erfordert eine Reaktion.

Zielzustand: Authentifizierungsfehler pro Agent werden ausgewertet. Ab einem Schwellenwert wird der Verantwortliche benachrichtigt. Ein zentrales Aktivitätsprotokoll zeigt, wann und wie oft der Fehler aufgetreten ist.

Die sieben Fragen im Überblick

Was NIS2 und ISO 27001 damit zu tun haben

Die Anforderungen an die Zugriffskontrolle gelten auch für Agenten. In Deutschland verlangt das seit dem 6. Dezember 2025 geltende NIS-2-Umsetzungsgesetz von besonders wichtigen Einrichtungen Konzepte für die Zugriffskontrolle (§ 30 Abs. 2 Nr. 9BSIG). ISO 27001 fordert, Identitäten über ihren gesamten Lebenszyklus zu verwalten und Zugriffsrechte regelmäßig zu überprüfen. Im Audit heißt das: Sie sollten für jeden Agenten zeigen können, wer verantwortlich ist, welche Rechte er hat, bis wann und was er zuletzt getan hat.

‍

So starten Sie

Sie müssen nicht alle Agenten auf einmal in Ordnung bringen. Für den Anfang reichen drei Schritte:

1. Inventar erstellen. Listen Sie alle Clients auf, über die Agenten Tokens beziehen, und gleichen Sie die Liste mit den Token-Logs ab. Agenten ohne Aktivität können Sie meist sofort deaktivieren.
2. Nach Risiko priorisieren. Beginnen Sie mit Agenten, die weitreichende Rechte, ein Shared Secret und lange Token-Laufzeiten haben. Für sie gehen Sie die sieben Fragen der Reihe nach durch.
3. Regeln für neue Agenten festlegen. Kein neuer Agent ohne Verantwortlichen, ohne befristete Zuweisungen und ohne schlüsselbasierte Authentifizierung.

Der aufwendigste Teil ist dabei nicht die einmalige Bereinigung, sondern die laufende Überprüfung. Wer sie mit Skripten und Tabellen erledigt, hat nach wenigen Monaten wieder einen veralteten Stand.

‍

Neu als Preview: Agents in Bare.ID

Deshalb haben wir die Antworten auf die siebenFragen direkt in die Bare.ID-Oberfläche eingebaut. Auf der it-sa 2026 stellen wir die neue Agents-Verwaltung vor.

Ein eigener Bereich für Non-Human Identities. Unter „Agents“ finden Sie alle nicht-menschlichen Identitäten getrennt von den Nutzerkonten. Die Detailansicht zeigt für jeden Agenten den Verantwortlichen, die verknüpfte Applikation, Rollen und Gruppen, die letzte Aktivität und die Zahl der ausgestellten Tokens der letzten 30 Tage. Darunter stehen Authentifizierungsverfahren und Token-Laufzeit.

‍

Die Security-Analyse. Jeder Agenterhält eine Sicherheits-Analyse, die auch in Form eines Scores angezeigt wird. Bewertet werden u.a. Rechte, Credentials und Nutzung, entlang genau der Kriterien aus diesem Artikel: Verantwortlicher, Aktivität, Alter des Secrets, Authentifizierungsverfahren, Token-Laufzeit, befristete Zuweisungen und fehlgeschlagene Authentifizierungen. Jeder Befund ist nach Schwere eingestuft, was das schnelle Auffinden von problematischen Agenten ermöglicht.

‍

‍

Nachvollziehbare Aktivität. Das Aktivitätsprotokoll zeigt, was ein Agent zuletzt getan hat, getrennt nach Ereignistyp, etwa API-Anmeldung, Token-Prüfung oder Token-Austausch. Fehlgeschlagene Anmeldungen sind dort ebenso sichtbar wie erfolgreiche.

‍

Aus einem Agenten mit schlechtem Security Score wird so Schritt für Schritt ein Agent mit Bestnote: schlüsselbasierte Authentifizierung, kurze Token-Laufzeit, befristete Zuweisungen und ein klar benannter Verantwortlicher.

Bare.ID basiert auf Keycloak. Keycloak bildet Agenten als Clients mit Service-Account ab, bietet aber keine zusammengefasste Sicht auf Verantwortliche, Nutzung und Risiko je Agent. Diese Sicht wurde über die Agents-Verwaltung von Bare.ID ergänzt. Die Agenten authentifizieren sich weiterhin über die Standardprotokolle OAuth 2.0 und OpenID Connect.

Wie viele Agenten laufen bei Ihnen?

Die meisten Teams unterschätzen die Zahl ihrer Non-Human Identities, bis sie zum ersten Mal ein Inventar erstellen. Wenn Sie wissen möchten, wie Ihre Agenten bei den sieben Fragen abschneiden, schauen wir uns das gemeinsam an.

‍

‍