Non-Human Identity Management für AI-Systeme

144:1. Das ist das aktuelle Verhältnis von Non-Human Identities zu Mitarbeitern in Unternehmen – ein Anstieg von 44% gegenüber dem Vorjahr (Entro Labs H1 2025). Nicht 14 – einhundertvierundvierzig pro Person.

Und mit jedem AI-Agent, jedem RAG-System, jedem MCP-Tool wird diese Zahl größer. Die meisten dieser Identitäten wurden einmal erstellt und nie wieder angefasst. Niemand weiß, wer sie erstellt hat, wofür sie genutzt werden, oder ob sie überhaupt noch gebraucht werden. 2024 wurden allein auf GitHub 39 Millionen Secrets exponiert – ein Anstieg von 25% zum Vorjahr.

Dieser Artikel zeigt Ihnen, warum NHIs das unterschätzte Security-Risiko sind, wie AI das Problem verschärft, und wie Sie in fünf Stufen die Kontrolle zurückgewinnen.

Was sind Non-Human Identities?

Bevor wir ins Detail gehen: Was genau meinen wir mit Non-Human Identities?

NHIs sind Credentials, die Maschinen – nicht Menschen – zur Authentifizierung nutzen. Jedes Mal, wenn eine Anwendung mit einer anderen kommuniziert, braucht sie eine Identität. Das Problem: Die meisten dieser Identitäten hat niemand auf dem Schirm.

Die Typen im Überblick:

Warum AI die NHI-Explosion verursacht

Hier wird es interessant – und besorgniserregend. Eine klassische Web-Anwendung braucht vielleicht fünf NHIs: Datenbank, ein paar externe APIs, Cloud-Zugang. Eine AI-Anwendung? Zwanzig bis fünfzig. Mindestens.

Der Grund: AI-Systeme sind von Natur aus vernetzt. Ein RAG-System braucht Zugang zum LLM-Provider, zum Embedding-Service, zur Vector-Datenbank. Ein Agent braucht Credentials für jedes Tool, das er aufrufen kann – CRM, E-Mail, Kalender, Datenbanken. Und mit MCP (Model Context Protocol) wird die Tool-Integration noch einfacher, was bedeutet: noch mehr Credentials.

Die 4 NHI-Risiken: Warum das gefährlich ist

Sie fragen sich vielleicht: "Okay, wir haben viele Credentials. Und?" Die Antwort liegt in vier systematischen Problemen, die fast jedes Unternehmen hat – meist ohne es zu wissen.

Diese vier Risiken sind keine theoretischen Szenarien. Sie sind der Grund, warum Credential-Leaks zu den häufigsten Ursachen für Datenpannen gehören. Schauen wir uns jedes einzeln an:

Was passiert, wenn es schief geht?

Theorie ist eine Sache. Lassen Sie uns ein realistisches Angriffsszenario durchspielen, um zu verstehen, wie schnell aus einem einzelnen exponierten API-Key ein vollständiger Breach werden kann.

NHI-Management: Das 5-Stufen-Modell

Genug Problembeschreibung. Wie bekommen Sie die Kontrolle zurück?

Die gute Nachricht: NHI-Management ist kein Hexenwerk. Es ist ein strukturierter Prozess mit fünf Stufen. Sie müssen nicht alle auf einmal implementieren – aber Sie sollten wissen, wo Sie stehen und was der nächste Schritt ist.

Stufe 1: Discover (Inventarisieren)

Das Ziel: Alle NHIs finden, die existieren – auch die, von denen niemand weiß.

Sie können nicht schützen, was Sie nicht kennen. Der erste Schritt ist ein vollständiges Inventar. Das klingt banal, aber die meisten Unternehmen haben keine Ahnung, wie viele API-Keys, Service Accounts und Tokens in ihrer Infrastruktur existieren.

Methoden zur Discovery:

• Cloud-Provider-Audit (AWS IAM, Azure AD, GCP IAM)
• Secret Scanner auf Code-Repos (auch die Git-History!)
• Network Traffic Analysis (welche Credentials werden aktiv genutzt?)
• Config-Files durchsuchen
• Developer-Befragung (oft unterschätzt, aber effektiv)

Was Sie für jede NHI dokumentieren sollten:

Stufe 2: Classify (Klassifizieren)

Das Ziel: Kritikalität jeder NHI bewerten, um Prioritäten zu setzen.

Nicht alle NHIs sind gleich wichtig. Ein API-Key für einen Development-Newsletter-Service ist weniger kritisch als ein Database-Admin-Account für die Produktionsdatenbank. Die Klassifizierung hilft Ihnen, Ressourcen sinnvoll einzusetzen.

Kritikalitäts-Matrix:

Stufe 3: Right-Size (Berechtigungen minimieren)

Das Ziel: Least Privilege für jede NHI – nur die Rechte, die tatsächlich gebraucht werden.

Hier wird es technisch, aber der Aufwand lohnt sich. Laut OWASP NHI Top 10 haben 90% aller NHI-Tokens mehr Berechtigungen als sie brauchen. Das bedeutet: Im Falle einer Kompromittierung hat der Angreifer mehr Möglichkeiten als nötig.

Der Prozess:

1. Aktuelle Berechtigungen dokumentieren
2. Tatsächlich genutzte Berechtigungen analysieren (Logs!)
3. Differenz identifizieren = zu entfernende Berechtigungen
4. Neue, minimale Policy erstellen
5. Testen in Staging
6. Ausrollen in Production

Beispiel OpenAI API-Key:

# Vorher: Full Access (typisch, aber gefährlich)
api_key_permissions = "*"

# Nachher: Nur was die Anwendung tatsächlich braucht
api_key_permissions = {
    "models": ["gpt-4o-mini"],      # Nicht gpt-4o wenn mini reicht
    "endpoints": ["chat.completions"],  # Kein fine-tuning, kein file upload
    "rate_limit": 1000,              # Calls/Minute
    "budget_limit": 100              # USD/Monat - Kostenexplosion verhindern
}

Stufe 4: Rotate (Regelmäßig erneuern)

Das Ziel: Credentials haben eine begrenzte Lebensdauer – automatisch, nicht "wenn Zeit ist".

Je länger ein Credential existiert, desto höher die Wahrscheinlichkeit, dass es irgendwo exponiert wurde. Git-History, alte Logs, Slack-Nachrichten, ehemalige Mitarbeiter – die Angriffsfläche wächst mit der Zeit.

Empfohlene Rotation-Cadence:

Der Schlüssel ist Automatisierung. Manuelle Rotation passiert nicht – oder zu spät. Tools wie HashiCorp Vault können Rotation vollständig automatisieren.

Stufe 5: Monitor (Überwachen)

Das Ziel: Anomalien erkennen, bevor Schaden entsteht.

Die beste Prävention hilft nichts, wenn Sie nicht merken, dass etwas schief läuft. Monitoring ist Ihre letzte Verteidigungslinie – und oft die erste, die fehlt.

Was Sie überwachen sollten:

• Nutzungsmuster (wann, wie viel, von wo)
• Fehlgeschlagene Authentifizierungen
• Zugriff von neuen IPs/Locations
• Ungewöhnliche Operationen (z.B. plötzlich Admin-Aktionen)

Beispiel Alert-Rules:

rules:
  - name: unusual_api_usage
    condition: usage > 3 * avg_usage_7d
    severity: high
    action: notify_security

  - name: off_hours_access
    condition: access_time NOT IN business_hours AND NOT automated
    severity: medium
    action: log_and_review

  - name: new_location
    condition: ip_location NOT IN known_locations
    severity: high
    action: notify_security

  - name: failed_auth_spike
    condition: failed_auths > 10 in 5min
    severity: critical
    action: block_and_alert

Tools für NHI-Management (Stand: Dezember 2025)

Sie müssen das Rad nicht neu erfinden. Es gibt ausgereifte Tools für jeden Teil des NHI-Lifecycles.

Secret Management

Der Kern jeder NHI-Strategie. Ein Secret Manager ersetzt Environment-Variablen und Config-Files als Credential-Speicher.

Hinweis: HashiCorp hat 2023 die Lizenz von MPL 2.0 auf BSL geändert. Für echte Open-Source-Anforderungen sind OpenBao oder Infisical die Alternativen.

NHI Discovery & Management

Spezialisierte Tools, die Ihnen helfen, NHIs zu finden und zu verwalten. Dieser Markt wächst schnell – 2025 hat OWASP erstmals die NHI Top 10 veröffentlicht.

Code-Scanner

Finden Secrets in Ihrem Code – bevor es Angreifer tun.

NHI-Governance: Regeln etablieren

Tools allein reichen nicht. Sie brauchen klare Regeln, wer NHIs erstellen darf und wie.

Wer darf NHIs erstellen?

Nicht jeder. Ohne Governance entstehen NHIs unkontrolliert – ein Developer braucht schnell einen API-Key, erstellt ihn, und drei Jahre später weiß niemand mehr, wofür er war.

Ein sinnvoller Approval-Workflow:

1. Request (Developer) – Begründung, Scope, Duration, Owner
2. Review (Security) – Least Privilege Check, Alternativen geprüft?
3. Approval (Manager + Security) – Bei Critical: CISO-Approval
4. Provisioning (Automated) – Via Vault, mit Logging und Rotation-Schedule
5. Quarterly Review – Wird sie noch genutzt? Owner noch da?

Offboarding nicht vergessen

Wenn ein Mitarbeiter geht, denken alle an den Laptop und den Badge. An die NHIs, für die diese Person Owner war? Selten.

Offboarding-Checklist für NHIs:

• Von welchen NHIs war die Person Owner? → Ownership übertragen
• Hatte die Person Zugriff auf Secrets? → Alle rotieren
• Persönliche API-Keys? → Deaktivieren
• Audit: Wurden NHIs mitgenommen? → Logs prüfen

Best Practices: Die Kurzfassung

Do's

• ✅ Inventar aller NHIs pflegen – Sie können nicht schützen, was Sie nicht kennen
• ✅ Least Privilege von Anfang an – Nicht "wir machen das später"
• ✅ Automatische Rotation implementieren – Manuelle Rotation passiert nicht
• ✅ Monitoring für alle kritischen NHIs – Anomalien erkennen
• ✅ Owner für jede NHI dokumentieren – Verantwortung klar zuweisen
• ✅ Secrets Manager nutzen – Nicht Env-Vars im Code
• ✅ Pre-commit Hooks für Secret-Detection – Vor dem Push, nicht danach

Don'ts

• ❌ API-Keys in Code committen – Auch nicht "nur kurz zum Testen"
• ❌ "Temporary" Keys permanent nutzen – Das Temporäre wird permanent
• ❌ Admin-Keys für Standard-Operationen – Least Privilege!
• ❌ Shared Credentials zwischen Services – Blast Radius minimieren
• ❌ NHIs ohne Owner – Zombie-Credentials entstehen so
• ❌ Rotation "wenn Zeit ist" – Spoiler: Es ist nie Zeit
• ❌ Credentials in Slack/E-Mail teilen – Auch nicht "nur dieses eine Mal"

Fazit: Jetzt starten

NHI-Management ist kein einmaliges Projekt – es ist ein kontinuierlicher Prozess. Aber der Prozess muss irgendwo beginnen.

Der erste Schritt ist Discovery. Lassen Sie diese Woche einen Secret-Scanner über Ihre Repositories laufen. Die Ergebnisse werden Sie überraschen. Identifizieren Sie parallel die kritischen NHIs: Cloud-Provider-Credentials, LLM-API-Keys, Datenbank-Zugänge.

Das erste Ziel ist ein Inventar. Innerhalb eines Monats sollten Sie wissen, welche NHIs existieren, wer sie erstellt hat, wofür sie genutzt werden, und wann sie zuletzt rotiert wurden. Dieses Inventar ist die Grundlage für alles Weitere.

Der Game-Changer ist Automation. Ein Secret Manager eliminiert manuelle Credential-Verwaltung. Automatische Rotation für Critical und High-Priority NHIs reduziert das Zeitfenster für Kompromittierung von Jahren auf Tage.

Die 144 NHIs pro Mitarbeiter werden nicht weniger. Mit AI-Agents und MCP-Tools werden es mehr. Die Frage ist nicht ob, sondern wann eines dieser Credentials kompromittiert wird. Sorgen Sie dafür, dass es dann das richtige Monitoring gibt, die Rotation funktioniert, und der Blast Radius begrenzt ist.

Weiterführend

• Sichere LLM-Integration – Die 5 Patterns und ihre NHI-Anforderungen
• API Security für AI-Systeme – API-Key-Handling im Detail
• KI Security Framework – NHI-Management im Gesamtkontext
• Enterprise AI Architecture – Zurück zur Übersicht