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.