Saltar al contenido principal
Cuando un modelo responde, no solo devuelve texto — emite tool_calls: invocaciones concretas con argumentos reales elegidos por el modelo. La superficie response del agent firewall inspecciona exactamente esos, en el momento en que dejan el modelo y antes de que lleguen a tu bucle de agente. Es la superficie donde filtras lo que el modelo realmente decidió hacer, con los argumentos que realmente eligió. Esta página cubre el caso de uso para filtrar en la superficie response — cuándo recurrir a ella en vez de inbound, el único giro de veredicto que añade, y cómo se comporta en un stream. Para el vocabulario de reglas completo y la semántica de veredictos, ver Esquema de regla y Veredictos.

​
1. Filtra las llamadas de respuesta de herramienta del LLM, con argumentos en alcance

La etapa inbound ve las herramientas que anuncias — solo nombres, aún sin argumentos en tiempo de llamada. La etapa response ve los tool_calls que el modelo emite, que llevan los argumentos que el modelo eligió. Esa es toda la razón para filtrar aquí: es la única superficie que ve la llamada real + argumentos para una herramienta ejecutada por el cliente (no-MCP), así que las cláusulas de argumentos, las secuencias y las reglas de estado de ejecución aterrizan todas en response. La distinción en una línea:
EtapaVeÚsala para
inboundDefiniciones de herramienta anunciadasHacer una herramienta invisible al modelo
responsetool_calls emitidos + argumentosFiltrar la llamada que el modelo realmente hizo
Así que inbound responde qué herramientas existen; response responde qué hizo el modelo con una. Recurre a response (o deja stage vacío para cubrir ambas) cuando una herramienta aparece legítimamente en algunas solicitudes pero una llamada particular de ella es peligrosa — o cuando solo controlas el bucle del agente, no el conjunto de herramientas anunciado.
Una regla sin stage se ejecuta en cada superficie, incluida response. Fija a response solo cuando una regla deba solo inspeccionar llamadas emitidas — por ejemplo una cláusula de argumentos que de todos modos no tiene nada que coincidir en la superficie inbound. Ver Etapas.

​
2. Un ejemplo concreto

Permite shell.exec en general, pero quítalo de la respuesta del modelo en el momento en que su argumento command se ve destructivo. En la consola de tu espacio de trabajo, abre una política (o crea una) y añade una regla fijada a la superficie response: 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
El coincidente de argumentos vive en args_match_json — un string JSON que contiene {"clauses":[…]}, cada cláusula un triple path / op / value (op es uno de eq, contains, regex, gt, lt). El formulario de la consola lo construye por ti; la forma en bruto se muestra aquí para que el nombre del campo sea inequívoco. La herramienta sigue anunciada — el modelo aún puede proponer shell.exec — pero cuando la llamada emitida lleva un command destructivo, el firewall quita ese tool_call de la respuesta antes de que tu agente lo vea siquiera. Un shell.exec benigno (digamos, ls -la) navega intacto. Este es el patrón “permitir la herramienta, gobernar la llamada” para el que existe la superficie response; la cláusula de argumentos es lo que lo hace posible.
Las reglas evalúan en orden de prioridad, gana la primera coincidencia. Pon una excepción allow estrecha en un número de priority más bajo que un deny amplio para que la excepción se ejecute primero. Ver Prioridad de reglas.

​
3. Qué hace un veredicto en la superficie response

La superficie response inspecciona cada tool_call emitido y reescribe la respuesta en su lugar. Las llamadas conservadas se reenvían byte a byte; solo una llamada coincidente cambia:
El tool_call coincidente se quita de la respuesta del modelo antes de que llegue a tu agente. A diferencia de un deny en inbound — que devuelve HTTP 400 con el código firewall_blocked — un deny en la superficie response no falla la solicitud; el resto de la respuesta (otras llamadas a herramienta, cualquier texto) fluye con la llamada infractora simplemente ausente.
Las subcadenas coincidentes en los argumentos de la llamada se reemplazan con los argumentos redactados del motor y la llamada limpia se reenvía — útil cuando la herramienta está bien pero el modelo puso un secreto o valor PII en un argumento. Sanitize redacta solo los argumentos de la llamada a herramienta; nunca toca el contenido que una herramienta devuelve. Si el motor no tiene nada que sustituir, la llamada se quita (falla cerrado). Ver Sanear respuestas.
Las retenciones de humano en el ciclo se mantienen abiertas en la superficie inbound, no en response. Una regla pending_approval que primero coincide sobre una llamada emitida se quita por lo tanto (falla cerrado) — conservarla reenviaría una llamada no revisada sin decisión humana. Autora las retenciones HITL para dispararse en inbound; ver Aprobaciones.
allow y audit ambos reenvían la llamada; audit es el default_verdict habitual — registra todo, no bloquea nada, hasta que estés listo para aplicar.
cap_cost y pending_approval son conceptos de inbound en esta superficie. cap_cost es inerte en response (el modelo ya se ejecutó), y pending_approval resuelve a un quitado en vez de una retención. Pon los topes de coste y las retenciones HITL en la superficie inbound — ver Limitar coste y Aprobaciones.

​
4. Streaming: retenido, luego filtrado

En una respuesta no-stream toda la respuesta se parsea y filtra de una vez. En un stream, los tool_calls de un modelo llegan como deltas por índice a lo largo de muchos frames SSE — y una vez que un delta se reenvía, tu agente ya lo tiene y no se puede retractar. Así que el gateway retiene los frames de llamada a herramienta: nunca se reenvían a mitad de stream. Al final del stream el firewall ensambla cada llamada (nombre + argumentos completos), la evalúa, y emite solo las llamadas supervivientes.
Los frames de contenido aún se transmiten normalmente — los tokens de texto llegan a tu cliente conforme llegan. Solo los frames tool_call se retienen para evaluación, así que una llamada denegada o saneada se filtra antes de que la llamada a herramienta ensamblada se entregue. La semántica de veredicto y regla es idéntica a la superficie no-stream. Para los detalles a nivel de frame, ver Internos de streaming y Streaming del proveedor.

​
5. Lánzalo de forma segura

La pestaña Test de la consola ejecuta una política contra una llamada a herramienta de muestra y devuelve el veredicto, la regla coincidente y la razón — nada se despacha, nada se persiste. Confirma que tu glob y cláusula de argumentos coinciden con la llamada que querías antes de adjuntar una clave. Ver Probar reglas.
Activa el modo shadow y cada veredicto de aplicación — incluido un deny de superficie response — se degrada a audit, razón prefijada con [shadow] would …. Mides exactamente qué quitaría la regla contra tráfico real antes de que cambie una sola respuesta.
Cada evaluación escribe un evento del firewall con el veredicto, la superficie, la herramienta y la regla coincidente. Filtra el registro de eventos por superficie response para ver tu regla dispararse en las llamadas emitidas que esperabas. Ver Analítica.

​
6. Adjunta la política y quién puede configurarla

Una política no hace nada hasta que una clave resuelve a ella. Adjunta en la consola estableciendo firewall_policy_id en la clave, o haz la política el valor por defecto del espacio de trabajo. La resolución: la política adjunta de la clave (cuando existe y está habilitada), si no el valor por defecto del espacio de trabajo — y una política adjunta deshabilitada hace fallback al valor por defecto del espacio de trabajo. Ver Gestionar políticas. Toda la configuración se ejecuta en la consola bajo tu sesión (/api/workspace/firewall/*):
AcciónRol
Leer políticas, presets, herramientas descubiertas, SimulateMember
Ejecutar en seco (Test), leer el registro de eventos y agregados de ejecucionesDeveloper+
Crear / editar / eliminar reglas y políticasDeveloper+

​
Relacionado

Validar argumentos

Las cláusulas de argumentos que hacen preciso el filtrado de superficie response.

Sanear respuestas

Redacta secretos de los argumentos de una llamada en vez de quitarla.

Etapas del firewall

Cómo se compara response con inbound, mcp y egress.

Bloquear herramientas

La contraparte inbound: denegar una herramienta antes de que se le ofrezca al modelo.

Llamadas a herramienta peligrosas

La amenaza que aborda el filtrado de respuesta.

Referencia del Firewall

La referencia completa de reglas + coincidencia.