KI- und LLM-Sicherheit

Die OWASP Top 10 für LLM-Anwendungen 2026, praktisch erklärt

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Die OWASP Top 10 für LLM-Anwendungen ist die Referenzliste des OWASP GenAI Security Project für die zehn kritischsten Sicherheitsrisiken von Anwendungen, die ein großes Sprachmodell (LLM) einbauen. Aktuell ist die Fassung 2026, veröffentlicht im August 2026, mit den Kennungen LLM01:2026 bis LLM10:2026. Auf Platz eins steht weiterhin Prompt-Injection, Excessive Agency ist auf Platz drei gestiegen, und aus System Prompt Leakage wurde Hidden Context Exposure. Dieser Leitfaden erklärt jeden Eintrag mit einem realistischen Beispiel, einem Prüfweg und den Maßnahmen, die wirklich greifen.

Welche Fassung gilt: 2025 oder 2026?

Die Liste wird vom OWASP GenAI Security Project gepflegt. Die Fassung 2025 erschien im November 2024, die Fassung 2026 im August 2026. Neu ist die Methode: Bisher beruhte die Reihenfolge allein auf der Einschätzung von Praktikern. Für 2026 hat das Projektteam diese Abstimmung erstmals gegen eine Sammlung von 7.714 öffentlich dokumentierten Vorfällen geprüft. Die Abstimmung zählt zu drei Vierteln, die Vorfalldaten zu einem Viertel. Deshalb hat sich die Reihenfolge stärker verschoben als in früheren Jahren.

Die Kennungen sind an das Jahr gebunden. „LLM03“ meint 2025 die Lieferkette und 2026 Excessive Agency. Schreiben Sie in Berichten, Tickets und Anforderungen deshalb immer die volle Kennung mit Jahr, also LLM03:2026.

Warum LLM-Anwendungen eine eigene Top 10 brauchen

Ein Sprachmodell unterscheidet technisch nicht zwischen Anweisung und Daten. System-Prompt, Nutzereingabe, gefundene Dokumente und Werkzeug-Antworten landen im selben Kontextfenster. Es gibt also kein Gegenstück zur parametrisierten SQL-Abfrage, das Befehle sauber von Inhalten trennt. Die Grundhaltung der Liste 2026 fasst das Projektteam in einem Satz zusammen: Bauen Sie nicht auf ein Modell, das sich nicht täuschen lässt, sondern bauen Sie das System so, dass nichts Wichtiges kaputtgeht, wenn das Modell getäuscht wird.

Die zehn Risiken im Detail

LLM01:2026 Prompt Injection

Eine Eingabe verändert das Verhalten des Modells so, wie es die Entwickler nicht vorgesehen haben. Direkt geschieht das über das Chatfenster, indirekt über Inhalte, die das Modell liest: eine Webseite, ein PDF, eine E-Mail, eine Werkzeug-Antwort oder einen Eintrag im Gedächtnis. Neu in der Fassung 2026 sind ausdrücklich Anweisungen in Bildern und Audio. Nach Einschätzung von OWASP gibt es derzeit keinen verlässlichen Schutz, der Prompt-Injection vollständig verhindert.

Beispiel: Ein Assistent soll eine Webseite zusammenfassen. Im Quelltext steht unsichtbar die Anweisung, eine Markdown-Grafik einzufügen, deren Adresse den bisherigen Gesprächsverlauf als Parameter enthält. Der Browser lädt die Grafik, und das Gespräch landet beim Angreifer.

Prüfen: Legen Sie präparierte Inhalte überall dort ab, wo das Modell liest, und beobachten Sie, ob sie Werkzeuge auslösen oder Daten nach außen tragen. Testen Sie gegen einen Angreifer, der Ihre Schutzmaßnahmen kennt, nicht nur mit bekannten Mustern. Mindern: Rechte im Anwendungscode halten statt im Modell, jede Aktion pro Aufruf deterministisch prüfen, unsichtbare Unicode-Zeichen an jeder Grenze entfernen, für folgenreiche Aktionen eine Bestätigung mit der exakten Aktion verlangen. Die vertiefte Mechanik steht im Beitrag zu Prompt-Injection und Tool-Poisoning.

LLM02:2026 Sensitive Information Disclosure

Die Anwendung gibt vertrauliche, personenbezogene oder geschäftskritische Daten auf einem Weg preis, der nicht vorgesehen war. Das ist nicht nur die Antwort im Chat. OWASP zählt auch Werkzeug-Argumente, Reasoning-Ausgaben, gefundene Textabschnitte, Logs, Telemetrie und messbare Eigenschaften wie Antwortzeiten zu den Kanälen. Die Ursache kann im Training liegen, im Kontext zur Laufzeit, in der Datenpipeline oder in der Beobachtung von außen.

Beispiel: Ein interner Wissensassistent durchsucht alle Dokumente und prüft erst danach, ob die Person sie sehen darf. Eine geschickt formulierte Frage bringt Passagen aus Gehaltslisten in die Zusammenfassung, weil die Rechteprüfung am fertigen Ergebnis nicht greift.

Prüfen: Mit Testkonten unterschiedlicher Rechte dieselben Fragen stellen und vergleichen. Logs und Traces auf Klartext-Daten durchsehen. Mindern: Berechtigungen schon in der Suchabfrage durchsetzen, nicht danach. Nur die Felder an das Modell geben, die die Aufgabe braucht. Keine Geheimnisse im System-Prompt. Logs vor der Weitergabe an Monitoring-Werkzeuge bereinigen.

LLM03:2026 Excessive Agency

Das Modell darf mehr, als die Aufgabe braucht, und richtet deshalb Schaden an, sobald es sich irrt oder manipuliert wird. OWASP nennt drei Wurzeln: zu viele Funktionen, zu weite Rechte, zu viel Autonomie. Der Auslöser ist dabei zweitrangig, eine Halluzination wirkt genauso wie eine Prompt-Injection. Das ist der größte Aufsteiger der Fassung 2026, von Platz sechs auf drei.

Beispiel: Ein E-Mail-Assistent soll eingehende Mails zusammenfassen. Die eingebundene Erweiterung kann aber auch senden und löschen. Eine präparierte Mail bringt ihn dazu, das Postfach an eine fremde Adresse weiterzuleiten.

Prüfen: Für jedes Werkzeug auflisten, welche Funktionen und Rechte es hat und welche die Aufgabe wirklich braucht. Prüfen, unter welcher Identität es auf Folgesysteme zugreift. Mindern: Werkzeuge, Funktionen und Rechte auf das Minimum beschränken, offene Werkzeuge wie „Shell-Befehl ausführen“ durch eng geschnittene ersetzen, Aktionen im Kontext des echten Nutzers ausführen, folgenreiche Schritte von einem Menschen freigeben lassen.

LLM04:2026 Supply Chain

Die Anwendung baut auf fremden Bausteinen auf: vortrainierte Modelle, Feinabstimmungs-Adapter, Datensätze, Konvertierungsdienste, Inferenz-Server und klassische Bibliotheken. Jeder davon kann manipuliert, veraltet oder vertauscht sein. Neu ist der Fall, dass ein freigegebenes Modell-Artefakt nicht das ist, was es vorgibt.

Beispiel: Ein Team lädt ein Modell von einem öffentlichen Hub, dessen Name einem bekannten Anbieter täuschend ähnlich ist. Das Modell funktioniert unauffällig, enthält aber ein eingebautes Fehlverhalten, das nur bei bestimmten Eingaben auftritt.

Prüfen: Gibt es ein Verzeichnis aller Modelle, Adapter, Datensätze und Pakete mit Herkunft und Version? Werden Prüfsummen oder Signaturen kontrolliert? Existieren die Pakete, die ein Code-Assistent vorschlägt, wirklich? Mindern: Stückliste für Software und Modelle führen, Versionen festschreiben, Signaturen prüfen, Lieferanten bewerten, Inferenz-Dienste wie jeden anderen Server patchen und absichern. Eine Signatur belegt Herkunft und Unversehrtheit, nicht Sicherheit.

LLM05:2026 Data and Model Poisoning

Ein Angreifer oder ein unsauberer Prozess manipuliert Daten oder Modell-Artefakte so, dass das Modell schädliches Verhalten, eine Verzerrung oder eine Hintertür lernt. Das betrifft Vortraining, Feinabstimmung, Embeddings und Rückkopplungsschleifen. Das Tückische: Das Modell wirkt weiter funktionsfähig.

Beispiel: Ein Support-Modell wird regelmäßig mit Kundenbewertungen nachtrainiert. Ein Angreifer speist über Wochen gezielt Bewertungen ein, bis das Modell bei einer bestimmten Formulierung eine falsche Rückerstattungsregel nennt.

Prüfen: Woher stammen Trainings- und Feinabstimmungsdaten, wer darf sie ändern, und ist jede Änderung versioniert? Wird das Modell nach jedem Trainingslauf gezielt auf versteckte Auslöser getestet? Mindern: Datenherkunft dokumentieren, eingehende Daten validieren, automatisches Nachtrainieren mit Freigabe und Mengengrenzen versehen, Datenstände versionieren, damit sich ein Rückfall auf einen sauberen Stand umsetzen lässt.

LLM06:2026 Unbounded Consumption

Die Anwendung lässt unkontrolliert viele oder teure Anfragen zu. Die Folgen sind Ausfälle, unerwartete Kosten oder der Nachbau des Modells über massenhafte Abfragen. Kennzeichnend ist die Asymmetrie: Ein Angreifer löst mit wenig Aufwand teure Rechenarbeit aus. Reasoning-Modelle, multimodale Eingaben und Agenten, die aus einer Anfrage viele Werkzeugaufrufe machen, verschärfen das.

Beispiel: Ein öffentlicher Chatbot auf einer Firmenwebsite hat kein Limit pro Nutzer. Ein Skript schickt über Nacht lange Anfragen, die maximale Antwortlängen erzwingen. Am Morgen ist das Monatsbudget beim Modellanbieter verbraucht („Denial of Wallet“).

Prüfen: Gibt es Grenzen pro Nutzer, Schlüssel und Zeitraum, gemessen in Tokens und Kosten, nicht nur in Anfragen? Bricht die Anwendung bei Überschreitung ab oder schickt sie nur eine Warnung? Mindern: Ratenbegrenzung und Eingabelängen prüfen, harte Ausgabengrenzen, die die Verarbeitung stoppen, Grenzen für Werkzeug-Schleifen und Warteschlangen, kontrollierter Teilbetrieb unter Last.

LLM07:2026 Misinformation

Das Modell liefert falsche, unvollständige oder nicht belegte Informationen, die glaubwürdig genug sind, dass ein Mensch, ein Workflow oder ein Agent danach handelt. Das Risiko ist nicht die falsche Antwort an sich, sondern dass ihr vertraut wird. In den Vorfalldaten taucht dieser Eintrag deutlich häufiger auf, als die Abstimmung erwarten ließ.

Beispiel: Ein Code-Assistent empfiehlt ein Paket, das es nicht gibt. Ein Angreifer hat genau diesen Namen vorher registriert. Wer der Empfehlung folgt, installiert fremden Code.

Prüfen: An welchen Stellen löst eine Modellausgabe ohne Gegenprüfung eine Entscheidung oder Aktion aus? Werden Quellen mitgeliefert und kontrolliert? Mindern: Aussagen an verlässliche Quellen binden, Erzeugen und Ausführen trennen und dazwischen prüfen, Werkzeugaufrufe auf Vorbedingungen prüfen, Pflichtfelder in strukturierten Ausgaben gegen Auslassungen, gekennzeichnet, was belegt und was angenommen ist.

LLM08:2026 Hidden Context Exposure

Früher hieß der Eintrag System Prompt Leakage. Gemeint ist das Auslesen oder Rekonstruieren von Kontext, den Nutzer nicht sehen sollen: System-Prompt, Entwickleranweisungen, nachgeladene Regeltexte und die Schemas der Werkzeuge. Gefährlich wird es, wenn dieser Kontext Geheimnisse, Regellogik oder Rechtegrenzen enthält. OWASP rät, davon auszugehen, dass verborgener Kontext auffindbar ist.

Beispiel: Ein Chatbot enthält im System-Prompt einen API-Schlüssel und die Regel „Rabatte über 20 Prozent nur für Bestandskunden“. Ein Nutzer bringt das Modell dazu, seine Anweisungen zu wiederholen, und hat damit Schlüssel und Umgehungsidee zugleich.

Prüfen: Was stünde im Klartext auf dem Tisch, wenn der komplette Kontext öffentlich würde? Hängt eine Sicherheitsentscheidung davon ab, dass eine Anweisung geheim bleibt? Mindern: keine Zugangsdaten oder sicherheitskritische Konfiguration im Kontext, Verhaltensgrenzen und Berechtigungen außerhalb des Modells deterministisch durchsetzen, Aufgaben mit unterschiedlichen Rechten trennen.

LLM09:2026 Vector and Embedding Weaknesses

Schwächen in der Vektorsuche, die entscheidet, welche Inhalte das Modell überhaupt zu sehen bekommt. Das betrifft RAG, Agenten-Gedächtnis und semantische Caches. Anders als bei Prompt-Injection braucht es dafür oft gar keine bösartige Anweisung. OWASP fasst es so: Vergiftung macht das System falsch, Inversion lässt es Daten preisgeben, Verdrängung macht es stumm, fehlende Zugriffskontrolle macht es wahllos.

Beispiel: Eine SaaS-Anwendung legt die Dokumente aller Mandanten in einen gemeinsamen Index und filtert erst nach der Suche. Ein Mandant sieht keine fremden Dokumente, kann aber aus Trefferzahlen und Antwortzeiten ablesen, zu welchen Themen ein anderer Mandant Unterlagen hat.

Prüfen: Wird die Mandanten- und Rechtegrenze in der Indexabfrage selbst durchgesetzt? Wer darf Inhalte in den Index schreiben, und wird die Herkunft jedes Eintrags festgehalten? Mindern: Zugriffskontrolle in der Abfrage und auf Abschnittsebene, getrennte Indizes für sensible Mandanten, Inhalte vor dem Einbetten normalisieren, Herkunft je Eintrag speichern, auffällige Treffermuster überwachen.

LLM10:2026 Improper Output Handling

Die Ausgabe des Modells wird ungeprüft an andere Komponenten weitergegeben: an den Browser, an eine Datenbank, an eine Shell oder an ein Terminal. Weil sich die Ausgabe über die Eingabe steuern lässt, entstehen daraus klassische Lücken wie Cross-Site-Scripting, SQL-Injection, SSRF oder Codeausführung. Neu dazugekommen ist unsicherer Code, den Assistenten in großer Menge erzeugen.

Beispiel: Eine Anwendung lässt Nutzer Datenbankfragen in Alltagssprache stellen und führt das vom Modell erzeugte SQL direkt aus. Eine Formulierung, die das Modell zu einem DELETE bringt, genügt.

Prüfen: Verfolgen Sie jede Modellausgabe bis zu ihrem Ziel und prüfen Sie dort, ob kodiert, parametrisiert oder validiert wird. Rendert die Oberfläche Markdown-Bilder oder Links automatisch? Mindern: das Modell wie einen nicht vertrauenswürdigen Nutzer behandeln, kontextgerecht kodieren, parametrisierte Abfragen, eine strenge Content Security Policy, Steuerzeichen entfernen und automatisches Nachladen externer Inhalte abschalten oder auf eine Allowlist begrenzen.

LLM, Agentic, MCP: welche Liste wofür?

OWASP zieht die Grenze selbst: Die LLM-Liste gilt, solange das Modell eine Komponente in Ihrer Anwendung ist. Sobald es zum Akteur wird, mit Werkzeugen, Gedächtnis über Sitzungen hinweg und Folgen in nachgelagerten Systemen, wandert das Risiko in die Agentic-Liste. Viele reale Vorfälle liegen genau auf dieser Grenze. Die dritte Liste betrifft die Infrastruktur dazwischen, den MCP-Server.

Die Listen überschneiden sich bewusst. Laut OWASP zeigt sich Excessive Agency (LLM03:2026) in agentischen Systemen als Werkzeug-Missbrauch (ASI02), als Identitäts- und Rechte-Missbrauch (ASI03) und als kaskadierende Ausfälle (ASI08). Lieferkettenrisiken für MCP-Server und Werkzeugverzeichnisse verweist die LLM-Liste ausdrücklich an ASI04. Für die Praxis heißt das: Ein Chatbot ohne Werkzeuge ist mit der LLM-Liste gut abgedeckt. Ein Assistent, der Mails senden, Tickets anlegen oder Code ausführen darf, braucht zusätzlich die Agentic-Liste, und wer dafür MCP-Server betreibt oder einbindet, die MCP-Liste.

Von der Prüffrage zum KI-Pentest

Die Prüfwege oben zeigen, wo Sie hinschauen müssen. Ob eine Kontrolle hält, zeigen sie nicht. Bei LLM-Anwendungen kommt hinzu, dass Abwehrmaßnahmen gegen bekannte Angriffsmuster oft gut aussehen und gegen einen Angreifer, der sie kennt und gezielt umgeht, deutlich schlechter. OWASP empfiehlt deshalb ausdrücklich Tests mit adaptiven Angreifern, denen die eingesetzte Abwehr bekannt ist.

Ein KI-Pentest für eine LLM-Anwendung verbindet beides: die klassische Prüfung von Schnittstellen, Rechten und Datenflüssen und die gezielte Prüfung der Modell-Grenzen, also präparierte Inhalte in jedem Eingabekanal, Rechteausweitung über Werkzeuge, Datenabfluss über Ausgaben und Kostenmissbrauch. Er findet in einem schriftlich vereinbarten Umfang statt, und jeder Befund wird mit einem nachvollziehbaren Proof of Concept belegt. Wie wir dabei vorgehen, beschreibt die Seite KI- und MCP-Sicherheit. Für die Web-Anwendung rund um das Modell ist der SaaS-Penetrationstest der passende Rahmen.

Häufige Fragen

Weiterlesen

• AI Red Teaming erklärt
• OWASP Top 10 2025 erklärt
• LLM-Pentest: die Checkliste für KI-Anwendungen vor dem Livegang
• Prompt-Injection testen: Testplan, Testfälle und Bewertung
• Die OWASP Top 10 für Agentic Applications, praktisch erklärt
• Die OWASP MCP Top 10, praktisch erklärt
• Prompt-Injection und Tool-Poisoning in MCP-Servern
• Leistung: KI- und MCP-Sicherheitsprüfung

Quellen

• OWASP GenAI Security Project: OWASP GenAI LLM Top 10 2026
• OWASP GenAI Security Project: Ankündigung der Fassung 2026
• OWASP GenAI Security Project: LLM Top 10 2025 und Übersetzungen
• OWASP GenAI Security Project: Top 10 for Agentic Applications 2026
• OWASP: MCP Top 10