Saltar al contenido principal
La forma más rápida de impedir que un agente haga algo peligroso es nombrar la herramienta y denegarla. Un veredicto deny sobre un glob de nombre de herramienta es la primitiva de lista de bloqueados del agent firewall: una regla, un glob, veredicto deny, adjuntada a una clave — y a partir de entonces el gateway rechaza esa herramienta en cada llamada, sin cambio al código de tu agente. Esta página cubre el caso de uso de lista de bloqueados y la única decisión que fuerza: en qué superficie bloqueas — las herramientas que anuncias (inbound) o las llamadas a herramienta que el modelo emite (response). Para el vocabulario de coincidencia completo y la semántica de veredictos, ver Esquema de regla y Veredictos.

​
1. Bloquear una llamada a herramienta que hace un agente de IA

Una regla de lista de bloqueados es lo más simple que una política de firewall puede expresar: coincide una herramienta por nombre, devuelve deny. Úsala cuando una herramienta nunca deba dispararse para una clave dada — shell.exec, *.delete, un plugin de la comunidad en el que no confías — sin importar los argumentos. En la consola de tu espacio de trabajo, abre una política (o crea una) y añade una regla: 
{
  "label": "block destructive shell",
  "tool_name_glob": "*.exec",
  "verdict": "deny"
}
El tool_name_glob es un glob pequeño y sensible a mayúsculas — shell.* captura toda una familia, *.delete captura un verbo a través de servidores, * captura todo. No se necesita cláusula de argumentos: un glob pelado + deny bloquea la herramienta incondicionalmente. Añade una cláusula de argumentos solo cuando quieras permitir la herramienta en general pero denegar una forma de llamada.
El motor recorre las reglas de una política en orden de prioridad y gana la primera coincidencia. Pon las excepciones allow estrechas en un número de priority más bajo (se ejecutan primero) y tu deny amplio debajo de ellas — p. ej. permitir shell.exec desde una skill builtin.* confiable, denegarlo en todas partes. Ver Prioridad de reglas.

​
2. Inbound vs response: elige la superficie

Un deny puede aterrizar en dos puntos diferentes del ciclo de vida de la solicitud, y la diferencia importa. Fija la regla con el campo stage, o déjalo vacío para cubrir ambos.

inbound

Las herramientas que tu agente anuncia al modelo en la solicitud (las definiciones de herramienta). Un deny aquí quita la herramienta antes de que el modelo pueda siquiera elegirla — el modelo nunca la ve como una opción.

response

Los tool_calls que el modelo emite en su respuesta. Un deny aquí captura la llamada que el modelo ya decidió hacer, antes de que llegue a la herramienta.
Prefiere inbound cuando quieras que una herramienta sea invisible — el modelo no puede llamar a lo que nunca se le ofreció, así que evitas turnos desperdiciados donde elige una herramienta solo para ser rechazado. Usa response (o deja stage vacío) cuando la herramienta aparece legítimamente en algunas solicitudes y quieres capturar la llamada emitida real, o cuando solo controlas el bucle del agente y no el conjunto de herramientas anunciado.
Una regla sin stage aplica a todas las superficies — el mismo deny cubre una herramienta ya sea anunciada, emitida o despachada a través de MCP. Ese es el valor por defecto de cinturón-y-tirantes; fija una superficie solo cuando un deny deba acotarse a una. Ver Etapas.

​
3. Adjunta la política y obsérvala dispararse

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 es: la política adjunta de la clave (cuando existe y está habilitada), si no el valor por defecto del espacio de trabajo. (Una política adjunta deshabilitada hace fallback al valor por defecto — ver Gestionar políticas.) Una vez adjunta, una llamada denegada en la superficie inbound devuelve HTTP 400 con el código de error firewall_blocked y una razón que nombra la herramienta — p. ej. tool "shell.exec" blocked by firewall. El error se marca como skip-retry (reejecutar la llamada idéntica simplemente volvería a bloquear) y no cuesta tokens de modelo, ya que un bloqueo inbound se dispara antes de la llamada upstream. Un deny despachado a través del gateway MCP se manifiesta como un error de herramienta en su lugar, así que el modelo ve el rechazo y puede reaccionar.
Un deny en la superficie inbound quita la herramienta de lo que se le ofrece al modelo. Si tu framework de agente requiere que una herramienta que anunció sea invocable, bloquearla inbound puede confundir el bucle — en ese caso bloquea en response en su lugar, para que la herramienta siga anunciada pero la llamada real sea rechazada. Prueba la diferencia antes de lanzar (ver §5).

​
4. Deny es uno de varios veredictos

Deny es la herramienta más contundente de la lista de bloqueados. Cuando un bloqueo duro es demasiado, el mismo glob puede llevar un veredicto más suave:
VeredictoCuándo recurrir a él en vez de deny
auditQuieres ver la herramienta dispararse pero aún no bloquearla.
sanitizeLa herramienta está bien pero sus argumentos pueden llevar secretos/PII — redacta args, nunca resultados de herramienta.
pending_approvalUn humano debería aprobar cada llamada fuera de banda.
cap_costPermite hasta que el gasto de una ejecución de agente cruza un tope en centavos.
Todos estos están documentados en Veredictos. Una lista de bloqueados es solo el subconjunto donde el veredicto es deny. Para una postura de lista de permitidos (denegar todo, permitir un conjunto nombrado) cambia el default_verdict de la política a deny y añade reglas allow estrechas — ver Lista de permitidos de herramientas.

​
5. Lánzalo de forma segura

La pestaña Test de la consola ejecuta en seco 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 coincide con la herramienta que querías (y solo esa herramienta) antes de adjuntar una clave. Ver Probar reglas.
Activa el modo shadow en la política y cada veredicto de aplicación — incluido tu deny — se degrada a audit, razón prefijada con [shadow] would …. Mides exactamente qué bloquearía el deny contra tráfico real, luego apagas shadow para aplicar.
¿No estás seguro del nombre exacto de la herramienta a poner en glob? La vista Discovered Tools lista cada herramienta que el espacio de trabajo ha visto, marcada covered o gap. Autora tu deny directamente desde los nombres que realmente aparecieron. Ver Analítica.
Cada evaluación escribe un evento del firewall con el veredicto, la superficie, la herramienta y la regla coincidente. Después de aplicar, filtra el registro de eventos por veredicto deny para ver la regla dispararse en las llamadas que esperabas.

​
6. Quién puede hacer qué

Toda la configuración de lista de bloqueados se ejecuta en la consola bajo tu sesión (/api/workspace/firewall/*):
AcciónRol
Leer políticas, presets, herramientas descubiertas, SimulateMember
Ejecutar en seco una política (Test)Developer+
Crear / editar / eliminar reglas y políticasDeveloper+
Leer el registro de eventos y agregados de ejecucionesDeveloper+
Autorar o cambiar una regla deny es una escritura Developer+, y también lo es la ejecución en seco Test de la consola. Leer una política y la vista Simulate (“qué pasaría si”) de solo lectura están abiertas a cada miembro.

​
Relacionado

Sintaxis glob

Exactamente cómo coinciden shell.*, *.exec y *.shell.*.

Lista de permitidos de herramientas

La postura inversa: defecto-deny, permitir un conjunto nombrado.

Validar argumentos

Denegar solo una forma de llamada, no toda la herramienta.

Llamadas a herramienta peligrosas

La amenaza que aborda una lista de bloqueados.

Veredictos

Qué hacen deny y sus hermanos más suaves en el cable.

Referencia del Firewall

La referencia completa de reglas + coincidencia.