LLM-Sicherheit: OWASP LLM Top 10, Prompt Injection und der Weg zu sicherer generativer KI

Kurz gesagt: LLM-Sicherheit schützt Anwendungen mit großen Sprachmodellen vor Angriffen wie Prompt Injection, Datenabfluss und Datenvergiftung. Der maßgebliche Referenzrahmen ist die OWASP LLM Top 10 in der Version 2025. Wirksamer Schutz entsteht nicht durch ein einzelnes Tool, sondern durch geschichtete Maßnahmen, eingebettet in ein Managementsystem nach ISO 42001 und ISO 27001.

LLM-Sicherheit auf einen Blick

• Definition: LLM-Sicherheit umfasst alle Maßnahmen, die Anwendungen mit großen Sprachmodellen (LLMs) und generativer KI vor Missbrauch, Manipulation und Datenabfluss schützen.
• Referenzrahmen: die OWASP Top 10 für LLM-Anwendungen in der Version 2025 (LLM01 bis LLM10).
• Größtes Risiko: Prompt Injection (LLM01:2025), direkt über Nutzereingaben oder indirekt über externe Inhalte.
• Threat-Modeling: MITRE ATLAS dokumentiert reale Angriffstaktiken gegen KI-Systeme.
• Governance: Verankerung in einem KI-Managementsystem nach ISO 42001 und einem ISMS nach ISO 27001; NIST AI RMF als Risikorahmen.
• Regulatorik: der EU AI Act verlangt in Artikel 15 Genauigkeit, Robustheit und Cybersicherheit für Hochrisiko-KI.
• Wichtig: Es gibt keinen einzelnen vollständigen Schutz gegen Prompt Injection; nötig sind geschichtete Maßnahmen.

Was ist LLM-Sicherheit?

LLM-Sicherheit (englisch LLM Security) bezeichnet die Disziplin, Anwendungen mit großen Sprachmodellen über ihren gesamten Lebenszyklus gegen Angriffe und Fehlverhalten abzusichern. Dazu zählen das Modell selbst, die vorgelagerten Daten und Embeddings, die Schnittstellen sowie die nachgelagerten Systeme, die Modellausgaben weiterverarbeiten.

Der entscheidende Unterschied zur klassischen Anwendungssicherheit liegt in der Angriffsfläche. Ein Sprachmodell trennt nicht zuverlässig zwischen Anweisung und Inhalt: Eine Eingabe, die wie harmloser Text aussieht, kann das Verhalten des Modells umsteuern. Dadurch entstehen Risiken, die herkömmliche Web Application Firewalls und einfache Eingabefilter nicht vollständig abdecken.

LLM-Sicherheit ist deshalb kein reines Tooling-Thema. Sie verbindet technische Schutzmaßnahmen mit Governance: klaren Verantwortlichkeiten, Risikobewertung und einem Managementsystem, das den sicheren Betrieb dauerhaft trägt.

LLM-Sicherheit und klassische IT-Sicherheit: der Unterschied

LLM-Sicherheit ersetzt klassische IT-Sicherheit nicht, sondern erweitert sie um KI-spezifische Angriffsflächen:

• Angriffsvektor: klassisch über Code und Konfiguration; bei LLMs zusätzlich über natürliche Sprache und externe Inhalte (Prompt Injection).
• Vertrauensgrenze: klassisch klar zwischen Code und Daten getrennt; ein Sprachmodell vermischt Anweisung und Inhalt und verwischt diese Grenze.
• Determinismus: klassische Systeme reagieren deterministisch; LLMs sind probabilistisch, dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen.
• Datenrisiko: neben klassischen Lecks werden Trainings- und Embedding-Daten zum Angriffsziel (Poisoning, Extraktion).

Warum LLM-Sicherheit jetzt zählt

Generative KI ist in kürzester Zeit vom Experiment zum produktiven Bestandteil von Kundenservice, Wissensmanagement und Softwareentwicklung geworden. Mit jedem Sprachmodell, das an interne Daten, Werkzeuge oder Agenten angebunden wird, wächst die Angriffsfläche. Ein erfolgreicher Angriff kann vertrauliche Daten offenlegen, falsche Auskünfte erzeugen oder über angebundene Werkzeuge ungewollte Aktionen auslösen.

Parallel steigt der regulatorische Druck. Der EU AI Act verlangt für Hochrisiko-KI ausdrücklich Robustheit und Cybersicherheit, und Kunden erwarten zunehmend den Nachweis, dass KI sicher betrieben wird. LLM-Sicherheit ist damit zugleich eine technische und eine Compliance-Anforderung.

Verwandtes Risiko aus der Praxis: Shadow AI kontrollieren statt verbieten: Wie ein AI Governance Framework wirklich schützt

Die OWASP LLM Top 10 for LLM Applications 2025

Der wichtigste Referenzrahmen für LLM-Sicherheit ist die OWASP Top 10 für LLM-Anwendungen. Die aktuelle Fassung stammt aus dem Jahr 2024 und löst die ältere Liste von 2023 ab. Die zehn Risiken im Überblick, jeweils mit der zentralen Gegenmaßnahme:

• LLM01:2025 Prompt Injection: Eingaben verändern das Modellverhalten in unbeabsichtigter Weise. Gegenmaßnahme: Eingaben und Ausgaben filtern, Rechte einschränken, menschliche Freigabe für kritische Aktionen.
• LLM02:2025 Sensitive Information Disclosure: Das Modell gibt vertrauliche Daten preis. Gegenmaßnahme: Datenminimierung, Zugriffskontrolle und Prüfung der Ausgaben.
• LLM03:2025 Supply Chain: Risiken aus Modellen, Bibliotheken und Trainingsdaten Dritter. Gegenmaßnahme: Herkunftsprüfung, Lieferantenkontrollen und eine AI-Bill-of-Materials.
• LLM04:2025 Data and Model Poisoning: Manipulierte Trainings- oder Feinabstimmungsdaten schleusen Hintertüren oder Verzerrungen ein. Gegenmaßnahme: Datenherkunft sichern, validieren, überwachen.
• LLM05:2025 Improper Output Handling: Modellausgaben werden ungeprüft weiterverarbeitet. Gegenmaßnahme: Ausgaben validieren, kodieren und wie nicht vertrauenswürdige Eingaben behandeln.
• LLM06:2025 Excessive Agency: Das Modell erhält zu weitreichende Rechte oder Werkzeuge. Gegenmaßnahme: Least Privilege, enge Werkzeugrechte, menschliche Freigabe.
• LLM07:2025 System Prompt Leakage: Der System-Prompt mit sensiblen Anweisungen wird offengelegt. Gegenmaßnahme: keine Geheimnisse im System-Prompt, Schutz auf Architekturebene.
• LLM08:2025 Vector and Embedding Weaknesses: Schwachstellen in Vektor- und Embedding-Datenbanken, etwa bei RAG. Gegenmaßnahme: Zugriffskontrolle sowie Trennung und Kennzeichnung externer Inhalte.
• LLM09:2025 Misinformation: Das Modell erzeugt falsche, aber plausible Inhalte. Gegenmaßnahme: Quellenbindung über RAG, Faktenprüfung und menschliche Aufsicht.
• LLM10:2025 Unbounded Consumption: Unkontrollierter Ressourcenverbrauch bis hin zur Dienstverweigerung. Gegenmaßnahme: Rate Limiting, Kontingente und Monitoring.

Prompt Injection: das größte LLM-Risiko

Prompt Injection steht nicht ohne Grund an erster Stelle der OWASP-Liste. Der Begriff wurde 2022 in Anlehnung an SQL Injection geprägt und beschreibt Eingaben, die das Modell dazu bringen, seine eigentlichen Anweisungen zu missachten. Man unterscheidet zwei Formen:

• Direkte Prompt Injection: Der Angreifer gibt die manipulierende Anweisung unmittelbar ein, etwa im Chat, um das Modell zur Missachtung seiner Sicherheitsregeln zu bewegen.
• Indirekte Prompt Injection: Die Anweisung versteckt sich in externen Inhalten, die das Modell verarbeitet, etwa in einer Webseite, einem Dokument oder einer E-Mail. Das ist besonders gefährlich bei RAG-Systemen und Agenten, die fremde Inhalte abrufen.

Wichtig zu verstehen: Es gibt bislang keinen Filter, der Prompt Injection vollständig verhindert. OWASP und führende Sicherheitsforscher betonen, dass Filterung allein nicht genügt. Wirksam ist erst die Kombination aus geringsten Rechten (Least Privilege), strenger Behandlung der Ausgaben und menschlicher Freigabe für kritische Aktionen.

Typische Angriffsszenarien

Drei Szenarien zeigen, wie LLM-Risiken in der Praxis zusammenwirken:

• Datenabfluss über ein angebundenes Werkzeug: Ein Angreifer bringt einen Assistenten per Prompt Injection dazu, interne Dokumente abzurufen und in die Antwort zu kopieren. Hier greifen LLM01, LLM02 und LLM06 ineinander.
• Vergiftete RAG-Quelle: In ein Dokument der Wissensdatenbank werden versteckte Anweisungen eingeschleust. Sobald das System dieses Dokument abruft, wird eine indirekte Prompt Injection ausgelöst (LLM01 und LLM08).
• Manipuliertes Modell aus der Lieferkette: Ein aus einer öffentlichen Quelle bezogenes, feinabgestimmtes Modell enthält eine Hintertür. Ohne Herkunftsprüfung gelangt sie unbemerkt in die Produktion (LLM03 und LLM04).

Allen Szenarien ist gemeinsam, dass ein einzelner Schutzmechanismus nicht ausreicht. Erst die Verbindung aus technischer Absicherung und klarer Governance unterbricht die Angriffskette.

Die OWASP LLM Top 10 auf ISO 42001, ISO 27001 und NIST AI RMF abbilden

Die meisten Beiträge zu LLM-Sicherheit behandeln die OWASP-Risiken als reine Tooling-Frage. Für Unternehmen ist jedoch entscheidend, sie in vorhandene Managementsysteme einzubetten. So wird aus einer Liste von Einzelmaßnahmen eine prüfbare, dauerhaft getragene Disziplin. Die folgende Zuordnung zeigt, welcher Rahmen welche Risiken adressiert:

• ISO/IEC 42001 (KI-Managementsystem): steuert den KI-Lebenszyklus. Adressiert vor allem Supply Chain (LLM03), Data and Model Poisoning (LLM04), Excessive Agency (LLM06) und Misinformation (LLM09) über Controls zu Daten, Drittparteien, Folgenabschätzung und menschlicher Aufsicht.
• ISO/IEC 27001 (Informationssicherheit): sichert die darunterliegende Infrastruktur. Adressiert Sensitive Information Disclosure (LLM02), Vector and Embedding Weaknesses (LLM08) und Unbounded Consumption (LLM10) über Zugriffskontrolle, Datenklassifizierung und Verfügbarkeit.
• NIST AI RMF: liefert mit den Funktionen Govern, Map, Measure und Manage einen Risikorahmen, der alle zehn Risiken über den Lebenszyklus hinweg ordnet. Das Generative-AI-Profile (NIST AI 600-1) ergänzt ihn für generative KI.
• EU AI Act, Artikel 15: macht Genauigkeit, Robustheit und Cybersicherheit für Hochrisiko-KI rechtlich verbindlich. ISO 42001 und ISO 27001 liefern die organisatorische Grundlage, um diese Pflichten strukturiert zu erfüllen.

So entsteht ein durchgängiger Bogen: OWASP benennt die technischen Risiken, MITRE ATLAS modelliert die Angriffe, ISO 42001 und ISO 27001 verankern die Steuerung, und der EU AI Act setzt den rechtlichen Rahmen.

Wichtig: Diese Zuordnung ist ein analytisches Hilfsmittel, keine offizielle Norm-Abbildung. In der Praxis überlappen sich die Rahmenwerke, und welcher Control welches Risiko abdeckt, ist eher das Ergebnis einer Abstimmung als eine eindeutige Formel. Die Zuordnung schafft Orientierung, ersetzt aber nicht die eigene Risikobewertung.

Angriffe modellieren mit MITRE ATLAS

Während die OWASP LLM Top 10 die Risikoklassen benennt, liefert MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) die Angreiferperspektive. ATLAS ist eine frei zugängliche, fortlaufend gepflegte Wissensbasis realer Taktiken und Techniken gegen KI-Systeme, aufgebaut nach dem Vorbild von MITRE ATT&CK. Sie umfasst rund 16 Taktiken, über 170 Techniken sowie dokumentierte Fallstudien und Gegenmaßnahmen.

Für die Praxis bedeutet das: Mit ATLAS lassen sich konkrete Angriffspfade durchspielen, etwa das Extrahieren eines Modells (Model Extraction) oder das Umgehen von Schutzmaßnahmen über manipulierte Eingaben. Anders als in der OWASP-Liste von 2023 ist Modelldiebstahl in der Version 2025 kein eigener Top-10-Punkt mehr; als Angriffstechnik bleibt er über MITRE ATLAS abgedeckt. Im Frühjahr 2025 wurde ATLAS gezielt um Techniken für generative KI erweitert, darunter RAG Poisoning, False RAG Entry Injection und LLM Prompt Crafting.

Agentische KI: die nächste Eskalationsstufe

Viele Beiträge behandeln LLM-Anwendungen, als wären sie reine Chatbots. Sobald Sprachmodelle als Agenten agieren, also eigenständig Werkzeuge aufrufen, ein Gedächtnis nutzen und mehrstufige Aufgaben planen, vergrößert sich die Angriffsfläche erheblich.

Das OWASP Gen AI Security Project hat dafür eine eigene Agentic Security Initiative gestartet. Ihre Taxonomie der agentischen Bedrohungen (Anfang 2025) und die im Dezember 2025 veröffentlichten Top 10 for Agentic Applications benennen neue Angriffsflächen: das Agenten-Gedächtnis, die Werkzeug-Anbindung, Identität und Berechtigungen sowie die Koordination mehrerer Agenten.

Typisch agentische Risiken sind Werkzeug-Missbrauch, mehrstufige Prompt-Injection-Ketten und laterale Bewegung über angebundene Werkzeuge hinweg. Die Gegenmaßnahmen folgen denselben Prinzipien, nur strenger angewandt: geringste Rechte je Werkzeug, menschliche Freigabe an kritischen Punkten und eine klare Begrenzung der Autonomie.

Vertiefend zur Absicherung autonomer Agenten: Sicherheitskonzept für autonome KI-Agenten: Spezialisierte Sicherheitsagenten als Überwachungsinstanzen einsetzen

LLM-Sicherheit als Governance-Disziplin

Punktuelle Werkzeuge greifen zu kurz, wenn niemand verantwortlich ist und kein Prozess den sicheren Betrieb trägt. Genau hier setzt der Governance-Ansatz an. Ein KI-Managementsystem nach ISO 42001 schafft die Struktur: Es verlangt Risikobewertung, Folgenabschätzung, klare Rollen und Kontrolle über den gesamten KI-Lebenszyklus, einschließlich der Sicherheit von KI-Systemen als Teil der Risikobehandlung.

Ergänzend sichert ein ISMS nach ISO 27001 die Informationssicherheits-Ebene, auf der die KI aufsetzt. Speziell auf die Cybersicherheit von KI zielt die kommende ISO/IEC 27090, ein nicht-zertifizierbarer Leitfaden, der sich Stand 2026 noch in Entwicklung befindet; eine begleitende Norm ISO/IEC 27091 adressiert den Datenschutz. Bis diese veröffentlicht sind, bilden ISO 42001 und ISO 27001 gemeinsam das tragfähige Fundament.

Über die ISO-Welt hinaus haben sich international abgestimmte Baselines etabliert. Die „Guidelines for Secure AI System Development" von CISA und dem britischen NCSC (November 2023, mitgetragen von Behörden aus 18 Ländern) beschreiben einen sicheren KI-Lebenszyklus nach dem Prinzip Secure by Design. Ergänzend verbindet NIST mit dem Entwurf NIST IR 8596 (Cyber AI Profile, Dezember 2025) Cybersicherheit und KI auf Basis des CSF 2.0. Diese Rahmenwerke ergänzen ISO 42001 und ISO 27001, statt sie zu ersetzen.

Schutzmaßnahmen: geschichtete Verteidigung

Wirksame LLM-Sicherheit folgt dem Prinzip der geschichteten Verteidigung. Keine einzelne Maßnahme genügt; erst ihr Zusammenspiel senkt das Risiko spürbar:

• Eingaben filtern und prüfen, aber nicht als alleinigen Schutz gegen Prompt Injection verstehen.
• Ausgaben strikt behandeln: validieren, kodieren und nie ungeprüft an nachgelagerte Systeme übergeben.
• Least Privilege für Modelle, Werkzeuge und Agenten, um Excessive Agency zu begrenzen.
• Menschliche Freigabe (Human-in-the-Loop) für kritische oder irreversible Aktionen.
• Sandboxing und Isolierung der Werkzeug- und Code-Ausführung.
• Rate Limiting und Kontingente gegen unkontrollierten Ressourcenverbrauch.
• Externe Inhalte für RAG kennzeichnen, trennen und nur aus vertrauenswürdigen Quellen beziehen.
• Adversariales Testen und regelmäßiges Red Teaming, begleitet von Monitoring.

Häufige Missverständnisse über LLM-Sicherheit

• „Ein guter Filter verhindert Prompt Injection." Nein. Filterung hilft, ist aber kein vollständiger Schutz und muss mit Least Privilege und strenger Ausgabe-Behandlung kombiniert werden.
• „Sicherheit ist allein Sache des KI-Anbieters." Nur teilweise. Für die eigene Anwendung, die Daten und die angebundenen Werkzeuge bleibt das Unternehmen verantwortlich.
• „RAG macht das Modell sicher." Nein. RAG verbessert die Faktentreue, eröffnet über externe Inhalte aber neue Wege für indirekte Prompt Injection.
• „LLM-Sicherheit ist ein reines Entwicklerthema." Nein. Ohne Governance, klare Verantwortlichkeiten und ein Managementsystem bleibt sie Stückwerk.
• „ISO 27001 genügt für KI." Nein. ISO 27001 sichert die Infrastruktur, deckt KI-spezifische Risiken aber nicht vollständig ab; ISO 42001 ergänzt sie.

Erste Schritte zu sicherer generativer KI

Ein pragmatischer Einstieg ordnet die Maßnahmen, statt einzelne Tools zu kaufen:

1. Bestandsaufnahme: Welche LLM-Anwendungen, Datenquellen, Werkzeuge und Agenten sind im Einsatz?
2. Bedrohungsmodell erstellen, orientiert an den OWASP LLM Top 10 und an MITRE ATLAS.
3. Risiken auf ISO 42001 und ISO 27001 abbilden und Verantwortliche benennen.
4. Geschichtete Schutzmaßnahmen umsetzen und Red Teaming etablieren.
5. Den sicheren Betrieb in das KI-Managementsystem überführen und regelmäßig auditieren.

Regulatorischer Kontext: EU AI Act Hochrisiko: Was Unternehmen bis August 2026 umsetzen müssen

Häufig gestellte Fragen zur LLM-Sicherheit

Was ist LLM-Sicherheit?

LLM-Sicherheit ist die Disziplin, Anwendungen mit großen Sprachmodellen über ihren gesamten Lebenszyklus gegen Angriffe und Fehlverhalten abzusichern. Sie verbindet technische Schutzmaßnahmen gegen Risiken wie Prompt Injection mit Governance, also Verantwortlichkeiten, Risikobewertung und einem Managementsystem für den sicheren Betrieb.

Was sind die OWASP LLM Top 10?

Die OWASP Top 10 für LLM-Anwendungen sind der maßgebliche Referenzrahmen für die häufigsten Sicherheitsrisiken generativer KI. Die aktuelle Version 2025 reicht von LLM01 Prompt Injection bis LLM10 Unbounded Consumption und nennt zu jedem Risiko passende Gegenmaßnahmen.

Was ist Prompt Injection?

Prompt Injection ist ein Angriff, bei dem eine Eingabe das Sprachmodell dazu bringt, seine eigentlichen Anweisungen zu missachten. Der Begriff wurde 2022 in Anlehnung an SQL Injection geprägt und steht als LLM01:2025 an erster Stelle der OWASP-Liste.

Was ist der Unterschied zwischen direkter und indirekter Prompt Injection?

Bei direkter Prompt Injection gibt der Angreifer die manipulierende Anweisung unmittelbar ein, etwa im Chat. Bei indirekter Prompt Injection versteckt sie sich in externen Inhalten, die das Modell verarbeitet, etwa in Webseiten oder Dokumenten. Die indirekte Form ist besonders bei RAG-Systemen und Agenten gefährlich.

Kann man Prompt Injection vollständig verhindern?

Nein. Es gibt bislang keinen Filter, der Prompt Injection vollständig verhindert. Wirksam ist nur die Kombination mehrerer Maßnahmen: geringste Rechte, strenge Behandlung der Ausgaben und menschliche Freigabe für kritische Aktionen.

Deckt ISO 42001 die LLM-Sicherheit ab?

ISO 42001 ist ein Managementsystem für KI, kein dedizierter Sicherheitsstandard. Es adressiert Sicherheit als Teil der Risikobehandlung über den KI-Lebenszyklus, etwa bei Daten, Drittparteien und Aufsicht. Die rein technische LLM-Sicherheit ergänzen die OWASP LLM Top 10, ISO 27001 und die kommende ISO/IEC 27090.

Reicht ISO 27001 für generative KI aus?

Nein. ISO 27001 sichert die Informationssicherheit der Infrastruktur, deckt aber KI-spezifische Risiken wie Prompt Injection oder Datenvergiftung nicht vollständig ab. Für generative KI kombiniert man ISO 27001 mit ISO 42001 und den OWASP LLM Top 10.

Wie hängt der EU AI Act mit LLM-Sicherheit zusammen?

Der EU AI Act verlangt in Artikel 15 für Hochrisiko-KI ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit über den gesamten Lebenszyklus. LLM-Sicherheit liefert die technischen Maßnahmen, ISO 42001 und ISO 27001 die organisatorische Grundlage, um diese Pflicht zu erfüllen.

Was ist MITRE ATLAS?

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) ist eine frei zugängliche Wissensbasis realer Taktiken und Techniken für Angriffe auf KI-Systeme, aufgebaut nach dem Vorbild von MITRE ATT&CK. Sie hilft, Angriffspfade zu modellieren und Gegenmaßnahmen abzuleiten.

Wie fange ich mit LLM-Sicherheit an?

Mit einer Bestandsaufnahme der LLM-Anwendungen, einem Bedrohungsmodell nach OWASP LLM Top 10 und MITRE ATLAS, der Zuordnung der Risiken zu ISO 42001 und ISO 27001, der Umsetzung geschichteter Schutzmaßnahmen sowie regelmäßigem Red Teaming und Auditierung im KI-Managementsystem.