Executive Summary
Das unternehmensinterne Management von Identitäten für KI-Agenten entwickelt sich schnell zu einer kontinuierlichen Governance- und Compliance-Belastung. Dies erfordert die Zentralisierung von Authentifizierung, Autorisierung, Token-Lifecycle-Management und Audit-Logging über alle internen, Drittanbieter- und Schatten-Agenten hinweg. Der Aufbau einer benutzerdefinierten Zugriffsebene führt zu Sicherheitslücken, Compliance-Verstößen bei Audits und kontinuierlichem Entwicklungsaufwand, da sich die MCP- und OAuth-Spezifikationen weiterentwickeln.
Die Investition in eine zentralisierte Agenten-Identity-Ebene ermöglicht es Unternehmen, den Tool-Zugriff von der Verwaltung von Anmeldeinformationen zu entkoppeln, während sie gleichzeitig eine kontinuierliche Überprüfbarkeit und Zero-Trust-Sicherheit unterstützt – und dafür sorgt, dass sich Ihre Entwickler:innen auf die Entwicklung der Agenten konzentrieren können, die Ihnen bei der Ausführung geschäftskritischer Aufgaben helfen.
Was ist eine Identity-Ebene für KI-Agenten und wie wird sie aufgebaut?
Als KI-Agenten begannen, Aktionen auszuführen, anstatt nur Fragen zu beantworten, mussten Plattform-Teams sie schnell mit echten Tools und Daten verbinden. Viele Teams haben letztendlich selbst eine Zugriffsebene aufgebaut, die normalerweise drei Hauptkomponenten umfasst:
- Ein Model Context Protocol (MCP)-Gateway, das den Agenten-Datenverkehr an MCP-Server weiterleitet
- Ein Token-Broker, der die Anmeldedaten der jeweiligen Nutzer:innen für die von Agenten aufgerufenen SaaS-Apps speichert und aktualisiert
- Rollenbasierte Scope-Filterung, die einschränkt, welche Tools ein Agent abhängig von der Benutzerrolle verwenden darn
Diese Builds erforderten monatelange Entwicklungsarbeit, brachten Agenten in die Produktion und hielten Anmeldedaten aus Prompts fern. Für die meisten Teams war die Eigenentwicklung damals die einzige Option.
Laden Sie unser Whitepaper AI Agent Identity: Build vs. Buy herunter, um zu erfahren, warum der Kauf einer speziell entwickelten Identity-Ebene der effektivste Weg ist, KI-Agenten über ihren gesamten Lebenszyklus hinweg zu verwalten – ohne Ihr Entwicklerteam mit endloser Identity-Wartung zu überlasten.
Die sechs entscheidenden Identitätsfragen für KI-Agenten in Unternehmen
Da die Nutzung von Agenten zunimmt und Agenten mehr geschäftskritische Aufgaben übernehmen, stellen Teams fest, dass sie mehr Fragen beantworten müssen:
- Agentenidentität: Wer ist der jeweilige Agent?
- Eigentümerschaft: Wem gehört der Agent?
- Delegation: In wessen Namen handelt der Agent?
- Geltungsbereich: Auf welche Tools und Ressourcen kann es zugreifen?
- Audit-Trail: Welche spezifischen Aktionen hat es ausgeführt?
- Not-Aus-Schalter: Wie können Teams den Zugriff schnell widerrufen oder abschalten?
Wie der Umfang wächst
Die erste Version beim Aufbau einer Agenten-Zugriffsebene ist handhabbar. Ein Team entwickelt eine Handvoll Agenten, weist jedem eine Service-Identität zu, speichert die SaaS-Token der Nutzer:innen in einem Broker und führt eine Liste darüber, welche Agenten existieren und wer sie entwickelt hat. Für ein einzelnes Team, dessen Agenten innerhalb seiner eigenen Plattform bleiben, bewährt sich dieses Modell gut.
Dann nehmen die Anzahl der Agenten und die geschäftlichen Anforderungen weiter zu. Jede neue SaaS-App, auf die Ihre Agenten zugreifen, betreibt einen eigenen Autorisierungsserver mit eigenem Zustimmungsmodell, eigenen Token-Lebensdauern und eigenem Widerrufsverhalten, sodass der Broker eine zusätzliche Integration benötigt. Andere Teams beginnen, Agenten nach ihren eigenen Zeitplänen bereitzustellen, und einige laufen nie über die Ebene, die Ihr Plattform-Team entwickelt hat.
Entwickler:innen führen Programmier-Agenten wie Claude Code, Codex und Cursor auf ihren Laptops aus, und diese Agenten verbinden sich direkt mit MCP-Servern und Code-Repositories, indem Token in eine lokale Konfigurationsdatei eingefügt werden, da sie den zentralen Build nie durchlaufen. Agenten auf Anbieterplattformen greifen über die eigenen Konnektoren des Anbieters auf Ihre Daten zu. Eingebettete Agenten, Agentenschwärme und lokale Modelle decken jeweils neue Lücken auf, und jede neue Integration erhöht die Belastung für einen Identity-Stack, von dem nun mehr kritische Workflows abhängen.
Bis dahin betreibt das Team, das eine Zugriffsebene für seine eigenen Agenten entwickelt hat, ein Identitätsprodukt für den Rest des Unternehmens.
Die Verwaltung Ihrer eigenen Identity Governance bedeutet, dass die Audit-Saison nie endet
Viele Organisationen beginnen mit einem einfachen Agenten-Verzeichnis: einer Liste jedes Agenten, seiner Eigentümer:innen und der Tools und Apps, auf die er zugreifen kann. Es funktioniert nicht mehr, wenn andere Teams Agenten bereitstellen, Verantwortliche ihre Rolle wechseln oder das Unternehmen verlassen und Prüfer:innen Nachweise dafür verlangen, dass jemand den Zugriff jedes Agenten in diesem Quartal überprüft hat.
Diese Nachweise befinden sich selten an einem einzigen Ort. Das Gateway protokolliert eine Sache, der Broker eine andere und die SaaS-Apps, die der Agent erreicht hat, eine dritte. Um also nachzuweisen, was passiert ist, müssen Datensätze aus jedem System abgerufen und manuell korreliert werden.
Um Agenten tatsächlich skalieren zu können, stellen die meisten Teams fest, dass die Registry ebenfalls mehr leisten muss: Agenten, deren Eigentümer:innen ausgeschieden sind, neu zuweisen oder stilllegen, Zugriffszertifizierungen planmäßig durchführen und noch Monate nach dem Ereignis anzeigen, wer eine Aktion für wen und unter welcher Richtlinie autorisiert hat. Dieser Aufwand wiederholt sich bei jedem Audit-Zyklus und steigt mit jedem Agenten, den Ihr Unternehmen hinzufügt.
OWASP stuft Agentenidentität und den Missbrauch von Berechtigungen auf Platz 3 der größten Risiken für agentenbasierte Anwendungen ein und nennt dabei unklare Verantwortlichkeiten, vererbte Anmeldedaten und zwischengespeicherte Token als Gründe. Genau das sind die Lücken, die sich auftun, wenn ein selbst entwickeltes Verzeichnis an seine Grenzen stößt.
MCP- und OAuth-Sicherheitsstandards entwickeln sich ständig weiter
Die Standards für die Autorisierung von Agenten werden noch erarbeitet. In den letzten 12 Monaten haben wir wesentliche Änderungen in den Richtlinien beobachtet:
| Datum | Spezifikations-/Regulierungs-Update |
|---|---|
| Juni 2025 | Die Autorisierungsspezifikation des Model Context Protocol hat OAuth 2.1 übernommen und die Weitergabe des Tokens eines Clients an nachgelagerte APIs untersagt. |
| September 2025 | Die IETF OAuth-Arbeitsgruppe hat den Identity Assertion Authorization Grant angenommen, der als Grundlage für die Delegierung des Zugriffs von einem Unternehmens-Identity-Anbieter an Drittanbieter-Apps dient. |
| Juli 2026 | Die MCP-Spezifikation begann, die Validierung des Autorisierungsserver-Ausstellers zu verlangen, und verlagerte die Client-Registrierung in Client-ID-Metadaten-Dokumente. |
Zusätzlich weist der NSA-Leitfaden zur MCP-Sicherheit darauf hin, dass das Protokoll die Token-Aktualisierung und den Token-Widerruf nicht spezifiziert, sodass jedes Team, das seine eigene Ebene entwickelt, das Design und den Schutz dieser Verhaltensweisen selbst übernehmen muss.
Jede Spezifikationsänderung bedeutet, dass jemand die neue Spezifikation liest, den Code aktualisiert und erneut testet.
Warum selbst entwickelte Token-Broker bei der Enterprise-SaaS-Autorisierung scheitern
Ein selbst entwickelter Broker kann Token, die SaaS-Apps bereits ausgestellt haben, aufbewahren und aktualisieren, aber er kann nicht eigenmächtig Zugriff gewähren. Jede SaaS-App entscheidet, welchen Identity-Anbietern sie vertraut, um für Ihre Nutzer:innen zu bürgen, und App-Anbieter bauen dieses Vertrauen für eine kleine Auswahl etablierter Identity-Anbieter auf. Wenn ein Broker, den ein Unternehmen intern betreibt, nicht auf dieser Liste steht, bedeutet jede neue App eine weitere Runde von Zustimmungsbildschirmen pro Benutzer:in oder manuelle Freigaben durch Administrator:innen.
Cross-App Access funktioniert anders. Ihr Identity-Anbieter gewährt dem Agenten direkt bereichsbezogenen Zugriff, sodass die IT die Richtlinie nur einmal festlegt, Nutzer:innen den Zustimmungsbildschirm überspringen und die Zugriffskontrolle zentralisiert ist. Immer mehr SaaS-Apps unterstützen dies, und das Model Context Protocol hat dasselbe Muster wie die unternehmensverwaltete Autorisierung übernommen.
Eigenentwicklung vs. Kauf: Verlagerung der Entwicklungsgeschwindigkeit auf zentrale Geschäftsanforderungen
Der Wert eines Agenten ergibt sich daraus, was er für das Unternehmen leistet: aus dem Workflow, den er automatisiert, den Daten, die er zusammenführt, und den Entscheidungen, die er beschleunigt. Jede Stunde, die Ihre Entwicklungsteams damit verbringen, die Token-Aktualisierungslogik zu warten, Zustimmungs-Flows für die nächste SaaS-App neu zu erstellen oder Berichte zur Zugriffsüberprüfung für Prüfer:innen zu generieren, ist eine Stunde, die sie nicht für die Agenten selbst aufwenden.
Die meisten Plattform-Entwickler:innen entwickeln lieber Agentenfunktionen, als einen Identitätsdienst zu betreiben.
Eigene Entwicklungen behalten – die Basis darunter einkaufen
Die Zugriffsebenen, die Teams für ihre ersten Agenten entwickelten, lösten ein dringendes Problem. Die darunterliegende Identity-Ebene stellt eine andere Verpflichtung dar. Es muss jeden Agenten im Unternehmen abdecken, einschließlich derer, die Ihr Team nie entwickelt hat, Apps erreichen, die Ihre Organisation nicht kontrolliert, mit Standards Schritt halten, die sich noch ändern, und in jedem Zyklus Audit-Nachweise erbringen, solange Agenten ausgeführt werden.
Die Investition in eine Sicherheitsebene sorgt dafür, dass sich Ihre Entwickler:innen auf die Agenten konzentrieren können, die das Geschäft vorantreiben, bietet Sicherheits- und IT-Teams einen zentralen Ort, um Agenten zu überblicken und zu steuern, und verlagert die fortlaufende Arbeit der Verwaltung von Standards, Integrationen und Governance auf ein Team, dessen einzige Aufgabe die Identität ist.
Okta® for AI Agents ist eine Identity-Ebene für Agenten, die mit dem Identity-Anbieter und den Gateways zusammenarbeitet, die Sie bereits betreiben. Es beantwortet vier entscheidende Fragen zu Ihrer gesamten Agentenflotte:
- Wo sind meine Agenten? Erkennung und Registrierung
- Was können sie tun? Scope- und Berechtigungsmanagement
- Was tun meine Agenten tatsächlich? Einheitliche Audit-Protokollierung
- Wie reagiere ich? Automatisierter Widerruf und Bedrohungsisolation
Einkaufsführer: Technische Analyse und Framework für Sicherheitsüberprüfungen
Für die vollständige Analyse, einschließlich der Fragen, die Sie jedem Identity-Anbieter im Rahmen Ihrer Sicherheitsüberprüfung stellen sollten, lesen Sie das Whitepaper „AI Agent Identity: Build vs. Buy“.
Diese Materialien dienen ausschließlich allgemeinen Informationszwecken und stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Unternehmensberatung dar.
Der Inhalt gibt womöglich nicht den aktuellen Stand der relevanten Sicherheits-, Rechts- und Datenschutzfragen wieder. Sie tragen die alleinige Verantwortung dafür, sich von Ihren eigenen Rechts- und/oder Fachberatern beraten zu lassen, und sollten sich bei Entscheidungen bezüglich Compliance, Implementierung oder Kauf nicht auf diese Materialien verlassen.
Okta übernimmt keinerlei Zusicherungen oder Garantien in Bezug auf diesen Inhalt und haftet nicht für Verluste oder Schäden, die aus Ihrer Implementierung dieser Empfehlungen resultieren. Information zu den vertraglichen Zusicherungen von Okta gegenüber Kunden finden Sie unter okta.com/agreements.
