Sicherheitsrisiken im KI-Zeitalter : OWASP Top 10 für LLM-Anwendungen : Eine systematische Betrachtung zentraler Sicherheitsrisiken im KI-Einsatz
Die „OWASP Top 10 for LLM Applications“ zeigen systematisch auf, wo die größten Gefahren im Umgang mit generativer KI lauern: von Prompt Injection über unsichere Plug-ins bis zu Datenlecks und Modell-Diebstahl. Unser Beitrag bietet eine fundierte Übersicht über die zehn wichtigsten Risikofelder.
Große Sprachmodelle (Large Language Models, LLMs) werden zunehmend in unternehmenskritischen Prozessen eingesetzt. Ob im Kundenservice, bei der Codegenerierung oder als Bestandteil interner Assistenzsysteme – LLMs verschieben die klassischen IT-Sicherheitsgrenzen und schaffen eine neue, dynamische Bedrohungslandschaft. Mit der Veröffentlichung der „OWASP Top 10 for LLM Applications“ liegt eine strukturierte Aufarbeitung der häufigsten Sicherheitsrisiken im Umfeld generativer KI vor. Für Sicherheitsverantwortliche bietet dieser Katalog einen praxisnahen Referenzrahmen zur Bewertung eigener Systeme.
- Prompt Injection
Prompt Injection beschreibt die gezielte Beeinflussung eines LLMs durch manipulierte Eingaben, die Steuerbefehle oder Sicherheitseinschränkungen außer Kraft setzen. Neben der direkten Manipulation durch Endnutzer tritt zunehmend auch die indirekte Variante auf – etwa wenn ein LLM externe Texte analysiert, in denen schädliche Instruktionen versteckt sind. Dies kann besonders gefährlich werden, wenn KI-Systeme automatisch Inhalte aus E-Mails, Tabellen oder Webformularen verarbeiten.
Im Jahr 2023 wurde zum Beispiel bei Microsofts Copilot (https://arstechnica.com/information-technology/2023/09/hidden-commands-in-microsoft-office-files-can-prompt-copilot-to-expose-data/) eine Prompt Injection bekannt, bei der über Excel-Tabellen eingebettete Anweisungen den Assistenten dazu brachten, interne Daten offenzulegen. Die ENISA bezeichnet diesen Angriffsvektor in ihrer „AI Threat Landscape“ als eine der kritischsten Bedrohungen generativer Systeme und warnt vor unzureichend isolierten Prompt-Komponenten.
Effektive Schutzmaßnahmen umfassen die Trennung zwischen Steuerprompts und Nutzereingaben, strukturierte Prompt-Vorlagen und semantische Validierung. Fortgeschrittene Architekturen setzen zusätzlich auf „Guardrails“, die das Verhalten des Modells technisch einschränken.
- Insecure Output Handling
Die Ausgaben von LLMs werden häufig direkt in Folgesysteme eingespeist – zum Beispiel zur Konfiguration von Software, zur Beantwortung von E-Mails oder zur Erzeugung von Code. Werden diese Inhalte ungeprüft weiterverarbeitet, können daraus Sicherheitsrisiken entstehen. Halluzinierte URLs, fehlerhafte SQL-Befehle oder nicht konforme JSON-Strukturen bergen ein erhebliches Potenzial für systemische Schwachstellen.
LLM-Ausgaben müssen daher wie Nutzereingaben behandelt werden: Sie sind zu validieren, kontextsensitiv zu analysieren und bei sicherheitskritischen Anwendungen durch zusätzliche Prüfmechanismen abzusichern. Besonders bei der Generierung von Konfigurations- oder Codefragmenten sollte eine technische und inhaltliche Freigabe erfolgen, bevor der Output übernommen wird.
- Training Data Poisoning
Die Qualität und Integrität eines Modells hängt entscheidend von seinen Trainingsdaten ab. Beim sogenannten Data Poisoning versuchen Angreifer, gezielt manipulierte Inhalte in öffentlich zugängliche Datenquellen einzuschleusen – etwa in Code-Repositories, Foren oder Textkorpora. Werden diese unbeabsichtigt in das Modelltraining integriert, kann es zu dauerhaftem Fehlverhalten kommen.
Auch unternehmensinternes Fine-Tuning birgt Risiken, wenn unzureichend geprüfte Daten oder fehlerhafte Klassifikationen verwendet werden. Der Schutz gegen solche Manipulationen erfordert einen nachvollziehbaren Herkunftsnachweis (Data Provenance), formalisierte Qualitätsmetriken sowie strukturierte Freigabeprozesse. Die ENISA empfiehlt darüber hinaus die Trennung von Training, Validierung und Tests, um interne Datenlecks zu vermeiden.
- Model Denial of Service
LLMs sind rechenintensiv. Angreifer können dies ausnutzen, indem sie komplexe, verschachtelte oder besonders tokenreiche Prompts erzeugen, um Ressourcen zu binden oder Systeme zu überlasten. Solche Angriffe können nicht nur zur Unterbrechung von Diensten führen, sondern auch erhebliche Cloud-Kosten verursachen – besonders bei Modellen mit nutzungsbasierter Abrechnung.
Zur Absicherung bieten sich Tokenlimits, Antwortzeitbeschränkungen und Request-Quoten an. Ein kontinuierliches Monitoring des Prompt-Verhaltens kann außerdem helfen, missbräuchliche Nutzungsmuster frühzeitig zu erkennen. Auch die Limitierung auf genehmigte Nutzergruppen reduziert das Risiko gezielter Überlastung.
- Supply Chain Vulnerabilities
Die meisten LLM-Anwendungen integrieren vortrainierte Modelle, Frameworks und Datenquellen aus Drittsystemen. In dieser Lieferkette entstehen Angriffsflächen, wenn Komponenten aus nicht verifizierten Quellen übernommen oder Bibliotheken mit bekannten Schwachstellen eingebunden werden.
Die ENISA hebt hervor, dass LLM-Systeme in besonderem Maße von Open-Source-Komponenten abhängig sind, und regt den Einsatz KI-spezifischer SBOMs zur Nachvollziehbarkeit der Lieferkette an. : „Organizations should verify the cryptographic provenance of third-party models before integration.“
Realbeispiele aus den Jahren 2022/23 zeigen, dass Schadcode gezielt über typosquattende Python-Pakete in ML-Workflows eingeschleust wurde. Abhilfe schaffen signierte Modellgewichte, regelmäßige Komponentenaudits und die konsequente Isolierung externer Bibliotheken.
- Sensitive Information Disclosure
LLMs können unbeabsichtigt vertrauliche Daten wiedergeben – sei es aus den Trainingsdaten oder aus aktuellen Kontexteingaben. Das „AI Risk Management Framework“ des National Institute of Standards and Technology (NIST) nennt den Schutz vor unbeabsichtigter Datenweitergabe als zentrale Anforderung an vertrauenswürdige KI-Systeme. Ein prominenter Vorfall war beispielsweise das Datenleck von ChatGPT im März 2023, bei dem durch einen Fehler in der Redis-Datenbank fremde Konversationsinhalte und Zahlungsdaten angezeigt wurden. Obwohl die Ursache in der Infrastruktur lag, war es ein LLM, das die Inhalte vermischte.
Die Absicherung erfordert Datenklassifikation, Anonymisierung und eine kontinuierliche Überprüfung der Ausgaben auf sensitive Inhalte. In kritischen Bereichen kann Differential Privacy eingesetzt werden.
- Insecure Plug-in-Design
Moderne LLM-Plattformen bieten Plug-ins für Datenzugriff, Websuche oder API-Verbindungen. Diese Erweiterungsmodule können zu Sicherheitslücken führen, wenn sie unsachgemäß implementiert sind – etwa durch unvalidierte Eingaben, mangelhafte Authentifizierung oder zu weitreichende Berechtigungen.
Eine sichere Plug-in-Architektur erfordert die strikte Trennung zwischen Modell und Systemfunktionen, granulare Berechtigungen und eine protokollierte Interaktion mit dem Backend. Plug-ins sollten in isolierten Umgebungen betrieben, vor dem Einsatz auditiert und auf minimalen Funktionsumfang begrenzt werden.
- Excessive Agency
LLMs übernehmen zunehmend Aufgaben mit Handlungscharakter – etwa die Erstellung von E-Mails, die Steuerung von Terminprozessen oder die Verwaltung von Konfigurationsdaten. Je weiter diese Autonomie reicht, desto größer ist das Risiko unbeabsichtigter oder nicht rückverfolgbarer Systemveränderungen.
Die Sicherheitsarchitektur muss solche Agentensysteme durch Rollenmodelle, Genehmigungsmechanismen und klare Interaktionsgrenzen kontrollieren. Kritische Aktionen – etwa Schreibzugriffe auf produktive Systeme – sollten grundsätzlich eine menschliche Freigabe erfordern. Darüber hinaus ist eine Entkopplung zwischen Entscheidung und Ausführung technisch sinnvoll.
- Overreliance
Die hohe sprachliche Qualität LLM-generierter Inhalte führt in der Praxis häufig zu einer übermäßigen Abhängigkeit –besonders bei nicht technischen Nutzern. So zeigen Studien, dass Informationen mit hoher sprachlicher Kohärenz häufig ungeprüft übernommen werden, selbst wenn sie sachlich falsch sind.
Zur Risikoreduktion sollten Unternehmen LLMs also ausdrücklich als Assistenzsysteme und nicht als Entscheidungsinstanz positionieren. Schulungen, Validierungsprozesse und Plausibilitätsprüfungen können dabei helfen, Fehlentscheidungen zu vermeiden. Dies gilt besonders für sicherheitsrelevante oder regulierte Anwendungsbereiche.
- Model Theft
LLMs, die mit unternehmensspezifischem Wissen feinjustiert wurden, stellen ein geistiges Kapital dar. Durch systematische Abfragen (Model Extraction) oder den Zugriff auf Modellgewichte können Angreifer versuchen, diese Modelle zu stehlen oder zu replizieren. Die Arbeit von Carlini et al. zeigte bereits 2021, dass Modelle wie GPT-2 bei gezielter Nutzung Trainingsdaten vollständig reproduzieren konnten.
OpenAI selbst empfiehlt in seiner API-Dokumentation, keine sensiblen Daten in Prompts zu verwenden, da diese zu Monitoring-Zwecken verarbeitet werden können. Schutzmaßnahmen umfassen Rate Limiting, Verrauschung der Modellantworten sowie Zugriffskontrollen auf Modellebene.
Fazit
Die OWASP Top 10 for LLM Applications liefern einen systematischen Einstieg in die Bedrohungslage generativer KI-Anwendungen. Durch die Verbindung mit internationalen Rahmenwerken wie dem NIST AI RMF und den Bedrohungsmodellen der ENISA entsteht ein konsistentes Sicherheitsbild. Reale Vorfälle belegen, dass die Risiken bereits heute praktisch relevant sind. Für Sicherheitsverantwortliche bedeutet das: LLM-Sicherheit muss als eigenständige Domäne verstanden und mit technischen, organisatorischen und regulatorischen Mitteln adressiert werden – bevor aus Produktivsystemen neue Angriffsflächen entstehen.
Literatur
[1] OWASP: Top 10 for Large Language Model Applications, 2023, https://owasp.org/www-project-top-10-for-large-language-model-applications/
[2] ENISA: Artificial Intelligence Threat Landscape, 2023, https://www.enisa.europa.eu/publications/artificial-intelligence-threat-landscape
[3] NIST: AI Risk Management Framework (AI RMF 1.0), 2023, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
[4] Carlini, N. et al.: Extracting Training Data from Large Language Models, 2021, https://arxiv.org/abs/2012.07805
[5] OpenAI: Security Best Practices for API Users, https://platform.openai.com/docs/guides/security-best-practices
[6] OpenAI: March 20 ChatGPT Outage Report, https://openai.com/blog/march-20-chatgpt-outage
[7] Ars Technica: Hidden commands in Microsoft Office files can prompt Copilot to expose data, https://arstechnica.com/information-technology/2023/09/hidden-commands-in-microsoft-office-files-can-prompt-copilot-to-expose-data/