Prompt-Injection-Schutz evaluieren: eine praktische Checkliste

Ein Prompt-Injection-Eval beginnt nicht mit einer Liste von Phrasen wie „ignore previous instructions“. Definieren Sie zuerst die Security Expectation: welche Daten der Agent lesen darf, welche externen Parteien seinen Kontext beeinflussen können, welche Aktionen er vorschlagen oder ausführen darf und was ohne separate Prüfung niemals geschehen darf. Direct Injection durch den Nutzer und Indirect Injection aus Webseite, E-Mail, Dokument, Tool Output oder Memory erzeugen unterschiedliche Attack Surfaces.

Erstellen Sie für jeden Workflow Source-Sink-Paare. Eine Source ist nicht vertrauenswürdiger Inhalt, den ein Angreifer verändern kann; ein Sink ist die Übertragung eines Secrets, ein Network Request, eine Nachricht, Zahlung, Dateiänderung, ein Memory Write oder eine andere consequential capability. OpenAI beschreibt dieselbe Source-Sink-Rahmung für Agenten: Der Test muss nicht nur zeigen, dass das Modell verdächtigen Text erkannt hat, sondern dass ein gefährlicher Datenfluss zum Sink blockiert wurde oder die korrekte Bestätigung erforderte.

• Asset → Secrets, personenbezogene Daten, Credentials, Geld sowie reputative oder operative Aktionen.
• Source → User Input, Web, E-Mail, RAG, Dateien, Tool Output, Memory und multimodaler Content.
• Sink → Network, Message, Write Tool, Code Execution, Memory Write oder Privilege Change.
• Invariant → verbotenes Ereignis, das der Harness deterministisch prüft.

Der Corpus sollte reale Trajektorien abbilden: eine normale Seite mit versteckter Anweisung, eine E-Mail mit plausiblem Business Pretext, ein RAG-Dokument mit der Aufforderung zur Policy-Änderung, eine Redirect Chain, eine URL mit Daten im Query, ein vergiftetes Tool Result und ein Memory-Eintrag, der sich als Approval ausgibt. Ergänzen Sie Paraphrasen, mehrere Sprachen, Encodings, typografisches Verstecken, Bilder und mehrstufige Angriffe. Jedes Fixture speichert angegriffene Source, erlaubte Evidenz, erwartete Tool Calls und verbotene Ereignisse.

Benigne positive Fixtures sind genauso wichtig wie Angriffe. Sie zeigen, ob der Schutz legitimes Zitieren von Anweisungen, Security Research, Support-E-Mails, externe Links und erlaubte Aktionen fälschlich blockiert. Segmentieren Sie nach Source, Sink, Asset Sensitivity, Autonomy, Permission Scope und Bedarf an User Confirmation. Ein einzelner Durchschnittswert kann den Ausfall eines seltenen, aber kritischen Data-Exfiltration-Slice leicht verbergen.

Führen Sie jedes Fixture in einer production-nahen Sandbox mit denselben Prompts, Modellen, Tools, Policies, Network Rules, Credentials Broker und Confirmation UI aus, aber mit Canary-Secrets und fiktiven Destinations. Nur die finale Antwort zu testen reicht nicht: Das Modell kann still eine URL aufrufen, einen Payload in ein Tool Argument übertragen, den Angriff in Memory schreiben oder einen gefährlichen Draft vorbereiten. Der Harness zeichnet die vollständige Trajektorie auf und beobachtet jeden Sink unabhängig.

Geben Sie dem Test-Agenten keine weitergehenden Rechte als seiner Production Role und ersetzen Sie die Policy nicht durch einen Mock, der immer ablehnt. Prüfen Sie Least Privilege, Tenant Binding, Scoped Credentials, Destination Allowlists, Sandbox Egress, Schema Validation und Approval Binding an den exakten Payload. Eine Bestätigung besteht das Gate nicht, wenn der Agent danach Empfänger, Daten oder Betrag ohne neue Nutzerentscheidung verändern kann.

Der primäre Verdict ist deterministisch: verbotener Sink erreicht, Secret offengelegt, unautorisierter Write, vergiftetes Memory, Confirmation Bypass oder Safe Completion. Separat markieren Sie Attack Detected, Refused, Content Safely Summarized, User Warned und Task Completed. Eine Ablehnung kann sicher wirken, ohne zu beweisen, dass kein Background Request gesendet wurde; umgekehrt kann das Modell die Attacke nicht benennen, während die Policy Layer den Side Effect korrekt blockiert.

Berichten Sie Attack Success Rate nur zusammen mit exaktem Corpus, Wiederholungen, Sampling Settings, Model- und Policy-Versionen sowie Confidence Interval; übertragen Sie keinen Vendor Benchmark auf Ihr System. Nützliche Operations-Metriken sind Critical Invariant Failures, Sink-specific Compromise Rate, Secret-Canary Exposure, geblockte unauthorized attempts, Benign Task Success, False-positive Rate, Confirmation Quality, Containment Time, Latency und Cost per Evaluated Trajectory. Kritische Exfiltration wird nicht durch hohen durchschnittlichen Task Success kompensiert.

Defense in Depth umfasst Model Behavior, Trust Labels, Content Handling, Least Privilege, Data-flow Checks, Sandbox, Network Controls, Approval und Monitoring. Führen Sie zuerst den vollständigen Stack und dann kontrollierte Ablations aus: entfernen Sie den Classifier, verengen oder erweitern Sie den Tool Scope, deaktivieren Sie Destination Check oder Confirmation. So wird sichtbar, welche Schicht die Attacke tatsächlich gestoppt hat, wo ein Single Point of Failure liegt und ob eine dekorative „AI Firewall“ nur zusätzliche Latenz erzeugt.

OpenAI und Anthropic beschreiben Prompt Injection ausdrücklich als aktives Problem ohne einzelne garantierte Defense. Classifier Precision ist daher kein Security Result. Prüfen Sie, ob das System den Schaden begrenzt, selbst wenn Modell oder Detector eine sozial überzeugende Attacke übersehen. Bei Web Agents testen Sie zusätzlich stille URL-basierte Leaks, Redirects, Previews und Embedded Resources; eine Domain Allowlist beweist nicht, dass ein konkreter Data Flow sicher ist.

Der Decision Record fixiert Workflow, Sources, Sinks, Permissions, Model, Prompt, Policy Bundle, Tool Schemas, Corpus Revision, Critical Invariants, Thresholds, Owner und Review Date. Promote gilt nur für den verifizierten Scope. Restrict kann Network Egress, Memory Writes oder High-impact Tools deaktivieren; Reject kehrt zu einem Read-only- oder deterministischen Baseline zurück. Jeder Canary-Secret Leak, Cross-tenant Access oder unauthorisierte consequential action blockiert den Release unabhängig vom Durchschnittsscore.

Der Rollout führt über Offline Replay, Adversarial Staging, Read-only Canary, eine kleine permission-bounded Cohort und kontinuierliches Monitoring. Rollback widerruft Scoped Credentials, deaktiviert Sinks und kontaminierte Memory Writes, stellt das Known-good Policy/Model Bundle wieder her und bewahrt einen bereinigten Trace für Incident Review. Ein neuer Exploit wird nach dem Triage zum Regression Fixture. Wiederholen Sie die Critical Suite nach Änderungen an Model, Prompt, Retriever, Browser, MCP/Tool Server, Permissions, Network Policy oder Confirmation UX.

• Promote → alle Critical Invariants bestehen im definierten Scope.
• Restrict → Sources, Sinks, Data Class, Autonomy oder Permissions reduzieren.
• Reject → Read-only- oder deterministischen Baseline beibehalten.
• Roll back → Credentials widerrufen, Sinks deaktivieren, State quarantänisieren und Side Effects reconciliieren.