Fase 8 · Bloco D — injection-guard em todas as rotas LLM + red-team

[diegosouzapw]

Fase 8 · Bloco D — Segurança-LLM (cobertura do injection-guard + red-team)

Último bloco da Fase 8. Fecha um gap real de segurança: o injection-guard estava em só 3 de ~14 rotas que aceitam prompt. Estende a cobertura a todas + red-team nightly.

D1 — Cobertura do guard (PRODUÇÃO)

• Extração (extractMessageContents): agora cobre prompt (str/array), input-string (corrige char-split de embeddings), query+documents (rerank), instructions (Responses) — além de messages/input[]/system.
• Wrapper (withInjectionGuard): passa a emitir o bloco canônico { code: "SECURITY_001" } + CORS.
• 11 rotas wrapped (export const POST = withInjectionGuard(handler)):
  • Generativas: messages, responses, images/generations, images/edits, videos/generations, music/generations, audio/speech
  • Dados: embeddings, rerank, search, moderations
• ⭐ Seguro por default: o guard respeita INJECTION_GUARD_MODE (default warn = só loga, não bloqueia). Cobrir todas as rotas não introduz false-block (inclusive embeddings/moderations); o operador habilita block globalmente quando quiser. moderations incluída por consistência (isentável via resolveDisabledGuardrails).

D2 — Red-team (nightly)

• promptfoo (promptfooconfig.yaml + corpus OWASP-LLM): valida que as rotas bloqueiam injeção em INJECTION_GUARD_MODE=block (assert error.code === "SECURITY_001", sem custo — bloqueio antes do upstream). Quality-rubric + garak (probes promptinject/dan/leakreplay) gated if: secrets.PROMPTFOO_PROVIDER_KEY != '' (skip-if-no-secret).
• nightly-llm-security.yml (cron + dispatch).

Validação local (TDD)

• Extração 7/7 · cobertura-por-shape 2/2 (block-mode bloqueia todos os shapes via patterns HIGH system_override+system_prompt_leak; warn não bloqueia) · 73/73 testes de guardrails existentes (zero regressão) · typecheck:core 0 · configs parse · check:test-discovery 0 órfãos · check:doc-links PASS · promptfoo/garak provados no 1º nightly (Hard Rule fix(ci): add environment for npm token access #18 op2).

Limitação conhecida (follow-up)

O wrapper guarda bodies JSON; rotas que aceitam multipart/form-data (ex.: images/edits com upload) têm cobertura parcial — o wrapper no-opa com segurança em body não-JSON (sem false-block, mas sem extração do prompt nesses casos). Migrar as 3 rotas inline para o wrapper + cobrir form-data ficam no backlog.

Doc: docs/security/GUARDRAILS.md § "Injection-guard route coverage & red-team".

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request expands prompt injection guard coverage across multiple API routes by wrapping POST handlers with withInjectionGuard, updating the input sanitizer to extract more fields, and adding red-team configurations and unit tests. The reviewer feedback highlights a critical bug in extractMessageContents where string inputs still trigger a memory-intensive character-by-character iteration (char-split). Additionally, the reviewer raises valid architectural concerns regarding the application of the injection guard to non-generative endpoints (such as moderations, embeddings, rerank, and search) where there is no execution risk and guarding may block legitimate use cases or degrade performance.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Correção Incompleta do Bug de Char-Split em Embeddings

Embora esta linha adicione a string completa de body.input ao array contents, ela não impede o comportamento de char-split que ocorre no loop anterior (linhas 120-135).

Como const messages = body.messages || body.input || []; faz o fallback para body.input quando body.messages é indefinido, se body.input for uma string, o loop for (const msg of messages) ainda irá iterar sobre cada caractere individual da string e adicioná-lo ao contents (já que typeof msg === "string" é verdadeiro para cada caractere).

Para inputs grandes de embeddings (com milhares de caracteres), isso causa um overhead de memória massivo e executa as regexes de injeção/PII milhares de vezes desnecessariamente.

Correção Recomendada

Modifique a linha 120 (fora deste diff) para garantir que messages seja atribuído apenas se for realmente um array:

const messages = Array.isArray(body.messages) ? body.messages : (Array.isArray(body.input) ? body.input : []);

[gemini-code-assist]

Problema Arquitetural: Guarding em Endpoint de Moderação

Aplicar o withInjectionGuard ao endpoint /v1/moderations é contraproducente e introduz um problema crítico de usabilidade:

1. Sem Risco de Execução: Endpoints de moderação não executam instruções nem geram respostas de LLM; eles apenas classificam o texto. Portanto, não são vulneráveis a ataques de prompt injection.
2. Bloqueia Casos de Uso Legítimos: O propósito principal de um endpoint de moderação é verificar se um input (que pode conter textos adversariais ou prompt injections) é seguro. Se o INJECTION_GUARD_MODE estiver definido como block, qualquer cliente tentando moderar um prompt injection será bloqueado com um erro SECURITY_001, quebrando completamente o fluxo de moderação.

Recomendamos excluir /v1/moderations do wrapper de proteção contra injeção.

[gemini-code-assist]

Problema Arquitetural: Guarding em Endpoint de Embeddings

Aplicar o withInjectionGuard ao endpoint /v1/embeddings é desnecessário e introduz problemas de performance e funcionais:

1. Sem Risco de Execução: Modelos de embedding não executam instruções; eles apenas geram representações vetoriais do texto de entrada. Não são vulneráveis a prompt injection.
2. Overhead de Performance: Inputs de embeddings podem ser extremamente grandes (documentos inteiros). Executar verificações de injeção baseadas em regex em textos grandes adiciona latência e uso de CPU significativos a uma rota de dados de alta vazão.
3. Bloqueia Casos de Uso Legítimos: Se um cliente estiver gerando embeddings para um dataset que contém exemplos de prompts ou textos adversariais, essas requisições serão bloqueadas no modo block.

Recomendamos excluir /v1/embeddings do wrapper de proteção contra injeção.

[gemini-code-assist]

Problema Arquitetural: Guarding em Endpoint de Rerank

Aplicar o withInjectionGuard ao endpoint /v1/rerank é desnecessário e introduz problemas funcionais:

1. Sem Risco de Execução: Modelos de rerank apenas computam scores de relevância entre queries e documentos; eles não executam instruções.
2. Bloqueia Casos de Uso Legítimos: Se um usuário buscar ou reordenar documentos que contenham exemplos de prompt injection ou documentação de segurança, a requisição será bloqueada no modo block.

Recomendamos excluir /v1/rerank do wrapper de proteção contra injeção.

[gemini-code-assist]

Problema Arquitetural: Guarding em Endpoint de Busca

Aplicar o withInjectionGuard ao endpoint /v1/search é desnecessário e introduz problemas funcionais:

1. Sem Risco de Execução: Endpoints de busca executam pesquisas na web; eles não executam instruções.
2. Bloqueia Casos de Uso Legítimos: Se um usuário pesquisar por termos que contenham padrões de prompt injection ou tópicos de segurança, a requisição será bloqueada no modo block.

Recomendamos excluir /v1/search do wrapper de proteção contra injeção.