Sicherheit von LLM-Anwendungen: Schutz vor Prompt-Injection & KI-Leitplanken

Jedes Unternehmen, das ein LLM mit seinen Dokumenten, E-Mails oder Werkzeugen verbindet, schafft eine neue Angriffsfläche: Text eines Angreifers kann vom Modell als Anweisung gelesen werden. Prompt-Injection steht auf Platz eins der OWASP Top 10 für LLM-Anwendungen. Kein einzelner Filter löst das Problem; die praktische Antwort ist daher Verteidigung in der Tiefe: Leitplanken für Ein- und Ausgaben, Werkzeuge mit minimalen Rechten, Isolation nicht vertrauenswürdiger Inhalte, menschliche Freigabe riskanter Aktionen sowie laufende Überwachung und Tests.

Problem & Nutzen

• Heute: Teams liefern Copiloten, RAG-Assistenten und Agenten nach einer kurzen Anpassung des Systemprompts aus. Angriffe sind entweder direkt (ein Nutzer weist den Bot an, seine Regeln zu ignorieren) oder indirekt (eine versteckte Anweisung in einer Webseite, einem PDF, einer E-Mail oder einem Ticket, die das Modell verarbeitet). Folgen: abgeflossene Systemprompts und vertrauliche Daten, manipulierte Antworten, nicht autorisierte Werkzeugaktionen (E-Mail senden, ins CRM schreiben, Code ausführen), Datenabfluss über dargestellte Links oder Bilder und teure außer Kontrolle geratene Nutzung.
• KI-Nutzen: Eine Leitplankenschicht ist selbst ML-basiert (kleine Klassifikatoren und LLM-Bewerter) und erkennt semantische Angriffe, die reguläre Ausdrücke nicht erfassen. Sie ergänzt außerdem das Schwärzen personenbezogener Daten, die Kontrolle von Themen und Toxizität sowie Prüfungen auf Belegtreue und liefert die für Prüfungen nötigen Logs.
• Ehrliche Grenze: Die Taxonomie des NIST zu Angriffen auf maschinelles Lernen hält fest, dass die Gegenmaßnahmen gegen Prompt-Injection unvollständig sind und es keine narrensichere Abwehr gibt [2]. Die Architektur (was das Modell tun darf) zählt mehr als die Erkennungsgenauigkeit.

Varianten

• Chatbot für Kunden: Missbrauch, Jailbreaks, rufschädigende Ausgaben, Abfluss personenbezogener Daten, themenfremde Nutzung.
• Interner RAG-Assistent: indirekte Injection über Dokumente, Abfluss über Zugriffsgrenzen zwischen Nutzern hinweg (Berechtigungen auf Dokumentebene müssen beim Abruf durchgesetzt werden).
• Agenten mit Werkzeugen / MCP-Servern: höchstes Risiko; Tool Poisoning, überprivilegierte Tokens, Confused-Deputy-Aktionen. Siehe die OWASP-Hinweise zu übermäßiger Handlungsfreiheit (Excessive Agency) [1].
• Coding-Assistenten und Browser-Agenten: nicht vertrauenswürdige Repository- oder Webinhalte lenken den Agenten.
• Öffentlicher Sektor / regulierte Branchen: Leitplanken On-Premises, Protokollierung und dokumentierte menschliche Aufsicht.
• Private Nutzung: beschränkt sich auf Vorsicht bei KI-Browsern und E-Mail-Assistenten; keine eigene Produktkategorie.

So funktioniert es

1. Nutzereingabe / abgerufener Inhalt / Werkzeugergebnis
2. Eingabe-Leitplanken (Injection- und Jailbreak-Klassifikator, PII-Erkennung, Richtlinien-/Themenprüfung)
3. LLM mit gehärtetem Prompt (Anweisungshierarchie, nicht vertrauenswürdige Inhalte abgegrenzt, keine Geheimnisse im Prompt)
4. Schranke für Werkzeugaufrufe (Allow-List, Argumentprüfung, eng begrenzte kurzlebige Zugangsdaten, menschliche Freigabe für sensible Aktionen)
5. Ausgabe-Leitplanken (Schwärzen von PII/Geheimnissen, Toxizität, Belegtreue, Filter für Links/Markdown/Datenabfluss)
6. Antwort + strukturierte Protokollierung (SIEM) + regelmäßige Red-Team-Regressionstests

• Erkennungsmodelle: kleine Encoder-Klassifikatoren (z. B. Prompt Guard, Detektoren im Stil von Lakera) und Sicherheits-LLMs (Llama Guard, Granite Guardian, gpt-oss-safeguard, Qwen3Guard) bewerten Eingaben und Ausgaben gegen eine Richtlinie in Millisekunden bis wenigen hundert Millisekunden.
• Architektonische Kontrollen (die stärkste Schicht): privilegierte und isolierte Modelle trennen; nie einem Agenten gleichzeitig Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und einen ausgehenden Kanal geben (die Idee der „tödlichen Dreierkombination“, Lethal Trifecta); Werkzeuge je Aufgabe beschränken und Entwurfsmuster wie Plan-dann-Ausführen oder den CaMeL-Ansatz nutzen, der die Herkunft der Daten verfolgt [5].
• Mensch-in-der-Schleife (Human-in-the-Loop): Freigabe für nicht umkehrbare Aktionen (Zahlungen, externe E-Mails, Löschungen), Prüfung blockierter, aber unsicherer Fälle und Verantwortung für die Leitplankenrichtlinie bei Sicherheit und Fachverantwortlichem gemeinsam.

Datenaufbereitung

Dieser Anwendungsfall braucht wenig Geschäftsdaten, aber gute Test- und Richtliniendaten. Relevant sind der Systemprompt und die Werkzeugdefinitionen (meist im Code-Repository), die Berechtigungen der angebundenen Datenquellen (ERP, DMS, SharePoint, E-Mail) sowie die Anwendungslogs und Traces.

Typische Lücken: zu weit freigegebene SharePoint- oder Dateiablage-Ordner, die ein RAG-Bot im Namen aller lesen kann, keine Datenklassifizierung („was darf in welches KI-Werkzeug“), kein Testsatz mit Angriffen, Logs, die entweder nicht existieren oder ungeschwärzte personenbezogene Daten enthalten, und API-Schlüssel mit zu weitreichenden Rechten.

Schritte der Aufbereitung: (1) die Berechtigungen jeder Quelle bereinigen, die der Assistent lesen kann (PREP-023); (2) Klassifizierungsregeln sowie eine Sperrliste für Geheimnisse und PII-Muster festlegen (PREP-024); (3) gemeinsam mit Fachleuten einen Red-Team- und Regressionssatz bekannter Injection-Prompts aufbauen (PREP-018); (4) reale Missbrauchsfälle und Korrekturen als Labels sammeln (PREP-021); (5) Logs pseudonymisieren, bevor sie gespeichert oder ausgewertet werden (PREP-022).

Werkzeuge: offene Testsuiten für Prompt-Injection wie garak oder promptfoo, der bereits genutzte Logging-Stack und eine kleine Tabelle für den Testsatz. Grober Aufwandsanteil: etwa 10 bis 20 Prozent; die Bereinigung der Berechtigungen ist der größte Posten und nützt allen anderen KI-Anwendungsfällen.

Umsetzungswege

Welcher Weg für wen

• enterprise: C, weil Leitplanken- und Erkennungsmodelle bei jedem Prompt inline laufen und eine gemeinsame interne KI-Plattform selbst betriebene Sicherheitsmodelle (z. B. Llama Guard, Granite Guardian) günstiger macht und die Prompts im Netzwerk hält.
• developer: B, weil verwaltete Sicherheits-APIs und offene Leitplanken-Bibliotheken sich mit wenig Betriebsaufwand direkt in den Anwendungscode einbinden lassen.
• smb: B, weil die Leitplanken in den eigenen Chatbot oder Agenten des Unternehmens eingebaut werden müssen und kein Produkt das anwendungsspezifische Berechtigungsdesign ersetzen kann.
• public: C, weil Prompts, abgerufene Dokumente und Logs oft Bürgerdaten enthalten und das Vergaberecht souveräne, selbst betriebene Komponenten begünstigt.

Weg A — Kaufen (Standardsoftware)

• KI-Sicherheitsplattformen / Gateways: Lakera Guard (Check Point; in der Schweiz gegründet), Protect AI Guardian (Palo Alto Networks), HiddenLayer, Prompt Security (SentinelOne), Straiker, Zenity (Agentensicherheit), Cisco AI Defense, Palo Alto Prisma AIRS, CrowdStrike (Pangea), F5 AI guardrails (CalypsoAI). Zu den Optionen aus der EU bzw. Europa zählen Lakera (CH), Mindgard (UK, Tests) und Giskard (FR, Tests/Evaluierung).
• In Modellplattformen integriert: Azure AI Content Safety mit Prompt Shields, Amazon Bedrock Guardrails, Google Model Armor, Moderations-API von Mistral (EU-Anbieter), Leitplanken des Cloudflare AI Gateway.
• A wählen, wenn: viele Teams KI-Anwendungen ausliefern und Sie zentrale Richtlinien, Protokollierung und SIEM-Anbindung brauchen, ohne sie selbst zu bauen. Prüfen Sie EU-Hosting, die Aufbewahrung von Prompts und die Bedingungen des AVV.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlene Standardwahl für KMU)

• Aktivieren Sie den Leitplankendienst der Modellplattform, die Sie bereits nutzen (Prompt Shields, Bedrock Guardrails, Model Armor), in einer EU-Region und leiten Sie alle Aufrufe über ein Gateway (LiteLLM, Kong, Azure API Management, Cloudflare AI Gateway), das Protokollierung sowie Raten- und Budgetgrenzen übernimmt.
• Nutzen Sie strukturierte Ausgaben und Schemas für Funktionsaufrufe, damit das Modell keine freien Befehle ausgeben kann.
• Ergänzen Sie Microsoft Presidio zur PII-Erkennung und Anonymisierung, bevor Daten Ihren Mandanten verlassen.
• Setzen Sie Berechtigungen je Nutzer in der Abrufschicht durch und geben Sie Agenten eng begrenzte, kurzlebige Tokens.

Weg C — Selbst betreiben (Open Source)

• Frameworks: NVIDIA NeMo Guardrails, Guardrails AI, LLM Guard (Protect AI), LlamaFirewall (Meta, mit PromptGuard 2, Agent Alignment Checks, CodeShield), Rebuff, Microsoft Presidio.
• Modelle: Llama Guard 4, Llama Prompt Guard 2, IBM Granite Guardian, Qwen3Guard, gpt-oss-safeguard, ShieldGemma; bereitgestellt mit vLLM oder Ollama.
• Tests: garak, PyRIT und promptfoo für automatisierte Angriffssuiten (siehe SEC-014).
• Hardware: HW1 für Leitplanken nur mit Klassifikatoren (für Encoder-Modelle genügt die CPU); HW2 für ein kleines Sicherheits-LLM neben dem Hauptmodell. Betriebsaufwand: Schwellenwerte abstimmen und Richtlinien aktuell halten.

Weg D — Eigenes Training

Feintunen Sie einen kleinen Klassifikator auf Ihren eigenen Angriffslogs und Richtlinienverstößen, wenn generische Detektoren bei der Fachsprache (Recht, Medizin, mehrsprachig Deutsch/EU-Sprachen) zu viele Fehlalarme erzeugen. Dafür sind einige tausend beschriftete harmlose und bösartige Beispiele nötig, überwiegend aus Red-Team-Läufen und Produktionslogs.

Stand der Technik (2026)

• Konsens: Prompt-Injection ist nicht „gelöst“; Anbieter und Forschende behandeln sie als Restrisiko, das durch die Architektur begrenzt wird. Adaptive Angriffe aus der Literatur umgehen veröffentlichte Detektoren immer wieder, daher sind Detektorwerte allein kein Nachweis von Sicherheit [2][5].
• Fokus auf Agenten: OWASP hat neben den LLM Top 10 (Ausgabe 2025) eine Top 10 für agentische Anwendungen veröffentlicht, die übermäßige Handlungsfreiheit, Werkzeugmissbrauch und Memory Poisoning abdeckt; MCP-Sicherheit (Tool Poisoning, Token-Reichweite) ist inzwischen ein Standardpunkt jeder Prüfung [1].
• Herkunftsbasierte Entwürfe (CaMeL, Dual-LLM-Muster) bieten für enge Aufgaben beweisbare Eigenschaften, kosten aber Flexibilität.
• Benchmarks: AgentDojo und ähnliche Suiten messen den Angriffserfolg gegen Agenten; nutzen Sie sie für Regressionstests, nicht als Zertifizierung.
• Fehlerbilder: Fehlalarme, die legitime Nutzer blockieren, mehrsprachige und kodierte Umgehungen, schrittweise Eskalation über mehrere Dialogrunden, Latenz und Kosten der Leitplanken sowie Leitplanken, die selbst LLMs sind und manipuliert werden können.

Gemeinsame Bausteine & Kombinationen

• Gemeinsamer Stack: Leitplanken + llm-small + text-classifier; dasselbe Sicherheitsmodell und dasselbe Gateway bedienen alle internen KI-Anwendungen.
• Kombinierbar mit: SEC-014 (Red Teaming speist die Abstimmung der Leitplanken), SEC-012 (Bedrohungsmodellierung vor dem Bau), SEC-013 (Inventar und Sicherheitsstatus der Agenten), SEC-017 (PII/DLP), SEC-022 (KI-Governance und Dokumentation nach der KI-Verordnung (AI Act)), SEC-001 (das SOC wertet Leitplankenalarme aus), AGENT-001 (Agentenentwurf).

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; typischerweise lizenziert pro Anfrage oder pro Anwendung.
• Weg B: 2-6 Wochen für Gateway, Richtlinien, Protokollierung und Tests; die Preise für Plattform-Leitplanken sind nutzungsbasiert.
• Weg C: 1-3 Monate plus laufende Abstimmung; GPU optional.
• Kennzahlen: Angriffserfolgsrate auf einer festen Testsuite, Fehlalarmquote im realen Datenverkehr, zusätzliche Latenz, Anteil der KI-Anwendungen hinter dem Gateway, Anteil der Agentenwerkzeuge mit eng begrenzten Zugangsdaten, mittlere Zeit zur Aktualisierung einer Richtlinie, Anzahl verhinderter PII-Abflüsse.

Menschen & Veränderung

Die Geschäftsleitung entscheidet über die Risikobereitschaft und sollte die KI-Richtlinie freigeben (GUIDE-007). Die oder der Informationssicherheitsbeauftragte und die IT betreiben die Leitplanken; Abteilungsleitungen und Endnutzer melden blockierte oder verdächtige Fälle, und die oder der Datenschutzbeauftragte prüft, ob protokollierte Prompts rechtmäßig und minimiert sind (GUIDE-005). Beziehen Sie den Betriebsrat früh ein.

Betriebsrat: in den meisten Fällen ja. Leitplanken protokollieren Prompts, markieren Nutzer und können Verhalten offenlegen; das System ist daher objektiv zur Überwachung von Beschäftigten geeignet, und § 87 Abs. 1 Nr. 6 BetrVG greift (Bundesarbeitsgericht: Eignung genügt); § 90 Abs. 1 Nr. 3 fügt die Pflicht zur Unterrichtung über KI-gestützte Arbeitsverfahren hinzu. Vereinbaren Sie in einer Betriebsvereinbarung, dass die Logs nur der Sicherheit dienen, pseudonymisiert werden und nicht für Leistungsbeurteilungen genutzt werden (GUIDE-004). Öffentlicher Dienst: Personalrat.

KI-Kompetenz: Art. 4 der KI-Verordnung (AI Act) verlangt Maßnahmen zur Förderung der KI-Kompetenz der Beschäftigten; schulen Sie Nutzer zu Prompt-Injection und dazu, keine Geheimnisse einzufügen, und Entwickler zum sicheren Entwurf von Agenten (GUIDE-006, GUIDE-013). Starten Sie einen Pilot mit einem internen Assistenten und einem kleinen Team Freiwilliger. Typische Sorgen: „Leitplanken blockieren legitime Arbeit“ (bieten Sie einen Rückmeldekanal und messen Sie Fehlalarme) und „Ich werde beobachtet“ (erklären Sie Zweck und Aufbewahrung der Logs). Menschen geben nicht umkehrbare Werkzeugaktionen frei und verantworten die Leitplankenrichtlinie.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Leitplankenschicht selbst hat minimales Risiko. Die geschützte Anwendung kann ein begrenztes oder hohes Risiko haben (z. B. HR oder Kreditscoring); dann verlangt Art. 15 Genauigkeit, Robustheit und Cybersicherheit, ausdrücklich einschließlich der Widerstandsfähigkeit gegen Versuche, Nutzung oder Ausgaben durch manipulierte Eingaben zu verändern (adversarische Beispiele, Modellumgehung, Data Poisoning) [3]. Chatbots brauchen Transparenz nach Art. 50. KI-Modelle mit allgemeinem Verwendungszweck und systemischem Risiko haben zusätzliche Pflichten zur Cybersicherheit. Leitplanken dürfen keine verbotenen Praktiken nach Art. 5 umsetzen (z. B. das Ableiten von Emotionen von Beschäftigten durch Überwachung des Chats).
• DSGVO: Prompts und Logs enthalten personenbezogene Daten; wenden Sie Datenminimierung, kurze Aufbewahrung, einen AVV mit Leitplankenanbietern und Zugriffskontrolle auf die Logs an und beachten Sie, dass die Überwachung von Beschäftigten über Logs eine Rechtsgrundlage und in Deutschland die Beteiligung des Betriebsrats braucht. Ein Datenabfluss durch Injection kann eine Verletzung des Schutzes personenbezogener Daten sein (Meldung nach Art. 33 innerhalb von 72 Stunden).
• NIS2 / DORA / Cyber Resilience Act: KI-Anwendungen gehören zum erfassten IKT-Risikomanagement und zur Vorfallsmeldung; BSI und ENISA veröffentlichen Hinweise zu Risiken von LLM und generativer KI [4].
• Gegenmaßnahmen: mehrschichtige Kontrollen, minimale Rechte, menschliche Freigabe, Red-Team-Regressionstests und Notfallpläne für Fehlverhalten der KI.

Erste Schritte

1. Erfassen Sie Ihre LLM-Anwendungen und bewerten Sie jede nach den drei Faktoren: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten, ausgehende Aktionen. Beheben Sie zuerst die Anwendungen, bei denen alle drei zutreffen.
2. Leiten Sie alle Modellaufrufe über ein Gateway mit Protokollierung, Ratenbegrenzung und Schwärzen von PII.
3. Aktivieren Sie einen verwalteten Leitplankendienst (oder LLM Guard / NeMo Guardrails) und messen Sie Fehlalarme an einer Woche realen Datenverkehrs, bevor Sie durchsetzen.
4. Reduzieren Sie die Rechte der Agenten: Werkzeuge per Allow-List, eng begrenzte Tokens, menschliche Freigabe für sensible Aktionen.
5. Bauen Sie mit garak oder promptfoo eine Regressionssuite aus den OWASP Top 10 für LLM-Anwendungen auf und führen Sie sie in der CI bei jeder Änderung an Prompt oder Modell aus.

Quellen

1. OWASP — Top 10 for LLM Applications and GenAI Security Project — https://genai.owasp.org/llm-top-10/
2. NIST — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (AI 100-2 E2025) — https://csrc.nist.gov/pubs/ai/100/2/e2025/final
3. Regulation (EU) 2024/1689 (AI Act), Art. 15 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. ENISA — Multilayer Framework for Good Cybersecurity Practices for AI — https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai
5. Debenedetti et al. — Defeating Prompt Injections by Design (CaMeL) — https://arxiv.org/abs/2503.18813
6. NVIDIA NeMo Guardrails — https://github.com/NVIDIA/NeMo-Guardrails
7. Meta — LlamaFirewall — https://github.com/meta-llama/PurpleLlama/tree/main/LlamaFirewall
8. Microsoft — Azure AI Content Safety Prompt Shields — https://learn.microsoft.com/azure/ai-services/content-safety/concepts/jailbreak-detection
9. Microsoft Presidio — https://github.com/microsoft/presidio