Descope Agentic Identity Hub 3.0 richtet sich gegen Schatten-KI in Unternehmen

Descope erweitert seine Identitätsplattform, um die KI-Agenten und Server des Model Context Protocol (MCP) zu verwalten, die Beschäftigte innerhalb eines Unternehmens nutzen – ein Bereich, in dem die Verbreitung häufig schneller voranschreitet, als Sicherheitsteams sie erfassen oder kontrollieren können.

Agentic Identity Hub 3.0 soll am 15. Oktober starten und ergänzt das Angebot um ein Portal für das Onboarding von Agenten, native Integrationen für MCP-Gateways, verbesserte Möglichkeiten zur Workload-Authentifizierung und die Ausgabe von ID-JAGs für Agenten, die auf interne Tools zugreifen. Ziel ist es, jedem Agenten einen dokumentierten Zweck, eine verantwortliche Person, klar abgegrenzte Berechtigungen und einen Prüfpfad zuzuweisen, ohne dass Unternehmen die bereits von ihren Beschäftigten genutzten Identitätssysteme ersetzen müssen.

Mit dieser Veröffentlichung geht Descope über den Schutz kundenorientierter Agenten und MCP-Server hinaus und widmet sich dem schwierigeren Problem der „Schatten-KI“ in Unternehmen. Beschäftigte können Claude, Cursor, ChatGPT oder einen intern entwickelten Agenten mit Geschäftssystemen verbinden – manchmal über statische API-Schlüssel oder persönliche Konten, die Sicherheitsteams nicht zentral sperren können. Descope verwies auf den Verizon Data Breach Investigations Report 2026 und erklärte, dass 45 % der Beschäftigten regelmäßig KI auf Unternehmensgeräten nutzen und 67 % dieser Aktivitäten über persönliche, nicht unternehmenseigene Konten laufen.

Internen Agenten einen Verantwortlichen und eine Identität zuweisen

Das neue Portal für das Onboarding von Agenten soll die Bereitstellung von Agenten in einen geregelten Antragsprozess überführen. Beschäftigte geben den Zweck des Agenten sowie die Anwendungen, APIs, Datenquellen oder MCP-Server an, die er benötigt. Prüfende können den Antrag genehmigen, bevor der Zugriff eingerichtet wird. So entsteht ein Verzeichnis, aus dem hervorgeht, wer den Agenten angefordert hat und wer weiterhin für ihn verantwortlich ist.

Damit wird eine grundlegende Schwäche herkömmlicher Identitäts- und Zugriffsverwaltung angegangen. Für menschliche Konten gibt es üblicherweise einen Beschäftigtendatensatz, eine Rolle, eine Führungskraft und einen geregelten Prozess für den Entzug von Zugriffsrechten beim Ausscheiden. Agenten werden dagegen oft eher wie Skripte oder Dienstkonten behandelt, obwohl sie dynamisch Tools auswählen und systemübergreifend handeln können. Dadurch sind die Zuständigkeit und die Autorisierung zur Laufzeit ebenso wichtig wie die erstmalige Anmeldung. Das greift auch einen Gedanken aus der jüngsten Diskussion von Securities.io mit Q2 über Agentenidentitäten auf: Ein Agent sollte eine eigene, begrenzte Rolle haben, statt sämtliche Befugnisse des Kontoinhabers zu übernehmen.

Laut Descope übernimmt der bestehende Agentic Identity Hub bereits die Authentifizierung und Zugriffskontrolle für mehr als eine Million Agentenidentitäten und Hunderte von MCP-Servern. Zu den in der Ankündigung genannten Kunden zählen You.com, WisdomAI, Cequence Security, Token Security und Daylight Security.

So funktioniert die zentrale Steuerungsebene für Identitäten

In der technischen Dokumentation des Unternehmens werden zwei Konzepte voneinander abgegrenzt, die auf Agentenplattformen häufig zusammengefasst werden. Eine Ressource ist eine API oder ein MCP-Server, auf die beziehungsweise den ein Agent zugreifen möchte. Sie wird durch eine Zielgruppe identifiziert und mithilfe von Scopes geschützt. Eine Verbindung ist ein Tresoreintrag, der ein OAuth-Token oder einen API-Schlüssel enthält, den ein nachgelagertes Tool benötigt.

In der von Descope empfohlenen Architektur erhält der Agent ein kurzlebiges Token, dessen Berechtigungen auf eine Ressource beschränkt sind. Der geschützte Server oder das Gateway ruft anschließend zur Laufzeit alle erforderlichen nachgelagerten Zugangsdaten aus dem Tresor für Verbindungen ab. Der Agent selbst speichert das langlebige Geheimnis des Drittanbieters nicht. Bei der Ausstellung oder dem Austausch von Tokens können Richtlinien den Agenten, den auslösenden Nutzer, den Mandanten, das angeforderte Tool und den Laufzeitkontext berücksichtigen. Gleichzeitig protokolliert die Plattform die gesamte Aktivitätskette zu Prüfzwecken.

Dieses Modell ist wichtig, weil MCP zwar standardisiert, wie Agenten Tools finden und aufrufen, aber die Notwendigkeit einer Autorisierung durch das Unternehmen nicht beseitigt. Agentic Identity Hub 3.0 kann als Identitätsanbieter für ein bestehendes Gateway dienen oder mit dem Early-Access-Agent-Gateway von Descope zusammenarbeiten. In der Veröffentlichung wird agentgateway, ein Open-Source-Projekt der Agentic AI Foundation, als native Integration genannt. Die Gateway-Dokumentation von Descope beschreibt außerdem die Kompatibilität mit Produkten wie Kong AI Gateway, Azure AI Gateway, Portkey und Golf.dev.

Wird die Durchsetzung von Richtlinien am Gateway angesiedelt, entsteht eine zentrale Stelle, um Agenten zu authentifizieren, Tool-Aufrufe zu autorisieren und Aktivitäten über interne und externe MCP-Server hinweg zu protokollieren. Zugleich kann das Gateway zu einem kritischen Kontrollpunkt werden: Ob es Risiken verringert oder lediglich zentralisiert, hängt von seiner Verfügbarkeit, der Qualität der Richtlinien und der präzisen Festlegung der Berechtigungsbereiche ab.

Agenten von gemeinsam genutzten Geheimnissen wegführen

Descope ergänzt außerdem mehrere Möglichkeiten, Agenten und Workloads ohne statische Client-Geheimnisse zu authentifizieren. Dazu zählen private-key-JWT-Assertions, gegenseitiges TLS, SPIFFE-Workload-Identitäten und Workload-Identitätsföderation.

Bei der Workload-Identitätsföderation kann ein Agent, der auf AWS, Google Cloud, Microsoft Azure, Kubernetes oder GitHub Actions läuft, die Identität vorweisen, die er bereits von dieser Umgebung erhalten hat. Descope validiert das signierte Token, legt einen Identitätseintrag für die Workload an und gibt ein Token mit eingeschränkten Berechtigungen zurück. Verschiedene Bereitstellungen können getrennt identifizierbar bleiben, auch wenn sie dieselbe Client-Konfiguration verwenden. So lässt sich eine Instanz widerrufen, ohne jede Kopie des Agenten deaktivieren zu müssen.

Die Ausstellung von ID-JAG soll ein ähnliches Modell auf MCP-Server ausweiten. Ein interner Agent authentifiziert sich über den bestehenden Identitätsanbieter der Organisation und erhält Zugriff, der auf den jeweiligen Server zugeschnitten ist. Richtlinien werden bei jeder Anfrage geprüft, statt in einem langlebigen Berechtigungsnachweis hinterlegt zu sein. So lässt sich der Zugriff zentral einschränken oder widerrufen. Descope beschreibt dies als ein SSO-ähnliches Erlebnis für Agenten. Wie gut es funktioniert, hängt jedoch davon ab, ob Gateways und Clients die zugrunde liegenden Standards unterstützen und ob Administratoren Berechtigungsbereiche festlegen, die den tatsächlichen Geschäftsgrenzen entsprechen.

Descopes Wandel: von Kundenidentität zu Agentensicherheit

Descope wurde 2022 von einem Team gegründet, das zuvor das Sicherheitsorchestrierungsunternehmen Demisto aufgebaut hatte, das Palo Alto Networks (PANW ) 2019 übernahm. Das Unternehmen trat 2023 mit einer Seed-Finanzierung von 53 Millionen US-Dollar erstmals öffentlich in Erscheinung und gibt an, die Finanzierungsrunde 2025 auf insgesamt 88 Millionen US-Dollar aufgestockt zu haben.

Ursprünglich konzentrierte sich das Unternehmen auf Kundenidentitäts- und Zugriffsverwaltung, darunter passwortlose Authentifizierung, visuelle Identitätsabläufe, SDKs und APIs. Der Agentic Identity Hub erweitert diese Identitätsinfrastruktur auf nichtmenschliche Akteure. Die gemeinsame Grundlage ist strategisch wichtig: Mitarbeiteridentitäten, Agentenidentitäten, Richtlinienprüfungen, die Vermittlung von Zugangsdaten und Prüfprotokolle lassen sich verwalten, ohne für jedes KI-Produkt ein eigenes Identitätssilo aufzubauen.

Für potenzielle Kunden stellt sich die praktische Frage, ob Descope die Verwaltung von Agenten so einfach gestalten kann, dass Entwicklungsteams die Lösung nutzen, statt sie zu umgehen. Der Onboarding-Prozess muss schneller bleiben als das informelle Teilen von Zugangsdaten, und die Gateway-Integrationen müssen die Clients und Server abdecken, die Mitarbeiter tatsächlich einsetzen. Sicherheitsteams müssen außerdem unterscheiden können, ob ein Agent lediglich authentifiziert ist oder ob seine Aktionen auch sicher sind. Die Identität schränkt den Zugriff ein und versieht ihn mit Attributen, verhindert jedoch weder Prompt-Injection noch eine fehlerhafte Auswahl von Werkzeugen oder schädliche Aktionen, die innerhalb eines genehmigten Berechtigungsumfangs bleiben.

Der Agentic Identity Hub 3.0 ist daher am besten als Versuch zu verstehen, einen Identitätsperimeter für Unternehmens-KI zu schaffen. Er bietet Organisationen eine Möglichkeit, zu klären, wem ein Agent gehört, welchen Nutzer oder welche Arbeitslast er repräsentiert, worauf er zugreifen kann und wie sich sein Zugriff widerrufen lässt. Wenn Agenten aus der Experimentierphase in produktive Arbeitsabläufe übergehen, werden diese Fragen zunehmend Teil der grundlegenden Cybersicherheitsinfrastruktur und nicht bloß einer optionalen Ebene rund um das Modell.