OWASP Top 10 für LLM-Anwendungen 2026: Was sich geändert hat

7.714 Vorfälle. So groß ist der Datensatz, gegen den das OWASP GenAI Security Project seine neue Top 10 für LLM-Anwendungen 2026 geprüft hat. 6.639 davon waren detailliert genug, um sie einer Kategorie zuzuordnen. Die Projektleiter Steve Wilson und Rock Lambros schreiben im Vorwort, alle bisherigen Ausgaben hätten auf Einschätzungen beruht. Diesmal wurde die Abstimmung der Praktiker zum ersten Mal an dem gemessen, was tatsächlich schiefgegangen ist.

Das Ergebnis liegt seit Anfang August vor. Die Ressourcenseite nennt den 3. August, das PDF den 4. August, und auf dem Deckblatt steht noch der Platzhalter "Publication date to be set". Auch Sicherheitsprojekte haben Lieferdruck.

Wer die Liste von 2025 kennt, findet keinen einzigen völlig neuen Eintrag und keinen gestrichenen. Interessant ist die Reihenfolge. Sie hat sich nach Aussage der Autoren stärker bewegt als in früheren Jahren, und die Begründung dafür ist lesenswerter als die Liste selbst.

Die Liste 2025 und 2026 nebeneinander

Die linke Spalte stammt aus der Übersichtsseite der 2025er Ausgabe (veröffentlicht im November 2024), die rechte aus dem Inhaltsverzeichnis des 2026er PDFs.

Eine praktische Folge vorweg: Die Kennungen sind nicht stabil. LLM06 bedeutete bisher Excessive Agency und bedeutet jetzt Unbounded Consumption. Wer in Risikoregister, Pentest-Berichten oder Tickets nur "LLM06" notiert hat, ohne Jahreszahl, hat ab sofort mehrdeutige Einträge.

Wie die Rangfolge entstanden ist

Die Abstimmung der Community zählt zu drei Vierteln, die Vorfallsdaten zu einem Viertel. Die Autoren begründen das offen: Die Liste sei ein Konsensprodukt, und ein einzelnes, verrauschtes Datenjahr solle das Urteil der Praktiker nicht überstimmen. Ein Viertel reiche aber, um einen Eintrag zu verschieben, wenn Überzeugung und Befund weit auseinanderliegen.

Ich halte diese Gewichtung für vertretbar und die Transparenz darüber für den eigentlichen Fortschritt. Der Korpus stammt laut Vorwort aus öffentlichen Schwachstellendatenbanken und einer Datenbank für KI-Schäden, sortiert haben ihn Klassifikatoren. Was nie gemeldet wurde, kommt darin nicht vor. Das muss man beim Lesen der Rangfolge im Kopf behalten.

Was die Verschiebungen über reale Vorfälle sagen

Prompt Injection bleibt vorn, obwohl die Daten etwas anderes zeigen

Das ist die überraschendste Stelle im Vorwort. Sortiert man die Kategorien nur nach der Vorfallsstatistik, fällt Prompt Injection vollständig aus den Top 10. OWASP erklärt das als Verteidigungseffekt: Teams bekämpfen Injection mit viel Aufwand, deshalb landen weniger saubere Exploits in öffentlichen Datenbanken. Die Angriffsfläche existiert weiterhin überall, wo ein Modell nicht vertrauenswürdige Eingaben liest. Also überall.

Ich teile die Entscheidung, den Eintrag auf Platz eins zu lassen. Wer aus der Statistik ableitet, das Thema sei erledigt, verwechselt fehlende Meldungen mit fehlenden Angriffen. Neu im Eintrag sind modalitätsübergreifende Angriffe, also Anweisungen, die in einem Bild oder einer Tonspur versteckt sind. Warum sich das Problem nicht wegpatchen lässt, steht in meinem Artikel zu Prompt Injection. Daran ändert die neue Ausgabe nichts.

Excessive Agency steigt auf Platz drei

Die Autoren nennen das die folgenreichste Bewegung der Liste. Hier sind sich Abstimmung und Vorfallsdaten einig: Der Schaden entsteht dort, wo Modelle handeln dürfen. Der Eintrag zu Prompt Injection formuliert den Zusammenhang deutlich. Die meisten schweren Injection-Vorfälle seien schwer geworden, weil die Injection in einem System landete, dessen Tools und Berechtigungen das kompromittierte Modell im Namen des Angreifers handeln ließen. Die Ursachen benennt OWASP unverändert: zu viel Funktionalität, zu viele Berechtigungen, zu viel Autonomie.

Für die Praxis heißt das: Der Entwickler, der dem Agenten einen Dokumenten-Connector gibt, weil er Lesezugriff braucht, und dabei Schreiben und Löschen mitliefert, erzeugt jetzt ein Risiko auf Platz drei. Dieses Beispiel steht sinngemäß so im OWASP-Text. Wie man Berechtigungen von Agenten und ihren technischen Identitäten klein hält, habe ich im Artikel zu Non-Human Identities beschrieben.

Misinformation ist der Eintrag, den die Praktiker unterschätzen

Die Abstimmenden setzten Misinformation fast ans Ende. Die Vorfallsdaten setzten es fast an die Spitze. Das Vorwort nennt das die größte Lücke in der Richtung, die wehtut: niedrig eingeschätzt, häufig eingetreten. Im Ergebnis steht der Eintrag auf Platz sieben.

Die Begründung überzeugt mich. Solange eine falsche Antwort nur auf einem Bildschirm steht, ist sie ein Qualitätsproblem. Sobald die flüssig formulierte, selbstsichere Ausgabe eine Entscheidung oder einen Tool-Aufruf auslöst, wird aus der falschen Antwort eine falsche Handlung. In Projekten sehe ich oft, dass dieses Risiko niemandem gehört. Die Security hält es für ein Fachthema, der Fachbereich für ein Modellthema.

Unbounded Consumption klettert vier Plätze

Hier hat vor allem die Abstimmung getragen. Praktiker gewichten Ressourcen- und Kostenerschöpfung höher als früher. Der Eintrag nennt die Treiber: Reasoning-Modelle mit großen Ausgabebudgets, multimodale Anfragen, Agenten und Tool-Protokolle wie MCP, die eine Anfrage in eine Kaskade nachgelagerter Operationen verwandeln. OWASP schreibt ausdrücklich, klassisches Rate Limiting allein genüge nicht mehr, und fordert tokenbasierte Kostenkontrollen, harte Ausgabenobergrenzen und Schutzschalter auf Agentenebene. Wer schon einmal eine Cloud-Rechnung nach einem Wochenende mit Endlosschleife erklärt hat, wird zustimmen.

Aus System Prompt Leakage wird Hidden Context Exposure

Der neue Name erweitert den Blick vom System Prompt auf alles, was die Anwendung unsichtbar in den Kontext legt: Entwickleranweisungen, abgerufene Richtlinientexte, Tool-Schemata. Die Kernaussage ist eine Designregel. Verborgener Kontext ist als auffindbar zu betrachten, Zugangsdaten gehören nicht hinein, und seine Geheimhaltung darf keine Autorisierungsgrenze sein. Der Eintrag liefert dazu eine Schweregradskala von informativ bis kritisch, die sich direkt in Review-Checklisten übernehmen lässt.

Improper Output Handling fällt auf Platz zehn

Der größte Abstieg der Liste, von fünf auf zehn. Gleichzeitig wurde der Eintrag breiter: Er umfasst jetzt auch unsicheren Code, den Assistenten in großer Menge erzeugen. Ich würde aus dem Abstieg nicht ableiten, dass Ausgabevalidierung weniger wichtig ist. Rang zehn von zehn heißt immer noch Top 10, und ein LLM, dessen SQL ungeprüft ausgeführt wird, bleibt ein klassischer Befund.

Wo die LLM-Liste endet und die Agentic-Liste beginnt

Seit dem 9. Dezember 2025 gibt es die OWASP Top 10 for Agentic Applications mit den Kennungen ASI01 bis ASI10. Die neue LLM-Liste zieht die Grenze so: Sie ist zuständig, solange das Modell eine Komponente in Ihrer Anwendung ist. Wird das Modell zum Akteur, mit Tools, die es aufruft, mit Gedächtnis über Sitzungen hinweg und mit Folgen in nachgelagerten Systemen, wandert das Risiko in die Agentic-Liste. Viele der ausgewerteten Vorfälle lagen laut Vorwort genau auf dieser Grenze, und keine der beiden Listen deckt sie allein ab.

Hilfreich ist Anhang A des PDFs. Er ordnet jeden der zehn Einträge neun anderen Rahmenwerken zu, darunter MITRE ATLAS, CWE, NIST AI RMF und die Agentic-Liste. Excessive Agency zeigt sich dort in agentischen Systemen als ASI02 (Tool Misuse & Exploitation), ASI03 (Identity & Privilege Abuse) und ASI08 (Cascading Failures). Prompt Injection verweist unter anderem auf ASI01 (Agent Goal Hijack) und ASI06 (Memory & Context Poisoning). Wer Agenten produktiv betreibt, sollte beide Listen nebeneinander legen.

So gleichen Sie Register, Controls und Schulungen ab

Das Vorgehen unten passt in ein bis zwei Wochen Kalenderzeit, wenn ein Risikoregister für KI-Systeme bereits existiert. Wenn nicht, beginnen Sie mit Inventar und Bewertung, wie im KI Security Framework und in der Methodik zur Risikobewertung beschrieben.

1. Kennungen bereinigen. Suchen Sie in Register, Pentest-Berichten, Ticketsystem und Richtlinien nach "LLM0" und "LLM10". Ergänzen Sie überall die Jahreszahl oder ersetzen Sie die Nummer durch den Namen des Risikos. Das ist stumpfe Arbeit von wenigen Stunden und verhindert Missverständnisse im nächsten Audit.

2. Erweiterte Einträge gegen das Register prüfen. Vier Einträge haben neuen Inhalt bekommen: Injection über Bild und Audio, Modellartefakte, die nicht sind, was sie vorgeben (Supply Chain), unterwandertes Fine-Tuning (Poisoning) und generierter unsicherer Code (Output Handling). Dazu kommt der breitere Zuschnitt von Hidden Context Exposure. Fragen Sie für jedes System, ob das Szenario zutrifft und ob es im Register vorkommt.

3. Controls für die Aufsteiger belegen lassen. Für jedes System mit Tool-Zugriff: Welche Funktionen und Berechtigungen hat der Agent, welche braucht er, wo bestätigt ein Mensch? Für jedes System mit nutzungsabhängigen Kosten: Gibt es eine harte Ausgabenobergrenze und eine Kostenzuordnung pro Anwendung? Für jedes System, dessen Ausgabe Entscheidungen oder Aktionen auslöst: Wer prüft die Ausgabe, und wem gehört das Risiko Misinformation namentlich?

4. Schulungen der Security Champions aktualisieren. In meinem Vorschlag für ein Security-Champion-Programm sind die LLM-Risiken ein Baustein im dritten Monat. Dieser Baustein braucht jetzt die 2026er Reihenfolge, das Vorwort als Pflichtlektüre (vier Seiten) und eine Übung zu Excessive Agency anhand eines echten Agenten aus dem eigenen Haus. Champions, die bereits geschult sind, bekommen ein Update von einer Stunde.

5. Agenten gesondert behandeln. Markieren Sie im Inventar jedes System, in dem das Modell als Akteur auftritt, und bewerten Sie es zusätzlich gegen ASI01 bis ASI10. Das ist der aufwendigste Schritt, weil er meist ein eigenes Threat Modeling pro Agent bedeutet.

Was eine Top-10-Liste nicht leistet

Sie ist ein Instrument für Aufmerksamkeit und gemeinsame Sprache. Eine Risikobewertung Ihres Unternehmens ersetzt sie nicht. Die Rangfolge spiegelt zu 75 Prozent eine Abstimmung und zu 25 Prozent öffentlich gemeldete Vorfälle, und beides sagt wenig darüber, ob bei Ihnen der interne Chatbot oder der Agent mit Schreibzugriff auf das ERP das größere Problem ist. Für einen Anbieter ohne Agenten kann Platz drei irrelevant sein und Platz neun existenziell.

Die Liste ist auch kein Standard, gegen den man zertifiziert, und kein Nachweis gegenüber einer Aufsicht. OWASP selbst weist im Dokument darauf hin, dass es keine Rechtsberatung darstellt. Und sie deckt bewusst nicht alles ab. Agenten, Datensicherheit und klassische Anwendungssicherheit haben eigene Dokumente, auf die der Anhang verweist.

Meine Grenze beim Schreiben dieses Artikels: Ich habe das Vorwort, die Einträge und den Anhang gelesen, den Vorfallskorpus selbst aber nicht geprüft. Die Methodik kenne ich nur so weit, wie das PDF sie beschreibt.

Was CISO und CTO entscheiden müssen

Erstens, ob Agenten eine eigene Risikoklasse bekommen. Ich würde das tun. Der Aufstieg von Excessive Agency und die Existenz der Agentic-Liste zeigen, dass die Community diese Trennung bereits vollzogen hat. Praktisch bedeutet das: eigenes Freigabeverfahren für jedes System mit Tool-Zugriff, Aufwand je nach Anzahl der Agenten im Bereich von Tagen pro System.

Zweitens, wem Misinformation gehört. Das ist eine Organisationsentscheidung, keine technische, und sie kostet eine Sitzung. Ohne Eigentümer wird das Risiko in keinem Register sauber bewertet.

Drittens, ob es harte Ausgabenobergrenzen für LLM-Nutzung gibt. Technisch ist das bei den meisten Anbietern schnell eingerichtet. Die eigentliche Entscheidung ist, welche Anwendung bei Erreichen der Grenze stehen bleiben darf und welche nicht.

Viertens, mit niedrigerer Priorität: ob Ihre Lieferanten und Pentest-Dienstleister ab einem Stichtag gegen die 2026er Ausgabe berichten sollen. Ein Satz im nächsten Auftrag genügt.

Der Schritt für diese Woche

Lassen Sie jemanden im Risikoregister und im Ticketsystem nach "LLM06" suchen. Jeder Treffer ohne Jahreszahl meint entweder einen Agenten mit zu vielen Rechten oder eine Kostenfalle, und im Moment weiß niemand sicher, welches von beiden. Wenn Sie das bereinigt haben, lesen Sie die vier Seiten Vorwort des PDFs. Danach wissen Sie, welche der fünf Schritte oben bei Ihnen zuerst drankommen.

Weiterführend

• Prompt Injection, warum Platz eins sich nicht patchen lässt
• LLM Security für C-Level, die Risikokategorien für die Geschäftsführung
• KI Security Framework, Inventar, Bewertung und Controls in vier Stufen
• OWASP Security Champion, das Schulungsprogramm, in das die neue Liste gehört

Quellen

• OWASP GenAI Security Project, "OWASP GenAI LLM Top 10 2026" (Ressourcenseite mit PDF "OWASP Top 10 for LLM Applications 2026", Version 2026), 3./4. August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
• OWASP GenAI Security Project, "OWASP Top 10 for LLM Applications 2025" (Übersicht der Einträge LLM01:2025 bis LLM10:2025), November 2024, https://genai.owasp.org/llm-top-10/
• OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications for 2026", 9. Dezember 2025, https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/