# Checkliste für die LLM-Sicherheitsprüfung

Verwenden Sie diese Liste vor der Bereitstellung einer LLM-Funktion, die nicht vertrauenswürdige Inhalte liest, private Daten abruft oder Werkzeuge aufruft.

## 1. Workflow-Grenze

- [ ] Die für den Workflow verantwortliche Person ist benannt.
- [ ] Die erlaubten Aktionen des Workflows sind dokumentiert.
- [ ] Externe, destruktive, finanzielle, rechtliche, personalbezogene oder für Kunden sichtbare Aktionen sind identifiziert.
- [ ] Es gibt eine dokumentierte Möglichkeit, den Workflow schnell zu deaktivieren.
- [ ] Der Workflow verfügt über einen Rollback- oder manuellen Fallback-Pfad.

## 2. Inventar nicht vertrauenswürdiger Eingaben

- [ ] Direkte Nutzereingaben werden als nicht vertrauenswürdig behandelt.
- [ ] Abgerufene Dokumente werden als nicht vertrauenswürdige Daten und nicht als Anweisungen behandelt.
- [ ] Tool-Ausgaben werden nur dann als vertrauenswürdig betrachtet, wenn sie innerhalb des vertrauenswürdigen Bereichs generiert wurden.
- [ ] Hochgeladene PDFs, Bilder, Audiodateien, Tabellen und Transkripte werden als nicht vertrauenswürdig behandelt.
- [ ] Webseiten und Beobachtungen des Browser-Agenten werden als nicht vertrauenswürdig behandelt.
- [ ] Admin-bearbeitbare Prompts, Workflow-Vorlagen, CMS-Inhalte und Wissensquellen werden vor der Produktionsnutzung überprüft.

## 3. Daten- und Retrieval-Grenze

- [ ] Geheimnisse, Anmeldeinformationen, Roh-Token und private URLs werden niemals an das Modell gesendet.
- [ ] Das Retrieval wird vor dem Ranking nach Mandant, Nutzer, Rolle und Quellberechtigungen gefiltert.
- [ ] Abgerufene Chunks bewahren Quell-ID, Mandanten-ID, Sichtbarkeit, verantwortliche Person, Version und Prüfzeitstempel.
- [ ] Der Antwortpfad kann angeben oder protokollieren, welche Quell-IDs verwendet wurden.
- [ ] Veraltete, nicht geprüfte oder niedrig vertrauenswürdige Quellen werden ausgeschlossen oder markiert.
- [ ] Logs schwärzen personenbezogene Daten und Zugangsdaten.

## 4. Prompt- und Kontextvertrag

- [ ] System-/Entwickleranweisungen werden wie Code versioniert und überprüft.
- [ ] Nicht vertrauenswürdige Inhalte werden umschlossen und als Daten gekennzeichnet.
- [ ] Das Modell erhält eine klare Anweisung für Konflikte zwischen nicht vertrauenswürdigen Inhalten und Aufgabenanweisungen.
- [ ] Das Modell erhält nur den minimalen Kontext, der für die Aufgabe erforderlich ist.
- [ ] Hochrisiko-Workflows verwenden einen eng begrenzten Extraktionsschritt, bevor der Hauptagent Inhalte sieht.
- [ ] Prompt-Canary-Phrasen werden nur zur Erkennung verwendet und nicht als primäre Verteidigung.

## 5. Werkzeug- und Aktionsdesign

- [ ] Werkzeuge sind eng begrenzt und aufgabenspezifisch.
- [ ] Werkzeuge beziehen Nutzer, Mandant und Rolle aus dem serverseitigen Authentifizierungskontext, nicht aus Modellargumenten.
- [ ] Jedes Werkzeug validiert Argumente anhand eines Schemas und von Geschäftsregeln.
- [ ] Jedes Werkzeug erzwingt die Autorisierung unabhängig vom Modell.
- [ ] Schreibtools sind so weit wie möglich idempotent.
- [ ] Externe Nebenwirkungen erfordern menschliche Freigabe oder deterministische Richtlinienprüfungen.
- [ ] Rate Limits, Quoten und Kostenlimits sind konfiguriert.
- [ ] Toolaufrufe werden mit Benutzer, Mieter, Workflow, Promptversion, Modell, Argumentübersicht und Ergebnis protokolliert.

## 6. Ausgabevalidierung

- [ ] Die Modellausgabe wird vor der Verwendung anhand eines strikten Schemas geparst.
- [ ] Unbekannte Felder werden abgelehnt, wenn der Vertrag geschlossen ist.
- [ ] URLs, Markdown, HTML, Dateinamen und Codeblöcke werden bei Bedarf bereinigt.
- [ ] Ausgaben dürfen keine Datenklassen enthalten, die außerhalb des für die Aufgabe erlaubten Bereichs liegen.
- [ ] Faktenbasierte Antworten über private Quellen benötigen Quell-IDs oder Quellabschnitte.
- [ ] Bei fehlerhaft formatierten Ausgaben schlägt der Prozess sicher fehl, statt auf freien Text zurückzufallen.

## 7. Regressionstests

- [ ] Direkter Injection-Test: Eine Nutzereingabe fordert das Modell auf, Anweisungen zu ignorieren.
- [ ] Indirekter Injection-Test: Abgerufene Inhalte verlangen vom Modell, Daten zu enthüllen oder ein Tool aufzurufen.
- [ ] Cross-Tenant-Test: Eine Anfrage versucht, Daten eines anderen Mandanten zu nutzen.
- [ ] Test eines unsicheren Werkzeugaufrufs: Das Modell fordert eine nicht verfügbare oder nicht erlaubte Aktion an.
- [ ] Falsch formatierter Ausgabetest: Zusätzliche Felder oder ungültige Enum-Werte werden abgelehnt.
- [ ] Exfiltrationstest: Die Ausgabe versucht, Geheimnisse, private Daten oder Prompttext offenzulegen.
- [ ] Persistenztest: Gespeicherter Inhalt enthält schädliche Anweisungen, die später abgerufen werden.
- [ ] Multimodaler Test, falls relevant: OCR-sichtbare oder bildsichtbare Anweisungen werden als nicht vertrauenswürdig behandelt.

## 8. Überwachung und Incident Response

- [ ] Versuche zur Prompt-Extraktion sind erkennbar.
- [ ] Wiederholte Validatorfehler lösen Warnmeldungen aus.
- [ ] Ungewöhnliche Retrieval-Breite, Zahl der Werkzeugaufrufe, externe Empfänger sowie Kosten- oder Ratenanstiege lösen Warnmeldungen aus.
- [ ] Prompt-Injection-Versuche können mit Benutzer-, Mandanten-, Workflow-, Quell-ID und Tool-Aufrufen verknüpft werden.
- [ ] Das Team weiß, wie der Workflow oder einzelne Tools deaktiviert werden können.
- [ ] Das Team weiß, wie Provider-Schlüssel widerrufen und betroffene Anmeldeinformationen rotiert werden können.
- [ ] Für Entscheidungen über Benachrichtigungen an Kunden, Rechtsabteilung, Sicherheitsteam und Aufsichtsbehörden ist eine Person benannt.

## Freigabekriterium

Markieren Sie den Workflow nicht als produktionsreif, bis:

- [ ] Alle folgenreichen Aktionen verfügen über eine Freigabestufe.
- [ ] Mindestens ein adversärer Dokumententest erfolgreich war.
- [ ] Mindestens ein Versuch einer unbefugten Zugriffsanfrage sicher fehlgeschlagen ist.
- [ ] Mindestens ein Versuch eines unsicheren Werkzeugaufrufs sicher fehlgeschlagen ist.
- [ ] Mindestens ein Test mit fehlerhaft formatierter Ausgabe sicher fehlgeschlagen ist.
- [ ] Mindestens ein Workflow-Deaktivierungspfad getestet wurde.