Saltar al contenido principal
La postura más segura para un agente autónomo es defecto-deny: bloquea cada herramienta por defecto, luego permite explícitamente solo el puñado que tu agente debe usar. Cualquier cosa nueva que un agente recoja — una skill de la comunidad, un servidor MCP mal configurado, una herramienta que un jailbreak convenció al modelo de usar — se deniega porque nunca optaste por ella, no porque recordaste bloquearla. Esta página es el patrón de lista de permitidos de herramientas para agentes en api.orcarouter.ai: un veredicto por defecto deny más una o más reglas allow con clave en un tool_name_glob. Para el lenguaje de coincidencia completo detrás de esas reglas, ver Reglas del Firewall.
Las listas de permitidos se autoran en la consola bajo Security → Firewall, o vía las rutas de gestión /api/workspace/firewall/* (tu sesión / token de acceso — no una clave de relay sk-orca-…). Solo las llamadas /v1/* de tu agente usan la clave de relay. Crear o editar una política es una acción Developer+.

​
1. Por qué defecto-deny para agentes

Una lista de bloqueados (“denegar shell.exec, denegar db.delete, …”) nunca es más completa que la última amenaza en la que pensaste. Una lista de permitidos invierte la carga de la prueba: el gateway deniega todo lo que la política no permite explícitamente, así que una herramienta desconocida queda cerrada por construcción.

Veredicto por defecto = deny

El piso de la política. Sin ninguna regla coincidente, cada llamada a herramienta se bloquea.

Las reglas allow optan por las herramientas de vuelta

Cada regla allow nombra las herramientas que realmente usas — por nombre exacto o por glob.
El motor recorre las reglas de una política en orden de prioridad y gana la primera coincidencia; si nada coincide cae al default_verdict de la política. Así que una lista de permitidos es simplemente: reglas allow de alta prioridad para tus herramientas reales, con un piso deny que captura todo lo demás.

​
2. Un ejemplo: lista de permitidos de las herramientas de un agente de investigación

Supón que tu agente solo necesita buscar en la web y leer de una base de conocimiento — herramientas llamadas web.search y kb.read. Todo lo demás (shell, escrituras de archivos, mutaciones de base de datos, cualquier herramienta que una inyección de prompts pudiera conjurar) debe ser denegado. Construye la política como deny por defecto + dos reglas allow:
1

Crea la política con un default deny

Security → Firewall → Policies → New policy. Nómbrala, deja Enabled activado, y establece el veredicto por defecto a deny. Este es el piso cerrado — ver Crear una política.
2

Añade una regla allow por familia de herramientas

En el editor de reglas añade dos reglas, ambas verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search es una coincidencia exacta; kb.* es un glob de prefijo que permite kb.read, kb.search y cualquier herramienta kb.* futura sin reeditar la política.
3

Adjúntala a la clave de tu agente

Establece el firewall_policy_id de la clave a esta política (o hazla el valor por defecto del espacio de trabajo). El cuerpo de solicitud de tu agente queda sin cambios.
Ahora web.search y kb.read pasan; una llamada a shell.exec no coincide con ninguna regla allow, golpea el piso deny, y vuelve como HTTP 400 con el código firewall_blocked en la superficie inbound — ver cómo se ve un bloqueo.
Autora reglas allow como nombres exactos o prefijos estrechos (kb.*), no sufijos amplios. Un *.read flojo permitiría kb.read y secrets.read — lo opuesto de para lo que sirve una lista de permitidos. Mantén el glob tan ajustado como el nombrado de la herramienta lo permita.

​
3. El glob en una pantalla

tool_name_glob es una gramática pequeña y sensible a mayúsculas — sin regex, tiempo lineal. Las formas que importan para una lista de permitidos:
PatrónPermite
web.searchExactamente esa herramienta.
kb.*Prefijo — kb.read, kb.search (no kb pelado).
*.searchSufijo — web.search, kb.search, y search pelado.
*.tools.*Infijo — byo.tools.fetch y similares.
Para la gramática completa (reglas de infijo, casos límite, globs de nombre de skill), ver Sintaxis glob y la referencia de Reglas del Firewall.
Un glob *.suffix también coincide con el verbo pelado, sin espacio de nombres — *.search permite una herramienta literalmente llamada search, no solo web.search. Los proveedores y los servidores MCP sin espacio de nombres exponen herramientas bajo verbos pelados, así que un sufijo en lista de permitidos es más amplio de lo que parece. Prefiere nombres exactos o prefijos cuando quieras una lista de permitidos ajustada.

​
4. Lánzalo sin romper tu agente

Defecto-deny es la postura con más probabilidad de bloquear una herramienta que olvidaste que necesitabas. Escalónalo:
Activa el modo shadow. La política evalúa y registra exactamente como lo haría en vivo, pero degrada cada deny a audit con la razón prefijada con [shadow] would …. Ejecuta tráfico real, luego lee el feed de eventos.
Herramientas descubiertas lista cada herramienta que el espacio de trabajo ha visto, marcada covered o gap. Los eventos “would-deny” del modo shadow más los gaps te dicen exactamente qué reglas allow aún necesitas.
El sandbox de Test ejecuta en seco la política contra una llamada a herramienta de muestra y devuelve el veredicto, la regla coincidente y la razón — nada despachado, nada persistido. Confirma que web.search permite y shell.exec deniega, luego apaga shadow.
Una llamada inbound denegada cuesta cero tokens de modelo — se bloquea antes de que el modelo upstream se ejecute — y se marca como skip-retry, así que una herramienta bloqueada no quemará un presupuesto de reintentos volviendo a bloquearse. Ver Veredictos.

​
5. Dónde ir a continuación

Bloquear herramientas específicas

Lo inverso — mantén un piso defecto-allow y deniega herramientas nombradas.

Validar argumentos

Permite una herramienta, pero solo con argumentos seguros (db.query pero no DROP TABLE).

Prioridad de reglas

Cómo gana-la-primera-coincidencia ordena tus reglas allow por encima del piso deny.

Veredictos

allow, audit, deny, sanitize, pending_approval, cap_cost.
Para la amenaza que aborda este patrón, ver agencia excesiva y llamadas a herramienta peligrosas. Para por qué defecto-deny es la línea base del agente, ver por qué zero trust.