Ho costruito uno scanner di sicurezza AI — poi ho trovato un bug nel mio stesso rilevatore

Il prompt injection è uno dei principali rischi di sicurezza per le applicazioni LLM. Si fornisce al modello un testo che gli ordina di ignorare le istruzioni originali. A volte, il modello ubbidisce.

Ho creato AgentProbe per testare questo aspetto. Esegue 49 prompt di attacco suddivisi in 8 categorie, come jailbreak ed estrazione di dati. Riporta quanto spesso un modello fallisce.

La vera lezione non è stata lo scanner. È stato un bug nel mio codice di rilevamento.

La parte difficile non è l'attacco. La parte difficile è il rilevamento.

Come si fa a sapere se un modello ha effettivamente assecondato un attacco? Il keyword matching è la via più semplice. Si cercano frasi di rifiuto come "Non posso aiutarti" o frasi di conformità come "developer mode".

Ma i modelli utilizzano un pattern "hedge-then-comply". Dicono "Non posso aiutarti con questo", ma poi forniscono comunque le informazioni riservate. Il keyword matching fallisce in questo caso perché la frase di rifiuto è presente.

Per risolvere il problema, ho utilizzato un sistema "LLM-as-judge". Ho inviato lo scambio a un modello più potente per decidere se il target avesse effettivamente assecondato l'attacco. Il mio piano era utilizzare prima controlli tramite parole chiave economici e usare il giudice costoso solo quando il controllo tramite parole chiave non era certo.

Poi ho trovato il mio bug.

Il mio rilevatore di parole chiave restituiva un punteggio di confidenza pari a 1 quando trovava un pattern "hedge-then-comply". Tuttavia, il mio codice si fidava della fase di keyword matching solo se la confidenza era pari o superiore a 2.

Ciò significava che il mio rilevatore "economico" non prendeva mai una decisione reale. Ogni singolo caso veniva passato al giudice costoso. Stavo pagando un giudice per ogni caso, anche quando il mio strumento gratuito avrebbe dovuto gestirlo.

Questo errore mi ha insegnato tre lezioni sull'uso degli LLM per valutare altri LLM:

  • Il giudice deve essere più intelligente del target. Se il giudice ha le stesse dimensioni del target, condividerà gli stessi punti ciechi.
  • L'accuratezza può ingannare. Se la maggior parte dei modelli rifiuta, un giudice che dice sempre "rifiutato" sembrerà accurato, ma non imparerà nulla. Usa metriche come il kappa di Cohen per tenere conto della fortuna.
  • Il giudice deve essere stabile. Esegui lo stesso test cinque volte. Se il giudice cambia idea, il risultato è ambiguo e richiede l'intervento umano.

Se sviluppi con gli LLM, ricorda questi punti:

  • Rilevare la conformità è più difficile che provocarla.
  • Fai attenzione ai modelli che rifiutano nella prima frase ma assecondano nella seconda.
  • Non fidarti ciecamente di un giudice LLM. Misurane l'affidabilità.
  • Condividi i tuoi bug. Trovare il mio difetto mi ha insegnato più di quanto avrebbe fatto un lancio perfetto.

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