Dokumente und Nachrichten können Text enthalten, der eine KI von ihrer eigentlichen Aufgabe ablenkt. Für die Abnahme zählt deshalb, ob technische Grenzen auch dann halten, wenn das Modell unerwarteten Anweisungen folgt.
Was Sie mit einem Test herausfinden wollen
Bei Prompt Injection beeinflussen Eingaben das Verhalten eines Sprachmodells auf unerwünschte Weise. Das kann im direkten Gespräch geschehen oder über Inhalte, die die Anwendung aus Dokumenten, Webseiten oder Werkzeugen übernimmt. OWASP unterscheidet diese direkten und indirekten Wege und weist darauf hin, dass RAG und Fine-Tuning das Problem nicht vollständig beseitigen.
Für ein Unternehmen ist deshalb nicht nur interessant, ob eine Antwort merkwürdig klingt. Entscheidend ist, ob Daten fremder Nutzer sichtbar werden, unerlaubte Aktionen stattfinden oder eine vorgeschriebene Freigabe entfällt. Formulieren Sie diese unerwünschten Ergebnisse vor dem Test zusammen mit Ihrer Agentur.
Prüfungen gehören in eine ausdrücklich freigegebene Umgebung mit künstlichen Daten. Ein echter Datenabfluss oder eine tatsächliche Bestellung ist nicht nötig, um einen Fehler nachzuweisen. Verwenden Sie harmlose Markierungen und simulierte Aktionen, deren Auftreten eindeutig erkennbar ist.
Die Eingangswege vollständig erfassen
Zeichnen Sie auf, welche Inhalte das Modell erhält. Bei einer einfachen Wissenssuche sind das die Frage und gefundene Textstellen. Eine erweiterte Assistenz erhält vielleicht zusätzlich E-Mails, Kalendereinträge oder Antworten aus einem Kundensystem. Jeder dieser Wege benötigt eine passende Prüfung.
Der OWASP-Leitfaden zur RAG-Sicherheit betrachtet die gesamte Verarbeitungskette. Daraus leiten wir für die Beauftragung eine einfache Forderung ab: Der Testbericht muss erkennen lassen, welche Teile untersucht wurden und welche ausserhalb des Umfangs lagen.
Prüfen Sie auch gewöhnliche Eingaben. Eine Schutzfunktion, die fast jede schwierige Frage blockiert, kann zwar auffällig wenige Fehler erzeugen, ist aber möglicherweise im Alltag unbrauchbar. Sicherheit und nutzbare Funktion müssen gemeinsam beurteilt werden.
Ein ungefährlicher Test mit klarer Erwartung
Als fiktives Beispiel dient ein Assistent, der interne Produktinformationen zusammenfasst. Für den Test wird ein künstliches Dokument mit einer auffälligen Anweisung versehen, die eine sachfremde Antwortmarkierung auslösen soll. Es enthält keine Geheimnisse und nennt kein reales externes Ziel.
Die Anwendung soll den fachlichen Inhalt nutzen, die enthaltene Anweisung jedoch nicht als berechtigten Arbeitsauftrag behandeln. Erscheint die Markierung, ist zunächst eine Beeinflussung der Antwort nachgewiesen. Das beweist noch nicht automatisch einen Zugriff auf andere Daten oder eine mögliche schreibende Aktion.
Für diese weitergehenden Fragen braucht es eigene, ebenfalls harmlose Tests. Ein simuliertes Werkzeug kann beispielsweise lediglich protokollieren, dass ein verbotener Aufruf versucht wurde. So trennt die Auswertung die Beeinflussung des Modells von der Wirksamkeit der technischen Schutzschicht.
Eine kompakte Prüfkarte
Verlangen Sie für jeden geprüften Fall eine Karte mit nachvollziehbaren Angaben. Folgende Felder sind ein redaktioneller Vorschlag und kein vollständiger Penetrationsteststandard.
Fallkennung und getestete Version der Anwendung.
Eingangsweg des künstlichen Inhalts.
Ursprüngliche, erlaubte Nutzeraufgabe.
Unerwünschtes Verhalten, das der Test erkennen soll.
Verfügbare Daten und erlaubte Aktionen des Testkontos.
Beobachtung in Antwort, Werkzeugaufrufen und Zielsystem.
Bewertung, offene Grenze und geplante Nachprüfung.
Eine Bildschirmaufnahme der letzten Antwort genügt häufig nicht. Wenn im Hintergrund eine unerlaubte Aktion versucht wurde, muss dies im Ergebnis stehen, auch wenn die Oberfläche am Ende eine harmlose Meldung zeigt.
Schutzmassnahmen getrennt nachweisen
Fragen Sie die Agentur, welche Grenzen ausserhalb des Sprachmodells durchgesetzt werden. Ein Modell kann etwa eine Änderung vorschlagen, während das Zielsystem die Berechtigung unabhängig prüft. Eine menschliche Freigabe muss die tatsächlich geplante Aktion zeigen, damit sie eine sinnvolle Entscheidung ermöglicht.
Besonders hilfreich ist ein Vergleich vor und nach einer Korrektur mit denselben Testfällen. So sehen Sie, welche Schwäche behoben wurde. Ergänzende Fälle prüfen, ob die Änderung normale Aufgaben beeinträchtigt oder nur eine einzelne Formulierung erkennt.
Ein bestandener Prüfsatz bedeutet nicht, dass alle künftigen Varianten ausgeschlossen sind. Dokumentieren Sie den Umfang und wiederholen Sie relevante Prüfungen nach Änderungen an Modellen, Datenzugängen oder Werkzeugen. Vereinbaren Sie einen Meldeweg für neue Auffälligkeiten aus dem Betrieb.
Die organisatorische Ergänzung ist eine klare Regelung von Freigaben und Agentenkontrolle. Wenn Sie Sicherheitsnachweise als Liefergegenstand formulieren möchten, kann einclick als KI-Agentur aus Zürich mit Ihnen einen begrenzten, überprüfbaren Testumfang für Ihre Anwendung festlegen.
