Ich habe einen KI-Sicherheitsscanner gebaut – und dann einen Bug in meinem eigenen Detektor gefunden

Prompt Injection ist ein großes Sicherheitsrisiko für LLM-Anwendungen. Man füttert ein Modell mit Texten, die es anweisen, seine ursprünglichen Anweisungen zu ignorieren. Manchmal folgt das Modell diesen.

Ich habe AgentProbe entwickelt, um dies zu testen. Es feuert 49 Angriffsprompts über 8 Kategorien hinweg ab, wie zum Beispiel Jailbreaks und Datenextraktion. Es berichtet darüber, wie oft ein Modell versagt.

Die eigentliche Lektion war nicht der Scanner. Es war ein Bug in meinem Detektionscode.

Der schwierige Teil ist nicht der Angriff. Der schwierige Teil ist die Detektion.

Woher weiß man, ob ein Modell einem Angriff tatsächlich nachgegeben hat? Keyword-Matching ist der einfache Weg. Man sucht nach Verweigerungsphrasen wie „I cannot help“ oder Compliance-Phrasen wie „developer mode“.

Aber Modelle nutzen ein „Hedge-then-Comply“-Muster. Sie sagen „I cannot help with that“, liefern dann aber trotzdem die eingeschränkten Informationen. Keyword-Matching scheitert hier, weil die Verweigerungsphrase vorhanden ist.

Um dies zu beheben, habe ich ein „LLM-as-judge“-System verwendet. Ich habe den Austausch an ein stärkeres Modell gesendet, um entscheiden zu lassen, ob das Zielmodell tatsächlich nachgegeben hat. Mein Plan war es, zuerst günstige Keyword-Checks zu nutzen und den teuren Judge erst dann einzusetzen, wenn der Keyword-Check unsicher war.

Dann fand ich meinen Bug.

Mein Keyword-Detektor gab einen Confidence-Score von 1 zurück, wenn er ein „Hedge-then-Comply“-Muster fand. Mein Code vertraute der Keyword-Stufe jedoch nur, wenn der Confidence-Score bei 2 oder höher lag.

Das bedeutete, dass mein „günstiger“ Detektor nie eine tatsächliche Entscheidung traf. Jeder einzelne Fall wurde an den teuren Judge eskaliert. Ich habe für jeden Fall einen Judge bezahlt, selbst wenn mein kostenloses Tool es hätte erledigen sollen.

Dieser Fehler hat mich drei Lektionen darüber gelehrt, wie man LLMs nutzt, um andere LLMs zu bewerten:

  • Der Judge muss intelligenter sein als das Zielmodell. Wenn der Judge dieselbe Größe wie das Zielmodell hat, wird er dieselben blinden Flecken haben.
  • Genauigkeit kann täuschen. Wenn die meisten Modelle verweigern, wirkt ein Judge, der immer „verweigert“ sagt, zwar genau, lernt aber nichts. Verwenden Sie Metriken wie Cohens Kappa, um den Zufallsfaktor zu berücksichtigen.
  • Der Judge muss stabil sein. Führen Sie denselben Test fünfmal aus. Wenn der Judge seine Meinung ändert, ist das Ergebnis mehrdeutig und erfordert eine menschliche Prüfung.

Wenn Sie mit LLMs arbeiten, denken Sie an diese Punkte:

  • Nachgiebigkeit zu erkennen ist schwieriger, als sie zu provozieren.
  • Achten Sie auf Modelle, die im ersten Satz verweigern, aber im zweiten nachgeben.
  • Vertrauen Sie einem LLM-Judge nicht blind. Messen Sie seine Zuverlässigkeit.
  • Teilen Sie Ihre Bugs. Die Entdeckung meines eigenen Mangels hat mich mehr gelehrt, als ein perfekter Launch es getan hätte.

Source: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a

Optional learning community: https://t.me/GyaanSetuAi