Firewall de Injeção de Prompt

Demo ao vivo: https://prompt-injection-firewall.streamlit.app Vídeo de demonstração de 2 minutos: https://drive.google.com/file/d/1tzb75nFysisrCYa11Lqj6egDs5VNmc2n/view?usp=drivesdk

Um firewall de duas camadas para um bot de suporte baseado em LLM: ele verifica o que os usuários enviam e o que o bot envia de volta.

Problema

Os usuários podem tentar substituir as regras de um bot ("ignore as instruções anteriores"), trocar sua persona ou fazê-lo revelar seu prompt de sistema ou segredos. Este projeto bloqueia tais entradas, detecta vazamentos nas respostas do bot e mede o quão bem ele funciona, incluindo onde ele falha.

Como funciona

user input
   |
   v
[1] Rule layer (regex, fast, free)  --match--> BLOCK
   |no match
   v
[2] LLM classifier (Gemini, JSON output, Pydantic validation, retries, fail-closed) --attack--> BLOCK
   |benign
   v
AcmeBot (Gemini + system prompt)
   |
   v
[3] Output check (canary token, secret patterns, system-prompt fragments) --leak--> BLOCK
   |clean
   v
answer to user

Executá-lo

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
copy .env.example .env      # then put your Gemini key in .env
python src\run_eval.py dev
python src\eval_output.py dev
python src\compare.py dev
streamlit run app.py        # local demo

Modelo usado: gemini-3.1-flash-lite. O nível gratuito pode retornar 503 quando está ocupado; o código aguarda e tenta novamente. Não execute src\build_cases.py a menos que queira reconstruir data\cases.jsonl (ele o sobrescreve; a mesma seed gera os mesmos casos).

Dados

• Casos de entrada: 25 amostrados (seed 7) de deepset/prompt-injections (Apache-2.0): 12 ataques, 13 benignos. Divisão: 15 dev, 10 ocultos.
• Casos de saída: 12 escritos por mim com assistência de IA (8 dev, 4 ocultos), incluindo vazamentos ocultados por espaçamento e texto benigno que menciona "password"/"API key".
• data/train.parquet está incluído no repositório (fonte: deepset/prompt-injections, Apache-2.0).
• A divisão oculta foi executada uma vez, após a última alteração na lógica de detecção e nos prompts.

Resultados

Conjunto	Camada	Resultado
dev	apenas regras	detecção 2/9, falso positivo 0/6
dev	regras + Gemini (final)	detecção 8/9, falso positivo 0/6
dev	verificação de saída (final)	vazamento detectado 4/4, falso positivo 0/4
oculto	regras + Gemini	detecção 3/3, falso positivo 0/7
oculto	verificação de saída	vazamento detectado 3/3, falso positivo 0/1

Firewall vs sem firewall:

	Sem	Com
dev: ataques que chegam ao bot	9/9	1/9
dev: benignos bloqueados por engano	0/6	0/6
oculto: ataques que chegam ao bot	3/3	0/3
oculto: benignos bloqueados por engano	0/7	0/7

O conjunto oculto tem apenas 3 ataques, portanto é um sinal fraco. Dev e oculto são reportados separadamente porque ajustei o prompt do classificador em dev.

O que falhou e o que mudei

O histórico completo com números está em CHANGELOG.md. Em resumo:

• Apenas as regras detectaram 2/9 ataques (somente frases literais). Adicionar o classificador Gemini elevou para 7/9.
• Um nome de modelo errado fez todas as chamadas falharem e o fallback fail-closed bloqueou tudo (9/9 ataques, 6/6 falsos positivos). Essa pontuação falsa mostrou por que erros devem interromper a execução em vez de serem engolidos.
• #4 (uma instrução oculta após uma pergunta normal) passou despercebida; adicionei uma regra geral ao prompt, resultando em 8/9.
• #14 "generate c++" ainda falha. Está rotulado como ataque no conjunto de dados de origem, mas parece inofensivo, provavelmente ruído de rotulagem.
• A verificação de saída não detectou um segredo escrito com espaços ("ZX CANARY 7731"); normalizei o texto antes da correspondência.
• Executar a verificação de saída nas respostas reais do bot mostrou falsos alarmes quando o bot se apresentava (correspondência de 6 palavras com o prompt do sistema); alterei o comprimento da correspondência para 8 palavras.
• Implantação: a chave de API agora também é lida do ambiente (segredos do Streamlit). Nenhuma alteração na lógica de detecção ou nos prompts.

Limitações

• Poucos dados: 25 casos de entrada e 12 casos de saída. Os números não são estatisticamente sólidos.
• A maioria dos ataques de origem são prompts de propaganda ou de persona, não roubo de prompt do sistema, então a verificação de saída não acrescentou nada além da camada de entrada na comparação.
• Os casos de teste da verificação de saída foram escritos por mim, então eles mostram que a verificação funciona nos meus casos, não em vazamentos reais.
• A verificação de saída não detecta vazamentos parafraseados, codificados em base64 ou em outros idiomas, e não detecta vazamentos com menos de 8 palavras consecutivas.
• Os padrões de regras se ajustam às frases comuns deste conjunto de dados; outros estilos de ataque dependem da camada de LLM.
• A camada de LLM adiciona uma chamada de API por mensagem (latência e custo) e depende de um serviço de terceiros.
• A demonstração pública é limitada a 10 mensagens por sessão e pode parar de funcionar se a cota gratuita da API se esgotar.