OWASP Top 10 für LLM-Anwendungen 2026

Die neue Fassung der OWASP Top 10 für LLM-Anwendungen kann für Vertragsverhandlungen und Complianceprojekte zu KI nicht mehr ignoriert werden: Was öffentlich, breit rezipiert und fachlich anerkannt beschreibt, welche Risiken eine Technologie hat, prägt den Maßstab dessen, was ein sorgfältiger Anbieter oder Betreiber kennen und adressieren muss. Wer die dort beschriebenen Angriffsflächen ignoriert, riskiert den Vorwurf systematischer Compliancelücken.

Was sich 2026 gegenüber den Vorjahren geändert hat

Methodisch ist die Liste 2026 belastbarer als ihre Vorgänger. Bislang beruhte die Rangfolge im Wesentlichen auf einer Expertenabstimmung. Für die aktuelle Fassung hat OWASP das Abstimmungsergebnis zusätzlich gegen einen Korpus realer Vorfälle gespiegelt: rund 7.700 dokumentierte Sicherheitsvorfälle, von denen etwa 6.600 klassifiziert werden konnten. Das Ergebnis wurde mit 75 % Community-Votum und 25 % Vorfalldaten gewichtet. Die Liste bildet damit erstmals nicht nur ab, was Fachleute für gefährlich halten, sondern auch, was tatsächlich passiert ist.

Die zehn Einträge lauten: Prompt Injection, Sensitive Information Disclosure, Excessive Agency, Supply Chain, Data and Model Poisoning, Unbounded Consumption, Misinformation, Hidden Context Exposure, Vector and Embedding Weaknesses sowie Improper Output Handling.

Drei Verschiebungen, die rechtlich relevant sind

Erstens ist Excessive Agency – also die zu weit gefasste Handlungsvollmacht eines Modells – auf den dritten Platz vorgerückt. Dahinter steht die Verbreitung von Systemen, die nicht mehr nur Text erzeugen, sondern Werkzeuge aufrufen, Datensätze verändern oder Bestellungen auslösen. Rechtlich verschiebt sich damit die Frage von der Ausgabequalität hin zur Zurechnung: Wer haftet für eine vom System selbständig ausgelöste Transaktion, und welche Kontroll- und Freigabemechanismen waren geschuldet? Für Hochrisiko-Anwendungen trifft das unmittelbar die Anforderungen an die menschliche Aufsicht nach Art. 14 AI Act.

Zweitens ist Unbounded Consumption um vier Plätze gestiegen. Gemeint sind unkontrollierter Ressourcenverbrauch, Denial-of-Service durch aufwendige Anfragen und die schrittweise Extraktion eines Modells über massenhafte Abfragen. Das ist zugleich ein Vertragsthema: Nutzungsbasierte Vergütungsmodelle verlagern das Kostenrisiko eines Missbrauchs auf den Kunden, wenn Verbrauchsobergrenzen, Rate Limits und Verantwortlichkeiten nicht sauber geregelt sind. Die Modellextraktion berührt darüber hinaus den Schutz von Geschäftsgeheimnissen nach dem GeschGehG, der angemessene Geheimhaltungsmaßnahmen voraussetzt.

Drittens wurde System Prompt Leakage zu Hidden Context Exposure umbenannt und deutlich weiter gefasst. Nicht nur der System-Prompt kann nach außen gelangen, sondern alles, was sich im Kontextfenster befindet: eingebundene RAG-Dokumente, Werkzeugdefinitionen, Zwischenergebnisse, Gesprächshistorien anderer Nutzer. Achtung: Genau dieser Punkt wird in der Praxis unterschätzt, weil das Modell keine Rechteprüfung kennt – der Kontext ist für das Modell schlicht Text. Wer Mandanten-, Patienten- oder Personaldaten in den Kontext gibt, muss die Zugriffskontrolle davor implementieren, nicht darin.

Warum ein unverbindliches Dokument rechtliche Wirkung entfaltet

Die OWASP-Liste bindet niemanden unmittelbar. Sie wirkt über Generalklauseln, und davon gibt es im IT-Recht reichlich. Art. 32 DSGVO verlangt technische und organisatorische Maßnahmen unter Berücksichtigung des Stands der Technik. Art. 15 Abs. 5 AI Act verlangt für Hochrisiko-KI-Systeme Widerstandsfähigkeit gegen Versuche unbefugter Dritter, Verwendung, Ausgaben oder Leistung durch Ausnutzung von Systemschwachstellen zu verändern – und nennt ausdrücklich Manipulationen des Trainingsdatensatzes („data poisoning“), Manipulationen vortrainierter Komponenten („model poisoning“) sowie Eingabedaten, die das Modell zu Fehlern verleiten sollen („adversarial examples“ oder „model evasions“). Das ist im Kern dieselbe Bedrohungslandschaft, die OWASP unter LLM01 und LLM05 beschreibt.

Hinzu kommen der Cyber Resilience Act mit seinen Anforderungen an Produkte mit digitalen Elementen, die Risikomanagementpflichten aus NIS2 und DORA sowie die reformierte Produkthaftung, die Software ausdrücklich erfasst und Sicherheitslücken als fehlerbegründend behandeln kann. In allen diesen Regimen ist der geschuldete Sicherheitsstandard nicht abschließend definiert, sondern dynamisch. Öffentlich verfügbare, fachlich anerkannte Risikokataloge füllen diese Lücke.

Bemerkenswert ist eine ausdrückliche Selbstbeschränkung: Sobald das Modell nicht mehr nur Text produziert, sondern als handelnder Akteur mit Werkzeugen, Gedächtnis und Zielvorgaben auftritt, verweist OWASP auf einen eigenen Katalog für agentische Systeme.

Präventive Maßnahmen für Unternehmen

Aus der Liste ein Compliance-Instrument zu machen, ist weniger aufwendig als es klingt. Sinnvoll sind vier Schritte:

• Mapping: Jede eingesetzte LLM-Anwendung gegen die zehn Kategorien abgleichen und dokumentieren, welche Risiken einschlägig sind und welche Maßnahmen greifen.
• Rollenklärung: Festhalten, welche Risiken beim Anbieter des Modells, welche beim Anbieter der Anwendung und welche beim Betreiber liegen. Prompt Injection und Output Handling sind typischerweise Anwendungsrisiken, Data Poisoning ein Modellrisiko.
• Vertragliche Verankerung: Sicherheitsanhänge, Leistungsbeschreibungen und SLAs auf konkrete Kataloge statt auf Leerformeln stützen; Verbrauchsobergrenzen, Rate Limits und Meldepflichten bei Vorfällen ausdrücklich regeln.

Sie haben Fragen? Aitava unterstützt Unternehmen bei der rechtlichen Bewertung von KI-Anwendungen, bei der Gestaltung von KI-Verträgen sowie bei der Einordnung technischer Standards für Compliance mit AI Act, CRA, NIS2, DORA und DSGVO.

Häufig gestellte Fragen (FAQ)