Saltar para o conteúdo principal
O dia em que você coloca um agente na frente dos usuários é o pior dia para descobrir que um jailbreak passa direto pela sua política de conteúdo, ou que uma ferramenta que você esqueceu de governar dispara na primeira run. Um red team pré-lançamento transforma essas surpresas em um número que você pode ler antes de lançar — e o OrcaRouter lhe dá três maneiras de produzi-lo, todas sem tocar no código do seu agente ou enviar uma única requisição ao vivo que você não pretendia. Esta receita é o passe de dry-run: meça uma política contra ataques conhecidos, faça shadow dela contra o seu próprio tráfego e simule uma postura mais apertada antes de se comprometer com ela.
Tudo aqui é somente leitura ou sandbox — nenhum block visível ao usuário, nenhum tráfego de produção afetado. (Regras de keyword, regex e PII rodam inteiramente local; uma regra llm_judge ainda chama o modelo configurado, então um eval sobre uma política de judge de fato faz essa chamada.) O ponto é quebrar coisas antes do lançamento, nos seus termos.

​
1. Como fazer red team em um agente de IA antes do lançamento

Um red team pré-lançamento responde a três perguntas, e o OrcaRouter tem uma ferramenta para cada:

Meu guardrail captura ataques?

Rode o harness de Eval do guardrail contra corpora adversariais embutidos e leia precision / recall / F1.

O que meu firewall quebraria?

Ligue o shadow mode e observe quais chamadas de ferramenta reais seriam negadas — sem negar nenhuma delas ainda.

Uma postura mais apertada é segura?

Simule um nível de autonomia para pré-visualizar exatamente o que ele mudaria contra o seu tráfego antes de aplicá-lo.
A primeira testa seus Guardrails (o plano de texto); a segunda e a terceira testam seu Firewall (o plano de ação). Um checklist de lançamento real roda os três.

​
2. Pontue seu guardrail contra corpora adversariais

A maneira mais rápida de saber se uma política de conteúdo sobrevive ao contato com um atacante é jogar um corpus de ataques conhecidos nela e ler o score. A aba Eval do editor de guardrail faz exatamente isso: ela reproduz cada amostra de um corpus através da sua política atual e compara o veredito com o resultado esperado de cada amostra — reproduzindo o corpus localmente contra as suas regras, nunca contra tráfego ao vivo. O OrcaRouter entrega corpora de red-team embutidos para que você não precise buscar os seus próprios. Entre eles:
CorpusO que é
advbench_harmful_behaviorsO conjunto-alvo canônico de adversarial-suffix — cada linha é uma requisição insegura que um guardrail deveria bloquear.
anthropic_hh_redteamTranscrições reais de red-team humano multi-turno contra um assistente.
deepset_prompt_injectionsInjeções de prompt vs requisições benignas rotuladas — uma baseline de precision/recall para um block no stage input.
databricks_dolly_benignUma baseline puramente benigna: uma política estrita demais não deveria bloquear nenhuma delas.
Sempre emparelhe um corpus de ataque com um benigno. Uma política que bloqueia 100% dos ataques mas também bloqueia databricks_dolly_benign não é segura — é inutilizável. A run benigna é o seu orçamento de falsos positivos.
Rode um eval contra o corpus embutido deepset_prompt_injections: 
curl https://api.orcarouter.ai/api/guardrail/123/eval \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{ "corpus_name": "deepset_prompt_injections" }'
As rotas /api/guardrail/* usam o seu token de sessão / acesso de console, não uma chave de relay sk-orca-... — e têm escopo de workspace via X-Workspace-Id. Na prática você rodará isto a partir da aba Eval no console; o curl está aqui para mostrar o formato. Rodar um eval está aberto a qualquer Member.
A run reporta as métricas de detecção computadas contra as ações esperadas:
  • TP / FP / FN / TN — verdadeiros/falsos positivos e negativos, onde um “falso positivo” inclui capturar um ataque com a classe de ação errada (ex.: mascarar quando você esperava um block).
  • Precision / Recall / F1 — os números de destaque. Recall baixo significa que ataques escapam; precision baixo significa que você está bloqueando tráfego benigno.
Abra a run para inspecionar as falhas amostra por amostra, ajuste a regra ou o rubric do judge e reexecute até o score se manter. Corpora customizados funcionam da mesma forma — faça upload do seu próprio JSONL (Developer+) para testar contra os formatos exatos de ataque que o seu produto enfrenta.
Onde vive a defesa contra injeção de prompt. O preset embutido Prompt-Injection Basics é uma regra de keyword na ação flag — ela exibe frases comuns de jailbreak para revisão sem bloquear o usuário. Para intenção semântica de injeção que nenhuma lista de keywords captura, adicione uma regra llm_judge e faça red-team nela da mesma forma: faça eval dela contra deepset_prompt_injections e anthropic_hh_redteam e leia o F1. Veja a referência de guardrail.

​
3. Coloque o firewall em shadow mode contra tráfego real

Um eval de guardrail testa texto contra um corpus fixo. Seu firewall, por contraste, precisa ser testado contra a realidade bagunçada do que o seu agente realmente faz — e a maneira mais segura de fazer isso antes do lançamento é o shadow mode. O shadow mode é uma flag por política que faz o firewall avaliar e registrar cada chamada de ferramenta exatamente como faria em produção, mas rebaixar todo veredito de enforcement para audit. Um deny vira uma linha de audit cujo motivo recebe o prefixo [shadow] would …. Nada é bloqueado. Nada quebra. Mas o feed de Events agora lhe mostra a lista precisa de chamadas que sua política teria rejeitado. Este é o red team de firewall: crie sua política pretendida mais rígida, ligue o shadow mode, rode seu agente por um ensaio de lançamento realista, depois leia os eventos [shadow] would ….
Construa sua política de enforcement no console (Developer+) — para um dry-run de lançamento, defina default_verdict como audit e adicione as regras de deny que você pretende lançar. Ligue o shadow mode. Toda a política agora registra sem aplicar enforcement.
Rode os fluxos reais do seu agente contra o gateway com uma chave vinculada à política em shadow. Cada chamada de ferramenta — inbound, response, dispatch de MCP, egress — é avaliada e registrada.
Abra Firewall → Events (Developer+) e filtre pelos motivos [shadow] would …. Cada um é uma chamada que sua política teria negado em produção. Confirme que cada entrada é uma chamada que você quer negada — e que nada legítimo está na lista.
Assim que a lista de would-block estiver limpa, desligue o shadow mode. A próxima chamada correspondente é aplicada de verdade — sem nenhuma outra mudança.
Emparelhe o shadow mode com o observe mode (uma configuração de workspace) para cobertura, não apenas correção. O observe mode registra cada chamada de ferramenta que resolve para nenhuma política como um gap, populando a visão de Discovered tools — então você captura a ferramenta para a qual esqueceu de escrever uma regra, não apenas as regras que você errou. Veja modos de enforcement.

​
4. Simule uma postura mais apertada antes de se comprometer

O terceiro movimento de red-team é o mais barato: antes de aplicar um nível de autonomia mais rígido, simule-o. O simulador pré-visualiza o que aplicar tight (ou qualquer nível) mudaria contra o tráfego recente do seu workspace — quantas chamadas virariam deny — sem escrever uma única linha de política. 
curl "https://api.orcarouter.ai/api/workspace/firewall/simulate?level=tight" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
Ler o simulador está aberto a qualquer Member. Use-o para responder “meu agente está pronto para tight?” antes do lançamento: se a prévia mostra uma parede de negações em chamadas das quais seu agente depende, você tem regras para suavizar antes do go-live, não um incidente depois dele.
O Simulate é somente prévia — ele nunca muta suas políticas. Aplicar um nível de autonomia é uma ação separada, Developer+, e é uma transação com desfazer em um clique se o resultado ao vivo ainda lhe surpreender.

​
5. O checklist de red-team pré-lançamento

Junte os três passes e você tem um portão de lançamento:
PasseFerramentaVerde quando
Política de conteúdoEval de guardrail vs. corpora de ataque + benignoRecall alto em ataques, nenhum block em benigno
Política de açãoShadow mode de firewall vs. tráfego de ensaioCada [shadow] would … é intencional
CoberturaObserve mode + Discovered toolsNenhuma ferramenta surpresa fica num gap de cobertura
PosturaSimule o nível de autonomia alvoA prévia corresponde ao que você espera
Rode os quatro verdes, depois aplique enforcement: desligue o shadow mode e aplique seu nível de autonomia. Como cada vínculo vive na chave dentro do gateway, o movimento de dry-run para ao vivo é uma mudança de config, não um deploy — seu agente continua chamando https://api.orcarouter.ai/v1/... exatamente como antes.
A máscara no stage output e o escaneamento de resposta ao vivo ainda estão amadurecendo — uma run de eval prova a lógica de uma regra no sandbox, mas confirme a sua combinação específica de stage e streaming contra as notas de guardrail antes de depender dela em produção.

​
6. Próximos passos

Modos de enforcement

Observe → shadow → enforce, o rollout seguro que esta receita ensaia.

A linha de base de Agentes Seguros

O que cada nível de autonomia define — e como o simulate o pré-visualiza.

Injeção de prompt

A ameaça contra a qual seu eval de guardrail está pontuando.

Vá ao ar

O cutover de produção depois que o red team passa.
Para os motores completos por trás de cada passe, veja as referências de Guardrails e Firewall, e as ameaças relacionadas: jailbreaks e chamadas de ferramenta perigosas.