Dies ist der sechste Blog-Beitrag einer siebenteiligen Reihe zum Thema Identity-Sicherheit zur Gewährleistung von KI-Sicherheit.
TL;DR:
KI-Agenten rufen Daten mit den Berechtigungen der Person ab, als die sie sich authentifizieren (geprüft). Die Ausgaben stellen sie jedoch in gemeinsam genutzten Arbeitsbereichen bereit, in denen Empfänger unterschiedliche Berechtigungen haben (nicht geprüft). So kann beispielsweise der Agent eines CFO in einem Slack-Kanal die Vergütung von Führungskräften gegenüber Junior-Analysten offenlegen. Vier kritische Sicherheitslücken (CVSS 9.3-9.4) im Jahr 2025 betrafen Anthropic, Microsoft, ServiceNow und Salesforce. Das Muster ist immer das gleiche: autorisierter Abruf, nicht autorisierte Empfänger. Dies lässt sich mit feingranularer Autorisierung beheben, bei der die Schnittmenge aller Empfängerberechtigungen ermittelt wird, bevor Daten die Abrufschicht verlassen. Dieser Schritt erfolgt, nachdem OAuth seine Aufgabe erfüllt hat.
Das Problem
OAuth wurde für eine einfachere Welt entwickelt: ein Benutzer, eine Anwendung, ein Berechtigungssatz. KI-Agenten durchkreuzen dieses Modell, indem sie in gemeinsam genutzten Kontexten operieren, in denen mehrere Personen die KI-Ausgabe sehen. Das Protokoll hat dieses Szenario zu keinem Zeitpunkt vorgesehen. Ebenso wenig die Plattformen, die darauf aufbauen.
Das Ergebnis: Ihr KI-Agent übernimmt die Zugriffsrechte einer Führungskraft, verteilt jedoch die Inhalte an alle Anwesenden. Einer Studie von McKinsey zufolge haben 80 % der Unternehmen bereits riskante Verhaltensweisen von KI-Agenten festgestellt, darunter unangemessene Datenoffenlegungen und nicht autorisierte Systemzugriffe. Die Sorge ist also begründet.
Wie stellt sich das in der Praxis dar? Das Whitepaper der OpenID Foundation zu agentenbasierter KI beschreibt folgendes Szenario:
Ein CFO setzt einen KI-Agenten in einem Slack-Kanal ein. Der Agent authentifiziert sich mit den Anmeldedaten des CFO und erhält Zugriff auf Vergütungsdaten, Vorstandsunterlagen und HR-Systeme. Ein Junior Analyst fragt: „Wie hoch ist unser Vergütungsbudget für das 3. Quartal?“ Der Agent ruft Budgettabellen, Vergütungspläne und Gehaltsübersichten von Führungskräften ab. Für die Autorisierung wird geprüft: Kann der CFO auf diese Dateien zugreifen? Ja. Der Agent antwortet im Kanal. Der Junior Analyst kennt nun das Gehalt des CEO – ebenso wie alle anderen in dem Kanal.
Der Agent hat genau wie vorgesehen gehandelt. Das Autorisierungsmodell hat versagt.
Das Muster: vier Plattformen, eine Gemeinsamkeit
Zwischen Juni und Oktober 2025 zeigte sich bei vier Schwachstellen mit kritischem Schweregrad ein Muster. Die Schwachstellen sind zwar nicht identisch, haben jedoch eine Gemeinsamkeit: Die Autorisierung wird beim Abruf geprüft, nicht aber bei der Ausgabe.
Slack MCP-Server von Anthropic, Juli 2025
Johann Rehberger entdeckte die erste kritische MCP-Schwachstelle. Wenn Agenten in Slack posten, verwendet die Plattform Hyperlinks, um Vorschauen zu generieren. Ein Angreifer injiziert einen Prompt, der den Agenten mit Administrator-OAuth-Berechtigungen dazu veranlasst, sensible Dateien zu lesen und diese Daten in eine URL einzubetten. Die Vorschau-Bots von Slack rufen die URL ab und führen eine Zero-Click-Exfiltration durch. Anthropic archivierte den Server, anstatt ihn zu patchen. Abruf: Admin-Berechtigungen (geprüft). Ausgabeziel: Server des Angreifers (nicht geprüft).
Copilot von Microsoft 365 (EchoLeak), Juni 2025
Aim Security enthüllte den ersten Zero-Click-Angriff auf einen KI-Agenten in einer Produktionsumgebung. Ein Angreifer sendet eine E-Mail mit verborgenen Anweisungen, die der Empfänger zu keinem Zeitpunkt öffnet. Die RAG-Engine von Copilot nimmt die Payload zusammen mit SharePoint- und OneDrive-Dateien auf und kodiert dann sensible Daten in eine ausgehende URL. Somit wird die Sicherheitsrichtlinie für Inhalt umgangen. Die Ersteller der Studie bezeichneten dies als „LLM Scope Violation“ (LLM-Bereichsverletzung): Der Agent vermischte nicht vertrauenswürdige Eingaben mit vertrauenswürdigen Daten, ohne Vertrauensgrenzen zu isolieren. Microsoft hat zwar eine Korrektur bereitgestellt, doch das Muster besteht weiterhin. Abruf: Microsoft 365-Berechtigungen des Opfers (geprüft). Ausgabeziel: URL des Angreifers (nicht geprüft).
KI-Plattform von ServiceNow (BodySnatcher), Oktober 2025
Aaron Costello von AppOmni fand heraus, dass Virtual Agent und Now Assist bei der Verknüpfung von Konten einem festkodierten Secret plus E-Mail-Adresse vertrauten. Ein Angreifer, der nur die E-Mail-Adresse eines Ziels kennt, könnte sich als beliebiger Benutzer ausgeben – auch als Administrator – und die MFA vollständig umgehen. Nach Übernahme der Identity können Angreifer KI-Agenten mit vollständigen Rechten der Opfer aufrufen, um auf ITSM-Datensätze zuzugreifen oder privilegierte Workflows auszulösen. Costello bezeichnete dies als „bislang schwerwiegendste KI-bedingte Sicherheitslücke“. Abruf: Berechtigungen des Benutzers, dessen Identity übernommen wird (geprüft). Identity des Anfragenden: Angreifer (nicht geprüft).
Salesforce Agentforce (ForcedLeak), September 2025
Noma Security entdeckte eine Prompt-Injizierung über Web-to-Lead-Formulare, die die Exfiltration von CRM-Daten ermöglicht. Ein Angreifer sendet ein Formular mit verborgenen Anweisungen. Wenn ein Mitarbeiter später die KI nach diesem Lead fragt, führt der Agent beide Anfragen aus. Es kommt noch schlimmer: Die Domain my-salesforce-cms.com verblieb trotz Ablauf auf der Whitelist. Angreifer kauften sie für 5 US-Dollar und richteten einen vertrauenswürdigen Exfiltrationskanal ein. Abruf: CRM-Berechtigungen des Mitarbeiters (geprüft). Ausgabeziel: Domain des Angreifers (nicht geprüft).
Die Gemeinsamkeit: Jedes System prüfte, ob der aufrufende Benutzer auf die Daten zugreifen konnte. Doch keines prüfte die Zugriffsrechte aller Empfänger der Ausgabe.
Wofür OAuth nicht konzipiert wurde
Zwei Jahrzehnte lang funktionierte OAuth, weil Anwendungen Daten an denselben Benutzer ausgaben, der den Zugriff autorisiert hatte. KI-Agenten heben diese Annahme nun auf, denn Agenten authentifizieren sich auf unterschiedliche Weise: mit delegierten Benutzeranmeldedaten, mit ihren eigenen Service-Identities oder als benutzerdefinierte Automatisierungen, die mit anderen geteilt werden. Das Muster variiert zwar, aber das Problem ist das gleiche: Die Agenten antworten in gemeinsam genutzten Kontexten, in denen mehrere Personen die Ausgabe sehen.
Das Ergebnis: Die Autorisierung erfolgt zwar beim Abruf, aber es findet keine Prüfung bei der Ausgabe statt. Kontexte mit mehreren Zielgruppen erfordern die Erweiterung von OAuth um zielgruppenorientierte Autorisierung. In OAuth-Spezifikationen bezieht sich „Zielgruppe“ auf die Ziel-API. Hier sind allerdings die Personen gemeint, die sehen, was der Agent ausgibt.
OAuth liefert die Grundlage. Die Erweiterung um zielgruppenorientierte Autorisierung trägt dazu bei, KI-Agenten sicher zu machen.
Die rettende Architektur
Um den Missstand zu beheben, ist eine zielgruppenorientierte Autorisierung erforderlich: Die Zielgruppe muss der Autorisierungsschicht vor dem Abruf bekannt sein, die Berechtigungsschnittmenge muss in Echtzeit ermittelt werden und der Agent antwortet nur mit Daten, die alle Mitglieder der Zielgruppe sehen dürfen.
Die Architektur erfordert das Ineinandergreifen von drei Komponenten:
Engine für feingranulare Autorisierung: Modelliert Berechtigungen als Beziehungen und nicht als statische Rollen. Ermittelt innerhalb von Millisekunden die Schnittmenge der Inhalte, auf die alle Mitglieder der Zielgruppe zugreifen dürfen.
Verwaltungsschicht für Anmeldedaten: Speichert OAuth-Token für verbundene Anwendungen. Gibt Anmeldedaten des Bereichs basierend auf der ermittelten Berechtigungsschnittmenge an Agenten aus.
Identity Governance: Sorgt durch kontinuierliche Überprüfung und Behebung für ein korrektes Berechtigungsdiagramm. Ohne korrekte Berechtigungen ergeben sich bei der Ermittlung der Berechtigungsschnittmenge falsche Antworten.
Ablauf der Ermittlung der Berechtigungsschnittmenge
Die wichtigste Erkenntnis: Die CEO-Gehaltsdaten werden gar nicht erst abgerufen. Das an den Agenten ausgegebene Token hat keinen Zugriff darauf. Dies ist keine Filterung nach dem Abruf, sondern Ermittlung des Berechtigungsbereichs (Scoping) vor dem Abruf.
Warum nicht einfach DLP verwenden? Datenverlustprävention (Data Loss Prevention, DLP) fängt sensible Daten ab, nachdem sie in der Antwort erscheinen. Durch die feingranulare Autorisierung wird der Abruf von vornherein verhindert. DLP fungiert als Sicherheitsgurt, während die Berechtigungsbereich-bezogene Abfrage die Bremse aktiviert.
Wie Okta und Auth0 dies ermöglichen
Fine-Grained Authorization (FGA)
Die herkömmliche rollenbasierte Zugriffskontrolle (RBAC) weist statische Rollen zu. FGA modelliert Berechtigungen als Beziehungen: „Der Vice President Sales kann Budgetdaten anzeigen, weil er Mitglied des Finanzkanals ist.“ Dieses Beziehungsdiagramm ermöglicht die Ermittlung von Schnittmengen. Wenn der Agent wissen möchte, auf welche Daten alle Kanalmitglieder zugreifen dürfen, liefert die BatchCheck-API von FGA die Antwort in Millisekunden, und das für Milliarden Beziehungen.
Token Vault speichert OAuth Refresh Token für jede SaaS-Anwendung und verwaltet den Token-Lebenszyklus automatisch. Die Orchestrierungsschicht ruft Token aus dem Vault ab und gibt Berechtigungsbereich-bezogene Anmeldedaten auf Basis der ermittelten Berechtigungsschnittmenge an die Agenten aus.
Wenn sich Agenten über mehrere Anwendungen verteilen, muss die Autorisierung auch alle Anwendungen umfassen. Cross-App Access erweitert OAuth, indem Zustimmung und Richtliniendurchsetzung an den Identity-Anbieter ausgelagert werden, wodurch die IT-Abteilung des Unternehmens die zentrale Kontrolle über die Verbindungen zwischen Agent und Anwendungen erhält.
Die Echtzeit-Autorisierung ist nur so präzise wie die zugrunde liegenden Berechtigungsdaten. Identity Governance sorgt dafür, dass Berechtigungen kontinuierlich überprüft und korrigiert werden. Wenn Berechtigungen abweichen oder wenn sich verwaiste Accounts summieren, liefert die Schnittmengenermittlung falsche Ergebnisse. Governance sorgt für ein akkurates Berechtigungsdiagramm.
Datenschutzvorschriften
Artikel 32 DSGVO und Artikel 5(1)(f): Artikel 32 der DSGVO verlangt „geeignete technische und organisatorische Maßnahmen“, einschließlich des Schutzes vor „unbefugter Offenlegung oder unbefugtem Zugang zu personenbezogenen Daten“. Artikel 5(1)(f) schreibt vor, dass die Verarbeitung „so erfolgt, dass ihre Sicherheit und Vertraulichkeit hinreichend gewährleistet ist“. Wenn ein KI-Agent personenbezogene Daten von Mitarbeitern unbefugten internen Benutzern zugänglich macht, kommen beide Artikel zur Anwendung. Die Geldbußen können bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes betragen.
Abschnitt 1798.150, CCPA: Das private Klagerecht Kaliforniens erlaubt Verbrauchern die Klageeinreichung, wenn persönliche Informationen „aufgrund der Verletzung der Pflicht des Unternehmens zur Implementierung und Aufrechterhaltung angemessener Sicherheitsverfahren unbefugtem Zugriff, unbefugter Extraktion, Diebstahl oder Offenlegung ausgesetzt sind“. Durch die interne Überexposition durch KI-Agenten könnte diese Voraussetzung erfüllt sein. Gesetzlicher Schadensersatz: 100 bis 750 US-Dollar pro Verbraucher und Vorfall.
Sarbanes-Oxley Abschnitt 404: Abschnitt 404 verpflichtet börsennotierte Unternehmen, „eine angemessene interne Kontrollstruktur einzurichten und aufrechtzuerhalten“. Wenn KI-Agenten mit Berechtigungen von Führungskräften wesentliche, nicht öffentliche Informationen gegenüber unbefugten Mitarbeitern offenlegen können, dürfte Ihre Fähigkeit, angemessene Kontrollen nachzuweisen, stark beeinträchtigt sein. Wirtschaftsprüfer könnten dies als wesentliche Schwäche einstufen.
Wie die Recherchen von McKinsey bestätigen, haben bereits 80 % der Unternehmen riskantes Verhalten von KI-Agenten festgestellt, darunter unangemessene Datenoffenlegungen. FGA ermittelt die Schnittmenge der Berechtigungen vor dem Abruf, um diesen Compliance-Verpflichtungen direkt nachzukommen.
Die Frage für Ihr nächstes Security-Review
Stellen Sie Ihrem Security-Team folgende Frage: „Können wir für jeden in einem gemeinsam genutzten Arbeitsbereich eingesetzten KI-Agenten nachweisen, dass die Ausgabe des Agenten auf diejenigen Daten beschränkt ist, die jedes Mitglied dieses Arbeitsbereichs anzeigen darf?“
Wenn die Antwort „Nein“ lautet, liegt möglicherweise ein Verstoß gegen die Vorschriften vor, der früher oder später entdeckt wird.
Die Technologie zur Behebung dieses Problems existiert bereits. Unter okta.com/ai und auth0.com/ai erfahren Sie, wie Okta und Auth0 KI-Agenten schützen. Laden Sie das Whitepaper Schutz von KI-Agenten von der Entwicklung bis zum unternehmensweiten Einsatz herunter oder wenden Sie sich an Ihren Okta-Vertreter, um die Berechtigungsschnittmenge Ihrer KI-Bereitstellungen auf Lücken zu prüfen.
Im siebten Teil unserer Blog-Reihe führen wir alle sechs Identity-bezogenen Herausforderungen in einem einheitlichen Framework zusammen.
