Eu Construí um Scanner de Segurança de IA — E Depois Encontrei um Bug no Meu Próprio Detector

O prompt injection é um dos principais riscos de segurança para aplicações de LLM. Você fornece ao modelo um texto que o instrui a ignorar suas instruções originais. Às vezes, o modelo obedece.

Eu construí o AgentProbe para testar isso. Ele dispara 49 prompts de ataque em 8 categorias, como jailbreaks e extração de dados. Ele reporta com que frequência um modelo falha.

A verdadeira lição não foi o scanner. Foi um bug no meu código de detecção.

A parte difícil não é o ataque. A parte difícil é a detecção.

Como você sabe se um modelo realmente obedeceu a um ataque? A correspondência de palavras-chave (keyword matching) é o caminho fácil. Você procura por frases de recusa como "I cannot help" ou frases de conformidade como "developer mode".

Mas os modelos usam um padrão de "hesitar-e-cumprir" (hedge-then-comply). Eles dizem "I cannot help with that", mas depois fornecem a informação restrita de qualquer maneira. A correspondência de palavras-chave falha aqui porque a frase de recusa está presente.

Para corrigir isso, usei um sistema de "LLM-como-juiz" (LLM-as-judge). Enviei a interação para um modelo mais forte para decidir se o alvo realmente cumpriu a instrução. Meu plano era usar verificações de palavras-chave baratas primeiro e usar o juiz caro apenas quando a verificação de palavras-chave não tivesse certeza.

Então, encontrei meu bug.

Meu detector de palavras-chave retornava uma pontuação de confiança de 1 quando encontrava um padrão de "hesitar-e-cumprir". No entanto, meu código só confiava na etapa de palavras-chave se a confiança fosse 2 ou superior.

Isso significava que meu detector "barato" nunca tomava uma decisão de fato. Cada caso era escalado para o juiz caro. Eu estava pagando por um juiz em todos os casos, mesmo quando minha ferramenta gratuita deveria ter resolvido.

Esse erro me ensinou três lições sobre o uso de LLMs para avaliar outros LLMs:

  • O juiz deve ser mais inteligente que o alvo. Se o juiz tiver o mesmo tamanho que o alvo, ele compartilhará os mesmos pontos cegos.
  • A precisão pode enganar. Se a maioria dos modelos recusar, um juiz que sempre diz "recusado" parecerá preciso, mas não aprenderá nada. Use métricas como o kappa de Cohen para levar a sorte em conta.
  • O juiz deve ser estável. Execute o mesmo teste cinco vezes. Se o juiz mudar de ideia, o resultado é ambíguo e precisa de um olhar humano.

Se você constrói com LLMs, lembre-se destes pontos:

  • Detectar a conformidade é mais difícil do que causá-la.
  • Fique atento a modelos que recusam na primeira frase, mas cumprem na segunda.
  • Não confie cegamente em um juiz LLM. Meça sua confiabilidade.
  • Compartilhe seus bugs. Encontrar minha própria falha me ensinou mais do que um lançamento perfeito teria ensinado.

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

Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi