Como o Floopy Protege Seu Tráfego de LLM

Quando você roteia suas chamadas de API de IA pelo Floopy, está nos confiando dados sensíveis: API keys, prompts, completions, informações de usuários e detalhes de cobrança. Este post percorre cada camada de segurança que construímos — o que cada uma faz, por que existe e como funcionam juntas.

O Floopy é uma plataforma de otimização de agentes de IA — o loop fechado de feedback é o produto, e a camada de gateway é a superfície que carrega seu tráfego. Este post foca especificamente nessa superfície de tráfego: as verificações, criptografia e sandboxing que aplicamos entre sua aplicação e os provedores de IA.

O modelo de ameaças

Qualquer camada que fica entre sua aplicação e um provedor de LLM de terceiros enfrenta uma combinação única de riscos:

• Roubo de API key — suas chaves de provedor (OpenAI, Anthropic) valem milhares de dólares. Um vazamento significa que outra pessoa acumula sua conta.
• Injeção de prompt — entradas maliciosas podem sequestrar seu LLM para contornar instruções, exfiltrar dados ou produzir saída prejudicial.
• Vazamento entre tenants — se a resposta em cache da organização A for servida para a organização B, você tem uma violação de dados.
• PII em logs — usuários colocam informações pessoais em prompts. Se os logs forem armazenados sem redação, uma violação de logs se torna um incidente de privacidade.
• Negação de carteira — um atacante ou loop descontrolado consome seu orçamento de tokens em minutos.

O Floopy aborda cada um desses riscos com uma camada de segurança dedicada.

Camada 1: A vantagem do Rust

O gateway é escrito em Rust — não Python, não Node.js, não Go. Isso não é uma escolha de performance (embora ajude — veja nossos benchmarks). É uma escolha de segurança.

O compilador do Rust elimina classes inteiras de vulnerabilidades em tempo de compilação:

• Buffer overflows — a causa #1 de CVEs em software C/C++. Impossível em Rust seguro.
• Desreferência de ponteiro nulo — o sistema de tipos obriga você a tratar valores ausentes explicitamente.
• Data races — o borrow checker impede acesso mutável concorrente. Ponto final.
• Use-after-free — a semântica de ownership garante que a memória é válida quando acessada.

Essas não são verificações em tempo de execução. Código que viola a segurança de memória não compila. A vulnerabilidade nunca é publicada.

Camada 2: Segurança de API key

Suas API keys do Floopy usam um formato estruturado:

flo_sk_live_<32_random_chars>_<crc32_checksum>

Três decisões de design tornam esse formato seguro:

1. Prefixo flo_sk_ — se sua chave vazar em um commit do GitHub, GitGuardian, TruffleHog e GitHub Advanced Security a detectam automaticamente. Strings hexadecimais genéricas não acionam esses scanners.

2. Hashing SHA-256 — as chaves são hasheadas antes do armazenamento. Nós literalmente não conseguimos recuperar sua chave do nosso banco de dados. Toda consulta compara hashes.

3. Revogação instantânea — quando você revoga uma chave no dashboard, o cache do Redis é invalidado imediatamente. A chave para de funcionar em segundos, não em minutos.

Camada 3: Criptografia de chaves de provedor

Suas API keys da OpenAI, Anthropic e Gemini são criptografadas em repouso usando criptografia de envelope XChaCha20-Poly1305.

Por que não AES-256-GCM? O AES-GCM usa um nonce de 96 bits. Com geração aleatória de nonce, o paradoxo do aniversário cria risco de colisão após ~2^32 criptografias. Uma colisão de nonce no AES-GCM quebra catastroficamente tanto a confidencialidade quanto a autenticidade. O XChaCha20-Poly1305 usa um nonce de 192 bits, tornando colisões aleatórias praticamente impossíveis.

Cada chave de provedor recebe sua própria Data Encryption Key (DEK), criptografada por uma Key Encryption Key (KEK) gerenciada pelo KMS. As chaves são descriptografadas apenas em tempo de execução, apenas ao encaminhar para o provedor, e nunca são armazenadas em cache em texto puro.

Camada 4: O Firewall de LLM

Cada prompt passa por um firewall LLM antes de chegar a qualquer provedor.

Um LLM ajustado para segurança (configurável via FIREWALL_MODEL, padrão Llama Guard 4 no Together) classifica cada prompt como safe ou unsafe contra categorias incluindo injeção de prompt, jailbreak, instruções de atividades ilegais e discurso de ódio. Distribuições como [bedrock](anthropic.claude-3-haiku-20240307-v1:0):0.5,[together](meta-llama/Llama-Guard-4-12B):0.5 roteiam entre provedores — cada chamada registra backend + model_ref na linha do request, então você vê exatamente qual modelo produziu cada veredito.

Um cache de vereditos no Qdrant fica na frente da chamada ao LLM. Quando o embedding de um prompt é similar o suficiente (limite configurável, padrão 0.95) a um veredito unsafe recente, o veredito em cache evita a chamada ao LLM. Apenas vereditos unsafe são cacheados — safe sempre é recalculado para que uma troca de modelo possa inverter o resultado sem etapa manual. O mesmo embedding calculado pela cache semântica de respostas é reutilizado, então prompts repetidos não pagam embed extra.

Ative por requisição via header floopy-llm-security-enabled: true. A flag de plano has_advanced_firewall controla a feature toda.

Requisições bloqueadas retornam 400 PROMPT_THREAT_DETECTED com erro claro — sem falhas silenciosas. Qualquer falha do LLM (rede, parse) é fail-open: a requisição passa com log loud para que o drift seja visível nas métricas.

Camada 5: Segurança contra SSRF e de headers

O gateway valida cada requisição de saída contra uma lista de permissão estrita de provedores: api.openai.com, api.anthropic.com, generativelanguage.googleapis.com e outros quatro. URLs fornecidas pelo cliente nunca influenciam o destino.

IPs resolvidos são verificados contra faixas privadas (RFC 1918, loopback, link-local, CGNAT). Um atacante não consegue enganar o gateway para fazer requisições à rede interna.

Headers do cliente são sanitizados antes do encaminhamento:

• Removidos: authorization, cookie, proxy-authorization, x-forwarded-for, host
• Encaminhados: Todo o resto, incluindo headers específicos do provedor
• A autenticação do provedor é injetada após a remoção — suas chaves nunca se misturam com headers do cliente

Camada 6: Limpeza de PII

Antes dos logs serem escritos no ClickHouse, os corpos de requisição e resposta são escaneados em busca de PII:

Isso roda no caminho de logging assíncrono — um pipeline separado da requisição. Nunca bloqueia nem atrasa sua chamada de API.

Camada 7: Rate limiting e proteção contra negação de carteira

Três níveis de rate limiting previnem abuso:

• Anônimo: 20 rpm por IP — bloqueia probing não autenticado
• Autenticado: Limites por organização (não por IP) — seguro atrás de NATs corporativos
• Por chave: RPM configurável por API key — controle granular por aplicação

Os rate limits usam sliding windows atômicas no Redis. Requisições autenticadas são indexadas pelo ID da organização, não pelo endereço IP. Isso previne limitação incorreta para clientes enterprise atrás de IPs de saída compartilhados — um problema que afeta a maioria dos gateways.

Cotas mensais de requisições atuam como um limite rígido. Se uma chave vazada ou um loop descontrolado começar a queimar tokens, o gateway retorna 429 MONTHLY_LIMIT_EXCEEDED antes que possa drenar seu orçamento.

Camada 8: Separação de arquitetura

O gateway (Olympus, Rust) e o dashboard (Zeus, Next.js) são sistemas completamente separados. O Zeus se conecta diretamente ao Supabase e ao ClickHouse — ele nunca faz proxy pelo Olympus.

Isso significa:

• Um gateway comprometido não consegue acessar dados do dashboard (contas de usuários, cobrança, configurações da organização)
• Um dashboard comprometido não consegue interceptar ou modificar tráfego do gateway
• Cada sistema pode ser corrigido, implantado e escalado independentemente

O fluxo completo da requisição

Cada requisição passa por 13 checkpoints de segurança, em ordem:

1. Verificação de tamanho do body (limite de 10MB)
2. Rate limiting por IP
3. Extração e validação SHA-256 da API key
4. Rate limiting por organização
5. Verificação do status da assinatura
6. Verificação da cota mensal de uso
7. Resolução de template de prompt
8. Consulta ao cache
9. Escaneamento do LLM firewall (cache de vereditos + LLM ajustado para segurança)
10. Validação contra SSRF
11. Sanitização de headers
12. Despacho ao provedor com descriptografia da chave criptografada
13. Logging assíncrono com limpeza de PII

Cada camada pode rejeitar a requisição independentemente. Uma falha em uma camada não contorna as demais.

O que vem a seguir

Segurança nunca está concluída. Estamos trabalhando ativamente em:

• Programa de conformidade SOC 2 Type II
• Chaves de criptografia gerenciadas pelo cliente para logs do ClickHouse
• 2FA baseado em TOTP para acesso ao dashboard
• Logging de auditoria para todos os eventos de segurança
• Implantação de WAF na borda

Para os detalhes técnicos completos, veja nossa documentação de Segurança.

Passe seu tráfego de IA pela plataforma de otimização de agentes mais segura do mercado. Cadastre-se gratuitamente — 5.000 requisições/mês incluídas, sem cartão de crédito.