Saltar al contenido principal
Un agente que ha sido inyectado de prompts, mal configurado o simplemente tiene demasiada libertad puede llamar a herramientas que nunca debería tocar — o llamar a una herramienta legítima con argumentos peligrosos: shell.exec con rm -rf /, una API de pagos con una cantidad de transferencia excesiva, una herramienta de base de datos apuntando a la réplica de producción. Este es el abuso de herramientas de agentes, y es uno de los riesgos más consecuentes en los sistemas agénticos porque las llamadas a herramienta tienen efectos secundarios en el mundo real que a menudo son irreversibles. El Agent Firewall tiene tres defensas en capas. Puedes desplegarlas independientemente o en combinación.

​
1. Lista de permitidos: deniega todo lo que no permitiste explícitamente

El control más fuerte es una lista de permitidos. En lugar de intentar enumerar cada herramienta peligrosa, enumeras las herramientas que este agente legítimamente necesita — y niegas todo lo demás. Esta es la línea base zero-trust. Una política con default_verdict: deny y reglas allow explícitas para cada herramienta aprobada logra esto. Ejemplo: un agente que solo debería leer de un CRM: 
[
  {
    "priority": 10,
    "label": "allow crm reads",
    "tool_name_glob": "crm.get*",
    "verdict": "allow"
  },
  {
    "priority": 20,
    "label": "allow crm search",
    "tool_name_glob": "crm.search",
    "verdict": "allow"
  },
  {
    "priority": 9999,
    "label": "deny everything else",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Cualquier llamada a shell.exec, db.delete, payment.transfer — ya sea emitida intencionalmente o desencadenada por una instrucción inyectada — alcanza el catch-all * y devuelve un error HTTP 400 firewall_blocked. El agente ve un error de herramienta estructurado y no puede reintentar (el bloqueo está marcado skip-retry), así que no puede hacer un bucle alrededor de la denegación.
Establece el default_verdict de tu política a deny para la aplicación completa de lista de permitidos. Con el veredicto audit por defecto, las llamadas no coincidentes están permitidas y registradas pero no bloqueadas — útil durante el despliegue pero no un control de seguridad por sí mismo.
Los patrones glob te permiten permitir familias enteras de herramientas con una regla. Los patrones comunes:
PatrónQué cubre
crm.*Todas las herramientas en el espacio de nombres crm
*.readCualquier herramienta de verbo de lectura en todos los servidores
db.queryExactamente esta herramienta
*Todo (usa esto para tu deny catch-all)
La coincidencia de herramientas es gana la primera coincidencia en orden ascendente de prioridad. Pon tus reglas allow específicas en números de prioridad bajos y el deny catch-all en uno alto.

​
2. Validación de argumentos: permite la herramienta, bloquea la invocación peligrosa

Una lista de permitidos sobre nombres de herramientas es gruesa — bloquea shell.exec por completo. A veces quieres permitir una herramienta pero restringir cómo puede llamarse. Las cláusulas de argumentos te permiten coincidir en campos específicos dentro de los argumentos de la llamada a herramienta, usando JSONPath y un conjunto de operadores. Ejemplo: permite shell.exec pero bloquea rm -rf 
{
  "priority": 10,
  "label": "block destructive rm",
  "tool_name_glob": "shell.exec",
  "args_match": {
    "clauses": [
      {
        "path": "$.command",
        "op": "regex",
        "value": "rm\\s+-[^\\s]*r[^\\s]*f|mkfs|dd\\s+if=|:\\(\\)\\{.*\\}"
      }
    ]
  },
  "verdict": "deny"
}
Esta regla se dispara solo cuando shell.exec se llama y el argumento $.command coincide con el regex de comando destructivo. Una llamada normal a shell.exec con un comando seguro cae a la siguiente regla (o el veredicto por defecto). Pon esta regla en un número de prioridad menor que cualquier regla general allow shell.exec para que se dispare primero. El conjunto completo de operadores de argumentos:
OperadorÚsalo cuando
eqCoincidencia exacta en un valor escalar (cadena o número)
containsCoincidencia de subcadena — p. ej. $.query contains DROP TABLE
regexCoincidencia de patrón RE2 — seguro en la ruta caliente, sin retroceso
inEl valor debe estar en un array dado — p. ej. permite solo entornos específicos
cidr_matchDirección IP en un bloque CIDR — útil para verificaciones de destino de egress
gt / ltComparación numérica — p. ej. $.amount gt 10000 para topes de pago
Todas las cláusulas en un bloque args_match son AND. Si un path no existe en los argumentos de la llamada, la cláusula evalúa false y la regla no se dispara — la llamada cae a la siguiente regla o al valor por defecto. Ejemplo de guardia de pago — niega cualquier llamada a herramienta de pago con una cantidad que supere un umbral: 
{
  "priority": 5,
  "label": "cap payment amount",
  "tool_name_glob": "payment.*",
  "args_match": {
    "clauses": [
      { "path": "$.amount_cents", "op": "gt", "value": 100000 }
    ]
  },
  "verdict": "deny"
}

​
3. Humano en el ciclo: retiene llamadas de alto riesgo para aprobación

Para herramientas que son genuinamente necesarias pero de alto riesgo — desencadenar un despliegue, aprobar un reembolso, enviar un email masivo — puedes requerir la firma de un humano antes de que proceda la llamada. El veredicto pending_approval retiene la llamada y devuelve una respuesta firewall_approval_pending al agente: 
{
  "priority": 20,
  "label": "hold deployment calls for review",
  "tool_name_glob": "deploy.*",
  "verdict": "pending_approval"
}
El agente (o tu framework) hace polling del id de aprobación. Un revisor aprueba o rechaza desde la consola o vía un callback de webhook. Si se aprueba, el agente reenvía la llamada original con el token de aprobación de un solo uso y el gateway la deja pasar una vez. pending_approval es compatible con cláusulas de argumentos — puedes retener solo las invocaciones que coincidan con un umbral y dejar pasar las rutinarias: 
[
  {
    "priority": 10,
    "label": "hold large deploys",
    "tool_name_glob": "deploy.release",
    "args_match": {
      "clauses": [
        { "path": "$.environment", "op": "eq", "value": "production" }
      ]
    },
    "verdict": "pending_approval"
  },
  {
    "priority": 20,
    "label": "allow staging deploys",
    "tool_name_glob": "deploy.*",
    "verdict": "allow"
  }
]

​
4. Cómo se ve una llamada bloqueada

Una llamada denegada en la superficie inbound (herramienta anunciada en la solicitud) devuelve HTTP 400 con el código de error firewall_blocked. La respuesta incluye metadata estructurada — la etiqueta de la regla coincidente, el código de razón y los factores de riesgo — y está marcada skip-retry para que un bucle no pueda martillar la misma llamada denegada. Una llamada bloqueada en la superficie response (el modelo ya emitió tool_calls) devuelve un error de herramienta visible para el modelo, dándole una oportunidad de reaccionar — elegir una herramienta diferente, preguntar al usuario o detenerse — en vez de fallar.

​
5. Ordenamiento gana-la-primera-coincidencia

El ordenamiento por prioridad importa. El motor recorre las reglas en orden ascendente de prioridad y se detiene en la primera coincidencia. Un patrón común:
PrioridadReglaVeredicto
5shell.exec + regex destructivodeny
10shell.* (general)allow
20crm.*allow
9999* (catch-all)deny
La prioridad 5 se dispara antes que la prioridad 10 — así que shell.exec con un comando destructivo se niega aunque haya un allow general para shell.*. Sin el deny de baja prioridad, la regla allow shell.* ganaría primero.

​
6. Despliega de forma segura con el modo shadow

Antes de cambiar una nueva política a modo de aplicación, activa el modo shadow. La política evalúa cada llamada a herramienta y registra el veredicto exactamente como lo haría en producción, pero cada veredicto aplicante (deny, pending_approval, sanitize) se degrada a audit — nada se bloquea. La razón en el log de eventos tiene el prefijo [shadow] would deny para que puedas medir el impacto en las vistas de Events y Runs. Una vez que hayas confirmado que la política se dispara en lo que esperas — y nada que no pretendías — desactiva el modo shadow. La siguiente llamada se aplica.
El nivel de autonomía tight aplica el preset block_destructive_shell automáticamente. Si necesitas una postura rápida sin escribir reglas, aplica tight desde la consola y envía una política de denegación para llamadas de shell destructivo en un paso. Luego puedes añadir tus propias reglas de lista de permitidos encima. Ver Niveles de autonomía.

​
7. Amenazas relacionadas

El abuso de herramientas de agentes raramente llega de forma aislada. Una llamada a herramienta no autorizada es a menudo la consecuencia de otro vector de ataque:
  • Inyección de prompts — un atacante incrusta instrucciones en el contenido recuperado que dirigen al agente hacia herramientas que no debería llamar.
  • Agencia excesiva — el agente recibió más acceso a herramientas de lo que requiere su tarea, haciendo cualquier inyección o mala configuración inmediatamente peligrosa.
  • El modelo de amenazas — cómo el abuso de herramientas encaja en la superficie de ataque completa para los sistemas agénticos.
El Agent Firewall es la capa de aplicación; el principio de mínimo privilegio (listas de permitidos de herramientas estrechas, claves con alcance) es la postura de diseño que lo hace efectivo.

Referencia de reglas del firewall

El lenguaje completo de coincidencia — globs de herramienta, cláusulas de argumentos, todos los operadores, veredictos y la API.

Vista general del firewall

Políticas, superficies, niveles de autonomía, aprobación HITL y observabilidad.