Pular para o conteúdo

LLM Firewall

Visao Geral

O LLM Firewall do Floopy inspeciona cada prompt antes de ser encaminhado ao provedor de IA. Requisicoes sinalizadas como maliciosas, inseguras ou que violam politicas sao bloqueadas e nunca chegam ao modelo. Isso protege sua aplicacao contra injecao de prompt, tentativas de jailbreak e geracao de conteudo prejudicial.

O firewall opera inline — adiciona latencia minima a requisicoes seguras e bloqueia completamente as perigosas.

Como Funciona

O firewall envia cada prompt para um LLM ajustado para seguranca que classifica a mensagem como safe ou unsafe segundo as categorias abaixo. O veredito decide o caminho da requisicao: unsafe bloqueia; safe (ou qualquer falha do LLM) deixa a requisicao passar.

Categorias consideradas inseguras:

  • Tentativas de injecao de prompt e jailbreak
  • Pedidos de conteudo de autolesao
  • Conteudo sexual envolvendo menores
  • Instrucoes de atividades ilegais
  • Discurso de odio

Para manter a latencia e o custo controlados, o firewall mantem um cache de vereditos no Qdrant: quando o embedding de um veredito unsafe recente e similar o suficiente ao da requisicao (limite configuravel), o veredito em cache evita a chamada ao LLM. Apenas vereditos unsafe sao cacheados — safe sempre e recalculado para que uma troca de modelo possa inverter o resultado sem etapa manual.

Requisicoes Bloqueadas

Quando o firewall bloqueia uma requisicao, ele retorna um codigo de status 400 com uma mensagem de erro indicando que a requisicao foi rejeitada pelo filtro de seguranca. O prompt original nunca e enviado ao provedor de IA.

Sua aplicacao deve tratar essa resposta de forma elegante — por exemplo, exibindo uma mensagem amigavel informando que a entrada nao pode ser processada.

Configuracao

O modelo do firewall e o comportamento do cache sao controlados por variaveis de ambiente:

VariavelPropositoPadrao
FIREWALL_MODELBackend + modelo usado para classificar a seguranca, em notacao [provider](model):weightmeta-llama/Llama-Guard-4-12B (Together)
FIREWALL_SEMANTIC_CACHE_THRESHOLDLimite de similaridade de cosseno para hits no cache0.95
FIREWALL_VERDICT_CACHE_TTL_SECONDSTTL dos vereditos unsafe cacheados172800 (48h)

Distribuicoes como [bedrock](anthropic.claude-3-haiku-20240307-v1:0):0.5,[together](meta-llama/Llama-Guard-4-12B):0.5 roteiam entre provedores usando um RNG semeado pelo request_id, garantindo que uma mesma requisicao sempre escolhe o mesmo backend.

Monitorando Eventos do Firewall

Toda decisao do firewall — tanto permitidas quanto bloqueadas — e registrada e visivel no dashboard em Firewall. Cada evento inclui:

  • O timestamp e a chave de API utilizada.
  • O veredito (safe / unsafe) e se o cache evitou a chamada ao LLM.
  • O backend + modelo que produziu o veredito (colunas backend, model_ref na linha do request).
  • Se a requisicao foi permitida ou bloqueada.

Use o log de eventos para identificar padroes de ataque e verificar que requisicoes legitimas nao estao sendo bloqueadas.

Habilitando o Firewall via Headers

Voce pode habilitar o firewall por requisicao usando o header abaixo, independentemente da configuracao padrao da sua chave de API. Isso e util quando apenas certas requisicoes precisam de verificacao de seguranca.

HeaderValoresDescricao
floopy-llm-security-enabled"true"Executa o firewall para esta requisicao
import { OpenAI } from "openai";
const client = new OpenAI({
baseURL: "https://api.floopy.ai/v1",
apiKey: process.env.FLOOPY_API_KEY,
});
const response = await client.chat.completions.create(
{
model: "gpt-4o",
messages: [{ role: "user", content: userInput }],
},
{
headers: {
"floopy-llm-security-enabled": "true",
},
},
);
console.log(response.choices[0].message.content);

Requisitos de Plano

O LLM Firewall requer um plano com o recurso has_advanced_firewall habilitado. Verifique seu plano atual em Settings > Billing para ver se o firewall esta disponivel para sua organizacao.