Saltar al contenido principal
La respuesta corta: Los guardrails gobiernan texto; el Firewall gobierna acciones. Son complementarios — una sola solicitud fluye a través de ambos — y la forma más rápida de configurarlos juntos es un nivel de autonomía. El resto de esta página es para los casos donde necesitas saber qué capa posee una amenaza específica.
Rol requerido. Cualquier miembro del espacio de trabajo puede leer políticas y el feed de Matches del guardrail; el feed de Events del firewall requiere el rol Developer. Crear o editar guardrails o políticas de firewall también requiere Developer o superior.

​
1. La distinción en una línea

CapaGobiernaVe
GuardrailsTexto — lo que el modelo lee y escribeContenido del prompt, contenido de la respuesta
Agent FirewallAcciones — lo que hace el agenteLlamadas a herramienta, despachos MCP, destinos de red salientes
Los guardrails se disparan antes de la llamada upstream (en el prompt) y después de ella (en la respuesta). El Firewall se dispara en cada llamada a herramienta que el modelo emite o que el agente emite — independientemente del modelo o proveedor que atendió el turno.

​
2. Comparación lado a lado

DimensiónGuardrailsAgent Firewall
GobiernaTexto del prompt y texto de respuesta del modeloLlamadas a herramienta, despachos MCP, destinos de egress, coste del agente
VeEl mensaje del usuario, el prompt de sistema y la respuesta del modeloNombre de herramienta, argumentos de llamada, los tool_calls que emite el modelo, host/IP saliente
Se adjunta víaguardrail_id en la clave APIfirewall_policy_id en la clave API
Tipos de reglakeyword, regex, pii, max_chars, external, llm_judge, groundingGlob de nombre de herramienta + cláusulas de argumentos + alcance de egress + propiedad de skill
Amenazas de ejemploPII en prompts, secretos de API en respuestas, jailbreaks, salida fuera de tema, contexto sobredimensionadoLlamada a herramienta peligrosa, SSRF, exfiltración de datos, bucle de coste de agente descontrolado, servidor MCP no aprobado
Veredictos / accionesblock (HTTP 400 guardrail_blocked), mask, flagallow, audit, deny (HTTP 400 firewall_blocked), sanitize, pending_approval, cap_cost
Cuándo se disparaEtapa de entrada: antes de la llamada al modelo; etapa de salida: después de que el modelo respondeEn cada llamada a herramienta que el modelo emite o que el agente emite
Modo shadow / observeNo — los guardrails se disparan o no se disparanSí — el modo shadow degrada los veredictos aplicantes a audit para un despliegue seguro

​
3. Amenaza → qué capa

Usa esta tabla para enrutar un nuevo requisito de seguridad al control correcto:
AmenazaAcude a
PII en un mensaje del usuarioGuardrails — regla pii de entrada (mask / block)
Secreto en la respuesta del modeloGuardrails — regla de secretos de salida
Llamada a herramienta peligrosa (shell.exec rm -rf /)Firewall — deny en glob de herramienta + cláusula de argumentos
SSRF / exfiltración de datos vía URL salienteFirewall — lista de permitidos/denegados de egress
Inyección de prompts de contenido no confiableAmbos — guardrail de entrada + lista de permitidos del firewall
Secreto en un argumento de herramientaFirewall sanitize + regla de secretos de Guardrails
Jailbreak / evasión de políticaGuardrails — llm_judge / keyword / regex
Prompt sobredimensionado o coste de tokensGuardrails — regla max_chars
Gasto de agente descontrolado (bucle de costes)Firewall — veredicto cap_cost
Servidor MCP no aprobadoFirewall — deny de superficie MCP / pending_approval
Datos sensibles de un resultado de herramientaGuardrails — regla de salida en la respuesta
El “por qué” profundo de cada emparejamiento vive en las páginas de profundización de Amenazas.

​
4. Usa ambos — los niveles de autonomía los configuran juntos

Los guardrails y el Firewall están diseñados para componerse, no para competir. Una sola solicitud pasa por ambos planos:
  1. El guardrail de entrada se ejecuta — el texto del prompt se examina y opcionalmente se enmascara.
  2. Llamada al modelo — el prompt (posiblemente saneado) llega al modelo upstream.
  3. El Firewall — cada llamada a herramienta que emite el modelo se evalúa.
  4. El guardrail de salida se ejecuta — el texto de respuesta del modelo se examina.
La forma más rápida de configurar ambos a la vez es un nivel de autonomía — una única configuración que atómicamente escribe una política de Firewall y una de Guardrails para todo el espacio de trabajo, con deshacer de un clic:
Nivel de autonomíaPostura del FirewallPostura de Guardrails
tightDefecto-deny; bloquear shell destructivo + egress SSRFPII Shield + Secrets Blocker activados
balancedAuditoría por defecto; denegar shell destructivoPII Shield solo-auditoría (marca PII)
permissiveSin reglas de aplicación; observe mode activadoSin aplicación
Aplica un nivel de autonomía desde la consola del Firewall (POST /api/workspace/firewall/autonomy, Developer+), luego ajusta cada plano independientemente desde ahí.

​
5. Resumen

Los guardrails poseen el texto; el Firewall posee las acciones — ejecuta ambos, deja que el nivel de autonomía los conecte y endurece cada plano independientemente una vez que puedes ver el tráfico real de tus agentes.

Guardrails

Tipos de regla, detección de PII, LLM judge, arnés de eval y referencia de la API.

Agent Firewall

Veredictos, superficies, niveles de autonomía, aprobación HITL y referencia de la API.