Non Human Identities: Warum sie für KI-Governance plötzlich kritisch werden

TL;DR: Nichtmenschliche Identitäten steuern Datenflüsse, APIs und KI-Agenten. Wer ihre Rechte, Eigentümer und Credentials nicht kennt, verliert die Kontrolle über kritische Zugriffe.

Non human identities sind 2026 keine technische Randnotiz mehr. Laut ClearVector waren am 6. August 2026 91 Prozent der Produktionsidentitäten nicht menschlich. Dazu zählen Workloads, Service-Accounts, Anwendungen, Geräte und KI-Agenten.

Die non human identities definition trennt heute klar zwischen Identität und Credential. Ein KI-Agent ist die Identität. Ein API-Key, Token oder Zertifikat beweist nur, dass dieser Agent sich anmelden darf. Diese Unterscheidung verhindert den Klassiker: Ein geleakter Key wird gelöscht, aber niemand prüft, welche Rechte der zugehörige Agent weiterhin besitzt.

• KI-Agenten Identitäten brauchen eigene Konten statt geteilter Mitarbeiter-Logins.
• API Keys Governance ordnet jedem Key einen Eigentümer, Zweck und Ablaufzeitpunkt zu.
• Shadow AI Sicherheit beginnt mit Sichtbarkeit für nicht freigegebene Tools und deren Zugriffe.

Die neue NHI Sicherheit verlangt bei jedem Tool-Aufruf eine Prüfung nach Zero-Trust-Prinzipien. Ein Agent, der Rechnungsdaten ausliest, braucht keinen dauerhaften Schreibzugriff auf das ERP. Ehrlich gesagt, „einmal anmelden, dann läuft das schon“ ist bei autonomen Prozessen ungefähr so beruhigend wie ein Haustürschlüssel unter der Fußmatte.

Non human identity management heißt: Jede Maschinenidentität hat einen dokumentierten Zweck, einen verantwortlichen Menschen und exakt begrenzte Rechte.

innoGPT hilft Unternehmen dabei, KI-Anwendungen und Unternehmenswissen kontrolliert zu verbinden. Für non human identities security zählt dabei nicht nur der Login, sondern auch, welche Daten ein KI-Agent pro Aufgabe lesen, speichern oder weitergeben darf.

Definition nichtmenschlicher Identitäten

Nichtmenschliche Identitäten sind digitale Konten für Software, Geräte oder automatisierte Prozesse. Sie erhalten Zugriff, führen Aufgaben aus und hinterlassen Protokolle, aber kein Mensch tippt dabei ein Passwort ein.

Die non human identities definition trennt seit 2026 sauber zwischen dem Akteur und seinem Zugangsnachweis. Ein KI-Agent, eine Anwendung oder ein Server ist die Identität. Ein Token, Zertifikat oder API-Key ist nur das Credential dafür.

• Service-Account: Ein nächtlicher Backup-Job meldet sich an und kopiert Daten in den Cloud-Speicher.
• Workload-Identität: Ein Container ruft während der Ausführung einen Datenbankdienst ab.
• Geräteidentität: Ein Drucker oder Sensor authentifiziert sich im Unternehmensnetzwerk.
• KI-Agenten Identitäten: Ein Agent liest Vertragsdaten und erstellt daraus einen Entwurf.

Der Unterschied entscheidet über die richtige Verwaltung. Rotierst du einen API-Key, änderst du nur den Zugangsnachweis. Entfernst du die Identität nicht, bleibt der Service-Account mit seinen Berechtigungen im System. Genau dort entstehen verwaiste Accounts, die bei Audits gern plötzlich auftauchen. Wie Schimmel hinter dem Schrank, nur mit Zugriff auf Kundendaten.

Eine NHI braucht immer vier Angaben: eindeutigen Namen, technischen Zweck, verantwortliche Person und klar begrenzte Rechte.

Bei non human identities NHI zählt deshalb der Lebenszyklus. Ein Projektteam erstellt etwa einen Agenten für Angebotsentwürfe, ordnet ihn dem Vertriebsleiter zu und beschränkt den Zugriff auf freigegebene Vorlagen. Endet das Projekt, löscht das Team Identität, Credentials und Berechtigungen gemeinsam.

Aus meiner Erfahrung scheitert Non Human Identity Management selten an fehlender Technik. Es scheitert daran, dass niemand Eigentümer eines automatisierten Kontos sein will. Ohne benannten Owner bleibt jede spätere Prüfung bloß digitales Rätselraten.

Sicherheitsrisiken von nichtmenschlichen Identitäten

Nichtmenschliche Identitäten sind ein attraktives Angriffsziel, weil sie oft dauerhaft laufen und weitreichende Rechte besitzen. Laut KPMG kamen 2025 in Unternehmen durchschnittlich 82 technische Identitäten auf eine Person.

Das Risiko ist nicht der einzelne Service-Account. Gefährlich wird die Summe aus alten Accounts, vergessenen Tokens und Standing Privileges, die nie wieder geprüft wurden.

• Ein verwaister Backup-Account behält Zugriff, obwohl das Projekt seit Monaten beendet ist.
• Ein Token landet in einem Code-Repository oder Ticket und bleibt dort jahrelang gültig.
• Ein kompromittierter KI-Agent liest Daten aus mehreren Systemen schneller als ein menschlicher Angreifer.
• Geteilte Accounts verhindern die klare Zuordnung zu einem technischen Eigentümer.

Ein Credential-Leak ist kein kleiner Konfigurationsfehler, wenn die zugehörige Identität dauerhaft Schreibrechte besitzt.

Bei non human identities security zählt deshalb der mögliche Schaden pro Zugriff. Ein Agent für Angebotsentwürfe braucht Leserechte auf Vorlagen. Schreibrechte im CRM oder Zugriff auf die gesamte Kundendatenbank wären in diesem Szenario schlicht überzogen.

Besonders heikel sind Identitäten mit administrativen Privileges. Angreifer suchen nicht zwingend nach einem Benutzerkonto. Ein unterschätzter Workload mit zu vielen Rechten reicht oft aus, um Daten abzuziehen oder weitere Accounts anzulegen.

Prüfe bei jeder NHI zuerst drei Punkte: Wer verantwortet sie, welche Systeme erreicht sie und was passiert bei einem kompromittierten Token? Fehlt auf eine Frage eine klare Antwort, liegt bereits ein Governance-Risiko vor.

NHI Sicherheit scheitert häufig an falscher Priorisierung. Teams suchen nach exotischen Angriffen, während ein ehemaliger Projekt-Account noch immer produktive Daten lesen darf. Ehrlich gesagt ist der langweilige Berechtigungscheck meist der wertvollere Fund.

Auch Shadow AI Sicherheit beginnt bei diesen Spuren. Nutzt ein Fachbereich einen externen KI-Dienst mit privatem API-Key, fehlt der IT die Sicht auf Datenfluss, Eigentümer und Zugriff. Genau diese Lücke macht spätere Audits unerquicklich.

NHI Sicherheit

NHI Sicherheit bedeutet: Jede technische Identität erhält nur kurzzeitig genau den Zugriff, den sie für einen konkreten Auftrag braucht. Ein dauerhaft gültiger Key mit Admin-Rechten ist kein Komfort, sondern ein offenes Fenster.

Seit der CSA-Guidance vom 8. Juli 2026 gilt Zero Trust auch für automatisierte Tool-Aufrufe. Eine erfolgreiche Anmeldung reicht nicht mehr für einen ganzen Prozess. Jeder Zugriff auf Daten, APIs oder Infrastruktur wird erneut geprüft.

• Statische Secrets ersetzen: Nutze kurzlebige Tokens oder Zertifikate statt API-Keys, die monatelang unverändert bleiben.
• Rechte pro Aufgabe begrenzen: Ein Reporting-Job liest Daten, er erstellt keine Benutzerkonten und löscht keine Datensätze.
• Credentials zentral ausgeben: Keys gehören nicht in Git-Repositories, Tickets, Wiki-Seiten oder Chat-Verläufe.
• Jeden Zugriff protokollieren: Logs müssen Identität, Zielsystem, Aktion und Zeitpunkt eindeutig festhalten.

Eine NHI darf nie mehr dürfen als ihr enger Auftrag verlangt. Alles andere sind Standing Privileges mit Schleife drum.

Bei non human identities (NHI) scheitert Security oft an einem Denkfehler: Teams schützen das Passwort, nicht die Berechtigung dahinter. Ein rotierter Token hilft wenig, wenn der zugehörige Workload weiterhin Schreibzugriff auf produktive Kundendaten besitzt.

Prüfe deshalb Zugriffsrichtlinien anhand realer Abläufe. Ein Dokumentenassistent darf Vorlagen lesen und Entwürfe ablegen. Er braucht keinen Zugriff auf Personalakten oder Finanzfreigaben. Bei KI Agenten Identitäten gehören irreversible Aktionen, etwa Vertragsversand oder Datenlöschung, hinter eine menschliche Freigabe.

Auch API Keys Governance braucht klare Regeln: Jeder Schlüssel ist einer technischen Identität, einem Eigentümer und einem Zweck zugeordnet. Fehlt einer dieser drei Einträge, wird der Key gesperrt. Ehrlich gesagt, das spart später die wenig glamouröse Detektivarbeit nach einem Leak.

KI Agenten Identitäten

KI Agenten Identitäten benötigen eigene Konten, spezifische Rechte und eine nachvollziehbare Historie. Ein Agent sollte niemals das Konto eines Mitarbeiters „mitbenutzen“. Andernfalls bleibt nach einem fehlerhaften Toolaufruf unklar, ob der Agent oder der Kollege gehandelt hat.

Die CSA Guidance vom 8. Juli 2026 fordert für agentische Systeme eine Zero Trust Prüfung bei jedem Toolaufruf. Eine einmalige Anmeldung zu Beginn eines Prozesses genügt nicht. Der Agent muss bei jedem Zugriff erneut nachweisen, dass Auftrag, Zielsystem und Berechtigung übereinstimmen.

So begrenzt du einen KI Agenten praktisch

• Gib jedem Agenten eine eigene Identität mit einem fachlich benannten Owner.
• Erlaube nur die Tools, die der konkrete Auftrag wirklich benötigt.
• Nutze kurzlebige Tokens statt dauerhaft gültiger Zugangsdaten.
• Fordere bei Löschungen, Zahlungen oder Vertragsfreigaben eine menschliche Genehmigung.

Ein Vertriebsagent darf Angebote aus CRM-Daten vorbereiten und im Entwurfsordner speichern. Er darf jedoch keine Rabatte freigeben, Kundendaten exportieren oder Benutzerkonten anlegen. Diese Trennung verhindert, dass aus einem hilfreichen Assistenten ein automatisierter Generalschlüssel wird.

Ein KI Agent braucht Rechte für seinen nächsten Schritt, nicht für seinen ganzen Arbeitstag.

Non human identities (NHI) sind bei Agenten besonders kritisch, da ein Agent mehrere Systeme verbindet. Wenn ein Agent eine Wissensdatenbank liest, ein CRM abruft und eine E-Mail schreibt, entstehen drei prüfbare Zugriffe. Logge daher Identität, verwendetes Tool, Aktion, Zeitpunkt und Ergebnis pro Aufruf.

Beim Einsatz von innoGPT gilt dieselbe Regel: Unternehmenswissen darf nur innerhalb klar definierter Rollen und Datenräume verfügbar sein. Oft scheitert Governance nicht am Modell, sondern an der fehlenden Entscheidung, welcher Agent welche Aktion ohne Freigabe ausführen darf.

API Keys Governance

API-Schlüssel sind Credentials, keine Identitäten. Die Identität ist der Agent, die Anwendung oder der Workload, der den Schlüssel nutzt. Seit dem CSA-Bericht vom 5. August 2026 wird eine eigene Governance für API-Keys gefordert.

Ein Key ohne Owner ist wie ein Haustürschlüssel ohne Namensschild. Er funktioniert, aber nach einem Vorfall weiß niemand, wer ihn ersetzen muss. Bei non human identities (NHI) führt das schnell zu Zugriffsrechten, die länger leben als das Projekt selbst.

So prüfst du API-Keys in vier Schritten

1. Erfasse jeden API-Key mit zugehöriger Identität, Owner, Zielsystem und Berechtigung.
2. Entferne Keys aus Quellcode, Tickets, Chatverläufen und frei zugänglichen Dokumenten.
3. Begrenze jeden Key auf eine API, einen Zweck und die nötigen Endpunkte.
4. Rotiere Keys konsequent oder ersetze sie durch kurzlebige Tokens und Workload Identity Federation.

Ein konkreter Fall aus dem Alltag: Ein Marketing-Skript liest Kontaktfelder aus dem CRM, um E-Mail-Entwürfe zu erstellen. Der zugehörige API-Key braucht Leserechte für diese Felder. Er braucht weder Exportrechte für den gesamten Datenbestand noch Rechte zum Löschen von Kontakten.

Ein API-Key darf einen klaren Auftrag authentifizieren, aber niemals ein dauerhafter Generalschlüssel für mehrere Systeme sein.

Meiner Meinung nach scheitert API-Keys Governance selten an Technik. Das Problem ist fehlende Disziplin bei Ownership und Abschaltung. Prüfe daher bei jedem Projektende, ob der Key noch einen aktiven Owner hat. Fehlt diese Zuordnung, wird der Key gesperrt und neu ausgestellt.

Besonders heikel sind Keys für KI-Agenten. Ein Agent mit Zugriff auf CRM, Wissensdatenbank und E-Mail benötigt getrennte Credentials pro System. Dadurch bleibt jeder Zugriff prüfbar, auch wenn eine non human identity mehrere Arbeitsschritte ausführt.

Shadow AI Sicherheit

Schatten-KI wird gefährlich, sobald ein nicht freigegebenes Tool auf Unternehmensdaten oder Schnittstellen zugreift. Bei non human identities (NHI) fehlen dann häufig ein verantwortlicher Owner, eine Rechteprüfung und ein abschaltbarer Zugriff. Schatten-KI erzeugt dabei neue Konten, Tokens oder Agenten außerhalb des vorgesehenen Identity-Managements.

Ein Vertriebsteam verbindet ohne IT-Freigabe ein KI-Tool mit dem CRM, damit es Kundengespräche zusammenfasst. Das Tool erhält einen API-Zugang und übermittelt Kontaktdaten an einen externen Dienst. Fehlen Zweck, Owner und Ablaufdatum, bleibt der Zugriff nach dem Pilotprojekt aktiv.

Schatten-KI praktisch eindämmen

Eine Verbotsmail stoppt Schatten-KI nicht. Du brauchst Sichtbarkeit und einen freigegebenen Weg für echte Arbeitsaufgaben.

• Finde nicht registrierte KI-Zugriffe über SSO-Anmeldungen, Proxy-Protokolle und API-Logs.
• Ordne jedem gefundenen Tool einen Fachbereich, einen Owner und die verarbeiteten Datenklassen zu.
• Erlaube für vertrauliche Daten nur freigegebene Modellzugänge und blockiere private API-Tokens an Unternehmenssystemen.
• Prüfe monatlich, ob ein Tool, Konto oder Zugriff noch einen aktiven Geschäftszweck besitzt.

Mit innoGPT stellst du freigegebene KI-Modelle und Unternehmenswissen zentral bereit. Das senkt den Druck, private Konten für Protokolle, Entwürfe oder Recherche zu verwenden. Jede Freigabe braucht trotzdem einen Owner und eine Prüfung der konkreten Daten.

Ein erlaubtes KI-Tool ohne klaren Owner ist keine Kontrolle, sondern nur Schatten-KI mit Firmenlogo.

Bei einem Vorfall findest du mit dieser Zuordnung Zugang, Owner und betroffene Daten deutlich schneller.

FAQ

Fazit

Non human identities sind essenziell für jede KI-Governance, da sie Daten lesen, APIs aufrufen und Prozesse auslösen. Ohne Dokumentation ihrer Eigentümer, Rechte und Credentials entstehen blinde Flecken mit Admin-Zugang.

Besonders kritisch wird es bei KI-Agenten. Ein falsch konfigurierter Agent macht keine Pause, bevor er hunderte CRM-Datensätze verändert. Ein zentraler Service-Account ist meiner Meinung nach keine Abkürzung, sondern eine verschleierte Sicherheitslücke.

Eine NHI ohne Owner, klaren Zweck und Ablaufdatum gehört deaktiviert, nicht in eine spätere Aufgabenliste.

Starte nicht mit einem Mammutprojekt. Ein solider erster Durchlauf sieht so aus:

1. Erfasse alle Accounts, Tokens, Zertifikate und KI-Agenten mit Zugriff auf Unternehmensdaten.
2. Ordne jeder Identität einen fachlichen Owner, einen Zweck und eine erlaubte Aktion zu.
3. Entferne stehende Admin-Rechte und ersetze langlebige Keys durch kurzlebige Credentials.
4. Prüfe nach jedem Pilotprojekt, ob der Zugriff noch aktiv benötigt wird.

KI-Governance funktioniert nur, wenn IT, Fachbereich und Datenschutz dieselbe Liste sehen. Excel-Dateien reichen selten aus, sobald mehrere Tools, Cloud-Systeme und Agenten beteiligt sind.

innoGPT unterstützt beim kontrollierten KI-Rollout, ersetzt aber kein Identity-Management. Hinterlege Agenten, Datenquellen und Freigaben sauber in deinem Berechtigungskonzept. So bleibt KI ein Werkzeug für produktive Arbeit und wird nicht zum schlecht dokumentierten Mitbewohner im Netzwerk.

KI-Governance für Fachbereiche

KI-Governance regelt, wer welche Daten mit welchem Modell verarbeiten darf. Das betrifft nicht nur IT. Vertrieb, HR und Rechtsabteilung brauchen eigene Freigaben, weil ein Angebotsentwurf andere Daten nutzt als eine Bewerbungsanalyse.

Eine Richtlinie mit drei klaren Fragen reicht für den Start: Welche Daten fließen hinein? Wer gibt den Einsatz frei? Wo bleibt das Ergebnis gespeichert?

DSGVO-konforme KI im Unternehmen

DSGVO-Konformität scheitert häufig an schlecht dokumentierten Datenflüssen. Ein Team kopiert Kundendaten in einen externen Chat, weil der offizielle Weg zu langsam wirkt. Fertig ist die Schatten-IT.

• Prüfe bei jedem KI-Anwendungsfall Zweck, Datenkategorie, Speicherort und Löschkonzept.
• Besonders bei Personalakten, Verträgen und CRM-Daten braucht der Datenschutzbeauftragte diese Informationen vor dem Rollout.

KI-Agenten kontrolliert einführen

Ein KI-Agent braucht vor dem ersten Tool-Aufruf einen klaren Arbeitsauftrag und eine Freigabegrenze. Ein Agent darf etwa Meeting-Notizen erstellen, aber keine Kundendaten im CRM löschen oder Angebote versenden.

innoGPT unterstützt Teams beim geregelten KI-Rollout mit Unternehmenswissen, Freigaben und persönlicher Begleitung. Das ersetzt kein Berechtigungskonzept. Es sorgt aber dafür, dass Fachbereich, IT und Datenschutz nicht drei verschiedene Geschichten erzählen.

Ein produktiver KI-Einsatz beginnt nicht beim Prompt. Er beginnt bei der Frage, welche Aktion ein System ausführen darf.

Das könnte dich auch interessieren

• AI Policy
• KI Policy
• Anthropic zeigt, wie Claude denkt
• ChatGPT Umwelt

Quellen

• Nicht-menschliche Identitäten sichern | CrowdStrike Falcon® Next-Gen Identity Security
• Non-Human Identities: Wenn Systeme privilegierten Zugriff erhalten | KPMG Financial Services Hub
• Sicherheit nicht-menschlicher Identitäten (NHI): Maschinen, Service-Accounts und KI-Agenten
• What Is a Non-Human Identity (NHI)? Machine Identity Security Explained - Palo Alto Networks
• What Are Non-human Identities? | Microsoft Security