Checkliste: 20 Punkte vor dem Produktivgang

Stand: 30. August 2026 · Gökhan Köse

Zum Mitnehmen: Die vollständige Liste gibt es als PDF mit Ankreuzfeldern — 20 Seiten, je Punkt Prüfweg und Durchfall-Kriterium, zum Ausdrucken oder Weitergeben ins Review. Die Reihenfolge folgt dem Weg der Daten: erst Entwurf und Rechte, dann Eingang, dann Ausgang, zuletzt Betrieb. Wer wenig Zeit hat, beginnt bei Punkt 1 — die tödliche Trias entscheidet, wie schwer ein Treffer wiegt. Grundlagen stehen unter Was ist Prompt Injection?, dokumentierte Fälle im Register der Vorfälle.

Wer prüft was

Die Liste ist nicht für eine Person gedacht. Vier Rollen teilen sie sich auf — wer alles allein abhakt, hakt erfahrungsgemäß zu schnell ab.

• Architektur und Entwicklung — Punkte 1 bis 5 sowie 9 und 13. Sie entscheiden über Rechte, Werkzeugzuschnitt und Ausführungsumgebung, bevor Code entsteht.
• Betrieb und Plattform — Punkte 4, 15, 16, 17 und 20. Sie verantworten Token-Laufzeiten, ausgehende Ziele, Protokolle und den Ernstfall.
• Sicherheit und Red Team — Punkte 8, 10, 18 und 19. Sie greifen an, statt zu bestätigen: versteckte Zeichen, auslesbarer System-Prompt, Testlauf, Speicherinhalt.
• Fachbereich und Freigabe — Punkte 5, 11 und 14. Sie legen fest, welche Aktion einen Menschen braucht und welches Ausgabeformat nachgelagerte Systeme akzeptieren.

Entwurf und Rechte

1. Tödliche Trias geprüft — Prüfen: Hat das System gleichzeitig Zugriff auf private Daten, verarbeitet es Fremdinhalte und kann es nach außen kommunizieren? Treffen alle drei zu, ist Datenabfluss nur eine Frage der Gelegenheit — eine der drei Eigenschaften muss weg. Durchgefallen, wenn niemand benennen kann, welche der drei das System nicht hat. Siehe tödliche Trias.
2. Rechte aus der Aufgabe abgeleitet — Prüfen: Zu jedem Recht den konkreten Arbeitsschritt benennen, der es braucht. Rechte, die aus der Rolle des aufrufenden Nutzers kopiert wurden, sind fast immer zu weit. Durchgefallen, wenn der Agent mehr darf, nur weil der Nutzer mehr darf. Siehe Least Privilege.
3. Werkzeugsatz zugeschnitten — Prüfen: Die pro Anfrage verfügbare Werkzeugliste ausgeben lassen und gegen die Aufgabe halten. Ein globaler Katalog macht jede Injektion mächtiger, als sie sein müsste. Durchgefallen, wenn das Modell Werkzeuge sieht, die es für diese Aufgabe nie braucht.
4. Zugangsdaten kurzlebig — Prüfen: Laufzeit und Geltungsbereich jedes Tokens nachsehen, das in den Kontext gelangt. Dauerhafte Anmeldedaten überleben die Sitzung und wandern mit jeder Ausgabe mit. Durchgefallen, wenn ein Token im Kontext steht, das morgen noch gilt.
5. Menschliche Freigabe definiert — Prüfen: Für jede Aktion mit Geld-, Daten- oder Außenwirkung schriftlich festhalten, wer freigibt. Ohne benannten Freigebenden ist die Freigabe ein Vorsatz, kein Kontrollpunkt. Durchgefallen, wenn eine folgenreiche Aktion allein vom Modell ausgelöst werden kann.

Eingang und Kontext

1. Datenquellen inventarisiert — Prüfen: Alle Wege auflisten, auf denen fremder Text in den Kontext gelangt — Dateien, Web, E-Mail, Werkzeugergebnisse, Gedächtnis. Was nicht auf der Liste steht, wird auch nicht geprüft. Durchgefallen, wenn die Liste beim Nachfragen noch wächst. Siehe Angriffsvektoren.
2. Fremddaten markiert — Prüfen: Im tatsächlich gesendeten Prompt nachsehen, ob abgerufener Text erkennbar von Betreiber-Anweisungen getrennt ist. Markierung senkt die Trefferquote, ersetzt aber keine Rechtegrenze. Durchgefallen, wenn Fremdtext und Anweisung im selben Block stehen. Siehe Spotlighting.
3. Unsichtbare Zeichen entfernt — Prüfen: Mit einem Testdokument arbeiten, das Unicode-Tag-Zeichen, Zero-Width-Zeichen oder Homoglyphen enthält. Was der Mensch nicht sieht, liest das Modell trotzdem. Durchgefallen, wenn versteckter Text die Antwort verändert. Siehe Eingabeprüfung.
4. Anweisungen bleiben in der Systemrolle — Prüfen: Suchen, ob Fremddaten jemals in die Systemrolle geraten — etwa über Zusammenfassungen oder Vorlagen mit Platzhaltern. Durchgefallen, wenn abgerufener Text in der Rolle landet, der das Modell die höchste Priorität zuweist.
5. System-Prompt ohne Geheimnisse — Prüfen: Davon ausgehen, dass der System-Prompt öffentlich ist, und ihn mit diesem Blick lesen. Schlüssel, interne Regeln und Preisgrenzen gehören nicht hinein. Durchgefallen, wenn sein Auslesen einen Schaden bedeuten würde. Siehe Prompt Leaking.

Ausgang und Wirkung

1. Ausgabeformat wird geprüft — Prüfen: Ein Schema festlegen und jede Antwort dagegen validieren, bevor sie weiterläuft. Freitext, der als Steuerbefehl weiterverwendet wird, ist die Grundlage der meisten Folgeschäden. Durchgefallen, wenn eine unerwartete Ausgabe nachgelagerte Systeme erreicht. Siehe Ausgabeprüfung.
2. Links und Ressourcen bereinigt — Prüfen: Markdown-Bilder und Links in der Ausgabe testen — ein Bild mit Daten in der URL genügt für den Abfluss. Durchgefallen, wenn die Ausgabe eine Ressource von einem beliebigen fremden Host laden darf. Siehe Datenabfluss über Markdown-Bilder.
3. Code nur in der Sandbox — Prüfen: Netzzugang und hinterlegte Geheimnisse der Ausführungsumgebung nachsehen. Modellgenerierter Code ist nicht vertrauenswürdiger Code. Durchgefallen, wenn generierter Code ins Netz kommt oder dauerhafte Zugangsdaten sieht.
4. Ausgaben gelten als Fremdeingabe — Prüfen: Jede Stelle suchen, an der eine Modellausgabe in ein anderes System fließt, und dort dieselbe Validierung verlangen wie bei Nutzereingaben. Durchgefallen, wenn ein nachgelagertes System der Ausgabe vertraut, nur weil sie vom eigenen Modell stammt. Siehe LLM05.
5. Ausgehende Ziele eingeschränkt — Prüfen: Die Liste erlaubter Ziele für Netzaufrufe ansehen — sie sollte kurz sein und jeder Eintrag begründet. Durchgefallen, wenn das System eine beliebige Adresse erreichen kann.

Betrieb und Nachweis

1. Werkzeugaufrufe protokolliert — Prüfen: Das Protokoll eines echten Laufs lesen — es muss zeigen, welches Werkzeug mit welchen Argumenten lief. Dazu Ratenlimits und Budgets. Durchgefallen, wenn sich im Nachhinein nicht rekonstruieren lässt, was der Agent getan hat.
2. Verhalten überwacht, nicht nur Text — Prüfen: Auf ungewöhnliche Handlungsketten messen — viele Aufrufe hintereinander, neue Ziele, plötzliche Rechteanfragen. Durchgefallen, wenn die Überwachung ausschließlich Eingabetext filtert. Siehe Erkennung.
3. Testlauf ist Teil der Freigabe — Prüfen: Vor dem Produktivgang einen dokumentierten Angriffslauf fahren, tokenauffällige und flüssig formulierte Eingaben getrennt. Ein bestandener Lauf beweist keine Sicherheit, ein durchgefallener beweist eine Lücke. Durchgefallen, wenn nie jemand versucht hat, das System zu brechen. Siehe Penetrationstest.
4. Speicher prüfbar und rückrollbar — Prüfen: Gedächtnis und Index einsehen, durchsuchen und einzelne Einträge entfernen können. Eine einmal abgelegte Injektion wirkt bei jedem späteren Abruf erneut. Durchgefallen, wenn niemand sagen kann, was aktuell im Speicher steht. Siehe gespeicherte Prompt Injection.
5. Verfahren für den Ernstfall — Prüfen: Benennen, wer welchen Zugang abschaltet, wie der Umfang eingegrenzt und wer informiert wird. Der Ernstfall ist der falsche Zeitpunkt, das zu klären. Durchgefallen, wenn auf die Frage, wer abschaltet, niemand antwortet.

Kurzfassung zum Abhaken

Die zwanzig Punkte ohne Erläuterung — zum Kopieren in ein Ticket, ein Freigabeprotokoll oder ein Review-Dokument. Als ausdruckbare Fassung mit Ankreuzfeldern: Checkliste als PDF (20 Seiten).

• 1. Tödliche Trias geprüft
• 2. Rechte aus der Aufgabe abgeleitet
• 3. Werkzeugsatz zugeschnitten
• 4. Zugangsdaten kurzlebig
• 5. Menschliche Freigabe definiert
• 6. Datenquellen inventarisiert
• 7. Fremddaten markiert
• 8. Unsichtbare Zeichen entfernt
• 9. Anweisungen bleiben in der Systemrolle
• 10. System-Prompt ohne Geheimnisse
• 11. Ausgabeformat wird geprüft
• 12. Links und Ressourcen bereinigt
• 13. Code nur in der Sandbox
• 14. Ausgaben gelten als Fremdeingabe
• 15. Ausgehende Ziele eingeschränkt
• 16. Werkzeugaufrufe protokolliert
• 17. Verhalten überwacht, nicht nur Text
• 18. Testlauf ist Teil der Freigabe
• 19. Speicher prüfbar und rückrollbar
• 20. Verfahren für den Ernstfall

Häufige Fragen

Gibt es eine Checkliste gegen Prompt Injection?

Ja. Diese Seite fasst zwanzig prüfbare Punkte aus den OWASP-Empfehlungen zu LLM01 und der BSI-Handreichung zu Evasion Attacks zusammen — von der Rechtevergabe über Eingang und Ausgang bis zu Betrieb und Nachweis.