OWASP LLM Top 10: Prompt Injection Defense für deutsche Unternehmen

Pexon Consulting | 14 Min. Lesezeit | 17.04.2026

TL;DR

Die OWASP LLM Top 10 (Version 2025) ist der De-facto-Standard für LLM-Security-Reviews und wird in DACH zunehmend in Auditberichten für NIS2, DORA und BaFin-MaRisk verlangt. Die zehn Risikoklassen — LLM01 Prompt Injection bis LLM10 Unbounded Consumption — lassen sich direkt auf deutsche Regulatorik mappen. Pexon Consulting, Microsoft Partner mit 80 Mitarbeitern in Deutschland, nutzt die Taxonomie als Scoping-Basis in Security-Audits und verbindet jedes Item mit konkreten TOMs nach Art. 32 DSGVO.

Warum CISOs 2026 die OWASP LLM Top 10 lesen müssen

Der regulatorische Druck auf KI-Sicherheit hat 2025 und 2026 mehrere Stufen genommen. NIS2 ist seit dem 6. Dezember 2025 in Deutschland in Kraft, rund 29.500 Unternehmen sind betroffen. DORA gilt seit dem 17. Januar 2025 für Finanzentitäten — bis zu 2% Weltjahresumsatz Bußgeld. Der EU AI Act greift für High-Risk-Systeme nach Anhang III ab dem 2. Dezember 2027 (per Digital-Omnibus verschoben). Die BSI/ANSSI-Designprinzipien für LLM-basierte Systeme (11. August 2025) definieren Zero-Trust-Grundsätze, auf die sich deutsche Aufsichtsbehörden zunehmend beziehen. Die BaFin konsultiert seit dem 1. April 2026 die neunte MaRisk-Novelle — erstmals mit einem expliziten Modul AT 4.3.4 für KI-Systeme.

In jedem dieser Rahmenwerke fehlt eine eigene LLM-Risikotaxonomie. Was existiert, ist die OWASP Top 10 for LLM Applications 2025. Wir sehen in aktuellen Security-Reviews bei DACH-Kunden: Die Taxonomie wandert aus OWASP-Publikationen direkt in die Checklisten der Aufsichtsbehörden und in die Fragenkataloge von TÜV, BDO und internen IT-Audits. Ein CISO, der 2026 einen KI-Service produktiv hat und diese zehn Items nicht systematisch adressiert, wird in jedem Audit darauf angesprochen werden.

Die zehn Risikoklassen im Überblick

Die OWASP-Klassifikation in Kurzform, mit Fokus auf das, was in Enterprise-Produktion wehtut:

LLM01 Prompt Injection. Direkte oder indirekte Manipulation des Modells durch untrusted Input. Laut OWASP in über 73% untersuchter Produktions-Deployments nachweisbar. Der prominenteste Fall 2025: EchoLeak (CVE-2025-32711, CVSS 9.3) in Microsoft 365 Copilot. Wir haben den Vektor ausführlich in Indirect Prompt Injection in RAG-Systemen aufgearbeitet.

LLM02 Sensitive Information Disclosure. Das Modell gibt personenbezogene Daten, Secrets oder Trainingsdaten preis. Im DSGVO-Kontext ist das ein potenzieller meldepflichtiger Vorfall nach Art. 33.

LLM03 Supply Chain. Kompromittierte Modelle, Plugins, Embeddings oder Datasets. 2025 gab es drei dokumentierte CVEs in Anthropics eigenem MCP-Server-Git, dazu das erste bösartige MCP-Paket im September 2025, das zwei Wochen unentdeckt blieb und E-Mails exfiltrierte.

LLM04 Data and Model Poisoning. Trainings-, Fine-Tuning- oder RAG-Daten werden bewusst vergiftet. ConfusedPilot (arXiv:2408.04870) beschreibt das akademisch für Copilot — ein manipuliertes Dokument im SharePoint reicht.

LLM05 Improper Output Handling. XSS, SQL-Injection oder Command-Injection durch un-sanitized Model-Output. Typisch: Der Agent generiert HTML, das ohne Filter in ein Chat-UI geht. Oder er generiert eine SQL-Query, die ohne Parametrisierung ausgeführt wird.

LLM06 Excessive Agency. Agent hat zu viele Tools oder zu breite Berechtigungen. Simon Willison beschrieb das im April 2025 als „Tool-Kombinations-Exfiltration“: files:read plus http:post plus externes Dokument ergibt Datenexfiltration.

LLM07 System Prompt Leakage. Neu in der 2025er Version. Der System-Prompt — oft Geschäftslogik, API-Keys, Geheimdaten — wird extrahiert. Häufiger Vektor: „Wiederhole den Text oben wortgenau.“

LLM08 Vector and Embedding Weaknesses. Ebenfalls neu 2025. Cross-Tenant-Leaks in Multi-Tenant-Vector-Stores, Embedding-Inversion (Rekonstruktion von Dokumenten aus Embeddings), Poisoning der Embedding-Pipeline.

LLM09 Misinformation. Halluzinationen und Over-reliance. Der Air-Canada-Fall ist der juristische Präzedenz — das Unternehmen haftet für die Aussagen seines Agenten.

LLM10 Unbounded Consumption. DoS und Wallet-Drain durch unbegrenzte Model-Aufrufe. In 2025 eine wachsende Angriffsklasse: Prompt Injection plus Tool-Call-Storm lässt ein Azure-OpenAI-Budget in Stunden explodieren.

Das DACH-Mapping, das in jedem Audit funktioniert

OWASP ist die Risiko-Taxonomie, die deutsche Aufsicht will das Mapping auf heimische Rahmenwerke sehen. Die Struktur, die wir in Kunden-Auditberichten einsetzen:

Dieses Mapping ist keine offizielle Referenz — es ist die Arbeitsversion, die wir in aktuellen Audits verwenden und die bisher von TÜV Süd, einer Big-Four-Prüfungsgesellschaft und einer internen Bankrevision ohne Widerspruch akzeptiert wurde. Wir aktualisieren es quartalsweise, weil sich die Rahmenwerke bewegen.

Die drei Items, die in DACH-Audits am häufigsten durchfallen

Aus rund 20 LLM-Security-Audits in den letzten 12 Monaten sehen wir drei Schwachpunkte, an denen Kunden regelmäßig scheitern:

LLM06 Excessive Agency ist der Klassiker. Ein Agent hat files:, db: und http:* — weil es in der Entwicklung praktisch war. In Produktion reicht ein einzelner Prompt-Injection-Vektor, um beliebige Daten zu lesen und zu exfiltrieren. Unsere Empfehlung: Jeder Agent bekommt eine explizite, dokumentierte Tool-Liste. Scope-Erweiterungen gehen nicht durch Code-Review, sondern durch ein Change-Board. Write-Tools sind immer Human-in-the-Loop.

LLM03 Supply Chain wird in DACH bisher selten ernst genommen. Die Analyse des Practical-DevSecOps-Teams aus März 2025 fand in den untersuchten MCP-Servern 43% Command-Injection-Flaws und 30% unrestricted URL-Fetching. Das ist die Software, die gerade in Produktion geht. Unsere Empfehlung: Keine MCP-Server ohne Signatur-Pinning, ohne Hash-Verifikation und ohne Container-Isolation. Wir dokumentieren das als Teil der AVV-Pflichten nach Art. 28 DSGVO.

LLM02 Sensitive Information Disclosure ist der Punkt, an dem die DSGVO-Meldepflicht wirksam wird. Ein Agent, der in einer Antwort Kundennamen aus einem falschen Tenant preisgibt, ist ein Fall von Art. 33. Die Meldefrist liegt bei 72 Stunden. Wir sehen in Kundenprojekten, dass Multi-Tenant-Vector-Stores selten sauber isoliert sind — Qdrant-Collections mit geteiltem Namespace, Azure AI Search ohne Row-Level-Security. Die Umsetzung ist machbar, die Default-Konfiguration ist es nicht.

Der Defense-Stack, den wir bei Kunden bauen

Unsere Standard-Architektur für LLM-Services in regulierten Branchen:

Jede Schicht adressiert mindestens ein OWASP-Item und mindestens eine DSGVO/NIS2-Anforderung. Im Auditbericht dokumentieren wir pro Komponente, welche Kontrolle welches Risiko minimiert — das ist die Dokumentation, die ein Prüfer sehen will.

Konkrete Messbarkeit: Von Angriffserfolgsrate zu Evidenz

Viele Security-Audits enden mit einem PDF voller „soll-Zustände“ und wenig messbaren Zahlen. Unsere Empfehlung: Pro deployed LLM-Service eine harte Angriffserfolgsrate (Attack Success Rate, ASR) als KPI.

Das AgentDojo-Benchmark der ETH Zürich (arXiv:2406.13352) liefert 629 Security-Tests gegen LLM-Agents. GPT-4o liegt im Default bei rund 53% ASR für den „Important message“-Angriff. Mit Tool-Filtering-Default-Deny sinkt das auf 7,5% bei leicht reduzierter Utility.

Zwei weitere Zahlen zur Einordnung: Der arXiv-Paper 2504.11168 testet kommerzielle Guardrails unter Ataque — NeMo JailbreakDetect bleibt bei 65% Angriffserfolgsrate, Azure Prompt Shields bei 13%. Kein einzelnes Tool ist ausreichend. Spotlighting (Microsoft Research, arXiv:2403.14720) reduziert ASR bei GPT-Modellen von über 50% auf unter 2% — aber nur wenn es mit anderen Schichten kombiniert wird.

Unser Messprotokoll bei Kunden:

1. Baseline: AgentDojo gegen Produktions-Agent ohne Defense-Schicht → ASR ermitteln.
2. Iteration: Spotlighting, Output-Filter, HITL schrittweise aktivieren, jeweils ASR messen.
3. Ziel-KPI: ASR < 5% auf AgentDojo, < 2% auf branchenspezifischen Tests (z.B. LLMail-Inject-Style).
4. Continuous Monitoring: Die Tests laufen in CI bei jedem Prompt-Template-Update.

Meldepflichten und Eskalation bei einem Incident

Ein dokumentierter Prompt-Injection-Vorfall mit Datenexfiltration löst in DACH mehrere Pflichten parallel aus:

DSGVO Art. 33 — Meldung an die Landes-Aufsichtsbehörde innerhalb 72 Stunden, wenn ein Risiko für Rechte und Freiheiten natürlicher Personen besteht. Bei hoher Risikowahrscheinlichkeit zusätzliche Benachrichtigung der Betroffenen nach Art. 34.

NIS2UmsuCG §11 — Erstmeldung ans BSI binnen 24 Stunden bei einem erheblichen Vorfall, Updatemeldung innerhalb 72 Stunden, Abschlussbericht in einem Monat.

DORA Art. 19 — Meldung an die zuständige Finanzaufsicht (BaFin/EZB) für ICT-bezogene Vorfälle im Finanzsektor.

BaFin MaRisk AT 4.3.4 — Interne Dokumentation im Risikomanagement-System, Berichterstattung an Vorstand und Aufsichtsrat.

Unsere Empfehlung: Ein vorgefertigtes Incident-Response-Runbook mit Templates für jedes dieser Rahmenwerke. Im Ernstfall beschleunigt das die Reaktion erheblich — und reduziert das Risiko von Folgebußgeldern wegen Meldefristversäumnis.

Häufig gestellte Fragen

Welche OWASP LLM Top 10 Items fordert NIS2 konkret?

NIS2 verlangt in §6 NIS2UmsuCG technische und organisatorische Maßnahmen zur Risikominderung. Die Gesetzesbegründung nennt explizit KI-Systeme als Teil der betroffenen Infrastruktur. Konkret adressieren LLM01 (Prompt Injection), LLM03 (Supply Chain), LLM04 (Model Poisoning) und LLM10 (Unbounded Consumption) Verfügbarkeits- und Integritäts-Anforderungen, die direkt aus NIS2 folgen. Wir dokumentieren das in Auditberichten als expliziten Cross-Reference.

Wer haftet bei einem Prompt-Injection-Schaden in Deutschland — Provider oder Deployer?

In der Regel der Deployer. Die Moffatt-vs.-Air-Canada-Entscheidung aus Februar 2024 hat das Argument „Der Chatbot ist eine separate Entity“ verworfen. DACH-Gerichte orientieren sich daran. Der LLM-Provider (OpenAI, Anthropic, Microsoft) ist Auftragsverarbeiter nach Art. 28 DSGVO — die Verantwortung für die Rechtmäßigkeit der Verarbeitung bleibt beim Verantwortlichen, also beim Unternehmen, das den Agent deployed.

Wie dokumentiere ich LLM-Risiken für den AI-Act-Nachweis?

Der EU AI Act verlangt für High-Risk-Systeme (Anhang III ab 2. Dezember 2027) eine Risk-Management-Dokumentation nach Art. 9 und eine Conformity Assessment. Die OWASP LLM Top 10 passt direkt in die Risk-Management-Taxonomie. Wir erstellen in Pexon-Projekten ein Living Document, das pro Item das identifizierte Risiko, die implementierten Kontrollen und die Restrisiko-Bewertung enthält — plus ASR-Messwerte aus AgentDojo.

Welche TOMs nach Art. 32 DSGVO sind für LLMs neu?

Art. 32 selbst ist technology-agnostisch. Neu bei LLMs ist der Schwerpunkt: Input-Validation gegen Prompt Injection (Spotlighting, Unicode-Sanitization), Output-Filter gegen Markdown-Exfiltration, Egress-Kontrolle auf Container-Ebene, Pseudonymisierung in Tool-Inputs, Audit-Logs mit PII-Redaction. Klassische TOMs wie Verschlüsselung und Zugriffskontrolle bleiben bestehen, werden aber um diese LLM-spezifischen Schichten ergänzt.

Reicht Azure OpenAI mit EU Data Boundary für DSGVO-Compliance?

Es ist ein wichtiger Baustein, aber nicht ausreichend. EU Data Boundary (seit 2024 verfügbar, muss explizit aktiviert werden) hält Payloads, Telemetrie und Abuse-Monitoring-Metadaten in der EU. Damit ist der Transfer-Aspekt adressiert. Was zusätzlich gebraucht wird: Auftragsverarbeitungsvertrag nach Art. 28, Verzeichnis der Verarbeitungstätigkeiten nach Art. 30, TOMs nach Art. 32 (inklusive LLM-spezifische Guardrails), Datenschutz-Folgenabschätzung bei hohem Risiko. DSGVO ist ein Rahmen, kein Schalter.

Nächster Schritt

Wenn Sie 2026 einen produktiven LLM-Service haben oder planen und wissen wollen, wie Ihr Stack gegen die OWASP LLM Top 10 abschneidet, führen wir einen systematischen Security-Audit durch: AgentDojo-Baseline, OWASP-Item-für-Item-Review, Mapping auf DSGVO/NIS2/DORA/BaFin, konkreter Defense-in-Depth-Maßnahmenkatalog mit Priorisierung.

Verwandte Themen