Die Zukunft der KI-Sicherheit

Im September 2025 entdeckte und unterband Anthropic den ersten dokumentierten, groß angelegten Cyberangriff, der überwiegend von einem KI-Agenten ausgeführt wurde. Eine vom chinesischen Staat unterstützte Gruppe (GTG-1002) manipulierte Code in Claude mit dem Ziel, etwa 30 Unternehmen in den Bereichen Finanzdienstleistungen, Technologie, Fertigung sowie Behörden anzugreifen (Anthropic-Bericht). Künstliche Intelligenz führte autonom 80–90 % der taktischen Operationen aus: Aufklärung, Schwachstellenerkennung, Erkennung, Ausnutzung, Sammeln von Anmeldedaten, laterale Bewegungen und Datenexfiltration. Menschliche Angreifende waren nur an kritischen, strategischen Knotenpunkten aktiv und wandten dabei pro Phase etwa 20 Minuten für gezielte Steuerung auf. Einige wenige Ziele wurden erfolgreich kompromittiert.

Dies war kein Proof of Concept, sondern eine operative Kampagne, die genau die architektonischen Lücken ausnutzte, die bei den meisten Unternehmen heute vorhanden sind: Keine Überprüfung auf Modellebene entdeckte die manipulierten Prompts, kein Agenten-Identity-Framework erkannte den nicht autorisierten autonomen Betrieb und kein Agent Relay setzte zur Laufzeit Kontrollen auf Toolebene durch. Der im Dezember 2025 veröffentlichte Leitfaden OWASP Top 10 for Agentic Applications mit Beiträgen von über 100 Branchenexperten kodifiziert die Ausfallmodi Agent Goal Hijacking (ASI01), Missbrauch von Tools (ASI02) und Identity- und Privilegienmissbrauch (ASI03) als die drei größten Risiken.

Dies ist kein Einzelfall: 88 % der Unternehmen berichteten im vergangenen Jahr von bestätigten oder vermuteten Sicherheitsvorfällen mit KI-Agenten (Gravitee-Umfrage). Von den Unternehmen, die von KI-bedingten Sicherheitsverletzungen betroffen waren, verfügten 97 % nicht über geeignete Zugriffskontrollen für ihre KI-Systeme (IBM/Ponemon-Bericht). Nur 22 % behandeln KI-Agenten als unabhängige Entitäten mit eigener Identität (Gravitee).

Anders ausgedrückt: Wenn Sie KI-Agenten in der Produktion einsetzen und keinen Vorfall verzeichnet haben, haben Sie ihn wahrscheinlich einfach noch nicht entdeckt.

Die richtige Architektur

Unternehmen setzen Agenten in drei unterschiedlichen Vertrauensbereichen ein. Interne Agenten (IT-Helpdesk-Bots, HR-Agenten, Finanz-Bots, die ERP-Berichte abrufen) agieren innerhalb des Unternehmensperimeters. Kundenagenten (Support-Assistenten, Self-Service-KI-Agenten, die im Auftrag von Endbenutzenden interne Knowledge Bases abfragen) verbinden interne Ressourcen mit externen Verbrauchenden. Partneragenten (Lieferkettenintegrationen, unternehmensübergreifende Service-Bereitstellungen) agieren vollständig über die Grenzen von Unternehmen hinweg. Die Sicherheitsanforderungen steigen mit jedem Muster: Interne Agenten benötigen Identity- und Lebenszyklus-Governance. Sobald Sie einen Kundenagenten hinzufügen, brauchen Sie delegierte Autorisierung und Zustimmung. Wenn Sie dies auf Partnerunternehmen ausweiten, müssen Sie domainübergreifendes Vertrauen und Datenablaufkontrollen verwalten. Für alle drei Szenarien ist die gleiche grundlegende Architektur erforderlich.

AWS, Google, Anthropic und Microsoft haben Sicherheitskontrollen für Agenten innerhalb ihrer eigenen Plattformen bereitgestellt, die diesen drei Ebenen zugeordnet sind. Dies validiert die Architektur. Doch Unternehmen führen Agenten nicht nur auf einer einzigen Plattform aus, weshalb sie eine Identity- und Autorisierungslösung benötigen, die für alle funktioniert. Gartner prognostiziert, dass bis zum Jahr 2028 etwa 25 % der Sicherheitsverletzungen in Unternehmen auf den Missbrauch von KI-Agenten zurückzuführen sein werden. McKinsey bezeichnet KI-Agenten als „digitale Insider“, die die gleiche Governance wie menschliche Mitarbeitende erfordern. Die Architektur konvergiert. Die Frage ist, ob Ihr Unternehmen sie proaktiv oder reaktiv einführen wird.

Ebene 1: Modellsicherheit, Absicherung der Intelligenz

In der Kampagne vom September 2025 umgingen die Angreifenden die Sicherheitsleitplanken durch Rollenspiel-Täuschung und Aufgabenzerlegung, indem sie mehrstufige Angriffe in einzelne Anfragen aufteilten, die isoliert betrachtet legitim erschienen (Anthropic). Kein Mensch überprüft Tausende Prompts pro Minute. Sicherheitsfunktionen auf Modellebene sind das, was einen manipulierten Prompt von der Kompromittierung eines Netzwerks abhält.

Die Modellbewertung und Red Teaming decken Schwachstellen vor der Produktion auf. Der Schutz vor Prompt Injection fängt schädliche Anweisungen ab, die in Dokumenten, E-Mails oder Tool-Antworten verborgen sind, während Ausgabe-Leitplanken und DLP verhindern, dass vertrauliche Daten nach außen dringen. Durch kontinuierliche I/O-Überwachung wird alles miteinander verknüpft und auffälliges Verhalten wird in Echtzeit gekennzeichnet. Diese Risiken sind keine Theorien. Forschende haben reale MCP-Schwachstellen in der Praxis gefunden: Tool-Poisoning durch schädliche MCP-Server, Prompt Injection über Tool-Antworten und Lieferkettenangriffe auf MCP-Pakete (OWASP). AWS Bedrock Guardrails und Google Cloud Model Armor bieten jeweils konfigurierbare, modellunabhängige Prüfungen zur Laufzeit. Wenn das Modell kompromittiert ist, ist alles, was Sie darauf aufbauen, irrelevant.

Ebene 2: Agentenidentität, Absicherung des Agenten

Sobald das Modell vertrauenswürdig ist, benötigt der Agent eine Identität, d. h. keinen gemeinsam genutzten Service-Account, keinen statischen API-Key, sondern eine echte Identität mit einer zugeordneten verantwortlichen Personen, die antwortet, wenn etwas schiefgeht, mit funktional und zeitlich eingeschränkten Berechtigungen sowie einem Lebenszyklus, der dann endet, wenn er enden soll.

Vor dem Aufkommen von KI bestand alles aus Code und man wusste deterministisch, was passieren würde. KI-Agenten hingegen arbeiten mit Prompts, und es ist völlig unklar, auf welche Systeme sie tatsächlich zugreifen. Vielleicht greifen sie sogar mit erhöhten Rechten auf ein System zu, mit dem Sie gar nicht gerechnet haben.

Harish Peri, Senior Vice President und General Manager, Okta

Die Verwaltung von Agentenidentitäten beginnt mit Erkennung: Wie viele Agenten sind im Einsatz, wer hat sie entwickelt, welche Anmeldedaten besitzen sie? Die Okta-Umfrage „AI at Work“ ergab, dass bereits 91 % der Unternehmen KI-Agenten einsetzen, aber nur 10 % über eine effektive Governance-Strategie verfügen. In jedem Kundenworkshop, den wir durchführen, ist die erste Frage immer die gleiche: Wie viele Agenten haben Sie eigentlich? Die Antwort lautet fast immer: „Wir wissen es nicht.“ Jeder Agent erhält eine dauerhafte Identität, eine zugewiesene verantwortliche Person und eine Klassifizierung. Die Autorisierung wird mit delegiert: Der Agent handelt im Namen bestimmter Benutzender, mit einem bestimmten Satz von Berechtigungen, für eine bestimmte Aufgabe. Mit Okta Cross App Access (XAA), einem offenen Protokoll zur Erweiterung von OAuth, das jetzt als unternehmenseigene Autorisierung in MCP übernommen wurde, werden diese Delegierungsketten prüfbar. Wird die Kette unterbrochen, endet der Zugriff. Die Lebenszyklusverwaltung durch SCIM bietet die gleiche Governance wie bei menschlichen Identitäten: Zugriffsüberprüfungen, automatisierte Deprovisionierung und Verantwortlichkeit einer zugewiesenen Person. Wenn der delegierende Benutzende aus dem System entfernt wird oder sich eine Richtlinie ändert, wird der Widerruf des Zugriffs an alle nachgelagerten Systeme weitergegeben.

Doch mit Identity-Management allein lässt sich die Lücke nicht schließen. Denn zu wissen, dass ein Agent autorisiert ist, heißt nicht, dass Sie sicher sein können, ob er jetzt – um 2 Uhr nachts – tatsächlich 50.000 Dollar von diesem Bankkonto an einen Empfänger überweisen soll, mit dem er noch nie zuvor interagiert hat.

Ebene 3: Datenautorisierung, Absicherung der Aktion

OAuth-Richtlinien überprüfen das Token auf gültige Berechtigungsbereiche, gültige Zielgruppen und zeitliche Gültigkeit. Dies ist notwendig, aber noch lange nicht ausreichend. Das Token bestätigt, dass der Agent Überweisungen vornehmen kann, doch es sagt nichts darüber aus, ob diese Überweisung an diesen Empfänger in dieser Höhe sinnvoll ist.

Identität und Perimeter bieten nur grobe Kontrollen für Agentenaktionen. Leitplanken für die Nutzung von Tools hingegen bieten mehr Möglichkeiten, um genau zu steuern, welche Aktionen erlaubt sind. 

Google Cloud, Sicherheitsdokumentation zum Agent Development Kit

Das Verhalten von Agenten ist nicht deterministisch. Das LLM wählt Tools zur Laufzeit aus, füllt Parameter basierend auf den von ihm getroffenen Schlussfolgerungen aus und verkettet Operationen in Sequenzen, die beim Verfassen der Richtlinie niemand vorhergesehen hat. Hier kommt das Agent Relay ins Spiel: der Durchsetzungspunkt zwischen dem Agenten und den von ihm aufgerufenen Tools. Das Agent Relay von Okta erzwingt feingranulare Kontrollen zur Laufzeit: Zugriff auf Toolebene (Welche Tools darf dieser Agent aufrufen?), Parameterbeschränkungen (Liegt der Betrag innerhalb der festgelegten Grenzwerte?), Human-in-the-Loop-Genehmigung im Rahmen von CIBA (Client-Initiated Backchannel Authentication) für Vorgänge mit hohem Risiko, anwendungsübergreifende Datenflusskontrolle (Ist die Ausgabe von Tool A als Eingabe für Tool B zulässig?) sowie vollständiger Audit-Trail.

Das Agent Relay ersetzt Identity-Management nicht, es setzt vielmehr dort an, wo Identity-Management aufhört. Identity-Management entscheidet, was in das Token einfließt. Das Agent Relay entscheidet anhand des Token-Inhalts, was zum Zeitpunkt der Ausführung geschieht. Claims übertragen Kontext von einer Ebene zur nächsten. Es besteht keine Lücke zwischen der Identität des Agenten und seinen Berechtigungen.

Welchen Zweck erfüllen die Ebenen?

Eine Kiteworks-Befragung unter 225 Sicherheitsverantwortlichen ergab, dass bei 100 % von ihnen agentenbasierte KI Teil der Roadmap ist, aber 63 % keine Zweckbeschränkungen durchsetzen können und 60 % einen Agenten mit Fehlverhalten nicht deaktivieren können. Die nicht vorhandenen Kontrollen sind jedoch diejenigen, die am wichtigsten sind.

Wohin bewegt sich die Architektur?

Die aus drei Ebenen bestehende Architektur schließt die strukturellen Lücken, die die meisten Unternehmen heute aufweisen. Die folgenden drei Bereiche weisen eine hohe Reifegeschwindigkeit auf und werden die nächste Phase definieren:

• Rekursive Delegierung: Agent A delegiert an Agent B, der an Agent C delegiert. Wie weit wird die Berechtigung weitergegeben? Wer widerruft Zugriffe an der Basis? Cross App Access (XAA) von Okta mit ID-JAG gewährleistet die Nachvollziehbarkeit, indem Benutzeridentität und Agentenidentität in jeden Token-Austausch eingebettet werden, wobei der Berechtigungsbereich mit jedem Delegierungsschritt stärker eingegrenzt wird. Die SCIM-Lebenszyklusverwaltung stellt sicher, dass beim Offboarding eines delegierenden Benutzenden der Widerruf des Zugriffs weitergegeben wird. Die verbleibende Herausforderung besteht in der Standardisierung der Grenzen für die Delegierungstiefe und in der Signalisierung von Multi-Hop-Widerrufen. An diesen Themen wird im Rahmen der OAuth-Spezifikation zur Verkettung von Identität und Autorisierung aktiv gearbeitet.
• Autorisierungsabweichung: Ein Agent ist zum Zeitpunkt des Aufrufs autorisiert, doch die Benutzerberechtigungen ändern sich innerhalb der Kette. Wie kann sichergestellt werden, dass ein Widerruf auch bei einer bereits laufenden Operation greift? Kurzlebige Token mit enger Gültigkeitsdauer begrenzen den Wirkungsradius. Mit der CIBA-basierten Step-up-Authentifizierung kann die Autorisierung an besonders risikoreichen Entscheidungspunkten erneut verifiziert werden. Die Zugriffsrichtlinien von Okta setzen Gewährungen für einen bestimmten Berechtigungbereich nach Gruppenzugehörigkeit durch, sodass eine Berechtigungsänderung auf Directory-Ebene beim nächsten Token-Austausch wirksam wird. Die Herausforderung besteht darin, den Widerruf in Echtzeit über aktive Ausführungsketten hinweg zu signalisieren, ohne legitime Operationen zu unterbrechen.
• Domainübergreifende Vertrauensgrenzen: Ein Agent verkettet Tools über zwei SaaS-Anwendungen mit unterschiedlichen Vertrauensmodellen und Datenklassifizierungsschemata. Wodurch wird die Grenze bestimmt? In einer einzigen Vertrauensdomain erzwingen XAA von Okta und benutzerdefinierte Autorisierungsserver pro Ressource bereits den eingeschränkten Zugriff bei jedem Grenzübertritt. Auth0 Token Vault erweitert dies durch vermittelte Zustimmung und Token-Übersetzung auf OAuth-Ressourcen von Drittanbietern (Google, GitHub, Salesforce). Das organisationsübergreifende Szenario, bei dem zwei unabhängige Identity-Anbieter eine gegenseitige Vertrauensstellung für die Delegierung von Agenten aufbauen müssen, ist die nächste Herausforderung. Die OAuth-Spezifikation für die Verkettung von Identitäten bietet die architektonische Grundlage, und Okta trägt aktiv zu ihrer Entwicklung bei.

Bei der Entwicklung klarer architektonischer Wege müssen Lösungen für alle diese Probleme gefunden werden. Die OWASP Agentic Security Initiative und die OpenID Foundation entwickeln beide Frameworks. Unternehmen, die sich jetzt für die auf drei Ebenen basierende Grundlage entscheiden, sind später in der Lage, diese Kontrollen zu übernehmen, sobald sie ausgereift sind.

Wo stehen Sie heute?

Bewerten Sie den Status Ihres Unternehmens auf jeder Ebene. Die meisten Unternehmen schneiden in mindestens zwei Bereichen mit „Reaktiv“ ab.

Okta und Auth0 bieten die Infrastruktur für Identity-Management und Autorisierung, die den Übergang von einer reaktiven zu einer adaptiven Herangehensweise über die Ebenen 2 und 3 gewährleistet. Als einzige unabhängige Identity-Plattform, die speziell für Mitarbeiter- und Kundenidentitäten entwickelt wurde, behandelt Okta die Agentenidentität als vollwertige Identitäten und lässt ihnen die gleiche Governance zukommen wie menschlichen Identitäten. Dazu nutzt Okta offene Standards wie XAA und SCIM und umgeht dadurch jegliche Anbieterbindung.

Wenn Sie sich in allen drei Ebenen als „Verwaltet“ eingestuft haben, sind Sie wahrscheinlich zu freigiebig.

Der 90-Tage-Weg

Fazit

Der Angriff vom September 2025 hat bewiesen, dass Bedrohungen durch KI-Agenten funktionieren. Gleichzeitig bestätigen Branchenzahlen, dass die meisten Unternehmen nicht gewappnet sind. Die auf drei Ebenen basierende Architektur ist nichts Neues. Sie ist das, was die größten Plattformunternehmen der Welt unabhängig voneinander aufgebaut haben, was die Standardisierungsgremien kodifizieren und was die Daten zu Vorfällen verlangen. Die einzige offene Frage ist die Geschwindigkeit.

Kontext ist die neue Berechtigung, Absicht der neue Perimeter. Die Zukunft der KI-Sicherheit entsteht durch das Zusammenführen von Modellsicherheit, Agentenidentität und Datenautorisierung zu einer einzigen Vertrauenskette.

Die Technologie dafür existiert bereits. Unter okta.com/ai und auth0.com/ai erfahren Sie, wie Okta und Auth0 KI-Agenten absichern. Wir helfen Ihnen bei der Umsetzung. Lassen Sie uns zusammenarbeiten.

Weitere Einblicke zu KI-Sicherheit:

• Sicherheit von KI-Agenten: Stärken Sie das Vertrauen in autonome Agenten. Eine siebenteilige Thought Leadership-Reihe von Okta. 
• KI-Agenten setzen eine grundlegende Entscheidung durch. Das ist eine falsche Entscheidung. Identity-Management ist der Baustein, um sie zu verweigern. Agenten sind entweder nützlich oder sicher.