Zurück zum Blog

Nicht-menschliche Identitäten für KI-Agenten: IAM für wachsende Teams

AICybersecuritySoftware ArchitectureGovernance

Nicht-menschliche Identitäten werden durch KI-Agenten vom Infrastrukturdetail zur Führungsfrage. Sobald Agenten Tickets ändern, Kundendaten lesen oder Deployments anstoßen, reicht es nicht mehr, API-Keys zu verwalten. Teams müssen klären, welche digitale Identität ein Agent besitzt, welche Rechte daran hängen und wer für diese Rechte verantwortlich ist.

Was nicht-menschliche Identitäten verändern

Nicht-menschliche Identitäten sind Service-Accounts, Workload-Identitäten, API-Keys, Bots, CI/CD-Jobs und KI-Agenten, die sich gegenüber Systemen authentifizieren. Sie sind nicht neu. Neu ist die Geschwindigkeit, mit der Agenten diese Identitäten nutzen, kombinieren und über mehrere Tools hinweg Aktionen ausführen.

Das macht IAM für Automatisierung zu einer Architekturentscheidung:

  • Accountability: Ein Logeintrag muss zeigen, ob ein Mensch, ein Agent oder ein Backend-Dienst gehandelt hat.
  • Least Privilege: Ein Agent braucht konkrete Fähigkeiten, keine geerbten Admin-Rechte aus einem generischen Service-Account.
  • Offboarding: Nicht mehr genutzte Agenten, Tokens und Integrationen müssen genauso entfernt werden wie ausgeschiedene Mitarbeitende.
  • Auditierbarkeit: Entscheidungen und Tool Calls müssen nachvollziehbar bleiben, besonders bei Kundendaten, Zahlungen oder produktiven Änderungen.

Die OWASP Non-Human Identities Top 10 2025 nennt genau diese Risiken: unsauberes Offboarding, Secret Leakage, überprivilegierte Identitäten, unsichere Authentifizierung und langlebige Secrets. Für wachsende Unternehmen sind das keine Security-Randthemen, sondern Quellen für Betriebsrisiko und spätere Compliance-Kosten.

Wo Teams vor der Einführung ansetzen sollten

Der häufigste Fehler ist, KI-Agenten an bestehende Service-Accounts zu hängen. Das ist schnell, aber es zerstört die Trennlinie zwischen Nutzeraktion, Automatisierung und Systembetrieb.

Ein belastbarer Startpunkt ist ein kleines Identitätsmodell für Agenten:

# Beispiel: Identitätsmodell für einen internen Release-Agenten
agent: release-assistant
owner: platform-team
identity_type: workload_identity
auth: oidc_short_lived_token
allowed_actions: ["read_ci_status", "create_release_note", "trigger_staging_deploy"]
forbidden_actions: ["deploy_production", "change_permissions", "export_customer_data"]
audit_log: required
review_cycle: quarterly

Vor dem produktiven Einsatz sollten Führung und Engineering mindestens drei Entscheidungen treffen. Delegation: Handelt der Agent im Namen eines Nutzers oder als eigener technischer Akteur? Rechtevergabe: Sind Rollen pro Agent, pro Workflow oder pro Team modelliert? Betrieb: Wer rotiert Secrets, prüft Logs und entfernt nicht mehr genutzte Identitäten?

Technisch helfen kurzlebige OIDC-Tokens, Secret-Manager, klare Scopes und getrennte Umgebungen. Organisatorisch wichtiger ist aber die Ownership: Jede nicht-menschliche Identität braucht einen fachlichen Zweck, einen technischen Besitzer und ein Ablaufdatum für die nächste Überprüfung.

Warum das wichtig ist

KI-Agenten werden wirtschaftlich erst interessant, wenn sie Arbeit in bestehenden Systemen erledigen. Genau dann entstehen aber neue Pfade zu Daten, Infrastruktur und Geschäftsprozessen. Ohne saubere nicht-menschliche Identitäten werden diese Pfade schwer kontrollierbar: Rechte wachsen mit jedem Experiment, Logs verlieren Aussagekraft, und niemand fühlt sich für alte Tokens zuständig.

Gute Identity-Architektur reduziert nicht die Geschwindigkeit, sondern spätere Reibung. Teams können Agenten schneller freigeben, weil Rechte, Grenzen und Verantwortung bereits definiert sind. Für Gründer, Produktverantwortliche und Engineering Manager ist das ein Kosten- und Risikothema: weniger Sicherheitsausnahmen, bessere Nachvollziehbarkeit und weniger technische Schulden in der AI-Infrastruktur. Eine Architecture & AI Review kann prüfen, ob Agentenrechte, Backend-Grenzen und Audit-Anforderungen zusammenpassen.