Jedes Quartal veröffentlicht das OWASP Security Project eine Zusammenfassung der bedeutendsten KI-Sicherheit des Berichtszeitraums und ordnet jeden einzelnen den OWASP 10 für LLM sowie den neuen Top 10 für agentische Anwendungen zu. Die Ausgabe für das erste Quartal 2026 verdient die Aufmerksamkeit jedes Sicherheitsverantwortlichen – nicht wegen eines einzelnen Vorfalls, sondern wegen des Musters, das sich durch alle Vorfälle zieht.
Die Zusammenfassung OWASP bringt es auf den Punkt: Der Bereich hat den Sprung vom theoretischen risk praktischen Ausnutzung geschafft, und der Fokus hat sich vom Modell selbst weg verlagert. Angreifer und Fehlfunktionen zielen nun auf Agentenidentitäten, Orchestrierungsschichten und Lieferketten ab – nicht nur auf Modellausgaben. Der Verdienst für die zugrunde liegende Forschung gebührt OWASP den dort zitierten Autoren; im Folgenden stelle ich meine Interpretation der vier Vorfälle dar, die für regulierte Unternehmen am wichtigsten sind, und was jeder einzelne von diesen für Ihre Kontrollmaßnahmen erfordert.
„Um die Sicherheit von KI zu gewährleisten, ist nun ein Wechsel von Schutzmaßnahmen auf Modellebene hin zu ganzheitlichen Sicherheitskontrollen auf System-, Identitäts- und Betriebsebene erforderlich.“ – OWASP Security Project, Zusammenfassung für das 1. Quartal 2026
Dieser Satz könnte das Leitbild für alles sein, was wir bei OneCompliant entwickeln. Im Folgenden wird jedem Vorfall die OneCompliant gegenübergestellt – also die Kontrollmaßnahme, die ihn hätte erkennen oder eindämmen können.
1. GrafanaGhost – wenn Ihr Dashboard zum Einfallstor für Datendiebstahl wird
Laut dem OWASP (unter Berufung auf Untersuchungen von Noma Security) konnten Angreifer versteckte Anweisungen in externe Inhalte einbetten, die vom KI-Assistenten von Grafana verarbeitet wurden. Der manipulierte Kontext veranlasste den Assistenten dazu, ein externes Bild darzustellen – und dieser Darstellungsaufruf schmuggelte Unternehmensdaten als URL-Parameter auf einen vom Angreifer kontrollierten Server. Grafana schloss die Sicherheitslücke im Markdown-Bilddarstellungs-Pfad und wies darauf hin, dass die Ausnutzung einer sinnvollen Benutzerinteraktion bedurfte. Entscheidend ist jedoch die Art des Angriffs : Eine vertrauenswürdige Observability-Ebene, die Telemetrie-, Infrastruktur-, Kunden- und Finanzdaten enthält, wurde zu einer Sicherheitslücke.
Behandeln Sie alles, was ein AI aufnimmt – Protokolle, Links, Dashboards, Tickets – als nicht vertrauenswürdige Eingabe und regeln Sie, was er nach außen senden darf. Dies ist eine indirekte Prompt-Injektion; behandeln Sie sie im Rahmen Ihres Bedrohungsmodells wie XSS oder SSRF. Ein Assistent mit umfassendem Zugriff auf Telemetriedaten sollte niemals auch über einen uneingeschränkten Ausgangskanal verfügen. Überprüfen Sie den in das Modell einfließenden Kontext und kontrollieren Sie, was das Modell verlassen darf.
2. Vertex AI Double Agent“ – Identität ist die neue Sicherheitsgrenze
Laut dem Bericht (unter Berufung auf Palo Alto Unit 42) erhielt ein in der Vertex AI Engine von Google Cloud bereitgestellter Agent über ein von Google verwaltetes Dienstkonto weitaus mehr Berechtigungen, als er benötigte. Die Forscher nutzten diese Identität mit übermäßigem Zugriffsumfang, um Anmeldedaten zu extrahieren, als Service-Agent zu agieren, auf Ressourcen von Kundenprojekten zuzugreifen und sogar auf eingeschränkte interne Images und Quellcode zuzugreifen. Google hat daraufhin seine Richtlinien überarbeitet. Die Lehre daraus lautet nicht „Vertex ist unsicher“ – sondern dass die Standardeinstellungen der verwalteten Plattform einem Agenten mehr Zugriffsmöglichkeiten gewährten, als ursprünglich beabsichtigt war.
Die Identität von Agenten verdient dieselbe sorgfältige Prüfung wie privilegierter Administratorzugriff. Standardmäßig sollte der Agent nur über minimale Zugriffsrechte verfügen, der Zugriffsbereich sollte auf die jeweilige Bereitstellung beschränkt sein, die Anmeldedaten sollten nur kurzzeitig gültig sein und es sollte ein aktuelles Verzeichnis aller Dienstidentitäten vorliegen, die mit der Ausführung des Agenten verbunden sind. Verlassen Sie sich nicht auf die Standardeinstellungen der Plattform – prüfen Sie ausdrücklich, ob ein Agent über Projekte, Buckets, Registries oder die Modellinfrastruktur hinweg zugreifen kann.
3. Die interne Agent-Leckage bei Meta – die Auswirkungen einer einzigen unsicheren Antwort
Laut dem Bericht (unter Berufung auf „The Guardian“) bat ein Meta-Ingenieur in einem internen Forum um Hilfe, ein AI Agent schlug eine Lösung vor, und der Ingenieur setzte diese um – wodurch eine große Menge sensibler Nutzer- und Unternehmensdaten für etwa zwei Stunden den Ingenieuren zugänglich war. Es gab keinen externen Angreifer, und Meta erklärte, es seien keine Nutzerdaten missbräuchlich verwendet worden, dennoch löste der Vorfall eine umfassende interne Sicherheitsreaktion aus. Dies ist ein anschauliches Beispiel dafür, wie eine einzige unsichere Empfehlung eines Agenten zu einem Vorfall im Bereich der Zugriffskontrolle auf Unternehmensebene werden kann.
Zwischen der KI-Empfehlung und der Ausführung muss eine Kontrollebene liegen. Jede Empfehlung, die Berechtigungen, die Sichtbarkeit von Daten oder policy ändern kann, policy einer deterministischen Validierung und einer Überprüfung durch einen Menschen unterzogen werden, bevor sie umgesetzt wird – insbesondere innerhalb von Entwicklungs- und Sicherheits-Workflows. Behandeln Sie die Ausgabe des Agenten so lange als nicht vertrauenswürdig, bis sie verifiziert wurde.
4. Mercor / LiteLLM – Ihre AI ist umfangreicher als Ihre Modelle
Laut dem Bericht (unter Berufung auf WIRED) hat Meta die Zusammenarbeit mit AI Mercor ausgesetzt, nachdem es zu einer Sicherheitslücke im Zusammenhang mit bösartigen Versionen des Open-Source-Tools LiteLLM gekommen war. Da Mercor die proprietäre Generierung von Trainingsdaten für große Forschungslabore unterstützt, ließ der Vorfall die Befürchtung aufkommen, dass sensible Methoden zur Erstellung von Trainingsdaten und die Abläufe bei Auftragnehmern offengelegt worden sein könnten – was eine Neubewertung in mehreren Forschungslabors zur Folge hatte. Die Sicherheitslücke entstand durch eine Software-Abhängigkeit im AI Stack, nicht im Modell selbst.
Ihre AI umfasst die Orchestrierungsbibliotheken, die MCP-Integrationen und die Anbieter, die Ihre Daten generieren. Erfassen und überprüfen Sie Abhängigkeiten, verlangen Sie von AI Nachweise im SBOM-Stil sowie eine ausgereifte Incident-Response-Strategie und behandeln Sie Datenanbieter im Rahmen Ihres Governance-Programms als kritische Lieferanten – und nicht als Fußnoten im Beschaffungsprozess.
Der rote Faden, der sie verbindet
OWASP eine zweite Beobachtung, die Ihre Sichtweise auf risk neu prägen dürfte: Die meisten dieser Vorfälle haben keine CVE-Nummer. Es handelt sich nicht um einzelne Codefehler – sondern um Fehlkonfigurationen, übermäßige Autonomie, schwache Vertrauensgrenzen und Manipulation des Datenflusses. Nur ein klassischer Fehler in der eingebetteten Software, wie die aktiv ausgenutzte Schwachstelle in Flowise zur Remote-Code-Ausführung (CVE-2025-59528), passt nahtlos in das traditionelle Schwachstellenmanagement.
Genau darin liegt die Lücke. Wenn Ihr risk auf der Suche nach CVEs basiert, übersieht es naturgemäß den Großteil der Fälle, in denen KI tatsächlich versagt. Dabei handelt es sich um systemische und architektonische Risiken, die Kontrollmaßnahmen erfordern, die zur Laufzeit greifen – über Identität, Handlungsfähigkeit und Datenfluss hinweg – und die Nachweise liefern.
„Der Schwerpunkt hat sich von Modellausgaben hin zu Identitäten, Orchestrierung und Lieferketten verlagert. Die Governance muss diesem Wandel folgen – weg von Dokumenten hin zu operativen Kontrollen.“
Genau diese Ebene OneCompliant : OASF die Kontrollbereiche, OASAT , wo Sie im Vergleich dazu stehen, und Aegis diese am Einsatzort Aegis – indem es Eingabeaufforderungen und den Kontext überprüft, regelt, welche Daten das System verlassen dürfen, den Handlungsspielraum der Agenten festlegt und jede Entscheidung als Nachweis aufzeichnet. Berichte wie OWASP zeigen uns anhand einzelner Vorfälle, warum diese Ebene nicht mehr optional ist.
Lesen Sie den vollständigen Überblick – er ist eine wirklich wertvolle vierteljährliche Informationsquelle, und OWASP Beiträge dazu: OWASP Exploit Round-up, 1. Quartal 2026 →
Diese Vorfälle lassen sich bestimmten Kontrollmaßnahmen zuordnen. Verfügen Sie über diese?
OASAT Ihre AI genau anhand dieser Fehlerquellen – Identität, Handlungsfähigkeit, Lieferkette und Datenfluss – und Aegis die Kontrollmaßnahmen zur Laufzeit Aegis . Decken Sie Ihre Schwachstellen auf, bevor sie Ihnen zum Verhängnis werden.