KI-Agenten sind längst keine Laborexperimente mehr. Sie planen Jobs, bewegen Daten zwischen SaaS-Werkzeugen, eröffnen Tickets, greifen auf Produktionssysteme zu und interagieren mit Kundinnen und Kunden. Heute haben sie oft mehr direkten Zugriff als viele Menschen - aber kaum wirksame Governance.

Diese Anleitung zeigt dir, wie du:

  • KI-Agenten und andere nicht-menschliche Identitäten in deine bestehende Identity Governance integrierst
  • Zugriffsrechte nach dem Prinzip der minimalen Berechtigung für autonome und teilautonome Agenten entwirfst
  • Kontrollen an Vorgaben des KI-Risikomanagements und an Compliance-Erwartungen ausrichtest
  • typische Fehler vermeidest, durch die KI-Agenten zur Angriffsfläche werden

Was folgt, ist ein praxistaugliches Schritt-für-Schritt-Playbook für schlanke IT- oder Security-Teams - kein Wunschtraum, bei dem du deine gesamte IAM-Landschaft neu aufbauen musst.

Warum Zugriffe von KI-Agenten andere Governance erfordern

Die klassische Identitätsverwaltung ging von zwei Schubladen aus: Mitarbeitende und technische Benutzerkonten. Agentische KI sprengt dieses Modell.

  • Agenten handeln eigenständig über Systemgrenzen hinweg.
  • Sie verketten Werkzeuge, ohne dass jemand die komplette Kette bewusst designt.
  • Entwicklerinnen, Entwickler - oder andere Agenten - können sie in Sekunden erstellen und wieder löschen.

Sicherheitsforschung stuft das als neue Risikoklasse ein. Die OWASP Top 10 für Anwendungen mit großen Sprachmodellen benennen Prompt Injection, Datenabfluss, übermäßige Handlungsfreiheit und unsicheren Umgang mit Ausgaben als zentrale KI-Risiken. Mit weitreichenden Berechtigungen ist ein kompromittierter Agent nicht nur ein "entgleister Chatbot", sondern ein privilegierter Benutzer, der tiefgreifende Änderungen durchführen kann.

Auch Aufsichtsbehörden haben das erkannt. NIST hat 2023 sein AI Risk Management Framework veröffentlicht und 2024 ein Profil für Generative KI ergänzt, um KI-spezifische Risiken gezielt abzudecken. Prüfende Stellen werden erwarten, dass KI-Agenten in deine Identity Governance eingebunden sind - nicht danebenherlaufen.

Du brauchst dafür kein exotisches neues System. Behandle KI-Agenten als Identitäten erster Klasse und wende die Disziplin an, die du dir ohnehin für menschliche Identitäten wünschst - ergänzt um ein paar KI-spezifische Maßnahmen.

Voraussetzungen: das Fundament legen

Mit Folgendem kommst du deutlich schneller voran:

  • SSO / IdP (z. B. Okta, Entra, Google Workspace) als maßgebliche Quelle für menschliche Identitäten
  • Grundlegende Identity Governance - selbst ticketbasierte Joiner/Mover/Leaver-Workflows genügen als Start
  • Inventar kritischer Systeme/Daten - kenne deine Kronjuwelen-Anwendungen und Umgebungen
  • Zentrale Protokollierung wichtiger Systeme - SIEM, Data Lake oder zumindest durchsuchbare Anwendungsprotokolle
  • Benannte KI-Verantwortliche - eine klar verantwortliche Person für jeden Agenten oder jede KI-Integration

Fehlt dir etwas? Notiere die Lücken. Du kannst sie im Laufe der folgenden Schritte schließen.

Schritt 1: KI-Agenten und nicht-menschliche Identitäten entdecken und klassifizieren

Du kannst nichts steuern, was du nicht kennst. Beginne mit einem belastbaren Inventar deiner KI-Agenten und nicht-menschlichen Identitäten (NHIs).

1.1 Bereits vorhandene Agenten finden

Prüfe drei Bereiche:

  1. Quellcode und Infrastruktur

    • Scanne Repositorys und CI/CD-Pipelines nach API-Schlüsseln oder Dienstkonten mit Bezeichnungen wie "AI", "LLM", "bot", "agent".
    • Untersuche Workflow-Engines, RPA-Lösungen und Scheduler, die LLMs aufrufen.

  2. SaaS-Anwendungen und Integrationen

    • Finde Chatbots, die mit Slack, Teams, Zendesk, Intercom oder ähnlichen Systemen verbunden sind.
    • Suche nach "KI-Assistent"-Funktionen in CRM-, ITSM- oder Support-Werkzeugen.

  3. Schatten-KI

    • Frage Entwicklung/Betrieb: "Wo berührt KI produktive Systeme oder echte Daten?"
    • Prüfe den Einkauf auf KI-Werkzeuge und Low-Code-Integrationen.

Typischer Fehler: Nur nach sichtbar als "KI" vermarkteten Lösungen zu suchen. Besonders risikoreiche Agenten verstecken sich oft als Skripte oder interne Services, die LLMs aufrufen - nicht als klar gekennzeichnetes "AI"-Produkt.

1.2 Nach Risiko und Verhalten klassifizieren

Für jeden Agenten oder jede NHI:

  • Was ist es? Chat-Assistent, Code-Agent, Datenpipeline, RPA-Bot etc.
  • Wo läuft es? SaaS, interner Service, Container, Serverless-Umgebung.
  • Auf welche Systeme/Daten kann es zugreifen?
  • Was kann es tun? Nur lesen, erstellen/aktualisieren, löschen, freigeben, Geld bewegen, Deployments anstoßen.
  • Wer ist verantwortlich? Team und konkrete Person.

Vergib Risikostufen:

  • Stufe 1 - Sicherheitskritisch: Hat Zugriff auf Produktionsinfrastruktur, Zahlungssysteme, Gesundheits-/Personendaten (PHI/PII), Rechtsdokumente oder Kundendaten in größerem Umfang.
  • Stufe 2 - Geschäftskritisch: Ändert Tickets, CRM-Einträge, Konfigurationen (Nicht-Produktion) oder führt Massenoperationen durch.
  • Stufe 3 - Geringes Risiko: Interne Frage-Antwort-Bots mit Zugriff nur auf nicht-sensible Inhalte.

Du brauchst keine perfekte Taxonomie - wichtig ist eine priorisierte Liste. Beginne mit Stufe 1 und 2.

Schritt 2: Zugriffe von KI-Agenten nach dem Prinzip der minimalen Berechtigung gestalten

KI-Agenten sollten weder "wie ein weiterer menschlicher Benutzer" behandelt noch mit Root-Rechten ausgestattet werden. Sie brauchen passgenaue, klar begrenzte Zugriffsrechte.

2.1 Jedem Agenten eine eigene Identität zuweisen

Jeder relevante Agent braucht eine eigene Identität - kein wiederverwendetes menschliches Konto und kein generischer Shared Account.

  • Lege für jeden Agenten ein dediziertes Konto bzw. einen eigenen Principal in deinem IdP oder deiner IGA-Plattform an.
  • Verwende eigene Zugangsdaten (API-Schlüssel, OAuth-Clients, Service Principals), die eindeutig dem Agenten zugeordnet sind.
  • Kennzeichne Identitäten als nicht-menschlich, zum Beispiel mit Attributen wie type=agent, owner_team=, tier=1/2/3.

Typischer Fehler: Agenten unter einem menschlichen Administrationskonto laufen zu lassen. Dadurch gehen Nachvollziehbarkeit und saubere Protokollierung verloren - und ein Entzug der Rechte bricht sofort auch den legitimen Zugriff.

2.2 Zugriff eng und explizit zuschneiden

Setze das Prinzip der minimalen Berechtigung konsequent um:

  • Beschränke API-Schlüssel/Tokens auf konkrete Aktionen (Lesen, Schreiben, Freigeben) und konkrete Ressourcen (Projekte, Repositorys, Kanäle) - niemals auf den gesamten Mandanten.
  • Bestehe bei SaaS auf feingranularen Rollen statt breiter Administratorrechte.
  • Nutze Just-in-Time-Zugriff für besonders sensible Funktionen: temporäre Rechteerhöhung mit Genehmigung und klarer Zeitbegrenzung.

Das ist Kern von Identity Governance & Administration. Iden ermöglicht tiefe, feingranulare Steuerung - weit über SCIM hinaus - bis auf Kanal-, Repository- und Projektebene und ist damit ideal für risikoreiche Agenten.

2.3 "Denken" und "Handeln" trennen

Wo möglich, trenne:

  • Entscheidungsagent: Bewertet, was getan werden sollte.
  • Ausführungsschicht: Ein durch Richtlinien abgesicherter Dienst, der tatsächlich APIs aufruft oder Zustände ändert.

Vorteile:

  • Starke Zugriffskontrollen und Schutzmechanismen liegen um die Ausführungsschicht herum.
  • Du kannst Modelle austauschen, ohne Berechtigungen neu zu verdrahten.

Schritt 3: KI-Agenten in den Lebenszyklus integrieren (Joiner/Mover/Leaver)

Menschen werden ein- und ausgebucht; Agenten brauchen das ebenfalls - schneller und deterministischer.

3.1 "Onboarding" von Agenten standardisieren

Folge für jeden Agenten einem einfachen Prozess:

  1. Agent im IGA/Identitätssystem registrieren:
    • Name, Beschreibung, verantwortliches Team/verantwortliche Person
    • Risikostufe, Zweck, erwartete Lebensdauer
  2. Zugriff anfordern über einen Standardablauf:
    • benötigte Systeme/Datenbestände
    • Begründung und Risikoeinstufung
  3. Genehmigen und bereitstellen:
    • Automatische Zuweisung an die richtigen Genehmigenden (System-/Datenverantwortliche, Security) anhand von Richtlinien
    • Automatisches Erstellen von Konten, Rollen und API-Schlüsseln nach Bedarf

Mit Iden werden daraus richtliniengesteuerte, agentische Workflows - das System bewertet in Echtzeit und stellt automatisch genau die benötigten Zugriffe bereit, auch für Anwendungen ohne SCIM.

3.2 "Wechsel" im Lebenszyklus von Agenten steuern

Agenten entwickeln sich weiter:

  • Sie erhalten neue Fähigkeiten oder Berechtigungen.
  • Sie werden mit neuen Systemen verbunden.
  • Sie wechseln den Verantwortungsbereich, wenn sich Teams neu ausrichten.

Lege Regeln fest, damit Änderungen (Risikostufe, Eigentümer, Fähigkeiten) Folgendes auslösen:

  • erneute Bewertung der Berechtigungen
  • Genehmigung, falls Umfang oder Risiko steigt
  • aktualisierte Kennzeichnungen/Dokumentation

3.3 "Offboarding" von Agenten automatisieren

Agenten brauchen ein klar definiertes, nachvollziehbares Lebensende:

  • Begrenze besonders risikoreiche Agenten zeitlich (z. B. auf 90 Tage) und verlange Verlängerungen.
  • Beim Außerbetriebnehmen:
    • Anmeldedaten widerrufen und löschen
    • Rollen/Gruppenmitgliedschaften entfernen
    • Konten überall deaktivieren bzw. löschen

Das muss auch für Nicht-SCIM- und Anwendungen ohne API funktionieren - genau dort versagen viele Werkzeuge. Das universelle Connector-Modell von Iden schließt diese Lücke und sorgt für Abdeckung in allen Systemen, nicht nur in den 30 % mit SCIM.

Schritt 4: Agenten mit KI-spezifischen Schutzmechanismen absichern

Agentische KI scheitert anders als menschliche Administratoren oder statische Skripte.

4.1 Prompt- und Befehlsinjektion verhindern

OWASP definiert Prompt Injection als Manipulation eines KI-Modells mit dem Ziel, dessen Anweisungen zu unterlaufen und unbeabsichtigte, unsichere Aktionen auszulösen - einschließlich unbefugter Datenzugriffe. Agenten mit echten Berechtigungen lassen sich damit sofort als Waffe einsetzen.

Praktische Kontrollen:

  • Reichweite des Agenten begrenzen - falls er doch manipuliert wird, ist der Schaden räumlich begrenzt.
  • Ausgaben vor der Ausführung validieren bei risikoreichen Aktionen:
    • Nutze Richtlinien-Engines oder Validierungsdienste.
    • Erstelle Positivlisten für erlaubte Befehle, APIs und Ressourcen.
  • Nicht vertrauenswürdige Eingaben isolieren - trenne Prompts, Code und Dokumente, wo immer möglich.

Verknüpfe diese Schutzmaßnahmen mit Branchenempfehlungen wie den OWASP LLM Top 10.

4.2 Prinzip "kein implizites Vertrauen" auf Agenten anwenden

Agenten werden niemals per Voreinstellung vertraut - auch nicht, wenn du sie selbst gebaut hast:

  • Starke Authentifizierung (gegenseitige TLS-Absicherung, signierte Tokens, hardwaregestützte Schlüssel)
  • Segmentierung - Agenten können nur das erreichen, was sie unbedingt benötigen
  • Richtlinienbasierte Genehmigungen - besonders folgenschwere Aktionen erfordern einen menschlichen Zwischenschritt, auch wenn der Auslöser ein Agent ist

4.3 Geheimnisse und Anmeldedaten absichern

Agenten ziehen Geheimnisse magisch an:

  • Speichere Geheimnisse in einer zentralen Geheimnisverwaltung - nie im Quellcode oder in Prompts.
  • Nutze kurzlebige Anmeldedaten und drehende Schlüssel.
  • Verhindere, dass Agenten auf ihre eigene Konfiguration der Geheimnisverwaltung oder auf Bootstrap-Tokens zugreifen können.

4.4 Hochrisikoaktionen an Menschen eskalieren

Verankere agentische Workflows mit menschlicher Aufsicht für besonders sensible Schritte:

  • Agenten schlagen Änderungen vor; Menschen genehmigen.
  • Für Hochrisikoaktionen (Finanzen, Schema-Migrationen in Produktion) verlange Vier-Augen-Prinzip oder mehrstufige Genehmigungen.

So kann KI die Automatisierung vorantreiben, ohne menschliches Urteilsvermögen bei kritischen Entscheidungen auszuschalten.

Schritt 5: Aktivitäten von Agenten kontinuierlich überwachen - nicht vierteljährlich

Vierteljährliche, statische Überprüfungen funktionieren nicht, wenn Agenten mit Maschinengeschwindigkeit handeln.

5.1 Nach Agentenidentität und Aktion protokollieren

Für jeden Agenten solltest du nachvollziehen können:

  • Was hat er getan?
  • In welchen Systemen?
  • Auf welche Ressourcen?
  • Unter welcher Richtlinie?

Wähle Plattformen mit unveränderlichen Prüfprotokollen, starker Verschlüsselung auf Bankniveau und feingranularer Nachverfolgung von Berechtigungen. Iden stellt das in den Mittelpunkt.

More about Iden

5.2 Agentenspezifische Auffälligkeiten erkennen

Agenten verstoßen auf andere Weise gegen Regeln als Menschen. Suche nach:

  • neuartigen oder seltenen Datenzugriffen
  • plötzlichen Spitzen bei Schreib-/Löschoperationen
  • wiederholten Versuchen, verbotene APIs aufzurufen

Moderne IGA-Lösungen können Berechtigungen und Verhalten korrelieren. KI-native Plattformen wie Iden nutzen agentische Workflows, um Zugriffe kontinuierlich zu bewerten und automatische Gegenmaßnahmen auszulösen (z. B. Berechtigungen einschränken oder entziehen bei Abweichungen).

5.3 Gießkannen-Reviews durch gezielte Prüfungen ersetzen

Höre auf, Führungskräften vierteljährlich Tabellen mit 400 Zeilen zur Abzeichnung vorzulegen:

  • Führe kontinuierliche Zugriffsüberprüfungen für risikoreiche Agenten durch.
  • Genehmige Agenten mit geringem Risiko und wenig Aktivität automatisch.
  • Eskaliere nur verdächtige oder besonders einflussreiche Berechtigungen.

Organisationen mit automatisierten Zugriffsüberprüfungen für Benutzer sparen im Schnitt rund 120 Stunden pro Quartal und verbessern ihre Prüfbereitschaft deutlich. Wenn Agenten in deiner Governance-Ebene abgebildet sind, lässt sich dieser Effekt nahtlos auf sie erweitern.

Schritt 6: Compliance nachweisen - KI-Agenten sind im Geltungsbereich

Prüfende Stellen fragen inzwischen: "Welche KI-Systeme handeln im Auftrag welcher Personen oder Einheiten?" - nicht nur "Wer hat Zugriff?"

6.1 Kontrollen auf KI-Risikorahmenwerke abbilden

Baue keinen parallelen Compliance-Apparat auf. Erweitere, was bereits funktioniert:

  • Verknüpfe Kontrollen für KI-Agenten mit dem NIST AI RMF (Govern, Map, Measure, Manage).
  • Ordne Kontrollen und Protokolle den OWASP LLM Top 10 zu:
    • Prompt Injection ↔ Eingabevalidierung, Begrenzung von Aktionen
    • Übermäßige Handlungsfreiheit ↔ Feingranulare Berechtigungen, menschliche Freigaben
    • Datenabfluss ↔ Klassifizierung, Ausleitungs-/Egress-Kontrollen

Zeige, dass KI kein Governance-Schlupfloch darstellt, sondern vollständig eingebunden ist.

6.2 Prüfnachweise im Voraus vorbereiten

Halte für jeden wichtigen Agenten bereit:

  • Registrierungs- und Eigentumsnachweis
  • genehmigtes Zugriffsprofil (Systeme, Datenbereiche)
  • Protokolle/Berichte:
    • Wer Änderungen genehmigt hat
    • Wann, wo und durch wen sich Zugriffe geändert haben
    • Wann Anmeldedaten gedreht oder widerrufen wurden

Moderne IGA-Systeme erzeugen diese Artefakte automatisch. Unternehmen, die Iden nutzen, verzeichnen rund 80 % weniger manuelle Zugriffstickets und deutlich geringere Aufwände für Prüfnachweise - selbst wenn durch KI immer mehr Identitäten hinzukommen.

6.3 Alle nicht-menschlichen Identitäten standardmäßig als "in scope" definieren

Lege in deinen Richtlinien fest:

  • Alle nicht-menschlichen Identitäten (KI, Bots, Dienstkonten) fallen in den Geltungsbereich von Zugriffskontrollen und -überprüfungen.
  • Für sie gelten mindestens ebenso strenge Regeln wie für Menschen bei Bereitstellung, minimalen Rechten und Entzug von Zugriffsrechten.

So vermeidest du Interpretationsspielräume - und Ausreden - bei Prüfungen.

Troubleshooting & typische Stolperfallen

1. "Wir finden nicht alle unsere Agenten."
Beginne bei den wertvollsten Systemen und Protokollen. Suche nach nicht zugeordneten API-Schlüsseln, User-Agents oder neuen Integrationsbenutzern. Verlange von Entwicklungsteams, alle automatisierten Integrationen als nicht-menschliche Identitäten zu registrieren.

2. "Agenten funktionieren nicht mehr, wenn wir sie einschränken."
Wahrscheinlich bist du in einem Schritt von massiv überprivilegiert auf stark unterprivilegiert gewechselt. Nutze schrittweise Härtung:

  • Starte mit reinen Leserechten.
  • Ergänze Schreibberechtigungen nur behutsam und zielgenau.
  • Teste zuerst in Test-/Staging-Umgebungen mit Feature-Flags.

3. "Die manuelle Arbeit erdrückt uns wieder."
Wenn du versuchst, KI mit Tickets und Tabellen zu steuern, eskaliert der Aufwand. KI-native IGA ist auf richtliniengesteuerte, agentische Workflows ausgelegt, die Bereitstellung, Überprüfungen und Prüfnachweise für alle Identitäten automatisieren.

4. "Unsere Werkzeuge decken nur SCIM-fähige Anwendungen ab."
Der klassische 30-Prozent-Falleffekt: Agenten tummeln sich gerade in Nischen-, Nicht-SCIM- und Altsystemen - dort, wo sich Daten und Risiken besonders konzentrieren. Du brauchst universelle Abdeckung über SCIM- und Nicht-SCIM-Anwendungen hinweg, sonst bleiben dir dauerhaft blinde Flecken. Das Design von Iden beseitigt diese Lücke gezielt.

Nächste Schritte: das Ganze als schlankes Team in den Betrieb bringen

Wenn sich nichts ändert, werden KI-Identitäten deine regulierten Benutzer zahlenmäßig übersteigen. Analysten gehen davon aus, dass nicht-menschliche Identitäten Menschen rasch überholen werden und das Management von Maschinenidentitäten bis in die 2030er-Jahre stark wächst.

Nutze diesen 30- bis 60-Tage-Plan für ein kleines IT-Team:

  • Woche 1-2: Inventarisiere und klassifiziere deine 10-20 wichtigsten Agenten/NHIs nach Risiko.
  • Woche 2-3: Entwirf eindeutige Identitäten, Zuschnitte der Berechtigungen und Genehmigungsabläufe für Agenten der Stufen 1 und 2.
  • Woche 3-4: Implementiere Lebenszyklus-Workflows für Agenten (Onboarding/Änderung/Offboarding) in deiner IGA-Lösung oder deinem SSO.
  • Woche 4-6: Schalte Protokollierung, Anomalieerkennung und gezielte Überprüfungen scharf; bereite eine einseitige Zusammenfassung für Prüfungen vor.

Wenn manuelle Prozesse an ihre Grenzen stoßen, wechseln Teams zu Plattformen wie Iden: vollständige Identity Governance - für Menschen und KI-Agenten, SCIM- und Nicht-SCIM-Anwendungen - schneller, ohne "SCIM-Aufpreis" und mit durchgängiger Abdeckung.

FAQ: Zugriff von KI-Agenten & nicht-menschlichen Identitäten

1. Sollten KI-Agenten eigene Identitäten haben?

Ja. Weise relevanten Agenten immer eigene Identitäten zu. Die Wiederverwendung von Administrationskonten zerstört Nachvollziehbarkeit und Offboarding-Fähigkeit und vergrößert die Angriffsfläche. Eindeutige, klar geschnittene nicht-menschliche Identitäten mit klarer Verantwortlichkeit sind unverzichtbar für wirksame Kontrolle.

2. Wie funktioniert ein Modell ohne implizites Vertrauen für KI-Agenten?

Ein Sicherheitsmodell ohne implizites Vertrauen bedeutet: niemals automatisch vertrauen.

  • Starke Authentifizierung für die Agentenidentität.
  • Jede Aktion wird nach minimalen Rechten und Kontext autorisiert.
  • Kontinuierliche Verhaltensüberwachung und Entzug von Rechten bei Abweichungen.
  • Bei besonders folgenschweren Aktionen wird ein Mensch einbezogen. "Kein implizites Vertrauen" heißt nicht "keine Menschen".

3. Was unterscheidet die Steuerung von KI-Agenten von der von Dienstkonten?

Dienstkonten sind meist statisch und auf ein System beschränkt. KI-Agenten hingegen:

  • verketten Werkzeuge und Datenquellen über den gesamten Stack hinweg,
  • handeln auf Basis von Prompts/Kontext, die manipulierbar sind,
  • arbeiten häufig im Auftrag mehrerer Teams oder Benutzer.

Breite, Autonomie und Anfälligkeit für Prompt-Manipulation machen die Governance von Agenten zu einer neuen Art von Herausforderung.

4. Brauchen wir ein separates KI-Governance-Werkzeug?

Wenn deine IGA-Lösung Folgendes kann:

  • nicht-menschliche Identitäten modellieren,
  • feingranulare, systemübergreifende Berechtigungen durchsetzen,
  • Nicht-SCIM- und Anwendungen ohne API abdecken,
  • Überprüfungen und Prüfnachweise automatisieren,

... kannst du sie erweitern. In der Praxis scheitern viele klassische und sogar "moderne" IGAs an Abdeckung oder Automatisierung - weshalb schlanke Teams auf KI-native Plattformen wie Iden setzen, um alle Identitäten in einer gemeinsamen Steuerungsebene zu führen.

5. Wie präsentieren wir das gegenüber Prüfenden?

Sei klar und strukturiert:

  • Lege das Agenten-Inventar und die Risikostufen vor.
  • Weise nach, dass Agenten denselben Joiner-Mover-Leaver-Prozess wie Menschen (oder strengere Varianten) durchlaufen.
  • Ordne Kontrollen dem NIST AI RMF und den OWASP LLM Top 10 zu.
  • Zeige Beispielprotokolle und -reviews für zentrale Agenten.

Prüfende Stellen erwarten keine Sondergeschichten für KI. Sie wollen den Nachweis, dass KI genauso gesteuert wird - Punkt.

Book a call