OWASP LLM Security Top 10 Die 10 größten KI-Risiken – und wichtigsten Schutzmaßnahmen

Anbieter zum Thema

F5 Networks GmbH

WatchGuard Technologies GmbH

Impossible Cloud GmbH

XOPERO SOFTWARE S.A.

Prompt Injection, Fehlinformationen, Manipulation von Daten und Modellen: Die Einführung von KI und ihrer LLMs führt zu zahlreichen neuartigen Sicherheitsgefahren. Die größten Risiken listet die aktuelle OWASP LLM Security Top 10 auf.

Der Druck auf Unternehmen zur Einführung von KI-Lösungen steigt enorm. Denn Führungskräfte wollen damit die Produktivität steigern und Mitarbeitende ihre Aufgaben effizienter erledigen. Doch das schnell wachsende Ökosystem aus Infrastrukturen, Tools, Modellen, Frameworks und zugehörigen Diensten erschwert es Security-Teams, den Überblick zu behalten und die neuen KI-Apps auf sichere Weise bereitzustellen.

Neben dieser höheren Komplexität führt generative KI (GenAI) auch zu neuen Risiken – intern aufgrund der stark steigenden Vernetzung durch APIs und fehlerhafter Bedienung, extern durch neuartige Angriffsmöglichkeiten für Cyberkriminelle. Die größten aktuellen Gefahren zeigt die Liste des „Open Web Application Security Project“ (OWASP), einer internationalen gemeinnützigen Organisation, die sich der Sicherheit von Webanwendungen widmet: OWASP Top 10 for LLM Applications 2025.

1. Prompt Injection

Prompt Injections entstehen durch Eingaben, die das Verhalten oder die Ausgabe des LLM auf unerwünschte Weise verändern. Prompt Injections müssen nicht für Menschen sichtbar oder lesbar sein, solange der Inhalt vom Modell erkannt und verarbeitet wird. Von direkten, indirekten, multimodalen und unbeabsichtigten Injektionen reichen die Gefahren bis zu Jailbreaking. Hier bringen Eingaben das Modell dazu, seine Sicherheitsprotokolle völlig zu ignorieren. Zu den wichtigsten Schutzmaßnahmen gehören die Einschränkung des Modellverhaltens, Input- und Output-Filter, Freigaben durch Menschen sowie strenge Zugangskontrollen.

2. Sensitive Information Disclosure

Der Diebstahl sensibler Informationen kann personenbezogene oder finanzielle Informationen, Geschäftsdaten, Sicherheitsnachweise, juristische Dokumente und LLM-Algorithmen betreffen. Um das Risiko zu verringern, sollten LLM-Anwendungen eine angemessene Datenbereinigung durchführen, damit keine Benutzerdaten in das Trainingsmodell gelangen. Zudem lassen sich die auszugebenden Datentypen beschränken, um die Offenlegung sensibler Informationen zu verhindern.

3. Supply Chain

Code-Fehler und Abhängigkeiten entstehen bei Maschinellem Lernen auch in vortrainierten Modellen und Daten Dritter. Schwachstellen in den LLM-Lieferketten beeinträchtigen die Integrität von Trainingsdaten, Modellen und Bereitstellungsplattformen. Zusätzlich können externe Dienste manipuliert sein. Dies führt zu verzerrten Ergebnissen, Sicherheitsverletzungen oder Systemausfällen. Daher sollten Unternehmen die Modelle und Datenquellen ihrer Lieferanten regelmäßig prüfen, einschließlich AGB und Datenschutzrichtlinien.

4. Data and Model Poisoning

Data Poisoning bedeutet, dass Daten vor dem Training, bei der Feinabstimmung oder der Eingabe manipuliert werden. Dies kann die Sicherheit und Leistung des Modells beeinträchtigen sowie zu verzerrten Ergebnissen, eingeschränkten Fähigkeiten, Schwachstellen oder Hintertüren führen, auch bei nachgelagerten Systemen. Daher müssen Unternehmen die Herkunft, Legitimität und Transformation der Daten in allen Phasen der Modellentwicklung validieren.

5. Improper Output Handling

Der unsachgemäße Umgang mit Ergebnissen bezieht sich insbesondere auf unzureichende Validierung, Bereinigung und Behandlung der von LLMs erzeugten Ausgaben, bevor sie an andere Komponenten und Systeme weitergegeben werden. Mögliche Gefahren sind Remote Code Execution, Cross-Site Scripting, Rechteerweiterung oder SQL Injection. Sprachmodelle sind daher wie jeder User mit einem Zero-Trust-Ansatz zu behandeln und ihre Ergebnisse zu überprüfen, bevor sie in andere Systeme eingegeben werden.

6. Excessive Agency

LLM-basierte Systeme besitzen oft eine gewisse Handlungsfähigkeit (Agency), um über Erweiterungen mit anderen Systemen zu interagieren. Excessive Agency ermöglicht es, in Folge unerwarteter, zweideutiger oder manipulierter Ausgaben eines LLM schädliche Aktionen durchzuführen. Daraus resultieren erweiterte Funktionalitäten und Berechtigungen. Entsprechend sollten die Erweiterungen in ihren Rechten und Funktionen eingeschränkt werden.

7. System Prompt Leakage

System-Prompts oder Anweisungen zur Steuerung des Modellverhaltens können sensible Informationen enthalten, die Cyberkriminelle stehlen und für Angriffe einsetzen. Daher sollten sensible Informationen wie Anmeldedaten, Verbindungsstrings, Funktionalitäten, interne Regeln, Filterkriterien, Rechte oder Nutzerrollen nicht in der Sprache der Systemsteuerung enthalten sein.

8. Vector and Embedding Weaknesses

Schwachstellen bei Vektoren und Einbettungen stellen ein Sicherheitsrisiko in Systemen dar, die Retrieval Augmented Generation (RAG) mit LLMs verwenden. Diese können ausgenutzt werden, um schädliche Inhalte einzuschleusen, Modellausgaben zu manipulieren oder auf sensible Informationen zuzugreifen. Geeignete Schutzmaßnahmen sind Rechte- und Zugangskontrollen, Datenvalidierung und -qualifizierung, Monitoring und Quellenauthentifizierung.

9. Desinformation

Fehlinformationen entstehen, wenn LLMs falsche oder irreführende Informationen produzieren, die glaubwürdig erscheinen. Dies kann zu Sicherheitsverletzungen, Rufschädigung und rechtlicher Haftung führen. Entsprechend ist jede Ausgabe von Menschen auf Richtigkeit zu prüfen, wofür Mitarbeitende entsprechendes Training benötigen. RAG, Feinabstimmung der Modelle, automatische Validierungen und Content-Filter können die Ausgabe von Fehlinformationen vermeiden.

10. Unbounded Consumption

Unbegrenzter Verbrauch tritt auf, wenn eine LLM-Anwendung exzessive und unkontrollierte Inferenzen erlaubt. Daraus entstehen Risiken wie Denial-of-Service (DoS), wirtschaftliche Verluste, Modelldiebstahl und Verschlechterung der Dienste. Daher sind zum Beispiel Grenzen für Eingabemenge, Anfrageraten oder API-Antworten festzulegen.

API-Schutz für KI-Lösungen

Für die technischen Schutzmaßnahmen bilden in der Regel APIs die Basis. Denn diese Schnittstellen dienen dazu, KI-Modelle zu trainieren und zu verwenden. Gleichzeitig nutzen sie Cyberkriminelle, um Daten zu stehlen oder KI-Modelle zu manipulieren. Daher sind Transparenz, Sicherheit und Governance der APIs frühzeitig in den KI-Entwicklungs- und -Trainingsprozess zu integrieren. Außerdem ist es wichtig, dass normale Nutzungsmuster und Kontrollen wie Ratenbegrenzungen und Datenbereinigung bereits in der Designphase integriert werden – sowie über den gesamten API-Lebenszyklus hinweg.

Im Zeitalter von KI verändern sich APIs jedoch immer schneller und steigen in ihrer Anzahl. Man kann aber nicht schützen, was man nicht sieht. Daher ist ein Inventar der Schnittstellen hinter den KI-Anwendungen nötig und API-Sicherheit muss ein integraler Bestandteil von KI-Governance-Programmen sein. Gleichzeitig sollten Unternehmen programmierbare und anpassungsfähige Lösungen für die API-Sicherheit einsetzen, um schnell auf neue Bedrohungen reagieren zu können. Da APIs zunehmend mit externen KI-Diensten verbunden sind, muss das Sicherheitsmodell nicht nur den eingehenden, sondern auch den ausgehenden API-Verkehr abdecken.

KI-Gateway-Technologie unterstützt Sicherheitsteams dabei, die aktuellen Risiken für LLMs zu senken. Sie lässt sich in eigenen Rechenzentren sowie in Private und Public Cloud installieren, um auch Lieferketten zu überwachen. Neben dem Erkennen und Blockieren von Angriffen übernimmt sie das Routing von Datenverkehr und begrenzt die Raten für lokale und externe Sprachmodelle, um die Leistung zu verbessern, Verfügbarkeit zu gewährleisten und Kosten zu kontrollieren. Denn eines gilt vom Schutz der Interaktionen zwischen Front-End-Anwendung und Inferenzdienst über die Prüfung von User-Interaktionen mit KI-SaaS-Apps bis zum Schutz der Konnektivität zwischen Plugins, Datenkonnektoren und nachgelagerten Diensten: Die sichere Einführung und Nutzung von KI-Apps hängt von der API-Sicherheit ab.

Über den Autor: Stephan Schulz ist Principal Solutions Engineer bei F5.

(ID:50369124)