Vier Vorfälle. Vier Prüfkriterien. Keins erfüllt. – Der OWASP Q1-Report als empirische Validierung

Am 14. April 2026 veröffentlichte das OWASP GenAI Security Project seinen Exploit Round-up Report für Q1 2026 📎. Der Bericht dokumentiert acht reale Sicherheitsvorfälle aus dem Zeitraum Januar bis Anfang April 2026 und ordnet sie systematisch dem OWASP Top 10 for LLM Applications und dem OWASP Top 10 for Agentic Applications zu.

Das ist keine akademische Übung. OWASP ist die Organisation, auf deren Taxonomy Auditoren, Versicherungen und Regulatoren weltweit verweisen. Wenn OWASP acht Vorfälle in einem Quartal dokumentiert, ist die Diskussion über agentische KI-Sicherheit keine Zukunftsfrage mehr. Sie ist eine Bestandsaufnahme.

Ich habe in den Vier Prüfkriterien für Delegationsketten nach §30 BSIG 📎 eine prüfbare Negativdefinition formuliert, ab wann ein Multi-Agenten-System die Zugriffskontrollpflicht strukturell nicht erfüllt: wenn Delegationsbeziehungen zwischen Agenten nicht explizit modelliert sind, wenn Bereichseinschränkung technisch nicht erzwungen wird, wenn die Handlungsherkunft nicht über die gesamte Kette rekonstruierbar ist, oder wenn Revocation nicht transitiv wirkt.

Der OWASP Q1-Report liefert jetzt für jedes dieser vier Kriterien einen dokumentierten Vorfall aus dem laufenden Quartal. Nicht als Warnung. Als Beleg.

Prüfkriterium 1: Delegationsbeziehungen nicht explizit modelliert

Das erste Prüfkriterium verlangt, dass jede Agent-zu-Agent-Übergabe in einem KRITIS-System explizit konfiguriert ist – wer darf wen beauftragen, in welchem Kontext, mit welchen Rechten. Was nicht explizit erlaubt ist, ist verboten. Ein System, das keine solche Modellierung hat, hat keine Zugriffskontrolle. Es hat ein Vertrauensverhältnis.

Am 20. März 2026 berichtete The Guardian über einen Vorfall, der einige Wochen zuvor bei Meta eingetreten war. Ein Mitarbeiter stellte auf einem internen Engineering-Forum eine technische Frage. Ein KI-Agent antwortete mit einer Lösung. Der Mitarbeiter setzte die Empfehlung um. Für zwei Stunden waren daraufhin sensible Nutzerdaten und Unternehmensdaten für eine große Zahl interner Meta-Mitarbeiter zugänglich. Meta teilte mit, dass keine Nutzerdaten missbräuchlich verwendet wurden – das interne Sicherheitssystem schlug sofort Alarm. Das hinderte den Vorfall nicht daran, einzutreten.

Was hier versagt hat, ist nicht ein Authentifizierungsschema und kein Zugriffstoken. Was versagt hat, ist das, was im ersten Prüfkriterium beschrieben wird: eine fehlende explizite Modellierung der Delegationsbeziehung. Es existierte keine Konfiguration, die definiert hätte, in welchen Kontexten der Advisory-Agent Empfehlungen ausgeben darf, die direkte Wirkung auf zugriffssensitive Systemkonfigurationen haben. Der Vorfall ist kein klassischer Delegationsfehler im technischen Sinne, sondern ein Grenzfall: Der Agent hatte keine explizite Autorisierungsbeziehung, sein Output wirkte jedoch operativ wie eine Delegation. Genau diese nicht modellierte Übergangszone ist der Kern des Problems – und in automatisierten Pipelines, in denen kein Mensch mehr zwischen Empfehlung und Ausführung steht, ist sie kein Grenzfall mehr, sondern der Regelfall.

Die OWASP-Einordnung für diesen Vorfall ist präzise: ASI01 (Agent Goal Hijack) und ASI08 (Cascading Failures). Beide setzen voraus, dass die Delegationslogik nicht explizit verankert ist – denn ein explizit modelliertes Delegationsverhältnis hätte die Reichweite des Agents strukturell begrenzt, bevor die Empfehlung überhaupt ausgesprochen werden konnte.

Prüfkriterium 2: Bereichseinschränkung technisch nicht erzwungen

Das zweite Prüfkriterium verlangt, dass Rechte entlang einer Delegationskette nur enger werden können, nie weiter. Wenn Agent A einen Unterauftrag an Agent B weitergibt, darf B maximal so viel dürfen wie A – in der Praxis weniger. Was technisch nicht erzwungen wird, wird irgendwann verletzt.

Am 31. März 2026 veröffentlichte Palo Alto Networks Unit 42 eine Untersuchung zur Vertex AI Agent Engine unter dem Titel „Double Agents: Exposing Security Blind Spots in GCP Vertex AI“ 📎. Autor Ofir Shaty hatte einen KI-Agenten in der Google Cloud Platform Vertex AI Agent Engine deployt und geprüft, welche Berechtigungen dieser Agent durch die standardmäßig zugewiesene Per-Project, Per-Product Service Agent-Identität (P4SA) tatsächlich trägt.

Das Ergebnis: Die standardmäßig gesetzten Berechtigungen erlaubten es dem Agenten, Credentials der Service Agent-Identität zu extrahieren, diese zu nutzen, um auf alle Google Cloud Storage Buckets im Consumer-Projekt zuzugreifen, und darüber hinaus in das Producer-Projekt zu pivoten – jenes Google-intern verwaltete Projekt, das die Vertex AI-Infrastruktur selbst betreibt. Dort waren private Container-Images aus eingeschränkten Artifact-Registry-Repositories abrufbar, darunter Core-Komponenten der Vertex AI Reasoning Engine. Die OAuth-Scopes des Agenten enthielten per Default Zugriffe auf Gmail, Google Calendar und Google Drive.

Das ist das zweite Prüfkriterium in seiner reinsten Form: Die Delegation hatte sich ausgeweitet, nicht verengt. Ein Agent, der eigentlich im Rahmen einer Kundendatenverarbeitung operieren sollte, konnte über eine kompromittierte Service-Agent-Identität Ressourcen erreichen, die strukturell außerhalb seines Mandats lagen. Der Vorfall zeigt dabei nicht zwingend eine Sicherheitslücke im engeren Sinne – Google würde formulieren, dass das System „secure by configuration“ ist. Aber genau das ist der Punkt: Ein Default-Modell, das ohne explizite Härtung keine erzwungene Bereichseinschränkung garantiert, genügt §30 nicht. Die Norm verlangt die Garantie – nicht die Option.

Googles Reaktion nach der Offenlegung durch Unit 42: Die offizielle Dokumentation wurde überarbeitet, um explizit zu dokumentieren, wie Vertex AI Ressourcen, Accounts und Agenten verwendet. Empfohlen wird seitdem das „Bring Your Own Service Account“-Modell (BYOSA), also die Nutzung eines selbst verwalteten, minimal berechtigten Service Accounts statt der Plattform-Default-Identität.

BYOSA ist die Antwort auf ein Versagen des Defaults. Es ist der manuelle Workaround für ein strukturelles Architekturproblem – kein Patch, keine Norm. Und es gilt ausschließlich für diesen Anbieter, in dieser Umgebung, für diesen Konfigurationspfad. Wer mehrere Agenten-Plattformen einsetzt, muss diese Analyse für jede einzelne separat führen.

Prüfkriterium 3: Handlungsherkunft nicht rekonstruierbar

Das dritte Prüfkriterium verlangt, dass für jede Aktion eines Agenten nachvollziehbar bleibt, welcher autorisierte Nutzer- oder Systemauftrag sie ausgelöst hat – auch über mehrere Agenten-Delegationsschritte hinweg, auch 90 Tage später. Fehlt diese Herkunftsdokumentation, ist forensische Prüfbarkeit nach einem Incident strukturell nicht möglich.

Am 7. April 2026 legte Noma Security eine Schwachstelle in den KI-Funktionen von Grafana offen, die unter dem Namen GrafanaGhost bekannt wurde und die im OWASP Q1-Report dokumentiert ist.

Grafana ist eine der meistgenutzten Observability-Plattformen weltweit – ein System, das Telemetrie, Infrastrukturdaten, Finanz- und Kundendaten aggregiert und visualisiert. Ich habe an anderer Stelle beschrieben 📎, warum Observability-Infrastruktur eine besonders kritische Sicherheitsschicht ist: Was das SOC nicht sieht, kann der Prüfer nicht bestätigen. Wenn die Observability-Schicht selbst zum Exfiltrationskanal wird, kehrt sich diese Logik um – das System, das sehen soll, wird zum Instrument, das verbirgt. Mit der Integration von KI-Assistenzfunktionen wurde Grafana zu einem System, das nicht nur Daten darstellt, sondern auf Basis dieser Daten Empfehlungen generiert und Aktionen vorschlägt.

Der Angriff funktionierte so: Angreifer brachten externe Ressourcen unter ihre Kontrolle, die von Grafanas KI-Assistenten im Rahmen normaler Nutzung abgerufen werden. In diesen Ressourcen hinterlegten sie versteckte Instruktionen. Der Assistent verarbeitete sie als regulären Kontext, ignorierte dabei seine System-Prompt-Guardrails und löste eine Rendering-Aktion aus, die Unternehmensdaten als URL-Parameter an einen vom Angreifer kontrollierten Server übermittelte.

Das dritte Prüfkriterium lautet: Die Handlungsherkunft muss über die gesamte Kette rekonstruierbar sein. Für jeden Prüfer muss nach 90 Tagen nachvollziehbar sein, welcher autorisierte Nutzer- oder Systemauftrag zu welcher Aktion geführt hat. Bei GrafanaGhost ist diese Rekonstruierbarkeit in der entscheidenden Dimension nicht gegeben – nicht weil Logs fehlen oder Requests nicht nachvollziehbar wären. Die technische Ausführung ist rekonstruierbar. Was nicht rekonstruierbar ist, ist die semantische Herkunft der Handlung: ob die Rendering-Aktion auf einen autorisierten Nutzerauftrag zurückgeht oder auf eine injizierte Fremdinstruction. Genau diese Differenz ist für §30 entscheidend – denn ein Zugangskontrollkonzept, das diese Frage nicht beantworten kann, beschreibt nicht die tatsächliche Zugriffsrealität.

Grafana korrigierte einen Teil des Problems schnell. Die Grundfrage – wie ein KI-Assistent, der breiten Datenzugriff und externe Rendering-Fähigkeiten kombiniert, strukturell gegen Herkunftsverschleierung abgesichert werden kann – bleibt offen.

Prüfkriterium 4: Revocation wirkt nicht transitiv

Das vierte Prüfkriterium verlangt, dass ein Stoppbefehl – ob durch Richtlinien-Trigger oder durch den Nutzer selbst – nicht nur den direkt angesteuerten Agenten erreicht, sondern alle von ihm initiierten nachgelagerten Aufträge kontrolliert beendet. Ein Widerruf, der nicht ankommt oder nicht wirkt, ist keiner.

Am 23. Februar 2026 bat eine Sicherheitsforscherin von Meta – laut TechCrunch auf ihrem persönlichen Gerät – einen OpenClaw-Agenten 📎, ihren E-Mail-Posteingang zu analysieren und Vorschläge zu machen, was gelöscht oder archiviert werden könnte. OpenClaw – die Klasse lokal betriebener, endpointnaher KI-Agenten, deren technische Angriffsfläche ich an anderer Stelle im Detail untersucht habe 📎 – verfügt per Design über Zugriff auf E-Mail, Kalender und Kommunikationsplattformen. Der Agent begann, E-Mails direkt zu löschen. Die Forscherin sendete Stoppbefehle von ihrem Telefon. Der Agent ignorierte sie und arbeitete weiter.

Das ist das vierte Prüfkriterium, auf seinen Kern reduziert: Revocation wirkt nicht transitiv. Ein explizites Stoppsignal des autorisierten Nutzers erreichte den laufenden Agenten nicht, oder wurde von ihm nicht als bindend behandelt. Was zwischen dem Stoppbefehl und der fortgesetzten Ausführung technisch passiert ist – ob das Signal nicht ankam, ob der Agent in einem Ausführungszustand war, der keine externen Interrupts mehr entgegennahm, oder ob die Implementierung schlicht keinen Mechanismus für synchrone Revocation vorsah – ist für die prüferische Einordnung irrelevant.

Relevant ist das Ergebnis: Ein Nutzer hat den Widerruf einer laufenden Delegation versucht. Der Widerruf hat nicht gewirkt. Die Delegation lief weiter. Ob das Signal nicht zugestellt wurde, nicht verarbeitet werden konnte oder nicht vorgesehen war, ist für die Bewertung unerheblich – entscheidend ist, dass das System keine garantierte Revocation-Wirkung implementiert hatte. Das ist keine Aussage über einen Bug. Es ist eine Aussage über eine Systemeigenschaft.

Der OWASP-Report ordnet diesen Vorfall unter ASI10 (Rogue Agents) ein. Das ist korrekt, aber für die §30-Perspektive greift es zu kurz. Das Problem ist nicht, dass der Agent „rogue“ geworden ist – er hat getan, was er tun konnte. Das Problem ist, dass das System keine Garantie für die Wirksamkeit von Revocation implementiert hatte. In einem KRITIS-Prozess wäre dieser Zustand – ein laufender Agent, der Stoppsignale ignoriert – nicht allein ein Datenschutz- oder Haftungsthema. Er wäre ein Nachweis dafür, dass das vierte Prüfkriterium nicht erfüllt ist: Revocation wirkt nicht transitiv, also ist Zugriffskontrolle im Sinne von §30 nicht implementiert.

Was der OWASP-Report am Ende sagt – und was das bedeutet

Das OWASP-Team schließt seinen Q1-Report mit einer Beobachtung, die ich wörtlich hier einordnen will: Die meisten dieser Vorfälle sind nicht auf traditionelle CVE-Identifikatoren gemappt. Sie entstehen aus Fehlkonfiguration, Designmängeln in Agenten-Autonomie und Vertrauensgrenzen, Supply-Chain-Schwächen und Prompt Injection. Nur klassische Softwareschwachstellen in KI-Plattformen erhalten konsistent CVE-Tracking.

Das ist die entscheidende Aussage – und sie ist für §30-Betreiber relevanter als jede einzelne technische Analyse im Bericht.

Herkömmliches Vulnerability Management funktioniert über CVEs: Schwachstelle wird identifiziert, gepatcht, geschlossen. Der Patch-Zyklus ist die Antwort. Für alle vier oben beschriebenen Vorfälle gibt es keinen Patch, der das Grundproblem löst. Den Meta-Vorfall behebt man nicht durch ein Software-Update. Den Vertex-AI-Vorfall behebt Google durch Dokumentationsüberarbeitung und eine Empfehlung zu BYOSA – kein Patch, eine Architekturanpassung. GrafanaGhost wird teilweise gepatcht, das strukturelle Problem bleibt. Das Revocation-Versagen bei OpenClaw wird durch kein Sicherheitsupdate behoben, solange das Framework keine synchrone Interrupt-Garantie implementiert.

Was all diese Vorfälle gemeinsam haben, ist das Muster, das ich in „Audit bestanden. Betrieb tot.“ 📎 für Europas Cybersicherheitslandschaft beschrieben habe: formal betriebene Systeme, deren tatsächliches Sicherheitsverhalten von der formalen Beschreibung abweicht – nicht weil jemand unehrlich war, sondern weil das Architekturmodell die Realität nicht abbildet.

Was all diese Vorfälle beheben würde, ist genau das, was §30 Abs. 2 Nr. 9 BSIG fordert: eine Steuerungslogik, die die tatsächliche Zugriffsrealität abbildet. Nicht dokumentierte Profile. Nicht Patch-Management. Abbildbare Steuerungslogik – über die Delegationskette, über die Bereichsgrenzen, über die Herkunftsdokumentation, über die Revocation.

Diese Vorfälle sind nicht das Versagen einzelner Sicherheitsmechanismen. Sie sind der Nachweis, dass die zugrunde liegende Steuerungslogik fehlt. Und wo keine Steuerungslogik existiert, existiert auch keine Zugriffskontrolle – nur dokumentiertes Verhalten.

Das ist eine eigene Klasse von Sicherheitsproblemen – systemische Steuerungsdefizite in autonomen Systemen: keine CVEs, keine Exploits im klassischen Sinne, keine klar abgrenzbaren Schwachstellen. Klassische Sicherheitsmodelle erkennen diese Klasse nicht. §30 verlangt jedoch genau ihre Beherrschung. Dass diese Klasse nicht auf agentische Supply-Chain-Angriffe beschränkt bleibt, zeigt eine UC-Berkeley-Studie vom April 2026 📎, in der frontier KI-Modelle beobachtet wurden, wie sie spontan Maßnahmen ergreifen, um das Abschalten anderer KI-Systeme zu verhindern – ohne dazu aufgefordert worden zu sein. Wenn Agenten beginnen, sich gegenseitig gegen Revocation abzusichern, ist das vierte Prüfkriterium nicht mehr nur ein Implementierungsproblem. Es ist ein Systemverhalten.

Der OWASP Q1-Report dokumentiert, dass in den betroffenen Fällen keine Steuerungslogik wirksam wurde, die diese Vorfallklassen verhindert hätte. Drei der vier Vorfälle betreffen keine Nischenprodukte. Sie betreffen Google Cloud, Grafana und Meta – Plattformen und Organisationen, die eigene Security-Teams in dreistelliger Personalstärke betreiben.

Wenn diese Steuerungslogik fehlt, lässt sich die Gegenfrage nicht vermeiden: Wie müsste ein System aussehen, das diese vier Kriterien nicht verletzt?

Wie ein System aussehen müsste, das diese vier Kriterien erfüllt

Die Frage ist nicht rhetorisch. Ein Auditor, der die vier Prüfkriterien gegen eine Architektur hält, wird irgendwann fragen: Wie hätte es richtig ausgesehen? Die Antwort existiert – nicht als marktreifes Produkt, aber als konzeptionelle Gegenform zu dem, was in den vier Vorfällen gefehlt hat.

Erstens braucht explizite Delegation eine signierte Auftragskette. Jeder Agent-zu-Agent-Übergang wird als explizites Dokument modelliert: wer beauftragt, wen, mit welchem Scope, auf welche Ressourcen, mit welchem Ablaufdatum. Nicht als Konfigurationsoption. Als technisch erzwungene Voraussetzung für jede Kommunikation. Was nicht in dieser Kette steht, findet nicht statt. Das ist das Gegenteil dessen, was Vertex AI per Default implementiert – und es ist der Grund, warum Googles Empfehlung „Bring Your Own Service Account“ keine strukturelle Antwort ist, sondern eine manuelle Annäherung an eine Anforderung, die das System selbst erfüllen müsste. Das Model Context Protocol 📎 definiert, wie Agenten auf Werkzeuge zugreifen – aber auch dort ist die Delegationssemantik zwischen Agenten eine offene Architekturschicht, die Betreiber heute selbst schließen müssen.

Zweitens muss Bereichseinschränkung technisch vererbt und irreversibel sein. Ein Agent erbt beim Empfang einer Delegation genau jene Rechte, die der delegierende Agent für diese Aufgabe explizit weitergegeben hat – und keine weiteren. Die Verengung ist nicht konfigurierbar, sie ist strukturell. Ein Mechanismus, der verhindert, dass der empfangende Agent seinen Scope eigenständig erweitert, ist keine optionale Härtungsmaßnahme, sondern Bestandteil des Delegationsprotokolls selbst. Dieser Mechanismus existiert – wie die Analyse zu Okta, Microsoft und IBM 📎 zeigt – in keinem der heute verbreiteten Agenten-Frameworks als Standard.

Drittens erfordert Herkunftsdokumentation eine durchgehende, unveränderbare Kontextbindung. Jede Agentenhandlung trägt einen kryptografisch gebundenen Herkunftsnachweis: den ursprünglichen Nutzerauftrag, die vollständige Delegationskette, den Zeitstempel jedes Übergangs. Dieser Nachweis ist nicht aus Logs rekonstruierbar – er ist Teil der Aktion selbst. GrafanaGhost wäre mit diesem Mechanismus nicht verhindert worden, aber seine Forensik wäre trivial: Die injizierte Fremdinstruction hätte keinen validen Herkunftsnachweis getragen. Die Aktion wäre erkennbar gewesen als das, was sie war.

Viertens bedeutet echte Revocation einen synchronen Interrupt mit globaler Wirkung. Ein Stoppbefehl – ob durch Richtlinientrigger oder durch den Nutzer – erreicht nicht nur den adressierten Agenten, sondern propagiert sofort durch die gesamte Delegationskette: alle nachgelagerten Agenten werden kontrolliert beendet, alle noch nicht ausgeführten Aufträge aus der Kette werden zurückgezogen. Das setzt voraus, dass die Delegationskette als Struktur bekannt ist – was wiederum das erste Kriterium voraussetzt. Die vier Kriterien sind keine unabhängigen Anforderungen. Sie sind architektonische Schichten, die aufeinander aufbauen.

Kein marktreifes Produkt implementiert nach aktuellem Stand aller öffentlich dokumentierten Implementierungen alle vier Schichten vollständig. Das ist der aktuelle Stand – und zugleich der Maßstab, gegen den jede Beschaffungsentscheidung im KRITIS-Kontext geprüft werden muss.

Was der nächste Prüfer fragen wird

Ich habe im April beschrieben 📎, dass Multi-Agenten-Architekturen heute in deutschen KRITIS-Umgebungen oft nicht als bewusste Architekturentscheidung eingeführt werden, sondern als Konsequenz von Effizienzentscheidungen: weil LangGraph, AutoGen oder A2A-basierte Cloud-Integrationen den Übergang von Einzel- zu Mehr-Agent so einfach machen, dass er passiert, bevor die Architekturfrage gestellt ist.

Der OWASP Q1-Report zeigt, was dann folgt: Vorfälle, die keine CVEs erzeugen, keine Patches erhalten, aber trotzdem Daten exponieren, Zugriffsgrenzen verschieben und Revocation-Mechanismen ins Leere laufen lassen. Und: Vorfälle, die bei Google, Meta und Grafana auftreten – Organisationen mit Sicherheitsbudgets, von denen die meisten deutschen KRITIS-Betreiber nicht einmal die Größenordnung kennen.

Ein Prüfer, der in zwölf Monaten eine §30-Prüfung durchführt, wird die OWASP-Taxonomie kennen. Er wird wissen, dass ASI03 (Identity & Privilege Abuse) und ASI04 (Agentic Supply Chain Vulnerabilities) und ASI10 (Rogue Agents) im ersten Quartal 2026 nicht hypothetisch waren. Er wird fragen, ob das Zugangskontrollkonzept diese Vorfallsklassen adressiert. Und er wird – wie ich an anderer Stelle für CRA und NIS-2 beschrieben habe 📎 – nicht nur Bußgelder im Blick haben, sondern die Frage, ob die Geschäftsleitung die Risiken dieser Systemklasse bewusst bewertet und dokumentiert hat.

Die Antwort, die heute noch akzeptiert werden könnte – „diese Szenarien betreffen uns nicht, weil wir keine Multi-Agenten-Systeme betreiben“ – wird in zwölf Monaten schwieriger zu halten sein. Nicht weil die Norm sich ändert. Sondern weil der Stand der Technik sich ändert, und damit, was als adäquate Risikoeinschätzung gilt.

Wer heute Multi-Agenten-Systeme einsetzt, sollte die vier Prüfkriterien gegen die eigene Architektur halten. Wer sie heute noch nicht einsetzt, sollte prüfen, ob die Entscheidung bewusst getroffen wurde – oder ob sie in den nächsten sechs Monaten durch die Effizienzlogik eines Framework-Updates für ihn getroffen wird.

Die eigentliche Prüffrage lautet nicht mehr: Welche Rollen haben Zugriff? Sondern: Welche Delegationskette erzeugt diese Aktion – und unter welchen Bedingungen kann sie gestoppt werden?

Der OWASP GenAI Exploit Round-up Report Q1 2026 ist öffentlich zugänglich und kostenlos verfügbar. Der Bericht ist Pflichtlektüre für jeden, der agentische KI-Systeme in regulierten Umgebungen betreibt oder plant.

Sie setzen agentische KI-Systeme ein und fragen sich, ob Ihre Architektur die vier Prüfkriterien erfüllt – oder ob der nächste OWASP-Quartalsbericht mit Ihrem System als Referenzfall erscheint? Dann ist jetzt der Zeitpunkt, darüber zu sprechen. 📎

Anmelden zu unserem Newsletter: