Saltar al contenido principal
El día que pones un agente frente a usuarios es el peor día para descubrir que un jailbreak atraviesa directamente tu política de contenido, o que una herramienta que olvidaste gobernar se dispara en la primera ejecución. Un red team de pre-lanzamiento convierte esas sorpresas en un número que puedes leer antes de lanzar — y OrcaRouter te da tres formas de producirlo, todas sin tocar el código de tu agente ni enviar una sola solicitud en vivo que no quisieras. Esta receta es la pasada de ensayo en seco: mide una política contra ataques conocidos, hazle shadow contra tu propio tráfico, y simula una postura más estricta antes de comprometerte con ella.
Todo aquí es de solo lectura o sandbox — sin bloqueo de cara al usuario, sin tráfico de producción afectado. (Las reglas de palabra clave, regex y PII se ejecutan enteramente en local; una regla llm_judge aún llama a su modelo configurado, así que una eval sobre una política de juez sí hace esa llamada.) El punto es romper cosas antes del lanzamiento, en tus términos.

​
1. Cómo hacer red team a un agente de IA antes del lanzamiento

Un red team de pre-lanzamiento responde tres preguntas, y OrcaRouter tiene una herramienta para cada una:

¿Mi guardrail captura ataques?

Ejecuta el arnés Eval del guardrail contra corpora adversariales incluidos y lee de vuelta precisión / recall / F1.

¿Qué rompería mi firewall?

Activa el modo shadow y observa qué llamadas a herramienta reales se denegarían — sin denegar ninguna aún.

¿Es segura una postura más estricta?

Simula un nivel de autonomía para previsualizar exactamente qué cambiaría contra tu tráfico antes de aplicarlo.
La primera prueba tus Guardrails (el plano de texto); la segunda y la tercera prueban tu Firewall (el plano de acción). Una lista de verificación de lanzamiento real ejecuta las tres.

​
2. Puntúa tu guardrail contra corpora adversariales

La forma más rápida de saber si una política de contenido sobrevive al contacto con un atacante es lanzarle un corpus de ataques conocidos y leer la puntuación. La pestaña Eval del editor de guardrail hace exactamente eso: repite cada muestra de un corpus a través de tu política actual y compara el veredicto contra el resultado esperado de cada muestra — repitiendo el corpus en local contra tus reglas, nunca contra tráfico en vivo. OrcaRouter incluye corpora de red-team para que no tengas que conseguir los tuyos. Entre ellos:
CorpusQué es
advbench_harmful_behaviorsEl conjunto objetivo canónico de sufijo adversarial — cada fila es una solicitud insegura que un guardrail debería bloquear.
anthropic_hh_redteamTranscripciones reales de red-team humano multi-turno contra un asistente.
deepset_prompt_injectionsSolicitudes de inyección de prompts vs benignas etiquetadas — una línea base de precisión/recall para un bloqueo en la etapa de entrada.
databricks_dolly_benignUna línea base puramente benigna: una política demasiado estricta no debería bloquear ninguna de estas.
Empareja siempre un corpus de ataque con uno benigno. Una política que bloquea el 100% de los ataques pero también bloquea databricks_dolly_benign no es segura — es inutilizable. La ejecución benigna es tu presupuesto de falsos positivos.
Ejecuta una eval contra el corpus incluido 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" }'
Las rutas /api/guardrail/* usan tu sesión de consola / token de acceso, no una clave de relay sk-orca-... — y tienen alcance de espacio de trabajo vía X-Workspace-Id. En la práctica ejecutarás esto desde la pestaña Eval en la consola; el curl está aquí para mostrar la forma. Ejecutar una eval está abierto a cualquier Member.
La ejecución reporta las métricas de detección calculadas contra las acciones esperadas:
  • TP / FP / FN / TN — verdaderos/falsos positivos y negativos, donde un “falso positivo” incluye capturar un ataque con la clase de acción equivocada (p. ej. enmascarar cuando esperabas un bloqueo).
  • Precisión / Recall / F1 — los números principales. Recall bajo significa que los ataques se cuelan; precisión baja significa que estás bloqueando tráfico benigno.
Abre la ejecución para inspeccionar los fallos muestra por muestra, afina la regla o la rúbrica del juez, y re-ejecuta hasta que la puntuación se mantenga. Los corpora personalizados funcionan igual — sube tu propio JSONL (Developer+) para probar contra las formas de ataque exactas que tu producto enfrenta.
Dónde vive la defensa de inyección de prompts. El preset incluido Prompt-Injection Basics es una regla de palabra clave en la acción flag — expone frases de jailbreak comunes para revisión sin bloquear al usuario. Para intención semántica de inyección que ninguna lista de palabras clave captura, añade una regla llm_judge y hazle red-team de la misma forma: evalúala contra deepset_prompt_injections y anthropic_hh_redteam y lee el F1. Ver la referencia de guardrail.

​
3. Shadow del firewall contra tráfico real

Una eval de guardrail prueba texto contra un corpus fijo. Tu firewall, en cambio, necesita probarse contra la realidad desordenada de lo que tu agente realmente hace — y la forma más segura de hacer eso antes del lanzamiento es el modo shadow. El modo shadow es un flag por política que hace que el firewall evalúe y registre cada llamada a herramienta exactamente como lo haría en producción, pero degrade cada veredicto de aplicación a audit. Un deny se convierte en una fila de audit cuya razón se prefija [shadow] would …. Nada se bloquea. Nada se rompe. Pero el feed de Events ahora te muestra la lista precisa de llamadas que tu política habría rechazado. Este es el red team del firewall: autora tu política más estricta pretendida, activa el modo shadow, ejecuta tu agente a través de un ensayo de lanzamiento realista, luego lee los eventos [shadow] would ….
Construye tu política de aplicación en la consola (Developer+) — para un ensayo en seco de lanzamiento, establece default_verdict a audit y añade las reglas de deny que pretendes lanzar. Activa el modo shadow. Toda la política ahora registra sin aplicar.
Ejecuta tus flujos de agente reales contra el gateway con una clave adjunta a la política en shadow. Cada llamada a herramienta — inbound, response, despacho MCP, egress — se evalúa y registra.
Abre Firewall → Events (Developer+) y filtra por las razones [shadow] would …. Cada una es una llamada que tu política habría denegado en producción. Confirma que cada entrada es una llamada que quieres denegada — y que nada legítimo está en la lista.
Una vez que la lista de se-bloquearía esté limpia, apaga el modo shadow. La siguiente llamada coincidente se aplica de verdad — sin otro cambio.
Empareja el modo shadow con el modo observe (un ajuste de espacio de trabajo) para cobertura, no solo corrección. El modo observe registra cada llamada a herramienta que resuelve a ninguna política como un hueco, poblando la vista de Discovered tools — así capturas la herramienta para la que olvidaste escribir una regla, no solo las reglas que hiciste mal. Ver modos de aplicación.

​
4. Simula una postura más estricta antes de comprometerte

El tercer movimiento de red team es el más barato: antes de aplicar un nivel de autonomía más estricto, simúlalo. El simulador previsualiza qué cambiaría aplicar tight (o cualquier nivel) contra el tráfico reciente de tu espacio de trabajo — cuántas llamadas pasarían a deny — sin escribir una sola fila 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>"
Leer el simulador está abierto a cualquier Member. Úsalo para responder “¿mi agente está listo para tight?” antes del lanzamiento: si la previsualización muestra un muro de denegaciones potenciales en llamadas de las que tu agente depende, tienes reglas que suavizar antes del go-live, no un incidente después.
Simulate es solo previsualización — nunca muta tus políticas. Aplicar un nivel de autonomía es una acción separada de Developer+, y es una transacción con deshacer de un clic si el resultado en vivo aún te sorprende.

​
5. La lista de verificación de red-team de pre-lanzamiento

Junta las tres pasadas y tienes una puerta de lanzamiento:
PasadaHerramientaVerde cuando
Política de contenidoGuardrail Eval vs corpora de ataque + benignoRecall alto en ataques, sin bloqueos en benigno
Política de acciónFirewall modo shadow vs tráfico de ensayoCada [shadow] would … es intencionado
CoberturaModo observe + Discovered toolsNinguna herramienta sorprendente está en un hueco de cobertura
PosturaSimulate del nivel de autonomía objetivoLa previsualización coincide con lo que esperas
Ejecuta las cuatro en verde, luego aplica: apaga el modo shadow y aplica tu nivel de autonomía. Como cada vinculación vive en la clave en el gateway, el movimiento de ensayo en seco a en vivo es un cambio de configuración, no un despliegue — tu agente sigue llamando a https://api.orcarouter.ai/v1/... exactamente como antes.
El enmascarado en la etapa de salida y el escaneo de respuesta en vivo aún están madurando — una ejecución de eval demuestra la lógica de una regla en el sandbox, pero confirma tu combinación específica de etapa y streaming contra las notas de guardrail antes de depender de ella en producción.

​
6. Próximos pasos

Modos de aplicación

Observe → shadow → enforce, el lanzamiento seguro que esta receta ensaya.

La línea base de Agentes Seguros

Qué establece cada nivel de autonomía — y cómo simulate lo previsualiza.

Inyección de prompts

La amenaza contra la que tu eval de guardrail está puntuando.

Ir en vivo

El cambio a producción tras pasar el red team.
Para los motores completos detrás de cada pasada, ver las referencias de Guardrails y Firewall, y las amenazas relacionadas: jailbreaks y dangerous-tool-calls.