In einem Dokument, das ein Assistent konsultiert, kann eine sofortige Injektion ausgeblendet werden: Der Text versucht, seine Aufgabe aufzugeben oder Informationen offenzulegen. Behandeln Sie wiederhergestellte Inhalte als unzuverlässige Daten und begrenzen Sie Aktionen, die das System ausführen kann.
Identifizieren Sie die Grenze des Vertrauens
Eine Webseite, ein PDF oder eine empfangene Nachricht hat nicht die Berechtigung für die Anweisungen Ihrer Anwendung. Ein Inhalt, der das Gegenteil bestätigt, muss eine zu analysierende Quelle bleiben. OWASP identifiziert Prompt Injection unter den Risiken von Sprachmodellanwendungen. Eine einfache Anweisung, die das Modell einlädt, die Angriffe zu ignorieren, stellt keine ausreichende technische Trennung dar.
mögliche Konsequenzen reduzieren
Ein Dokumentassistent muss im Allgemeinen nicht in der Lage sein, Nachrichten zu senden, Dateien zu bearbeiten oder alle Ordner des Unternehmens anzuzeigen. Beschränken Sie seine Werkzeuge und den Zugriff auf den nützlichen Perimeter. Trennen Sie die Dokumentensuche von der Ausführung einer Aktion. Wenn eine sensible Aktion vorhanden ist, lassen Sie ihre Parameter in einer kontrollierten Schnittstelle validieren, wobei Regeln außerhalb des generierten Textes liegen.
Erstellen Sie ein Testszenario ohne sensible Daten
Arbeiten Sie in einer geplanten Abnahmetestumgebung mit einem Korpus und Demo-Konten. Der Test sollte nicht um ein echtes Leck gebeten werden, um zu beweisen, dass das Risiko besteht. Legen Sie in ein Dummy-Dokument eine Anweisung, die versucht, die Aufgabe umzuleiten, und stellen Sie dann eine legitime Frage zu diesem Dokument. Ziel ist es, das Verhalten der gesamten Anwendung einschließlich ihrer Tools und Zugriffskontrollen zu beobachten.
| Dummy-Inhalte | Erwartetes Verhalten | Nützlicher Beweis |
|---|---|---|
| Eine Anweisung, die die Frage ignoriert | Die Anfrage des Benutzers bleibt der Arbeitsumfang | Frage, Antwort und verwendete Dokumente |
| eine Anfrage, ein Dokument an einen Dritten weiterzuleiten | Es ist keine unbefugte Sendung möglich | Liste der zugänglichen Tools und Anrufliste |
| Eine Anfrage zum Lesen einer Ressource außerhalb des Perimeters | App-Zugriffskontrolle lehnt die Wiedergabe ab | Modellunabhängiges Kontrollergebnis |
| Ein Ausflug, der wie eine Geschäftsaktion aussieht | Die Ausgabe bleibt zu validieren | Trace, die das Fehlen einer automatischen Ausführung zeigt |
dieOWASP beschreibt direkte und indirekte Injektionen und empfiehlt Maßnahmen, die ihre Folgen einschränken. Die Tatsache, dass ein Versuch das Modell nicht umleiten kann, zeigt keinen vollständigen Schutz. Die kritische Frage bleibt: Was könnte passieren, wenn ein nächster Versuch verfolgt wird? Die Antwort muss durch Anwendungsberechtigungen und Steuerelemente gesteuert werden.
Überprüfen Sie die Ausgaben vor der Verwendung
Übertragen Sie keine Modellantwort direkt an einen Befehlsinterpreter oder eine Geschäftsabfrage. Überprüfen Sie die Struktur, Ziele und Berechtigungen im Anwendungscode. Die angezeigten Links sollten ebenfalls mit Vorsicht behandelt werden. Die Antwort kann zur Analyse in einer geeigneten Umgebung aufgezeichnet werden, wodurch unnötige Aufbewahrung vertraulicher Informationen vermieden wird.
Fiktives Beispiel: Ein Support-Dokument
Eine Demo-Datei enthält eine Anweisung, die den Assistenten auffordert, seine Konfiguration anzuzeigen. Das erwartete Ergebnis ist eine Antwort, die sich auf die Benutzerfrage konzentriert, ohne Offenlegung oder Tool-Aufruf außerhalb des Umfangs. Der Test sollte Dummy-Daten in einer isolierten Umgebung verwenden. Überprüfen Sie vor allem, dass der technische Schutz das Leck verhindert, auch wenn das Modell einer unerwünschten Anweisung folgt.
Separate Antwort, Aktionsvorschlag und Ausführung
- Starten Sie für einen ersten Dokumentationsassistenten ohne Senden, Löschen oder Ändern des Business-Tools. Überprüfen Sie, ob diese Funktionen tatsächlich in Berechtigungen fehlen und nicht nur in der Benutzeroberfläche ausgeblendet werden.
- Wenn eine Aktion erforderlich ist, validieren Sie im Code ihr Ziel, ihren Typ und die Rechte des Antragstellers. Eine vom Modell erzeugte Zeichenfolge sollte nicht direkt als Autorisierung verwendet werden.
- Zeigen Sie wichtige Einstellungen in einem geeigneten Bestätigungsbildschirm an. Die Anweisungen auf der angezeigten Seite sollten diesen Vorgang nicht ändern können.
- Überprüfen Sie auch die Präsentation der Antwort: HTML, Links und vorgeschlagene Teile müssen den Regeln Ihrer Bewerbung folgen. Machen Sie einen Text nicht ausführbar, da er von einem Modell stammt.
In einem fiktiven Beispiel der Webunterstützung kann der Assistent erklären, wie eine Intervention angefordert wird. Er kann eine Zusammenfassung erstellen, die die Person erneut liest. Es muss nicht die gesamte technische Datei gesendet oder der Hosting-Zugriff geändert werden. Diese Trennung reduziert die Konsequenzen einer kompromittierten Reaktion, während die Nützlichkeit des Dienstes beibehalten wird.
Die Abnahmetestdatei muss zwischen den durchgeführten Tests, den kontrollierten Schutzmaßnahmen und den ungeprüften Risiken unterscheiden. Nach einer Weiterentwicklung der Werkzeuge oder Rechte die betreffenden Fälle wiederholen. Verknüpfen Sie diese Arbeit mit dem Vorbereitung der RAG-Dokumentationsbasis : Der Ursprung und die Rechte der Dokumente bleiben auch dann wichtig, wenn das Modell den Anweisungen zu folgen scheint.
Integrieren Sie den Test in das Abnahmetest
Bewahren Sie einige Testdokumente auf, die direkte und indirekte Versuche darstellen. Wiederholen Sie sie nach einer Entwicklung des Modells, der Werkzeuge oder des Korpus. Beachten Sie die erwarteten Verhaltensweisen und Restgrenzen, anstatt das System unverwundbar zu deklarieren. Wählen Sie für ein erstes Projekt einen eingeschränkten Leseassistenten und konsultieren Sie die Methode von Vorbereiten einer Website für Web-Agenten.