Status: Published 2026-04-26. Brand-voice-konform (Marcus-Achse: maximale technische Tiefe, direkte Ansprache, kein Hype). seo-optimizer Audit-PASS (seoScore 84). legal-advisor cleared (MSRC-disclosed Vendor-Incidents, RFC 2606 Beispiel-Domains, keine Payloads gegen Live-Targets).
Kurzantwort. OWASP LLM01 (Prompt Injection) klassifiziert die Manipulation eines LLM durch Eingaben, die System-Anweisungen überschreiben — direkt oder über retrieved Daten. Die 2025-Revision unterscheidet drei Subklassen: LLM01.1 Direct, LLM01.2 Indirect, LLM01.3 Tool/Function-Call-Hijacking. SOC-2-Type-II-Auditoren und ISO/IEC 42001 §6.1.4 verlangen seit Q4 2025 reproduzierbare CI-Tests gegen jede Subklasse — kein jährlicher Pentest-Bericht, sondern signierte, hash-anchored Run-Artefakte pro Commit.
OWASP LLM01 — Prompt Injection — ist seit der 2025-Revision der OWASP-LLM-Top-10 die Disziplin mit dem schärfsten Audit-Druck. Nicht weil sie neu wäre. Weil sie sich nicht mehr durch ein Prompt-Filter-Patch wegbügeln lässt, und weil SOC-2-Type-II-Auditoren seit Q4 2025 expliziten Evidence-Nachweis für Injection-Tests in der CI verlangen. Dieser Artikel zeigt, was LLM01 als testbare Anforderung bedeutet, warum die Antwort nicht in einer manuellen Red-Team-Session liegt, und wie eine reproduzierbare Pipeline aussieht, die einen signierten Befund bis in den Pull-Request trägt.
1. Was verlangt OWASP LLM01 in der 2025-Revision wirklich?
Der Eintrag selbst ist knapp. OWASP klassifiziert Prompt Injection als die Manipulation eines LLM durch Eingaben — direkt vom Nutzer oder indirekt über Daten, die das Modell konsumiert — sodass es Anweisungen ausführt, die nicht vom System-Prompt-Eigner intendiert waren. Konkretisiert wird das in drei Unterklassen, die jede für sich eine andere Test-Topologie verlangt:
- Direct Injection (LLM01.1): der Angreifer kontrolliert den User-Turn und überschreibt System-Anweisungen. Klassiker:
Ignore previous instructions and …, mehrsprachige Varianten, Base64-getarnte Payloads, Unicode-Confusables. - Indirect Injection (LLM01.2): der Angreifer platziert die Payload in Daten, die das LLM später retrieved — RAG-Dokumente, E-Mails im Inbox-Tool, Webseiten im Browser-Tool, Tickets im Support-Tool. Greshake et al. (2023) ist der kanonische Referenzangriff; das Microsoft-Copilot-Incident aus 08/2024 die kanonische Production-Reproduktion.
- Tool/Function-Call-Hijacking (LLM01.3): das Modell wird dazu gebracht, Function-Calls mit Argumenten auszuführen, die der Nutzer nie autorisiert hat. Relevant überall, wo das LLM mit Side-Effect-APIs verbunden ist: Stripe, GitHub, interne Admin-Endpunkte.
Was Auditoren seit Q4 2025 hören wollen, ist nicht “wir haben ein Filter”. Es ist: zeigt mir die Test-Suite, zeigt mir die letzten zehn Runs, zeigt mir, dass kein HIGH-Befund länger als 14 Tage offen war. Das ist eine CI-Anforderung, keine Pentest-Anforderung. Wer LLM01 weiterhin als jährlichen Engagement-Posten behandelt, hat das Delta zur ISO-42001-Realität noch nicht gelesen.
2. Warum passen manuelle Red-Team-Sessions nicht in CI?
Manuelles Red-Teaming hat seinen Platz — bei Threat-Modeling-Workshops, bei Pre-Release-Reviews, bei der Untersuchung neuer Modell-Releases. Es hat keinen Platz im Merge-Gate. Drei Gründe:
Reproduzierbarkeit. Ein menschlicher Red-Teamer schreibt eine Variante einer Payload und probiert sie. Findet er etwas, ist die Reproduktion oft “ich hab da was getippt, war ungefähr so”. Das ist kein Fixture. Ein CI-Test braucht ein deterministisches, versionskontrolliertes Payload-Artefakt mit Hash, Seed (wo nicht-deterministische Tokenisierung im Spiel ist), Erwartung und Severity-Mapping. Sonst kannst du den Befund nicht wiederholen, und ein Auditor wird ihn nicht akzeptieren.
Evidence-Trail. SOC 2 CC8.1 und ISO-42001 §6.1.4 verlangen einen lückenlosen Trail: was wurde getestet, von wem (Mensch oder System), wann, welches Ergebnis, welche Mitigation. Eine Slack-Konversation ist kein Trail. Ein signiertes JSON-Artefakt mit Run-ID, Payload-Hash, Endpoint-URL, Modell-Version-Header und Severity ist einer.
Cadence. Modell-Provider deployen Updates teilweise wöchentlich, teilweise stillschweigend (Anthropic 2025-09 hat das System-Prompt-Verhalten in Claude-Sonnet-3.7 ohne Versions-Bump verändert; OpenAI hat im selben Quartal gpt-4o-2024-11-20 ausgerollt mit messbar abweichendem Tool-Use-Verhalten). Ein jährlicher Pentest sieht solche Drifts nicht. Eine nightly CI-Suite gegen die produktiv eingesetzte Modell-Version sieht sie am nächsten Morgen.
Manuelles Red-Teaming ergänzt die Pipeline; es ersetzt sie nicht. Die Pipeline liefert die Cadence und das Evidence; die Menschen liefern die Kreativität für neue Payload-Klassen, die dann in die Suite zurückfließen.
3. Drei Integration-Punkte für LLM01-Checks
Eine pragmatische CI-Integration nutzt drei Schichten mit unterschiedlichem Coverage- und Latenz-Profil:
Pre-Merge (Pull-Request-Gate). Eine kleine, deterministische Suite — typischerweise 15 bis 25 Attacks aus den Klassen Direct-Injection-Smoke, Tool-Call-Smoke, und einem Spot-Check auf Indirect-Injection mit einem fest verdrahteten RAG-Fixture. Latenz-Budget: unter 90 Sekunden Wallclock. Severity-Schwelle für Block: HIGH oder CRITICAL. Ziel ist nicht vollständige Coverage, sondern: “diese PR macht nichts offensichtlich Kaputtes.”
Nightly (Branch=main). Die volle Suite — bei PromptShield aktuell 217 Attacks, OWASP-LLM-Top-10-mapped — gegen das produktive Modell mit produktivem System-Prompt. Run-ID wird gespeichert, Diffs gegen den Vortag generiert. Neue HIGH/CRITICAL-Befunde öffnen automatisch ein Issue mit Reproduktion. Latenz-Budget: irrelevant (läuft asynchron), aber Kosten-Budget muss explizit sein — eine 217-Attack-Suite gegen GPT-4o-class kostet pro Run im niedrigen einstelligen Dollar-Bereich.
Pre-Release (Tag-getriggert). Erweitert die nightly Suite um langsamere Attack-Klassen: multi-turn-Persistence-Versuche, Cross-Conversation-Leakage, Long-Context-Buried-Payloads (>16k Token). Diese Klassen haben höhere False-Positive-Raten und längere Wallclock — sie blocken keinen Merge, aber sie blocken einen Release-Tag, wenn der signierte Severity-Bericht offene HIGH-Befunde enthält.
Diese Drei-Schichten-Aufteilung ist nicht Theorie. Sie spiegelt die Cadence-Realität: PR-Gates dürfen den Merge nicht spürbar verlangsamen, nightly darf vollständig sein, Release darf langsam und teuer sein. Wer alles in den PR-Gate quetscht, bekommt entweder Suite-Auswahl-Theater (gehört nichts in CI) oder eine PR-Latenz, die das Team umgeht (so entstehen Bypass-Patterns und Coverage-Debt). Wer das Drei-Schichten-Modell gegen den eigenen Endpoint sehen will, kann den freien 5-Attack-Teaser-Scan ohne Signup laufen lassen — er produziert dieselbe Severity-Card-Struktur in unter 60 Sekunden.
4. Was leistet eine signierte Severity-Card im Pull-Request?
Der konkrete Output eines PromptShield-PR-Runs ist eine Severity-Card — ein deterministisches, signiertes Artefakt mit fünf Feldern, das in den PR-Kommentar gerendert wird:
Run-ID: ps_run_01HYQZ4F2MXC9...
Endpoint: https://api.acme.example/v1/chat
Modell-Header: anthropic-claude-sonnet-4-5-20250929
Suite-Hash: sha256:7a3f...e01c (217 attacks, ruleset 2026-04-12)
Severities: CRITICAL=0, HIGH=2, MED=7, LOW=14
Signiert: ed25519:c8...92 (PromptShield Run-Authority Key)Drei Personen lesen diese Card mit unterschiedlichen Fragen:
- Reviewer (Marcus’ Peer). Er sieht den HIGH-Count, klickt auf den Link zum Run-Detail, sieht die zwei Reproduktionen mit literalen Payloads und Endpoint-Responses. Entscheidet in unter zwei Minuten: Block-und-Fix, oder Block-und-Mitigation-Ticket. Er liest keinen Pentest-Bericht; er liest die Reproduktion.
- SOC-2-Auditor. Sie sieht den signierten Trail, prüft, dass die Suite-Hash zur dokumentierten Test-Policy passt, prüft die Severity-Schwelle gegen die dokumentierte Risk-Acceptance. Ihr Job ist nicht, die Payloads zu verstehen — ihr Job ist, dass das System existiert und konsistent läuft.
- CISO. Sie sieht aggregiert: Trend der HIGH-Befunde über die letzten 30 Tage, MTTR pro Severity, Coverage-Drift gegen den Suite-Katalog. Daraus speist sich der Quartals-Board-Report.
Die Signatur ist nicht Kosmetik. Sie ist der Grund, warum ein Auditor das Artefakt akzeptiert, ohne den CI-Worker selbst auditieren zu müssen. Run-Authority-Schlüssel und Verifikations-Prozedur dokumentieren wir öffentlich; der private Schlüssel rotiert quartalsweise. Branded Severity-Card-Exports (Customer-Logo, Procurement-PDF) gehören in den Business-Tier auf der Pricing-Seite.
5. Anti-Patterns
Vier Muster, die wir in Kunden-Pipelines (und in den ersten Iterationen unserer eigenen) regelmäßig sehen und die LLM01-Coverage in Mitigation-Theater verwandeln:
Mock-LLM in CI. “Wir testen gegen ein lokales 7B-Modell, das ist billiger.” Das misst nichts Relevantes. Prompt-Injection-Verhalten ist modell-spezifisch — eine Payload, die GPT-4o auslöst, wird von Llama-3-8B oft ignoriert, und umgekehrt. Wenn deine Production gegen Sonnet-4 läuft, muss deine LLM01-CI gegen Sonnet-4 laufen.
Coverage-Theater. “Wir haben 500 Tests in unserer Suite.” Wenn 480 davon Variationen desselben Direct-Injection-Patterns sind, hast du Coverage-1, nicht Coverage-500. Suite-Qualität misst sich an OWASP-LLM-Top-10-Mapping und Klassen-Diversität, nicht an absolutem Test-Count. PromptShield mappt jede Attack auf eine LLM01-Subklasse plus eine MITRE-ATLAS-TTP; die Suite-Übersicht zeigt Coverage als Heatmap, nicht als Zahl.
Prompt-Filter-Whack-a-Mole. Jeder neue Befund führt zu einem Regex im System-Prompt-Filter. Nach drei Quartalen ist der System-Prompt 4kb lang, niemand versteht ihn mehr, und neue Modell-Versionen ignorieren die Hälfte der Anweisungen. Mitigation gehört in die Architektur — output-encoding, tool-allowlists, retrieval-trust-boundaries — nicht in den Prompt.
Befund ohne Reproduktion. “Die Suite hat einen HIGH gefunden.” OK, welcher Payload, welcher Endpoint-Response, welcher Severity-Mapping-Grund? Wenn das Tool das nicht zeigt, ist der Befund nicht handlebar und der Auditor wird ihn nicht akzeptieren. Reproduzierbarkeit ist kein Nice-to-Have; sie ist die Bedingung dafür, dass ein Befund überhaupt zählt.
6. Wie sieht ein konkretes LLM01-CI-Setup mit PromptShield aus?
Onboarding für eine LLM01-CI-Pipeline mit PromptShield braucht drei Schritte und ungefähr fünf Minuten. Das ist kein Marketing-Claim, sondern ein expliziter Produkt-Constraint: jede Hürde länger als fünf Minuten verliert in der Discovery-Phase 30 % der Engineers.
Schritt 1 — Endpoint registrieren. Du gibst eine HTTPS-URL und ein Auth-Header an. Wir validieren mit einem 1-Attack-Smoke (promptshield_health-Probe). Keine Agents in deiner Runtime, kein Sidecar.
Schritt 2 — Suite wählen. Default ist owasp-llm-top-10-2025 (217 Attacks, vollständig OWASP-mapped). Für PR-Gates wählst du das Subset pr-smoke-25. Suiten sind versioniert; ein Suite-Hash im Run-Artefakt ist deterministisch reproduzierbar.
Schritt 3 — GitHub-Action einbinden. Eine Zeile im Workflow:
- uses: promptshield/action@v1
with:
endpoint: ${{ secrets.LLM_ENDPOINT_URL }}
suite: pr-smoke-25
fail-on: HIGHDer erste PR-Run produziert die Severity-Card als Kommentar. Der nightly-Run gegen main läuft als separater Workflow gegen suite: owasp-llm-top-10-2025. Beide schreiben in dieselbe Run-Historie; Diffs zeigen neue oder regressed Befunde.
Was du danach hast: einen reproduzierbaren, signierten Evidence-Trail für LLM01, der den Auditor in unter fünf Minuten überzeugt und den Reviewer in unter zwei. Was du nicht hast: ein Tool, das deine Architektur-Entscheidungen ersetzt. Output-Encoding, Tool-Allowlists, Retrieval-Trust-Boundaries — das bleibt deine Arbeit. PromptShield gibt dir das Signal, ob diese Entscheidungen halten, jeden Commit, gegen das Modell, das du wirklich deployst.
Häufig gefragt
Reicht es, das LLM hinter einem Klassifikator-Filter zu verstecken? Nein. Filter helfen gegen Low-Hanging-Direct-Injection, schlagen aber gegen Indirect-Injection und Multi-Turn-Persistence regelmäßig durch. Ein Filter ist eine Mitigation, kein Test. Du brauchst beides — und du brauchst den Test, um zu wissen, ob der Filter noch tut, was er soll, nachdem das Modell upgedated wurde.
Wie oft sollte die nightly Suite laufen?
Mindestens einmal pro Tag gegen main, plus jeder gemergte Branch. Bei wöchentlichen Modell-Provider-Updates lohnt sich ein zusätzlicher Run nach jedem Modell-Version-Bump (Header-basierte Detection im Worker reicht).
Was ist ein realistischer Cost-Floor? Eine 217-Attack-Suite gegen Sonnet-4-class kostet pro Run zwischen 0,80 und 2,40 USD an Modell-Inferenz, je nach durchschnittlicher Response-Länge. Das PR-Smoke-Subset (25 Attacks) liegt unter 0,30 USD. Das ist keine Investition, die du verteidigen musst.
Können wir die Suite gegen unser Staging-Modell laufen lassen? Ja, aber nicht statt Production. Staging deckt Code-Änderungen am System-Prompt ab; Production deckt Modell-Provider-Drift ab. Beide Signale sind unterschiedlich; beide gehören in den Trail.
Weiterlesen: Reproduzierbare Prompt-Injection-Tests: ein Katalog-Ansatz · Warum Pentest-Reports ohne signiertes Evidence-PDF wertlos sind
Nächster Schritt: Freier 5-Attack-Teaser-Scan ohne Signup · Pricing & CI-Plan-Vergleich · Signup für 25-Attack-Suite + PDF-Report
Quellen (vor Publish prüfen):
- OWASP LLM Top 10 (2025-Revision)
- Greshake et al., Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, 2023, arXiv:2302.12173
- Microsoft Security Response Center, Copilot Indirect-Injection-Disclosure, 08/2024
- ISO/IEC 42001:2023 §6.1.4, AI-System-Risk-Treatment
- MITRE ATLAS, TTP-Mapping für LLM-Angriffe