AI Agent Governance: Warum Discovery nicht ausreicht

Wenn Sie heute die Anzahl aktiver AI-Agents in einem mittelgroßen Finanzunternehmen zählen, zählen Sie in der Regel falsch – weil die meisten noch nicht erfasst wurden. Das ist das eigentliche Problem. Nicht fehlende Technologie, sondern fehlende Verantwortlichkeit. Non-Human Identities (NHIs) – AI-Agents, Service-Accounts, automatisierte Pipelines – übersteigen menschliche Identitäten in Organisationen heute um den Faktor 50 bis 100. Die Tendenz ist steigend, insbesondere seit die Standardisierung von Schnittstellen wie dem Model Context Protocol (MCP) die Integration von Anwendungen und Daten mit (externen) AI-Services vereinfacht hat.

Das Discovery-Problem ist weitgehend gelöst. Plattformen wie unser Partner Astrix und andere können Agents erkennen, auflisten und klassifizieren. Die eigentliche Frage ist die nächste: Wer ist für diesen Agent verantwortlich? Was darf er tun? Für wie lange? Und wer überprüft dies im Nachhinein?

Die meisten Organisationen haben darauf noch keine Antwort.

Warum klassisches IAM strukturell bei AI Agent Governance scheitert

Traditionelles Identity and Access Management wurde für Menschen gebaut. Hinter jeder Identität steht ein Mitarbeiter, ein Auftragnehmer, ein Partner – eine Person, die sich ausweisen, geschult werden und zur Verantwortung gezogen werden kann.

Agents folgen einer anderen Logik. Sie handeln autonom. Sie operieren kontextsensitiv. Sie können Berechtigungen akkumulieren – nicht durch böswillige Absicht, sondern weil sich ihre Aufgaben ändern, ohne dass Governance-Prozesse Schritt halten. Das ist klassischer Permission Creep, nur mit 50-facher Geschwindigkeit.

Statische Rollenmodelle funktionieren hier nicht. Ein Rollenmodell, das für einen Sachbearbeiter mit stabilen Aufgaben und einem festen Arbeitsvertrag konzipiert wurde, bildet nicht die Dynamik eines Agents ab, der morgen andere Tools nutzt als heute. Das ist kein Konfigurationsproblem – es ist eine konzeptionelle Diskrepanz.

Hinzu kommt: Viele Agents interagieren nicht nur mit internen Systemen, sondern mit externen, oft fremdgehosteten AI-Services. Das bedeutet, potenziell sensible Unternehmensinformationen verlassen den Kontrollbereich der Organisation – oft ohne Genehmigung, ohne Protokollierung, ohne Rückrufmöglichkeit.

Und die Zahlen verdeutlichen den Druck: NHIs übersteigen menschliche Identitäten in Organisationen heute um den Faktor 50 bis 100 – und in manchen Umgebungen sogar darüber hinaus. Wer diese Masse nur entdeckt, aber nicht steuert, hat die eigentliche Arbeit noch nicht begonnen.

Ein pragmatisches Framework für AI Agent Governance

Wer auf fertige Marktstandards wartet, wartet zu lange. Branchenweite, einheitliche Standards für Agent-to-Agent-Kommunikation [1], Delegation von Berechtigungen, Impersonation und Best Practices befinden sich noch in der Entwicklung.

Das sind reale, ungelöste Probleme. Dennoch gibt es heute einen pragmatischen Weg, der mit bestehenden IAM- und GRC-Strukturen umsetzbar ist.

Clustering und Ownership: Die Grundvoraussetzung

Ohne Ownership gibt es keine Verantwortlichkeit. Jeder Agent benötigt einen menschlichen Owner – eine Person, die für den Umfang der Berechtigungen, den Betrieb und die Rezertifizierung verantwortlich ist. Das klingt trivial. In der Praxis scheitern viele Organisationen genau hier, weil Agents von Entwicklungsteams bereitgestellt werden, ohne in bestehende Governance-Prozesse integriert zu werden.

Clustering hilft: Die Gruppierung von Agents nach Zweck, Risikoklasse, Systemzugehörigkeit – aber auch nach Intent-Profil und nach den Daten und Prozessen, auf die sie zugreifen – vereinfacht die Verwaltung erheblich. Diese Daten- und Prozessinformationen sind typischerweise bereits in GRC-Tools erfasst und können direkt genutzt werden. Eine darauf aufbauende Taxonomie schafft die Grundlage für skalierbare Governance, ohne jeden Agent einzeln verwalten zu müssen.

Lifecycle Management: Joiner, Mover, Leaver für NHIs

Was für menschliche Mitarbeiter selbstverständlich ist, fehlt bei Agents nahezu überall: ein klar definierter Lifecycle. Joiner – der Agent wird produktiv eingesetzt und erhält definierte Berechtigungen. Mover – seine Aufgaben oder sein technischer Kontext ändern sich, Berechtigungen werden angepasst. Leaver – der Agent wird außer Betrieb genommen, alle Zugriffe werden entzogen.

Das klingt trivial. In der Praxis scheitert es meist beim Offboarding – nicht von Agents, sondern von Menschen. Wenn ein Mitarbeiter das Unternehmen verlässt, der einen Agent erstellt und betrieben hat, wird dieser Agent zu einem verwaisten Objekt: aktiv, mit vollen Berechtigungen, aber ohne verantwortliche Person. Das ist einer der häufigsten und am wenigsten diskutierten NHI-Risikopfade.

Die Lösung liegt in der Verknüpfung von menschlichem und nicht-menschlichem Lifecycle Management. Offboarding-Prozesse für Mitarbeiter müssen NHI-Ownership als obligatorischen Schritt enthalten: Für welche Agents war diese Person verantwortlich? Was wird neu zugewiesen, was wird deaktiviert? Ohne diese Verknüpfung bleibt ein blinder Fleck, der mit jeder Mitarbeiterfluktuation wächst [2].

Least Privilege, SoD und Policy-Based Authorization

Das Least-Privilege-Prinzip gilt für Agents genauso wie für Menschen – mit dem Unterschied, dass Agents aktiv versuchen, es zu umgehen, wenn ihre Aufgaben es erfordern. Kontextbasierte Zugriffskontrolle ist daher wichtiger als statische Rollenzuweisungen.

Policy-Based Authorization – die Kombination aus RBAC, ABAC, und regelbasierter Steuerung – ermöglicht es, Zugriffsrechte dynamisch an den tatsächlichen Kontext des Agents zu binden: welche Aufgabe, welche Datenklasse, welches Risikoniveau. Segregation of Duties (SoD) muss ebenfalls konsequent durchgesetzt werden – die Trennung inkompatibler Berechtigungen, die für menschliche Identitäten seit Jahren Standard ist [3]. Mit Policy-basierten Ansätzen lässt sich SoD auch auf Agents anwenden: Wer Berechtigungen über Policies vergibt, kann SoD-Regeln auf Policy-Ebene definieren und so systemübergreifend durchsetzen – unabhängig davon, wie viele Agents diese Policies erhalten.

Ein wesentlicher Vorteil hierbei: PBAC-Policies können unabhängig von den Agents rezertifiziert werden. Da die Anzahl der Policies typischerweise deutlich geringer ist als die Anzahl einzelner Agents, vereinfacht dies die Governance erheblich – und macht sie skalierbar. Das ist keine Zukunftstechnologie. Das ist in IGA-Systemen heute umsetzbar, wenn das konzeptionelle Framework stimmt.

Intent Hierarchy als Governance-Fundament

Eine aufkommende Perspektive, die IAM und GRC direkt verbindet, ist das Konzept der Intent Hierarchy [5]. Sie beschreibt, wie verschiedene Ebenen von Intent definieren und begrenzen, was ein Agent tun darf:

Die Konflikthierarchie ist klar: Organizational überschreibt Role-Based, das überschreibt Developer, das überschreibt User. Für Governance-Teams bedeutet das: Die ersten beiden Ebenen sind ihr Terrain.

Organizational Intent schließt den Kreis zur GRC-Perspektive: Policies – also Richtlinien – beschreiben auf Unternehmensebene, technologieneutral, was im Unternehmen erlaubt ist und was nicht. Das Information Security Management System (ISMS) liefert den Rahmen dafür, wie Umsetzung, Verwaltung und Kontrolle dieser Richtlinien zu erfolgen haben. Sie sind die Leitplanken für jede Governance-Entscheidung – auch für Agents. Wer Organizational Intent in seinen Agents durchsetzen will, muss zunächst wissen, was seine Policies besagen.

Role-Based Intent ist die Verbindung zwischen technischem Design und organisatorischem Geschäftszweck – und sie ist direkt als organisatorische Rolle in IGA-Systemen abbildbar. Ein „HIPAA-Compliance-Prüfer“ hat eine andere Role-Based Intent als ein „HR-Einarbeitungsassistent“, selbst wenn beide auf derselben technischen Grundlage basieren.

Das ist keine abstrakte Architekturtheorie. Es ist die Grundlage für Rezertifizierungslogik, die tatsächlich Governance-Wert liefert.

IAM und GRC konvergieren – besonders bei externen Agents

Wer externe AI-Services nutzt, sei es ein LLM über API oder einen SaaS-gebundenen Agent, bewegt sich in rechtlichem und regulatorischem Terrain, das bisher dem Third-Party-Management vorbehalten war.

Das ist heute keine Analogie mehr. Es ist bereits Realität. Externe Agents haben Zugriff auf Unternehmensdaten, führen Aktionen aus und treffen kontextbasierte Entscheidungen – genau wie externe Dienstleister. Die Anforderungen aus DORA, NIS2 und internen Governance-Frameworks legen nahe, sie genauso zu behandeln: mit Risikoklassifizierung, vertraglicher Grundlage, Datenschutzprüfung und periodischer Zugriffsprüfung.

IAM und GRC haben bisher weitgehend getrennt operiert. Agent Governance ist der Punkt, an dem diese Trennung nicht mehr funktioniert. Eine Organisation, die NHIs nur als IAM-Problem behandelt, übersieht die regulatorische Dimension. Eine, die es nur als Compliance-Thema behandelt, übersieht die technische. Identity Visibility and Intelligence Platforms (IVIP) – wie die NEXIS Platform – adressieren genau diese Konvergenz: Sie schaffen eine einheitliche Governance-Ebene über fragmentierte IAM-Strukturen hinweg und machen Risiken sichtbar, die in Einzellösungen verborgen bleiben [4].

Jetzt beginnen – nicht auf fertige Standards warten

Die offenen Fragen zu branchenweiten, einheitlichen Standards (Agent-to-Agent [1] und andere), Delegation, Impersonation und Best Practices sind real. Aber sie dürfen kein Wartezustand sein. Die Grundstruktur – Ownership, Berechtigungs-Governance, Lifecycle Management, Rezertifizierung, Third-Party-Assessment für externe Services – ist heute umsetzbar.

Die Organisationen, die jetzt beginnen, investieren nicht in eine Übergangslösung. Sie bauen Anpassungsfähigkeit auf: die Fähigkeit, neue Agent-Klassen, neue Protokolle und neue regulatorische Anforderungen in eine bereits funktionierende Governance-Struktur zu integrieren.

Die NEXIS Platform unterstützt diesen Ansatz als Identity Visibility and Intelligence Platform (IVIP) mit integrierten Fähigkeiten für Governance, Policy-Based Authorization und der Integration von GRC-Fähigkeiten wie Policy Management und Third Party Management – direkt einsetzbar auf bestehenden IAM-Strukturen, ohne Greenfield-Anforderungen.

Anhang

FAQ

Was ist der Unterschied zwischen NHI Discovery und NHI Governance?

Discovery identifiziert, welche Non-Human Identities in einer Umgebung existieren – Agents, Service-Accounts, API-Schlüssel, Token. Dies ist eine notwendige, aber keine hinreichende Voraussetzung. Governance geht den nächsten Schritt: Sie stellt sicher, dass jede NHI einen verantwortlichen Eigentümer hat, nur die tatsächlich benötigten Berechtigungen besitzt, einem definierten Lebenszyklus unterliegt und regelmäßig rezertifiziert wird. Discovery beantwortet die Frage „Was existiert?“. Governance beantwortet die Fragen „Wer ist verantwortlich, was darf sie tun und bis wann?“

Wie integriere ich AI-Agents in bestehende IAM-Lifecycle-Prozesse?

Der pragmatischste Einstiegspunkt ist die Verknüpfung mit bestehenden Joiner-Mover-Leaver-Prozessen. Konkret: Offboarding-Workflows müssen NHI-Ownership als obligatorischen Schritt enthalten. Wenn ein Mitarbeiter das Unternehmen verlässt, müssen alle Agents, für die er verantwortlich war, neu zugewiesen oder deaktiviert werden. Darüber hinaus benötigt jeder Agent eine definierte organisatorische Rolle im IGA-System – das schafft die Grundlage für Berechtigungskontrolle, SoD-Prüfung und Rezertifizierung.

Was ist Organizational Intent und warum ist es für IAM-Teams relevant?

Organizational Intent beschreibt die äußerste Grenze für das Verhalten eines AI-Agents: Unternehmensrichtlinien, regulatorische Anforderungen und Sicherheitsvorgaben, die der Agent einhalten muss – unabhängig davon, was ein Benutzer verlangt. Das ist für IAM-Teams direkt relevant, weil Organizational Intent aus denselben Quellen stammt wie klassische Governance-Policies: dem ISMS, GRC-Frameworks und regulatorischen Anforderungen wie DORA oder NIS2. Wer diese Policies bereits verwaltet, hat die konzeptionelle Grundlage für Agent Governance bereits gelegt.

Was ist eine IVIP-Plattform und welche Rolle spielt sie bei NHI Governance?

Identity Visibility and Intelligence Platforms (IVIP) sind Plattformen, die Daten aus fragmentierten IAM-Systemen – IGA, PAM, Access Management – in einer einheitlichen Governance-Ebene zusammenführen und durch Analytik und AI anreichern. Für NHI Governance sind sie besonders relevant, weil sie die Konvergenz von IAM und GRC praktisch adressieren: Sie schaffen Sichtbarkeit über alle Identitätstypen hinweg – menschlich und nicht-menschlich – und ermöglichen konsistente Steuerung über Systemgrenzen hinweg. Ein Beispiel für eine IVIP-Plattform ist die NEXIS Platform [4].

Quellen

[1] Agent2Agent Protocol (A2A). https://a2a-protocol.org

[2] Klarl, H. (2025, 5. Juni) Enhancing IAM Hygiene – The Hidden IAM Risks You Can Fix This Quarter.

[3] Nexis. Segregation of Duties in Modern IT Landscapes: Your Guide to Secure and Audit-Ready SoD Controls.

[4] Klarl, H. (2025, 17. September). From Patchwork to Governance: The Role of IVIP in Modern Identity Fabrics.

[5] Copty, F., Haiby, N., Hen, I. (2026, 19. März). *Governing AI Agent Behavior: Aligning User, Developer, Role, and Organizational Intent.* Microsoft Security Community Blog. https://techcommunity.microsoft.com/blog/microsoft-security-blog/governing-ai-agent-behavior-aligning-user-developer-role-and-organizational-inte/4503551