Die OWASP Foundation hat mit der „Top 10 for LLM Applications“ eine Referenzliste der zehn kritischsten Sicherheitsrisiken für Anwendungen veröffentlicht, die auf Large Language Models basieren. Die Liste ist das Ergebnis der Arbeit von über 500 Experten und richtet sich an Entwickler, Architekten und Sicherheitsverantwortliche, die LLM-basierte Systeme entwerfen, betreiben oder absichern müssen. Dieser Artikel erklärt jedes der zehn Risiken mit Praxisbeispielen und konkreten Gegenmaßnahmen.
LLM01: Prompt Injection
Das gravierendste Risiko. Angreifer manipulieren die Eingabe an ein Sprachmodell so, dass es Anweisungen ausführt, die nicht im Sinne des Betreibers sind. Man unterscheidet zwei Varianten:
- Direct Prompt Injection: Der Angreifer gibt manipulierte Anweisungen direkt in das Chat-Interface ein, um System-Prompts zu überschreiben oder Sicherheitsfilter zu umgehen.
- Indirect Prompt Injection: Schadhafte Anweisungen werden in externen Daten versteckt – Webseiten, E-Mails, Dokumente – die das Modell während der Verarbeitung einliest.
Ein anschauliches Beispiel liefert der EchoLeak-Angriff: Forscher platzierten unsichtbare Anweisungen in Webseiten, die von RAG-Systemen indexiert wurden. Sobald das LLM diese Seiten verarbeitete, exfiltrierte es vertrauliche Daten aus dem Kontext. Mehr dazu in unserer Analyse: Prompt Injection 2026 – das unlösbare Problem.
Gegenmaßnahmen: Strikte Trennung von System-Prompt und Nutzereingabe, Input-Sanitization, Output-Filterung, Privilege Separation zwischen LLM-Komponenten.
LLM02: Insecure Output Handling
LLMs generieren Text – und dieser Text wird oft direkt in Webanwendungen, Datenbanken oder APIs eingespeist. Wenn die Ausgabe nicht validiert wird, entstehen klassische Injection-Schwachstellen: Cross-Site Scripting (XSS), SQL Injection oder Command Injection – nur dass der Angriffsvektor diesmal durch das Sprachmodell selbst verläuft.
Beispiel: Ein Chatbot generiert eine Antwort, die JavaScript-Code enthält. Wird diese Antwort ungefiltert in eine Webseite eingebettet, führt der Browser den Code aus. Der Angreifer muss nicht einmal direkten Zugang zur Anwendung haben – es reicht, das LLM über Prompt Injection zur Ausgabe von Schadcode zu bewegen.
Gegenmaßnahmen: Output Encoding, Content Security Policies, Validierung aller LLM-Ausgaben gegen ein striktes Schema, bevor sie an nachgelagerte Systeme weitergegeben werden.
LLM03: Training Data Poisoning
Wer die Trainingsdaten kontrolliert, kontrolliert das Modell. Angreifer schleusen manipulierte Daten in den Trainingsprozess ein – direkt oder über kompromittierte Datenquellen – und verändern dadurch das Verhalten des Modells. Die Manipulation kann subtil sein: Ein vergiftetes Modell liefert in 99 Prozent der Fälle korrekte Antworten, aber bei bestimmten Triggern gezielt falsche oder schädliche Ausgaben.
Gegenmaßnahmen: Verifizierung der Datenherkunft, Integritätsprüfungen, statistische Anomalieerkennung in Trainingsdaten, regelmäßiges Red Teaming des Modellverhaltens. Wer sich für praktische Ansätze interessiert, findet in unserem Red-Teaming-Tutorial für LLMs einen Einstieg.
LLM04: Model Denial of Service
Sprachmodelle sind rechenintensiv. Gezielte Anfragen, die besonders lange Kontextfenster, verschachtelte Rekursionen oder ressourcenintensive Operationen auslösen, können ein LLM in die Knie zwingen. Anders als bei klassischen DDoS-Angriffen genügt manchmal eine einzige sorgfältig konstruierte Anfrage, um signifikante Kosten oder Ausfälle zu verursachen.
Gegenmaßnahmen: Rate Limiting pro Nutzer, maximale Input-Länge, Timeout-Konfigurationen, Kostenmonitoring, automatische Skalierungsgrenzen.
LLM05: Supply Chain Vulnerabilities
LLM-Anwendungen bestehen aus zahlreichen Komponenten: vortrainierte Modelle, Fine-Tuning-Datensätze, Plugins, Embedding-Modelle, Vektor-Datenbanken, Orchestrierungs-Frameworks. Jede dieser Komponenten ist ein potenzieller Angriffsvektor. Kompromittierte Modelle auf Hugging Face, manipulierte PyPI-Pakete oder gefälschte Plugins können Schadcode in die gesamte Anwendung einschleusen.
Gegenmaßnahmen: Software Bill of Materials (SBOM) für KI-Komponenten, Signaturprüfung für Modelle, Dependency Scanning, Isolation von Drittanbieter-Plugins.
LLM06: Sensitive Information Disclosure
Sprachmodelle können vertrauliche Informationen preisgeben – sowohl aus ihren Trainingsdaten als auch aus dem Kontext der aktuellen Sitzung. Durch geschickte Prompt-Konstruktion lassen sich System-Prompts extrahieren, persönliche Daten aus dem Training reproduzieren oder vertrauliche Unternehmensinformationen aus RAG-Kontexten abgreifen.
Gegenmaßnahmen: Datenklassifizierung vor der Einspeisung, PII-Filterung (Personally Identifiable Information), Zugriffskontrollen auf RAG-Datenquellen, Output-Scanning auf sensible Muster.
LLM07: Insecure Plugin Design
Plugins erweitern LLMs um Funktionalitäten: Datenbankzugriff, Web-Suche, Code-Ausführung, API-Aufrufe. Wenn Plugins Eingaben vom LLM ohne Validierung akzeptieren, wird das Sprachmodell zum Proxy für Angriffe auf Backend-Systeme. Ein manipuliertes LLM kann über ein unsicheres Plugin SQL-Befehle ausführen, Dateien löschen oder Konfigurationen ändern.
Gegenmaßnahmen: Strenge Input-Validierung in jedem Plugin, Least-Privilege-Prinzip für Plugin-Berechtigungen, Sandbox-Ausführung, menschliche Bestätigung für kritische Aktionen.
LLM08: Excessive Agency
LLMs erhalten zunehmend Handlungsfähigkeit: Sie versenden E-Mails, führen Code aus, ändern Datenbanken, steuern Infrastruktur. Wenn diese Agenten zu viele Berechtigungen besitzen – „Excessive Agency“ – können Fehlentscheidungen des Modells oder erfolgreiche Prompt-Injection-Angriffe katastrophale Folgen haben. Die Analyse von Zero Trust für KI-Agenten beschreibt architektonische Ansätze zur Einhegung dieses Risikos.
Gegenmaßnahmen: Minimale Berechtigungen, Human-in-the-Loop für irreversible Aktionen, automatische Genehmigungsworkflows, Audit-Logging aller Agentenaktionen.
LLM09: Overreliance
Nutzer und Organisationen vertrauen LLM-Ausgaben blind – ohne sie zu verifizieren. Das führt zu Entscheidungen auf Basis halluzinierter Fakten, fehlerhaftem Code oder erfundener Rechtsgrundlagen. Der Schaden entsteht nicht durch einen Angriff, sondern durch übermäßiges Vertrauen in ein System, das strukturell nicht zuverlässig ist.
Gegenmaßnahmen: Verifikationsprozesse für LLM-Ausgaben, Kennzeichnung von KI-generierten Inhalten, Schulung der Nutzer über Modellgrenzen, automatisierte Faktenprüfung gegen verifizierte Datenquellen.
LLM10: Model Theft
Proprietäre Modelle repräsentieren erhebliche Investitionen. Angreifer versuchen, Modelle durch Model Extraction zu stehlen: Sie stellen systematisch Anfragen und trainieren auf Basis der Antworten ein Schattenmodell, das das Originalverhalten reproduziert. Alternativ werden Modellgewichte direkt über kompromittierte Infrastruktur oder Insider-Zugang kopiert.
Gegenmaßnahmen: Rate Limiting und Monitoring ungewöhnlicher Abfragemuster, Watermarking der Modellausgaben, Zugriffskontrollen auf Modellgewichte, rechtlicher Schutz durch Lizenzen und NDAs.
Fazit: Eine Referenz für die Praxis
Die OWASP Top 10 for LLM Applications liefern kein theoretisches Framework, sondern eine praxisorientierte Checkliste. Jedes der zehn Risiken ist durch dokumentierte Vorfälle belegt. Für Unternehmen, die LLM-basierte Systeme entwickeln oder einsetzen, ist die Liste der Ausgangspunkt für ein systematisches Bedrohungsmodell – nicht der Endpunkt. Die AI Security Landscape 2026 zeigt, welche Werkzeuge und Plattformen bei der Umsetzung helfen.