Warum Unternehmen für KI-Agenten eine eigene Identitätskontrolle brauchen

Der Kern des Problems liegt laut Leitfaden nicht allein in zu weit gefassten Berechtigungen, sondern in deren Vererbung. Wenn ein Agent im Auftrag eines Vertriebsleiters arbeitet, nutzt er dessen OAuth-Token, delegierte Rechte und gegebenenfalls über Jahre angesammelte Überprivilegierung. Der Agent unterscheidet dabei nicht zwischen dem, was der Mensch selbst getan hätte, und dem, was ihm aufgetragen wurde. Er handelt mit der vollen geerbten Autorität über alle Anwendungen hinweg, die diese Identität erreichen kann.

Damit gerät ein Grundprinzip klassischer IAM-Systeme an seine Grenzen. Solche Werkzeuge sind auf Authentifizierungsereignisse ausgerichtet: Ein Benutzer meldet sich an, das System prüft die Zugangsdaten, dann wird Zugriff gewährt oder verweigert. Agenten funktionieren anders. Sie authentifizieren sich oft einmalig über langlebige Token oder API-Zugangsdaten und arbeiten danach fortlaufend über Sitzungen, Systeme und Kontexte hinweg, ohne dass ein weiterer Governance-Kontrollpunkt greift. Was nach der Anmeldung passiert, bleibt laut Leitfaden für viele IAM-Werkzeuge unsichtbar.

Der Text beschreibt mehrere Gründe, warum sich agentische KI so schnell verbreitet. Genannt werden Modelle, die inzwischen mehrstufige Denkaufgaben zuverlässig erledigen, eine Infrastruktur, die deren Orchestrierung vereinfacht, sowie wirtschaftlicher Druck, Wissensarbeit in großem Maßstab zu automatisieren. Frameworks wie LangGraph, AutoGen und Anthropic’s Model Context Protocol hätten die Entwicklung standardisiert, während gesunkene Inferenzkosten den Dauerbetrieb wirtschaftlich machten. Dadurch sei agentische KI in kurzer Zeit vom Proof of Concept in produktive Umgebungen gewandert.

In Unternehmen übernehmen Agenten dem Leitfaden zufolge bereits Beschaffungsabläufe, Eskalationen im Kundensupport, Code-Reviews, finanzielle Abstimmungen und den Abruf internen Wissens. Das Einführungsmuster wiederhole sich dabei regelmäßig: Fach- oder Betriebsteams identifizieren einen automatisierbaren Ablauf, ein Anbieter liefert eine agentenfähige Funktion oder API, und der Agent geht live. Die Sicherheitsteams entdecken das oft erst später — bei einer Incident-Analyse, bei einem Audit oder gar nicht.

Als Antwort darauf beschreibt der Leitfaden den „Guardian Agent“ als autonome Kontrollschicht auf der Ausführungsebene. Seine erste Aufgabe ist die Erkennung: Er soll alle aktiven KI-Agenten kontinuierlich inventarisieren, ihre Ursprungsidentität, den verantwortlichen Besitzer, den Berechtigungsumfang und die berührten Anwendungen erfassen. Anders als eine manuelle Prüfung, die möglicherweise nie stattfindet, würde ein neuer Agent sofort registriert.

Inventarisierung allein reicht laut Text jedoch nicht aus. Ein Guardian Agent soll für jede autonome Identität eine Verhaltensbasislinie aufbauen: Welche Werkzeuge nutzt der Agent normalerweise, auf welche Daten greift er zu, welche APIs ruft er auf und welche Systemgrenzen überschreitet er? Abweichungen davon — etwa Zugriffe auf ungewohnte Dateispeicher, neue APIs oder Eskalationen über delegierte Berechtigungsketten — könnten auf eine Kompromittierung, einen Prompt-Injection-Angriff oder eine Fehlkonfiguration hindeuten.

Entscheidend sei die Durchsetzung zur Laufzeit. Statt sich auf statische Rollen zu verlassen, soll ein Guardian Agent Berechtigungen anhand des aktuellen Aufgabenkontexts einschränken und damit das Prinzip der minimalen Rechte während der Ausführung umsetzen. Genau diese Fähigkeit unterscheide ihn von IGA-, PAM- oder CIEM-Werkzeugen. Der Leitfaden betont, dass IGA für Lebenszyklen menschlicher Identitäten entwickelt wurde, PAM auf kontrollierte Sitzungen mit ausgecheckten Zugangsdaten zielt und CIEM an Plattformgrenzen endet. Agentische Workloads hingegen spannen sich über mehrere Clouds, SaaS-Anwendungen, selbst gehostete Systeme und Drittanbieter-APIs.

Als besonders problematisch beschreibt der Text überprivilegierte Agenten, verwaiste langlebige OAuth-Token und die Risiken von Prompt Injection. Hinzu kommen Multi-Agenten-Architekturen, in denen ein orchestrierender Agent Teilaufgaben an Unteragenten delegiert und dabei Teile seiner Autorität weitergibt. Orchid Security bezeichnet die dabei entstehende unsichtbare Masse an Identitätsaktivität als „Identity Dark Matter“.

Der Leitfaden stellt Orchid Security als Plattform vor, die diese Lücke schließen soll. Nach eigener Darstellung inventarisiert Orchid automatisch Anwendungen, Konten und Authentifizierungsflüsse, ordnet KI-Agenten ihren Ursprungsidentitäten zu und ergänzt diese um Besitzverhältnisse, Berechtigungsumfang und Geschäftskontext. Laufzeit-Schutzmechanismen sollen minimale Rechte auf der Ausführungsebene durchsetzen, während Verhaltensbeobachtung Anomalien über Werkzeugaufrufe, Datenzugriffe und Systemwechsel hinweg sichtbar macht. Die Plattform speise diese Telemetrie zudem in bestehende IAM-, PAM-, SIEM- und GRC-Prozesse ein.