Okta öffnet ISPM für KI-Agenten: Die Inventur wird zur Admin-Aufgabe

Die Inventur hat jetzt einen neuen blinden Fleck

Okta hat am 1. September 2026 die Erkennung von KI-Agenten in bestehende ISPM-Abonnements aufgenommen. Das klingt zunächst nach einer weiteren Zählung im Sicherheitsdashboard. Für Administratoren geht es aber um etwas Handfesteres: Agenten, die mit OAuth-Zugriffen arbeiten, über MCP-Server Werkzeuge ansprechen oder in einer Builder-Umgebung entstanden sind, fehlen oft in den Listen, mit denen ein Team seinen Betrieb tatsächlich steuert.

Genau dort wird es unangenehm. Ein Servicekonto hat meist einen Namen, einen Owner und einen Antragsweg. Ein Agent kann hingegen aus einem Fachbereichsprojekt stammen, an einen Browser-Grant gekoppelt sein und auf eine Verbindung zugreifen, die niemand im IAM-Team beim Namen kennt. Okta bringt diese Funde laut Ankündigung in die bestehende Posture-Ansicht. Das ersetzt keine Inventur, es gibt ihr aber einen zusätzlichen Eingang.

Der Beitrag von Okta beschreibt die Erweiterung für alle vorhandenen ISPM-Kunden. Damit ist die Beschaffungsfrage zunächst kleiner als die Betriebsfrage. Prüfen Sie im eigenen Tenant, ob die Funktion aktiv ist, welche Quellen angebunden sind und ob deren Daten mit der bekannten Agentenliste übereinstimmen.

Ein brauchbarer Startpunkt ist eine Soll-Liste, bevor der erste Fund eskaliert wird: genehmigte Agenten, fachliche Owner, technische Identitäten und verbotene Datenwege. Fehlt diese Liste, wird aus jeder Entdeckung ein Ad-hoc-Ticket. Das kostet Zeit und verschleiert, ob ein Eintrag unbekannt oder nur schlecht dokumentiert ist.

Endpunktdaten sind nur so gut wie ihre Anbindung

Für Endpunkte nennt Okta eine konkrete Grenze. Die Inventur von Endpoint-Agenten und MCP-Servern läuft zunächst über die CrowdStrike-Integration und befindet sich im Early Access. Okta Verify soll laut Hersteller die nächste Quelle werden; weitere EDR-Plattformen sind geplant, ohne genanntes Lieferdatum. Wer daraus eine vollständige Endpunktübersicht ableitet, baut seine Kontrolle auf Hoffnung.

Die Abdeckung gehört deshalb in den Betriebsbericht. Ein Fund aus der EDR-Integration belegt, dass der angeschlossene Sensor etwas gesehen hat. Er beweist nicht, dass jedes Gerät, jedes Betriebssystem oder jeder Server erfasst wird. Admin-Teams sollten die abgedeckten Geräteklassen, Ausnahmen und den Aktualisierungszeitpunkt direkt neben der Agentenliste führen.

Bei MCP-Servern reicht ein Produktname ohnehin nicht. In die technische Akte gehören Endpunkt, Betreiber, Authentisierungsart, angebundene Werkzeuge und Reichweite im Netz. Ein Server, der lediglich eine lokale Entwicklerumgebung bedient, verlangt eine andere Prüfung als ein Dienst, der produktive Wissensquellen oder Ticket-Systeme erreicht.

Diese Detailarbeit ist wenig glamourös, aber sie verhindert eine typische Sackgasse: Ein Team sieht einen Agenten, findet keinen klaren Owner und deaktiviert vorsorglich den falschen Zugang. Der bessere Weg ist ein gekennzeichneter Fund mit Quelle, Verantwortlichem und einer Frist für die Einordnung.

Welche Fundorte Okta nennt

Okta nennt neben Endpunkten auch Builder-Plattformen. Dazu zählen Salesforce Agentforce, Microsoft Copilot Studio, Amazon Bedrock und Agentcore. Dort entstehen hausgemachte Agenten oft nahe am Fachbereich. Ein Inventareintrag sollte deshalb nicht bei der Plattform enden: Projekt, Owner, verwendete Verbindung, Zielsysteme und Freigabestatus gehören dazu.

Die dritte Quelle ist der verwaltete Browser. Das Okta Browser Plugin soll OAuth-Grants und Shadow-AI-Apps auf solchen Browsern erfassen. Das ist für die Kontrolle nützlich, weil Zugriffe häufig über Einwilligungsdialoge entstehen, nicht über einen klassischen IAM-Antrag. Es bleibt aber ein Signal aus einer klaren Umgebung. Nicht verwaltete Geräte und Profile liefert diese Quelle nicht automatisch mit.

Okta will menschliche und nichtmenschliche Identitäten einschließlich KI-Agenten in einer gemeinsamen Posture-Ansicht zeigen. Zusätzlich nennt das Unternehmen eine Risikokategorie für agentenbezogene Fehlkonfigurationen sowie eine Agentenzahl im ISPM-Dashboard. Beides hilft beim Sortieren. Weder eine Zahl noch eine Kategorie sagt jedoch, ob ein Grant fachlich erlaubt oder ein Zugriff technisch nötig ist.

Hier passt die Analyse zu Microsoft Defenders Sicherheitsautomatisierung: Ein Signal wird erst belastbar, wenn es einen Empfänger und einen festen Ablauf gibt. Für die Agenten-Inventur heißt das, Herkunft und Owner zu erfassen, statt Einträge nur in eine neue Ansicht zu verschieben.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptClose side view of a hardware security key and employee badge placed beside a docked laptop with the lid closed, different workplace setting. No visible text, logos, labels, interface elements, signs, or branding. Photorealistic editorial photography with restrained daylight. The scene communicates access control without showing a dashboard. Avoid watermark, signature, blur, distortion, deformed anatomy, screens, and readable text.

OAuth-Grants brauchen einen eigenen Prüfpfad

OAuth-Grants sind mehr als ein Anhängsel des Agenten. Sie verbinden Anwendungen oder Agenten mit APIs und Daten, oft dauerhaft und mit einem Umfang, der beim ersten Klick kaum sichtbar war. Okta führt unverwaltete OAuth-Grants ausdrücklich als Teil der neuen Erkennung auf. Das bringt sie näher an die übrige Identitätsarbeit, hebt aber die Entscheidung über Zulässigkeit nicht auf.

Jeder auffällige Grant braucht einen fachlichen Owner, einen dokumentierten Zweck und eine Prüfung der angeforderten Berechtigungen. Besonders genau sollten Teams bei breiten Leserechten, langlebigen Tokens und Verbindungen hinsehen, die nach einem Pilotprojekt noch bestehen. Ein Agent automatisiert Arbeit. Er automatisiert auch die Folgen eines zu weit gefassten Zugriffs.

Der Kontrollpfad sollte Entdeckung und Eingriff trennen. Zuerst gleicht das Team einen Fund mit Owner und Freigabe ab. Danach entscheidet die zuständige Stelle über Behalten, Einschränken oder Entzug. Ein unüberlegter Widerruf kann einen produktiven Prozess abbrechen; ein ignorierter Grant lässt eine Berechtigung ohne belastbare Einordnung weiterlaufen.

Okta formuliert für seine umfassendere Agentenlösung drei Fragen: Wo befinden sich die Agenten, womit können sie sich verbinden und was können sie tun? Für Administratoren taugen diese Fragen als Prüfreihenfolge. Die Antworten müssen aus eigenen Logs, Freigaben und Datenklassen kommen, nicht aus einem grünen Dashboard-Symbol.

MCP-Server und Builder-Projekte getrennt verwalten

MCP-Server und Builder-Projekte landen zwar in derselben Inventur, sie erzeugen aber verschiedene Arbeit. Der MCP-Server beschreibt einen technischen Zugang zu Werkzeugen oder Daten. Die Builder-Plattform beschreibt, wo ein Agent konfiguriert wird und wer seine Verbindung angelegt hat. Eine Tabelle ohne getrennte Felder liefert am Ende eine Zahl, aber keine sinnvolle Wartungsgrundlage.

Für MCP-Server empfiehlt sich ein Eintrag mit Betreiber, Lebenszyklus und Deaktivierungsweg. Bei Builder-Projekten gehören zusätzlich Fachbereich, Projektstatus und die verwendeten Connectoren hinein. Diese Trennung vereinfacht auch die Störungssuche: Ein fehlender Eintrag kann an der EDR-Anbindung liegen, ein veralteter Owner an der Plattformverwaltung, ein ungewöhnlicher Zugriff am Grant.

Der Bericht über einen Cyberangriff durch Agenten zeigt, warum Rechte und Grenzen zusammen betrachtet werden müssen. Das gilt ebenso für interne Werkzeuge. Ein Team braucht nicht nur die Information, dass ein Agent existiert, sondern auch einen nachvollziehbaren Weg, seine Verbindungen zu begrenzen oder ihn geordnet abzuschalten.

Beim Abschalten darf die Inventur nicht enden. Prüfen Sie im selben Vorgang Grants, technische Konten, gespeicherte Verbindungen und Protokollierung. Sonst verschwindet der Agent aus dem Projektplan, während ein Berechtigungspfad weiterlebt. Die Wartbarkeit entsteht am Ende eines Lebenszyklus, nicht beim ersten Erkennen.

Die erste Woche entscheidet über die Qualität der Liste

Die ersten fünf Arbeitsschritte sind überschaubar. Erstens wird die Agentenansicht gegen Servicekonto- und Anwendungsinventar abgeglichen. Zweitens erhält jeder unbekannte Eintrag eine Herkunft: EDR, Browser oder Builder-Plattform. Drittens wird ein Owner benannt. Viertens folgen Grants und Zugriffe auf interne Werkzeuge. Fünftens legt das Team einen Wiederholungsrhythmus fest, der zu Änderungen in den angeschlossenen Plattformen passt.

Diese Reihenfolge ist absichtlich konservativ. Okta sagt, neue Tenants erhielten die Funktionen vom ersten Tag an; bei bestehenden Kunden soll die Aktivierung automatisch mit einer kurzen Einführung erscheinen. Auch nach einer automatischen Aktivierung müssen Quellen erst Daten liefern, und die Ergebnisse müssen mit der eigenen Umgebung zusammenpassen. Ein leeres oder übervolles Inventar ist zunächst ein Prüfauftrag.

Die Qualität misst sich nicht an der Zahl entdeckter Agenten. Sie zeigt sich daran, ob ein Team für einen Fund innerhalb weniger Minuten Owner, technische Quelle, Rechte und nächsten Schritt nennen kann. Fehlt eines davon, bleibt die Inventur ein Hinweis statt eines Betriebswerkzeugs.

Okta erweitert damit die Sicht auf Identitäten um einen Bereich, der in vielen Umgebungen zwischen Fachanwendung, Browser und Endpunkt liegt. Wer die neue Erkennung als Eingang in vorhandene Change- und Berechtigungsprozesse einbaut, gewinnt eine pflegbare Liste. Wer nur eine neue Kennzahl beobachtet, sammelt vor allem offene Fragen.

Für den ersten Abgleich genügt eine kleine, bekannte Agentengruppe. Vergleichen Sie die Einträge mit den zugehörigen Freigaben und notieren Sie auch doppelte Meldungen aus mehreren Quellen. Erst wenn Herkunft und Rechte eines Fundes nachvollziehbar sind, lohnt es sich, Regeln für Ausnahmen oder Eskalationen festzulegen. So bleibt die Liste bei der nächsten Plattformänderung wartbar, statt zu einem einmaligen Sicherheitsprojekt zu werden.