OWASP Top 10 LLM 2026: Von der Risikoliste zum Prüfnachweis

Die OWASP Top 10 LLM liegen seit dem 3. August 2026 in einer neuen Ausgabe vor, und noch nie hat sich die Reihenfolge so stark verändert wie diesmal. Excessive Agency (übermäßige Handlungsmacht) steht jetzt auf Platz drei, aus System Prompt Leakage wurde Hidden Context Exposure, und erstmals wurde die Rangfolge an 7.714 realen Vorfällen gemessen. Die meisten Erklärtexte geben die zehn Einträge bloß wieder. Dieser Leitfaden liest die Liste so, wie es ein Auditor oder eine Marktüberwachungsbehörde tun würde: Was hat sich verschoben, wie kam die Rangfolge zustande, welche EU-Pflichten berührt jeder Eintrag, und welche Aufzeichnungen belegen, dass Sie sich damit befasst haben?

Auf einen Blick

• Die Ausgabe 2026 der OWASP Top 10 LLM erschien am 3. August 2026. Acht von zehn Einträgen haben den Rang gewechselt, nur Prompt Injection und Sensitive Information Disclosure blieben an ihrem Platz.
• Die Rangfolge beruht zu 75 Prozent auf einer Abstimmung unter Praktikern und zu 25 Prozent auf Vorfallsdaten. Der Rang ist ein Konsenssignal, kein Risikowert für Ihr System.
• Anhang A ordnet die OWASP Top 10 LLM neun Sicherheitsrahmenwerken zu. Die KI-Verordnung und ISO/IEC 42001 gehören nicht dazu.
• Artikel 15 Absatz 5 der KI-Verordnung nennt Datenvergiftung, Modellvergiftung, feindliche Beispiele, Angriffe auf die Vertraulichkeit und Modellmängel. Alle fünf finden sich in der Liste wieder.
• Die Liste ist freiwillig. Der Nachweis ist es nicht, sobald KI-Verordnung, Cyberresilienz-Verordnung (CRA), DSGVO, NIS-2 oder DORA greifen.

Was sind die OWASP Top 10 LLM?

Die OWASP Top 10 LLM, mit vollem Titel OWASP Top 10 for LLM Applications, sind ein von der Community verfasstes Awareness-Dokument. Es benennt die zehn kritischsten Sicherheitsrisiken von Anwendungen, die auf großen Sprachmodellen aufbauen. Gepflegt wird es vom OWASP GenAI Security Project, einem Projekt jener Stiftung, deren Top 10 für Webanwendungen es seit 2003 gibt. Den größeren Rahmen zeigt unser Überblick zur KI-Sicherheit. Vier Ausgaben gibt es bisher: Version 1.0 vom 1. August 2023, Version 1.1 vom 16. Oktober 2023, die Ausgabe 2025 vom 18. November 2024 und die Ausgabe 2026 vom 3. August 2026. Das aktuelle Dokument umfasst 122 Seiten und steht unter der Lizenz CC BY-SA 4.0. Jeder Eintrag folgt demselben Aufbau: Beschreibung, typische Beispiele, Strategien zur Vorbeugung und Minderung, Angriffsszenarien. Nach unserer Zählung kommen die zehn Einträge der OWASP Top 10 LLM zusammen auf 96 nummerierte Minderungsstrategien, von 3 bei Hidden Context Exposure (Offenlegung verborgenen Kontexts) bis 19 bei Sensitive Information Disclosure. Die Grundhaltung steht schon im Vorwort der Projektleitung. Sinngemäß heißt es dort: Hören Sie auf, ein Modell bauen zu wollen, das sich nicht täuschen lässt. Bauen Sie stattdessen das System um das Modell herum so, dass ein getäuschtes Modell nichts Wichtiges beschädigt. Das ist eine Aussage über Architektur, und sie hat Folgen für die Governance: Der Kontrollpunkt wandert vom Modellanbieter zu dem Team, das die Anwendung einsetzt.

Ein Awareness-Dokument, kein Kontrollstandard

Gegen die OWASP Top 10 LLM lässt sich niemand zertifizieren. Das Dokument enthält keine verbindlichen Anforderungen, kennt kein Konformitätsverfahren und keine akkreditierten Prüfer. Der Wert liegt im gemeinsamen Vokabular: priorisierte Namen für das, was schiefgeht, samt Vorschlägen zur Abwehr. Entwickler, Penetrationstester, Hersteller und Auditoren verwenden diese Namen bereits. Ein Befund mit der Kennung LLM03 liest sich im Bericht eines KI-Red-Teamings genauso wie im Lieferantenfragebogen oder in der Vorlage für den Vorstand. Der Geltungsbereich ist zudem enger, als der Titel vermuten lässt. Die OWASP Top 10 LLM behandeln das Modell als Komponente innerhalb Ihrer Anwendung. Wird das Modell zum Akteur, mit Werkzeugen, die es aufruft, einem Gedächtnis über Sitzungen hinweg und Wirkungen in nachgelagerten Systemen, übergibt OWASP an die Top 10 for Agentic Applications, angekündigt am 9. Dezember 2025.

Die OWASP Top 10 LLM 2026: Was sich verschoben hat

Welche Angriffsfamilien hinter den Einträgen der folgenden Tabelle stehen, beschreibt unser Beitrag zu adversarialen KI-Angriffen. <table header-row=“true“> <tr> <td>Kennung 2026</td> <td>Eintrag</td> <td>Rang 2025</td> <td>Was sich geändert hat</td> </tr> <tr> <td>LLM01</td> <td>Prompt Injection</td> <td>1</td> <td>Bleibt auf Platz eins. Neu erfasst: modalitätsübergreifende Angriffe, versteckt in Bild, Audio oder Video, sowie Injektionen, die im Gedächtnis oder im Retrieval-Korpus (RAG) fortbestehen</td> </tr> <tr> <td>LLM02</td> <td>Sensitive Information Disclosure</td> <td>2</td> <td>Bleibt auf Platz zwei. Als Abflusswege gelten nun auch Argumente von Werkzeugaufrufen, Reasoning-Spuren, Logs, Embeddings und Zeit-Seitenkanäle</td> </tr> <tr> <td>LLM03</td> <td>Excessive Agency</td> <td>6</td> <td>Drei Plätze nach oben. Ursachen unverändert: zu viel Funktionalität, zu weite Berechtigungen, zu viel Autonomie</td> </tr> <tr> <td>LLM04</td> <td>Supply Chain</td> <td>3</td> <td>Ein Platz nach unten. Erfasst jetzt auch in den Betrieb übernommene Modellartefakte, die nicht sind, was sie vorgeben, dazu Adapter und Konvertierungspipelines</td> </tr> <tr> <td>LLM05</td> <td>Data and Model Poisoning</td> <td>4</td> <td>Ein Platz nach unten. Nimmt die Unterwanderung des Fine-Tunings und die Vergiftung über die Retrieval-Ingestion auf</td> </tr> <tr> <td>LLM06</td> <td>Unbounded Consumption</td> <td>10</td> <td>Vier Plätze nach oben. Neu gefasst rund um die Kostenasymmetrie: Reasoning-Modelle, multimodale Eingaben, Agentenschleifen</td> </tr> <tr> <td>LLM07</td> <td>Misinformation</td> <td>9</td> <td>Zwei Plätze nach oben, getragen von den Vorfallsdaten</td> </tr> <tr> <td>LLM08</td> <td>Hidden Context Exposure</td> <td>7</td> <td>Umbenannt (zuvor System Prompt Leakage) und erweitert auf abgerufene Richtlinientexte, Werkzeugschemata und jeden verborgenen Kontext</td> </tr> <tr> <td>LLM09</td> <td>Vector and Embedding Weaknesses</td> <td>8</td> <td>Ein Platz nach unten. Schließt nun vektorbasierte Agentengedächtnisse und semantische Caches ein</td> </tr> <tr> <td>LLM10</td> <td>Improper Output Handling</td> <td>5</td> <td>Fünf Plätze nach unten, der größte Abstieg. Neu: Terminal-Steuerzeichen, automatisch nachladende Renderer, unsicherer generierter Code</td> </tr> </table> Aus den OWASP Top 10 LLM 2026 folgen drei Schlüsse. Der Schaden entsteht dort, wo das Modell handeln darf. OWASP selbst wertet den Aufstieg von Excessive Agency als die folgenreichste Verschiebung der Liste, weil Abstimmung und Vorfallsdaten hier übereinstimmen. Ein Assistent, der nur antwortet, kann in die Irre führen. Ein Assistent, der E-Mails versendet, in eine Datenbank schreibt oder eine Gutschrift auslöst, setzt eine manipulierte Anweisung in die Tat um. Die drei Ursachen des Eintrags taugen als Prüfliste für jedes Review: Hat die Anwendung Werkzeuge, die sie nicht braucht? Reichen die Berechtigungen weiter als die Aufgabe? Darf sie ohne Freigabe handeln? Die Kennungen haben ihre Bedeutung gewechselt. Neue Risiken wurden in bestehende Einträge eingearbeitet, statt dünne neue Kategorien zu schaffen. Die zehn Namen sind deshalb weitgehend vertraut, die Nummern sind es nicht. LLM03 stand 2025 für Supply Chain und steht 2026 für Excessive Agency. LLM06 war Excessive Agency und ist jetzt Unbounded Consumption. Jedes Risikoregister, jeder Testplan und jeder Lieferantenfragebogen, der eine nackte Kennung zitiert, ist damit mehrdeutig. Schreiben Sie das Jahr immer mit (LLM03:2026) und schlüsseln Sie ältere Unterlagen um. Verborgener Kontext gilt als auffindbar. Der umbenannte Eintrag LLM08 verlangt, so zu entwerfen, als ließen sich Systemprompt, abgerufene Richtlinientexte und Werkzeugschemata auslesen. Das heißt: keine Zugangsdaten im Prompt, und verborgene Anweisungen sind nie die einzige Berechtigungsprüfung. Daraus folgt eine einfache Testfrage: Wenn morgen das gesamte Kontextfenster nach außen gelangte, was hätte ein Angreifer davon?

Wie die Rangfolge 2026 entstand: eine Abstimmung, an Vorfällen gemessen

Alle früheren Ausgaben der OWASP Top 10 LLM beruhten allein auf dem Urteil von Praktikern. Für 2026 trug das Projektteam 7.714 Vorfälle aus öffentlichen Schwachstellendatenbanken und einer Datenbank für KI-Schäden zusammen, baute Klassifikatoren, um sie auszuwerten, und ordnete 6.639 davon ein. In die endgültige Reihenfolge geht die Abstimmung der Community mit drei Vierteln ein, die Vorfallsdaten mit einem Viertel. Aufschlussreich ist, wo beide Quellen auseinanderliegen:

• Prompt Injection. Nach der Abstimmung Platz eins. Nach den rohen Vorfallsdaten allein fiele der Eintrag aus den ersten zehn heraus. OWASP liest das als Abwehreffekt: Teams bekämpfen Injektionen mit Nachdruck, also landen weniger saubere Exploits in einer öffentlichen Datenbank. Real bleibt die Gefahr trotzdem, wie CVE-2025-32711 zeigt, eine Zero-Click-Schwachstelle in einem produktiv eingesetzten Assistenten.
• Misinformation. In der Abstimmung weit unten, in den Vorfallsdaten weit oben, der größte Abstand der gesamten Liste. Am Ende steht Platz sieben.
• Sensitive Information Disclosure. Die einzige Stelle an der Spitze, an der Überzeugung und Evidenz zusammenfallen.

Für ein Risikoregister zählen drei Konsequenzen mehr als die Rangfolge selbst.

1. Der Rang sagt nichts über die Schwere in Ihrem System. Ein Kundenassistent ohne Werkzeuge ist LLM03 kaum ausgesetzt, ein interner Agent mit Schreibrechten sehr wohl. Bewerten Sie jeden Eintrag gegen Ihre eigene Architektur.
2. Öffentliche Vorfallszahlen unterschätzen gut verteidigte Risiken. Die Cloud Security Alliance hält in ihrer Research Note vom 15. August 2026 fest, dass das Ausbleiben von Vorfällen kein Beleg für das Ausbleiben von Risiko ist.
3. Misinformation ist jetzt ein Sicherheitseintrag und nicht mehr nur eine Qualitätsfrage. Löst eine flüssig formulierte, aber falsche Antwort einen Werkzeugaufruf aus, wird aus der falschen Antwort eine falsche Handlung. Damit reichen die OWASP Top 10 LLM bis in die Genauigkeitspflichten hinein, und in das Thema, das unser Beitrag über Halluzinationen als größtes Risiko generativer KI behandelt.

Was die OWASP Top 10 LLM nicht abbilden: KI-Verordnung und ISO/IEC 42001

Anhang A der OWASP Top 10 LLM bündelt die Zuordnungen zu neun externen Rahmenwerken, jeweils auf eine bestimmte Version festgelegt: OWASP Top 10 for Agentic Applications, OWASP GenAI Data Security 2026, MITRE ATLAS, MITRE ATT&CK, CWE, NIST AI 600-1, das NIST AI RMF, die CSA AI Controls Matrix und das OWASP AI Vulnerability Scoring System. Alle neun sind Sicherheits- oder Risikotaxonomien. Weder die KI-Verordnung noch ISO/IEC 42001 sind darunter. Die KI-Verordnung wird auf 122 Seiten dreimal erwähnt, jedes Mal im Umfeld von LLM02. Eine dieser Stellen datiert die Hochrisiko-Pflichten noch auf August 2026, ein Datum, das der Digitale Omnibus, Verordnung (EU) 2026/1744, für Systeme nach Anhang III auf den 2. Dezember 2027 verschoben hat. Einem Sicherheitsdokument ist das nicht vorzuwerfen. Eine Lücke ist es für alle, die einer Behörde zeigen müssen, wie ihre Sicherheitsarbeit eine Rechtspflicht erfüllt. Die Brücke ist allerdings kürzer, als sie aussieht. Artikel 15 Absatz 5 der KI-Verordnung verlangt, dass Hochrisiko-KI-Systeme widerstandsfähig sind gegen Versuche unbefugter Dritter, ihre Verwendung, ihre Ausgaben oder ihre Leistung zu verändern. Der Absatz zählt die KI-spezifischen Schwachstellen auf: Datenvergiftung (data poisoning), Modellvergiftung (model poisoning), feindliche Beispiele oder Modellumgehung (adversarial examples, model evasion), Angriffe auf die Vertraulichkeit und Modellmängel. Jede davon hat ihren Platz in den OWASP Top 10 LLM. Die folgende Gegenüberstellung ist unsere Lesart, keine Zuordnung von OWASP oder der Kommission. <table header-row=“true“> <tr> <td>Eintrag</td> <td>Anknüpfung in der KI-Verordnung</td> <td>Nachweise, nach denen ein Auditor fragt</td> </tr> <tr> <td>LLM01 Prompt Injection</td> <td>Art. 15 Abs. 5 (feindliche Eingaben); Art. 55 Abs. 1 Buchst. a (Angriffstests)</td> <td>Testbericht je Release gegen Angreifer, die die Abwehr kennen; Verzeichnis der nicht vertrauenswürdigen Eingabekanäle</td> </tr> <tr> <td>LLM02 Sensitive Information Disclosure</td> <td>Art. 15 Abs. 5 (Angriffe auf die Vertraulichkeit); Art. 10; Art. 32 DSGVO</td> <td>Datenklassifizierung jeder Kontextquelle; Ergebnisse der Schwärzungstests; Ablaufplan für Offenlegungsvorfälle</td> </tr> <tr> <td>LLM03 Excessive Agency</td> <td>Art. 14 (menschliche Aufsicht); Art. 26 (Betreiberpflichten)</td> <td>Werkzeug- und Berechtigungsregister je Anwendung; Freigaberegel für Aktionen mit hoher Tragweite; Protokolle der Werkzeugaufrufe</td> </tr> <tr> <td>LLM04 Supply Chain</td> <td>Art. 25 (Wertschöpfungskette); Art. 15 Abs. 5 (vortrainierte Komponenten)</td> <td>Herkunftsnachweise für Modelle und Datensätze; signiertes Komponentenverzeichnis; Lieferantenbewertungen</td> </tr> <tr> <td>LLM05 Data and Model Poisoning</td> <td>Art. 10 (Daten-Governance); Art. 15 Abs. 5 (Daten- und Modellvergiftung)</td> <td>Datenherkunft (Lineage); Validierung von Fine-Tuning und Retrieval-Ingestion; Freigabe von Nachtrainings</td> </tr> <tr> <td>LLM06 Unbounded Consumption</td> <td>Art. 15 Abs. 4 (Widerstandsfähigkeit gegenüber Fehlern und Störungen)</td> <td>Ausgabenobergrenzen; Ratenbegrenzungen; Testergebnisse der Schutzschalter (Circuit Breaker); Kostenalarme</td> </tr> <tr> <td>LLM07 Misinformation</td> <td>Art. 15 Abs. 1 und 3 (angegebene Genauigkeit); Art. 14 Abs. 4 Buchst. b (Automatisierungsbias)</td> <td>Kennzahlen zu Genauigkeit und Quellentreue (Groundedness); Evaluierungsergebnisse; Nutzerhinweise gegen übermäßiges Vertrauen</td> </tr> <tr> <td>LLM08 Hidden Context Exposure</td> <td>Art. 15 Abs. 5 (Angriffe auf die Vertraulichkeit)</td> <td>Secrets-Scan von Prompts und Werkzeugschemata; Nachweis, dass die Autorisierung außerhalb des Modells durchgesetzt wird</td> </tr> <tr> <td>LLM09 Vector and Embedding Weaknesses</td> <td>Art. 10; Art. 15 Abs. 5; Art. 32 DSGVO</td> <td>Tests der Mandantentrennung beim Retrieval; Herkunftsprotokoll der Ingestion; Löschverfahren für Embeddings</td> </tr> <tr> <td>LLM10 Improper Output Handling</td> <td>Art. 15 Abs. 5 (Modellmängel); Anhang I der Cyberresilienz-Verordnung</td> <td>Tests der Ausgabekodierung; Verzeichnis der nachgelagerten Senken; Aufzeichnungen zur sicheren Entwicklung</td> </tr> </table> Bei ISO/IEC 42001 landen dieselben Artefakte im Managementsystem, und zwar in den Maßnahmenbereichen des Anhangs A: Lebenszyklus des KI-Systems (Verifizierung und Validierung, Betrieb und Überwachung, Ereignisprotokolle), Daten für KI-Systeme (Qualität, Herkunft), Beziehungen zu Dritten und Kunden sowie Nutzung von KI-Systemen. Ein Zertifizierungsauditor fragt nicht, ob Sie „OWASP-konform“ sind. Er fragt, wie Sie KI-Sicherheitsrisiken ermittelt und was Sie für jedes einzelne entschieden haben. Ein Entscheidungsprotokoll je Eintrag beantwortet genau diese Frage.

Welches Recht diese Nachweise einforderbar macht

Die OWASP Top 10 LLM sind freiwillig. Was sie beschreiben, ist es nicht mehr, sobald eine der folgenden Regelungen für Sie gilt.

• KI-Verordnung, Artikel 15. Er bindet Hochrisiko-KI-Systeme. Nach dem Digitalen Omnibus müssen Systeme nach Anhang III die Anforderungen ab dem 2. Dezember 2027 erfüllen, Produkte nach Anhang I ab dem 2. August 2028. Am Anfang steht die Frage, ob Ihr System überhaupt als Hochrisiko-KI-System einzustufen ist.
• KI-Verordnung, Artikel 55. Anbieter von KI-Modellen mit allgemeinem Verwendungszweck mit systemischem Risiko müssen Angriffstests durchführen und dokumentieren und ein angemessenes Maß an Cybersicherheit für das Modell und seine physische Infrastruktur gewährleisten (Artikel 55). Diese Pflichten gelten seit dem 2. August 2025, die Durchsetzungsbefugnisse der Kommission seit dem 2. August 2026.
• Cyberresilienz-Verordnung (CRA). Die Verordnung (EU) 2024/2847 erfasst Produkte mit digitalen Elementen, und dazu zählt der Großteil kommerzieller Software, die ein Sprachmodell einbettet. Seit dem 11. September 2026 melden Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die einheitliche Meldeplattform an das koordinierende CSIRT und an die ENISA: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden (Überblick von Jones Day). Die grundlegenden Anforderungen gelten vollständig ab dem 11. Dezember 2027. Nach Artikel 12 derselben Verordnung gilt bei einem Hochrisiko-KI-System, das diese Anforderungen erfüllt, die Cybersicherheitsanforderung des Artikels 15 der KI-Verordnung als erfüllt.
• DSGVO, Artikel 32. Die Sicherheit der Verarbeitung betrifft jede Anwendung, die personenbezogene Daten berührt, unabhängig von der Risikoklasse nach der KI-Verordnung. LLM02 und LLM09 beschreiben Verletzungen des Schutzes personenbezogener Daten, bevor sie eintreten.
• NIS-2 und DORA. Wesentliche und wichtige Einrichtungen sowie Finanzunternehmen schulden für ihre IKT-Systeme bereits Risikomanagementmaßnahmen und Vorfallsmeldungen. Eine Sprachmodellanwendung ist eines dieser Systeme. DORA gilt seit dem 17. Januar 2025.

Zwei Termine gehören in den Projektplan: der 2. Dezember 2027 für die Hochrisiko-Pflichten nach Anhang III und der 11. Dezember 2027 für die volle Anwendung der Cyberresilienz-Verordnung. Dazwischen liegen neun Tage. Wer eine einzige Sicherheitsakte führt, gegliedert nach den Einträgen der OWASP Top 10 LLM und mit Querverweisen auf beide Verordnungen, bereitet sich auf beide zugleich vor. Die harmonisierte Norm zur Cybersicherheit von KI war Mitte 2026 bei CEN-CENELEC noch in Arbeit. Eine anerkannte öffentliche Taxonomie ist deshalb vorerst die am besten vertretbare Struktur für die eigene Analyse. Für Deutschland kommen zwei Bezugspunkte hinzu. Als Marktüberwachungsbehörde nach der KI-Verordnung ist die Bundesnetzagentur benannt. Und das BSI hat im November 2025 die Publikation „Evasion Attacks on LLMs: Countermeasures in Practice“ veröffentlicht. Sie behandelt sichere Systemprompts, das Filtern schädlicher Inhalte, die ausdrückliche Bestätigung durch den Nutzer vor der Ausführung und gestaffelte Abwehrmaßnahmen.

Von den OWASP Top 10 LLM zum Nachweis: eine Methode in sechs Schritten

1. Jede Sprachmodellanwendung inventarisieren. Halten Sie je Anwendung fest: Modell, Kontextquellen, Werkzeuge, Gedächtnisspeicher und nachgelagerte Senken. Ohne dieses Verzeichnis kann niemand sagen, welche Einträge überhaupt einschlägig sind. Ein Register wie das AI Registry von AI Sigil führt diese Angaben je System.
2. Anwendbarkeit Eintrag für Eintrag entscheiden. Notieren Sie für jeden Eintrag der OWASP Top 10 LLM „trifft zu“ oder „trifft nicht zu“, Letzteres mit Begründung. OWASP weist selbst darauf hin, dass ein Retrieval-System ohne Vektoren keine Angriffsfläche für LLM09 bietet. Eine dokumentierte Ablehnung ist ein Nachweis. Schweigen ist eine Lücke.
3. Maßnahmen auswählen und einen Verantwortlichen benennen. Wählen Sie aus den 96 Strategien der OWASP Top 10 LLM, ordnen Sie jede einer Kontrolle zu, die Sie bereits betreiben, und benennen Sie das Artefakt, das die Umsetzung belegt.
4. Vor dem Release und nach jeder Änderung testen. Eine neue Modellversion, ein geänderter Systemprompt, ein zusätzliches Werkzeug oder ein neuer Retrieval-Korpus öffnen LLM01, LLM03 und LLM08 erneut. OWASP verlangt Tests gegen adaptive Angreifer, die die eingesetzte Abwehr gelesen haben, keine statische Testsuite. Wie sich solche Prüfungen aufsetzen lassen, beschreibt unser Leitfaden zum KI-Red-Teaming.
5. Die Lieferkette in den Vertrag schreiben. LLM04 und LLM05 lassen sich durch Tests allein nicht schließen. Herkunftsnachweis, Signierung, Schwachstellenmeldung und Änderungsanzeige gehören in die Lieferanten-Due-Diligence und in die Vereinbarung selbst.
6. Schwellen und Fristen für Vorfälle vorab festlegen. Entscheiden Sie im Voraus, was als schwerwiegender Vorfall nach Artikel 73 der KI-Verordnung gilt, was als aktiv ausgenutzte Schwachstelle nach der Cyberresilienz-Verordnung und was als Verletzung des Schutzes personenbezogener Daten nach der DSGVO, und wer binnen 24 oder 72 Stunden meldet. Die Meldewege fasst unser Beitrag zur KI-Vorfallmeldung zusammen.

Jeder Schritt hinterlässt eine Aufzeichnung. Zusammen ergeben sie, was Sicherheitsteams als Erklärung zur Anwendbarkeit kennen, hier für die Risiken von Sprachmodellen: zehn Einträge, je eine Entscheidung, eine Kontrolle, ein Verantwortlicher und ein Testergebnis. Erst diese Akte macht aus den OWASP Top 10 LLM einen Prüfnachweis.

LLM Top 10 oder Agentic Top 10: Welche Liste gilt

OWASP zieht die Grenze nach der Rolle. Ist das Modell eine Komponente, die Text an Ihren Code zurückgibt, gelten die OWASP Top 10 LLM. Ist das Modell ein Akteur, der Werkzeuge aufruft, ein Gedächtnis führt und nachgelagerte Wirkungen auslöst, gelten zusätzlich die OWASP Top 10 for Agentic Applications. Anhang A ordnet jedem LLM-Eintrag seine agentischen Gegenstücke zu. Excessive Agency taucht dort als ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse und ASI08 Cascading Failures auf. Die meisten Unternehmensanwendungen liegen auf der Grenze. Ein Chat-Assistent bekommt einen Konnektor, dann einen zweiten, dann Schreibzugriff, und niemand schneidet die Risikoanalyse neu zu. Zwei Prüfungen helfen.

• Erfassen Sie je Anwendung drei Merkmale: Werkzeuge, persistentes Gedächtnis und die Fähigkeit, ohne Freigabe zu handeln. Ändert sich eines davon, wenden Sie beide Listen an.
• Nutzen Sie die „lethal trifecta“ (tödliche Dreierkombination), die OWASP von Simon Willison übernimmt, als Frage vor der Inbetriebnahme. Ein Agent, der private Daten lesen, nicht vertrauenswürdige Inhalte aufnehmen und nach außen kommunizieren kann, erfüllt die Bedingungen für eine folgenschwere Ausnutzung. Nehmen Sie eines der drei Beine weg, entfallen sie.

Die menschliche Freigabe ist die Kontrolle, auf die OWASP am häufigsten zurückkommt, und zugleich diejenige, der es bei hohem Aufkommen am wenigsten traut: Freigabemüdigkeit trübt das Urteil der Prüfenden. Das ist eine Gestaltungsaufgabe für die menschliche Aufsicht, kein Häkchen auf einer Liste. Das Governance-Modell rund um Agenten beschreiben unser Leitfaden zu autonomen KI-Agenten und der Vergleich agentische KI vs. generative KI. Zu einem ähnlichen Ergebnis kommen die französische ANSSI und das BSI in ihrem gemeinsamen Papier zu Zero-Trust-Designprinzipien für LLM-basierte Systeme.

Häufige Fragen

Was sind die OWASP Top 10 LLM in einfachen Worten? Die OWASP Top 10 LLM sind eine Rangliste der zehn kritischsten Sicherheitsrisiken von Anwendungen, die auf großen Sprachmodellen aufbauen, verfasst vom OWASP GenAI Security Project. Jeder Eintrag erklärt, wie das Versagen zustande kommt, nennt Beispiele und schlägt Abwehrmaßnahmen vor. Das Dokument ist kostenlos und steht unter der Lizenz CC BY-SA 4.0. Sicherheitsteams stecken damit den Umfang ihrer Tests ab, Hersteller beschreiben damit, was ihre Produkte abdecken, und Auditoren greifen zunehmend auf die Namen als Referenzvokabular zurück. Was hat sich 2026 an den OWASP Top 10 LLM geändert? Acht von zehn Einträgen der OWASP Top 10 LLM haben den Rang gewechselt. Excessive Agency stieg von Platz sechs auf drei, Unbounded Consumption von zehn auf sechs und Misinformation von neun auf sieben. Improper Output Handling fiel von fünf auf zehn. System Prompt Leakage heißt jetzt Hidden Context Exposure und reicht weiter als der alte Name. Auch die Methode ist neu: Die Abstimmung unter Praktikern zählt zu 75 Prozent, ein Bestand von 7.714 Vorfällen zu 25 Prozent. Sind die OWASP Top 10 LLM verpflichtend? Nein. Es handelt sich um ein freiwilliges Awareness-Dokument ohne Zertifizierungsverfahren. Die Risiken, die es benennt, fallen aber unter verbindliche Vorschriften: Artikel 15 der KI-Verordnung für Hochrisiko-KI-Systeme, Artikel 55 für KI-Modelle mit allgemeinem Verwendungszweck mit systemischem Risiko, die Cyberresilienz-Verordnung für Produkte mit digitalen Elementen und Artikel 32 DSGVO überall dort, wo personenbezogene Daten verarbeitet werden. Ob Sie Ihre Nachweise nach den OWASP Top 10 LLM gliedern, entscheiden Sie selbst. Ob Sie Nachweise vorlegen können, steht dagegen nicht zur Wahl. Wie verhalten sich die OWASP Top 10 LLM zur KI-Verordnung? Eine Zuordnung zur KI-Verordnung enthalten die OWASP Top 10 LLM nicht. Der nächstliegende Anker ist Artikel 15 Absatz 5, der Datenvergiftung, Modellvergiftung, feindliche Beispiele, Angriffe auf die Vertraulichkeit und Modellmängel aufzählt. Dem entsprechen LLM05, LLM04, LLM01, LLM02 zusammen mit LLM08 und LLM09 sowie LLM10. Excessive Agency knüpft an die menschliche Aufsicht nach Artikel 14 an, Misinformation an die Genauigkeitsgrade, die Anbieter nach Artikel 15 angeben müssen. Ist Prompt Injection noch immer das Risiko Nummer eins? Ja. In den OWASP Top 10 LLM 2026 hält Prompt Injection Platz eins, getragen von der Abstimmung unter Praktikern. Nach den öffentlichen Vorfallsdaten allein fiele der Eintrag aus den ersten zehn heraus. OWASP führt das darauf zurück, dass erfahrene Teams Angriffsversuche eindämmen, bevor sie öffentlich werden. Den Kern trifft das britische NCSC in seinem Beitrag, wonach Prompt Injection keine SQL-Injection ist: Sprachmodelle trennen Anweisungen nicht von Daten. Die Angriffsfläche lässt sich deshalb nicht schließen, nur eindämmen. Worin unterscheiden sich die LLM Top 10 und die Agentic Top 10? Die OWASP Top 10 LLM behandeln das Modell als Komponente innerhalb einer Anwendung. Die Agentic-Liste, angekündigt am 9. Dezember 2025, behandelt das Modell als autonomen Akteur mit Werkzeugen, Gedächtnis und nachgelagerten Wirkungen. Beide Listen sind darauf angelegt, gemeinsam verwendet zu werden, und Anhang A verknüpft die Einträge miteinander. Kann Ihre Anwendung Werkzeuge aufrufen oder handeln, ohne dass ein Mensch jeden Schritt freigibt, lesen Sie beide.

Fazit

Die OWASP Top 10 LLM sind das am weitesten verbreitete Vokabular für die Sicherheit von Sprachmodellen, und die Ausgabe 2026 ist ehrlicher geworden, weil sie Überzeugungen an Vorfallsdaten misst. Ein Sicherheitsdokument bleibt sie dennoch. Sie sagt Ihnen nicht, welches Recht gilt, ab wann, und was eine Behörde sehen will. Dieser Teil liegt bei Ihnen: ein Verzeichnis, eine Entscheidung je Eintrag, eine benannte Kontrolle samt Verantwortlichem, ein Testergebnis nach jeder Änderung und Meldefristen, die vor dem Ernstfall vereinbart sind. Die Termine liegen nah genug, um mit ihnen zu planen. Die Meldepflichten der Cyberresilienz-Verordnung gelten bereits, und der Dezember 2027 bringt sowohl die Hochrisiko-Pflichten als auch die vollständigen Produktanforderungen. AI Sigil verknüpft jede Sprachmodellanwendung im Register mit den einschlägigen Einträgen, den gewählten Kontrollen, den Testergebnissen und den Vorfallsentscheidungen, sodass die Antwort an einen Auditor ein Bericht ist und keine Rekonstruktion.