Sicherheit von LLMs - Daten gleich Code

Die Kurzform des LLM-Sicherheitsproblems lautet: Daten sind wieder Code. Nicht im engen Sinn von Maschinencode, der direkt auf einer CPU ausgeführt wird. Aber in einem funktional relevanten Sinn: Text, Dokumente, Webseiten, E-Mails oder Suchtreffer können das Verhalten eines Systems steuern, wenn ein Sprachmodell sie als Teil seines Kontexts verarbeitet.

Klassische IT-Sicherheit lebt von Trennungen. Code wird ausgeführt, Daten werden verarbeitet, Konfiguration wird kontrolliert, Nutzereingaben werden validiert. Diese Trennungen sind nie perfekt, aber sie bilden die Grundlage für Prepared Statements, Sandboxing, Rechtekonzepte, Content Security Policies, No-Execute-Bits und viele andere Schutzmechanismen.

LLM-Anwendungen weichen diese Ordnung auf. Systeminstruktionen, Nutzereingaben, RAG-Dokumente, Tool-Beschreibungen und Zwischenergebnisse landen häufig im selben Kontextfenster. Das Modell muss daraus ableiten, was Aufgabe, Hintergrundinformation, Zitat, fremde Anweisung oder gefährliche Manipulation ist. Genau diese Unterscheidung ist nicht formal garantiert.

Das Sicherheitsdilemma

Ein Sprachmodell führt Prompt-Text nicht wie Programmcode aus. Trotzdem kann ein Prompt eine ähnliche Rolle einnehmen wie Code in einem integrierten System: Er beeinflusst, welche Antwort erzeugt wird, welche Tools aufgerufen werden und welche Daten weitergegeben werden. Aus Sicherheitsperspektive zählt daher nicht nur, ob Text "ausgeführt" wird, sondern ob er handlungsleitend werden kann.

In traditionellen Systemen lassen sich gefährliche Eingaben oft syntaktisch beschreiben. SQL-Injection nutzt bestimmte Zeichen, Strukturen und Kontexte. Cross-Site Scripting nutzt HTML- und JavaScript-Kontexte. Für viele dieser Probleme gibt es robuste technische Muster: Escaping, Parameter Binding, Isolation, Typisierung.

Bei natürlicher Sprache existiert diese klare Grenze nicht. Eine schädliche Instruktion kann höflich, indirekt, mehrsprachig, verschachtelt, ironisch, als Zitat, als Dokumentinhalt oder als scheinbare Metaanweisung formuliert sein. Zwei syntaktisch sehr verschiedene Eingaben können dieselbe Wirkung haben, und zwei ähnliche Eingaben können völlig unterschiedliche Bedeutungen tragen.

Das Unentscheidbarkeitsproblem im Sicherheitskontext

Die Behauptung, Prompt-Sicherheit sei nicht allgemein entscheidbar, sollte nicht als mathematische Effekthascherei verstanden werden. Gemeint ist: Für beliebige natürliche Sprache, beliebige Kontexte, beliebige Modellzustände, beliebige Tool-Landschaften und beliebige Zieldefinitionen gibt es keinen einfachen Prüfer, der vorab sicher entscheidet, ob eine Eingabe harmlos bleibt.

Die Analogie zum Halting-Problem ist hier hilfreich, wenn sie richtig eingeordnet wird. Sie bedeutet nicht, dass jeder konkrete Prompt unprüfbar ist. Viele Angriffe lassen sich erkennen, viele Risiken lassen sich reduzieren, viele Aktionen lassen sich technisch blockieren. Sie bedeutet aber, dass vollständige Sicherheit durch einen vorgelagerten Prompt-Filter nicht erreichbar ist. Das Problem liegt nicht nur in fehlenden Blacklists, sondern in der offenen Semantik des Eingaberaums.

Damit unterscheidet sich Prompt Injection von klassischen Injection-Problemen. Bei SQL-Injection konnte die Industrie mit Prepared Statements eine robuste Trennung zwischen Befehl und Daten etablieren. Bei LLMs ist genau diese Trennung Gegenstand der Modellinterpretation. Der Parser ist nicht nur ein Parser, sondern ein probabilistisches Sprachmodell.

Prompt Injection

Prompt Injection tritt auf, wenn Eingaben das vom Betreiber gewünschte Verhalten eines LLM-Systems verändern. Direkte Prompt Injection kommt vom Nutzer selbst. Indirekte Prompt Injection wird über externe Inhalte eingeschleust, etwa Webseiten, E-Mails, Dokumente, Tickets, PDFs oder Einträge in Wissensdatenbanken.

Ein direkter Angriff kann versuchen, Systeminstruktionen zu überschreiben oder Prioritäten umzudeuten. Ein indirekter Angriff kann in einem Dokument versteckt sein, das ein RAG-System später abruft. Für das Modell erscheint dieser Text dann im Kontext der Aufgabe. Wenn das System keine robuste Trennung zwischen untrusted content und eigenen Instruktionen erzwingt, kann fremder Inhalt die Systemausgabe beeinflussen.

Genau darin liegt die besondere Gefahr. Der eigentliche Nutzer muss den Angriff nicht sehen. Ein Assistent, der E-Mails zusammenfasst, Webseiten auswertet oder interne Dokumente durchsucht, kann manipulierte Inhalte aufnehmen und daraus Handlungsanweisungen ableiten. Greshake et al. beschrieben diese indirekten Prompt-Injection-Risiken bereits 2023 als Angriff auf LLM-integrierte Anwendungen, bei denen fremde Datenquellen das Verhalten des Systems steuern können.⁷²⁴

Grenzen des Input-Filterings

Input-Filtering bleibt nützlich, aber es ist keine Lösung des Grundproblems. Blacklists gegen Phrasen wie "ignore previous instructions" blockieren nur bekannte Oberflächenformen. Angreifer können dieselbe Absicht anders formulieren, übersetzen, codieren, mit irrelevanten Informationen umgeben oder als legitimen Arbeitsauftrag tarnen.

LLMs sind gerade deshalb nützlich, weil sie ungenaue, variantenreiche und fehlerhafte Sprache interpretieren können. Im Sicherheitskontext wird diese Robustheit zur Schwäche. Ein klassischer Filter kann an Tippfehlern, Synonymen, Unicode-Tricks, Homoglyphen, Rollenwechseln oder semantischen Umwegen scheitern, während das Modell die Absicht trotzdem rekonstruiert.

Das gilt auch für wohlformatierte Systeme. Selbst wenn externe Inhalte als Zitat markiert oder in XML/JSON eingeschlossen werden, bleibt die Frage, ob das Modell diese Grenze zuverlässig respektiert. Strukturierung hilft, ersetzt aber keine Zugriffskontrolle, keine Tool-Grenzen und keine nachgelagerte Validierung.

RAG, Vektoren und Tool-Risiken

Retrieval-Augmented Generation verschärft das Problem, weil das Modell nicht nur Nutzereingaben verarbeitet, sondern auch dynamisch abgerufene Inhalte. Ein manipuliertes Dokument in Confluence, SharePoint, einem Ticketsystem oder einer öffentlichen Webseite kann später als Kontext in eine Antwort gelangen. Aus Sicht der Anwendung ist es "Wissen"; aus Sicht des Angreifers ist es ein Transportweg für Instruktionen.

Vector Stores bringen eigene Risiken mit. Embeddings können manipuliert, vergiftet oder so platziert werden, dass schädliche Dokumente bei bestimmten Anfragen bevorzugt abgerufen werden. OWASP 2025 nennt solche Vector and Embedding Weaknesses ausdrücklich als eigene Risikokategorie.⁷²⁵ Das ist wichtig, weil RAG häufig als Sicherheitsmaßnahme dargestellt wird, obwohl es selbst eine zusätzliche Angriffsfläche erzeugt.

Noch kritischer wird die Lage bei Tool-Use. Ein Modell, das nur Text erzeugt, kann falsche Informationen ausgeben. Ein Modell mit Zugriff auf E-Mail, Kalender, Dateisystem, Kundendatenbank, CRM, Terminal oder Zahlungsprozesse kann Handlungen auslösen. Dann wird Prompt Injection von einem Ausgabeproblem zu einem Berechtigungsproblem.

OWASP Top 10 2025

Die OWASP Gen AI Security Project Top 10 für 2025 ordnen die wichtigsten Risiken für LLM- und GenAI-Anwendungen neu. Die Liste lautet:⁷²⁶

1. LLM01 - Prompt Injection: Manipulation von Modellverhalten durch direkte oder indirekte Eingaben
2. LLM02 - Sensitive Information Disclosure: unbeabsichtigte Offenlegung vertraulicher Informationen
3. LLM03 - Supply Chain: Risiken durch Modelle, Daten, Komponenten, Plugins und Integrationen
4. LLM04 - Data and Model Poisoning: Manipulation von Trainings-, Fine-Tuning-, Embedding- oder RAG-Daten
5. LLM05 - Improper Output Handling: unzureichende Prüfung von Modelloutputs vor Weiterverarbeitung
6. LLM06 - Excessive Agency: zu weitgehende Handlungsmacht und Berechtigungen
7. LLM07 - System Prompt Leakage: Offenlegung interner Instruktionen oder Betriebslogik
8. LLM08 - Vector and Embedding Weaknesses: Angriffe auf Retrieval, Embeddings und Vektorspeicher
9. LLM09 - Misinformation: falsche oder irreführende Ausgaben in abhängigen Prozessen
10. LLM10 - Unbounded Consumption: Ressourcenmissbrauch, Kostenexplosion oder Denial-of-Service

Die Verschiebung gegenüber früheren Versionen ist aufschlussreich. Risiken rund um Supply Chain, Vektoren, Embeddings und System Prompt Leakage werden expliziter. Das passt zur Entwicklung der Anwendungen: LLMs sind nicht mehr nur Chatfenster, sondern eingebundene Systeme mit Datenquellen, Tools, Speichern und Berechtigungen.

Supply Chain und Modellherkunft

LLM-Anwendungen erben Risiken aus ihrer gesamten Lieferkette. Dazu gehören Basismodelle, Fine-Tuning-Daten, LoRA-Adapter, Embedding-Modelle, Vektordatenbanken, Prompt-Templates, Agent-Frameworks, Plugins, Evaluationsdaten und externe APIs. Ein schwaches Glied reicht aus, um das Verhalten des Gesamtsystems zu beeinflussen.

Modellmarktplätze und Open-Weight-Ökosysteme sind produktiv, aber nicht automatisch vertrauenswürdig. Ein scheinbar spezialisiertes Modell kann Backdoors enthalten, ein Adapter kann Verhalten subtil verschieben, ein Datensatz kann vergiftet sein. Anders als bei normalem Anwendungscode ist die Prüfung schwierig, weil das Verhalten nicht vollständig aus lesbarem Quelltext hervorgeht.

Für Betreiber bedeutet das: Modell- und Datenherkunft müssen dokumentiert werden. Checksums, Modellkarten, Lizenzprüfung, reproduzierbare Evaluierungen, kontrollierte Update-Prozesse und getrennte Testumgebungen werden wichtiger. Supply-Chain-Security endet nicht beim Code-Repository.

Grenzen klassischer Security-Ansätze

Sandboxing bleibt wichtig, löst aber nicht das ganze Problem. Ein isoliertes Modell ohne Tools ist sicherer, aber oft weniger nützlich. Der Wert vieler LLM-Anwendungen entsteht gerade durch Zugriff auf interne Daten und externe Systeme. Jede Integration erweitert die Angriffsfläche.

Deterministische Sicherheitsannahmen passen nur teilweise. LLMs können bei gleicher Eingabe unterschiedliche Ausgaben erzeugen, und kleine Kontextänderungen können Verhalten verschieben. Das erschwert klassische Tests, Freigaben und Audits. Sicherheit muss deshalb stärker statistisch, prozessual und architektonisch gedacht werden.

Auch Code-Review greift nur eingeschränkt. Die Anwendungsschicht kann geprüft werden, aber das Modellverhalten selbst bleibt nur über Evaluierungen, Red Teaming, Monitoring und begrenzte Handlungsräume kontrollierbar. Es gibt keine vollständige statische Analyse eines großen Sprachmodells, die alle sicherheitsrelevanten Reaktionen vorhersagt.

Mitigation ist Symptombekämpfung

Realistische Schutzmaßnahmen sind notwendig, aber sie beseitigen das Grundproblem nicht. Sie reduzieren Eintrittswahrscheinlichkeit und Schadenshöhe. Genau deshalb sollten sie als kontrollierte Symptombekämpfung verstanden werden, nicht als Nachweis vollständiger Sicherheit.

Externe Inhalte müssen technisch und promptseitig als nicht vertrauenswürdig behandelt, also als untrusted markiert und isoliert werden. Das Modell sollte wissen, welche Texte nur Quelle sind und welche Instruktionen vom System oder Nutzer stammen. Diese Markierung hilft, ist aber nicht absolut zuverlässig.

Das Modell darf nur Tools verwenden, die für die Aufgabe nötig sind (Allowlisting und Least Privilege). Tools sollten enge Parameter, klare Schemata und serverseitige Validierung haben. Ein Assistent für Rechnungsfragen braucht keinen administrativen Datenbankzugriff.

Kritische Aktionen brauchen eine menschliche Freigabe. E-Mails an externe Empfänger, Datenlöschungen, Zahlungen, Vertragsänderungen, Kundendatenexporte oder produktive Codeänderungen sollten nicht allein durch Modellentscheidung ausgelöst werden. Das System kann vorbereiten, aber nicht selbst freigeben.

Modelloutputs müssen validiert werden, bevor sie in SQL, HTML, Shell-Kommandos, API-Calls oder Geschäftsprozesse eingehen. Bei strukturierten Ausgaben helfen JSON-Schemas, formale Grammatiken, Typprüfung und serverseitige Regeln. Das Ziel ist, das Downstream-System zu schützen, nicht das Modell "sicher" zu machen.

Für Audit Logs und Reproduzierbarkeit sollten Systeme Eingaben, abgerufene Quellen, Tool-Aufrufe, Modellversionen, Parameter, Entscheidungen und Freigaben protokollieren. Ohne Logs bleiben Vorfälle schwer nachvollziehbar.

Unbounded Consumption ist ein reales Risiko, dem Rate Limits und Ressourcenbudgets begegnen. Tokenbudgets, Zeitlimits, Tool-Call-Grenzen, Kostenlimits und Abbruchbedingungen schützen gegen Missbrauch und Fehlverhalten.

Evals und Red Teaming gehören in die Entwicklung: Prompt-Injection-Tests, RAG-Poisoning-Szenarien, System-Prompt-Leakage-Tests und Tool-Missbrauch sollten Teil davon sein. Solche Tests beweisen keine Sicherheit, zeigen aber bekannte Schwachstellen und Regressionen.

Compliance und EU AI Act

Der EU AI Act macht nicht jede LLM-Anwendung automatisch zu einem Hochrisikosystem. Die Einordnung hängt von Zweck, Einsatzkontext und konkreter Anwendung ab. Hochrisiko-Kategorien ergeben sich insbesondere aus Artikel 6 und Annex III, wobei auch Ausnahmen für eng begrenzte oder vorbereitende Aufgaben vorgesehen sind.⁷²⁷

Für Betreiber ist trotzdem relevant, dass LLM-Anwendungen in regulierte Prozesse hineinwirken können. Wenn ein System Bewerbungen vorsortiert, Kreditentscheidungen vorbereitet, medizinische Entscheidungen beeinflusst oder Zugang zu Leistungen steuert, entstehen andere Pflichten als bei einem internen Textassistenten. Entscheidend ist nicht das Modell allein, sondern die Funktion im konkreten Prozess.

Daneben enthält der AI Act eigene Pflichten für Anbieter von General-Purpose-AI-Modellen. Für Modelle mit systemischem Risiko sieht die Verordnung zusätzliche Anforderungen vor, etwa Risikobewertung, adversarial testing, Sicherheitsmaßnahmen und Incident Reporting.⁷²⁸ Diese Pflichten liegen nicht automatisch beim normalen Anwender eines Modells, beeinflussen aber die Lieferkette und die Dokumentationserwartungen.

Leben mit probabilistischer Unsicherheit

LLM-Sicherheit ist kein Zustand, der einmal erreicht und dann abgehakt wird. Sie ist ein Betriebsmodell. Systeme müssen so gestaltet werden, dass Fehlverhalten erwartet, begrenzt, erkannt und korrigiert werden kann. Das ist unbequem, aber realistischer als das Versprechen eines perfekten Prompt-Filters.

Die zentrale Designfrage lautet: Was darf passieren, wenn das Modell falsch liegt, manipuliert wird oder eine fremde Instruktion ernst nimmt? Je folgenreicher die Antwort, desto enger müssen Berechtigungen, Freigaben und technische Grenzen sein.

Sichere LLM-Integration bedeutet daher nicht, dem Modell mehr zu vertrauen. Sie bedeutet, das Modell als nützliche, aber fehlbare Komponente in ein System einzubauen, dessen kritische Entscheidungen außerhalb des Modells kontrolliert werden.

Fazit: Daten gleich Code

"Daten gleich Code" ist keine exakte Beschreibung der Ausführungsebene, aber eine treffende Sicherheitsintuition. In LLM-Anwendungen können Daten Verhalten steuern. Externe Inhalte können Instruktionen enthalten. Retrieval kann Angriffe einschleusen. Tools können aus Text Handlung machen.

Das Grundproblem lässt sich nicht durch einen einzelnen Filter beheben. Mitigation bleibt Symptombekämpfung: notwendig, wirksam in Grenzen, aber nicht endgültig. Tragfähige LLM-Sicherheit entsteht durch Architektur: klare Vertrauensgrenzen, minimale Berechtigungen, überprüfte Tool-Aufrufe, menschliche Freigaben, Protokollierung, Tests und die Bereitschaft, Modelle nicht dort handeln zu lassen, wo ein Fehler nicht akzeptabel ist.

Quellen

1. Greshake et al.: Not what you've signed up for - Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection ↩
2. OWASP Gen AI Security Project: 2025 Top 10 Risks & Mitigations for LLMs and Gen AI Apps ↩
3. Regulation (EU) 2024/1689, Article 6 and Annex III - Artificial Intelligence Act ↩
4. Regulation (EU) 2024/1689, Articles 53-55 - General-purpose AI models ↩
5. DeepSeek V4-Pro Cuts Prices 75% Permanently. AI Automation Global, 2026. https://aiautomationglobal.com/blog/deepseek-v4-pro-75-percent-permanent-price-cut-inference-war-2026 ↩
6. AI API Pricing War 2026: Costs Dropped 60-80%. TokenMix, 2026. https://tokenmix.ai/blog/ai-api-pricing-war-2026 ↩
7. Startups and tech giants wage AI price war as inference costs spiral. Crypto Briefing, 2026. https://cryptobriefing.com/ai-price-war-startups-tech-giants/ ↩
8. Tokens are getting cheaper, but AI costs keep climbing. Fortune, 2026. https://fortune.com/2026/06/17/why-is-ai-spending-increasing-as-tokens-get-cheaper-jevons-paradox/ ↩
9. AI inference costs set to plunge. CIO Dive zu Gartner, 2026. https://www.ciodive.com/news/ai-inference-costs-drop-2030-gartner/815725/ ↩
10. Why Anthropic's 70% Inference Margins Matter for Your API Costs. MindStudio, 2026. https://www.mindstudio.ai/blog/anthropic-inference-margins-70-percent-api-costs ↩
11. Ouyang et al.: Training language models to follow instructions with human feedback ↩
12. OpenAI: GPT-4 Technical Report ↩
13. OpenAI: Learning to reason with LLMs ↩
14. Liu et al.: Lost in the Middle ↩