tool_name_glob evaluadas en la superficie
mcp.
Cada tools/call que cruza el gateway MCP se ejecuta
a través de tu política de firewall antes de que llegue
al servidor real. Así que la lista de permitidos no es consultiva — una llamada a
una herramienta que no permitiste nunca se despacha.
La edición de políticas es una acción de consola. Las rutas
/api/workspace/firewall/* se autentican con tu token de sesión / acceso, no con
una clave de relay sk-orca-…. Escribir reglas requiere el rol Developer+;
cualquier miembro del espacio de trabajo (hasta Viewer) puede leer políticas y
el feed de herramientas descubiertas.1. Por qué una lista de permitidos de denegación por defecto para secure mcp tools
Una lista de denegación — “bloquea las herramientas peligrosas” — falla en el momento en que un servidor añade una nueva herramienta, renombra una, o conectas un segundo servidor. El conjunto de herramientas peligrosas es abierto; el conjunto que quisiste usar es pequeño y conocido. Una lista de permitidos invierte el valor por defecto para que lo desconocido se rechace, no se admita:- Las herramientas nuevas se deniegan por defecto. Un servidor que crece una
herramienta
delete_repodespués de que lo conectaste no puede llamarse hasta que la añadas a la lista de permitidos. - El alcance es por servidor. El espacio de nombres
<server>.<tool>te deja permitirgithub.create_issuemientras deniegas todo lo demás bajogithub.*. - Un punto de estrangulamiento. La misma política gobierna el servidor incluido y cada servidor BYO detrás del gateway, así que hay un solo lugar para leer la lista de permitidos.
2. Las dos piezas
Una lista de permitidos es undefault_verdict más un conjunto ordenado de
reglas.
default_verdict: deny
El recurso de la política para cualquier
tools/call que ninguna regla
coincide. Ponlo en deny y cualquier cosa que no permitiste explícitamente
se bloquea. (También acepta allow y audit — audit es el valor por
defecto.)reglas allow
Una regla por herramienta (o por glob). Cada una lleva un
tool_name_glob y
un veredicto de allow. Un tools/call que coincide con el glob resuelve a
allow y se despacha; todo lo demás cae al valor por defecto deny.github.create_issue, shell.exec. * coincide con cualquier herramienta (úsalo
con moderación; una regla allow con * deshace toda la lista de permitidos). Un
<server>. inicial acota el glob a un servidor.
3. Un ejemplo concreto
Conectaste un servidorgithub y solo quieres que los agentes lean y abran
issues — nunca eliminar ni administrar nada. En la consola, abre Firewall →
Policies, establece el veredicto por defecto de la política en deny, y añade
dos reglas allow:
| Orden | tool_name_glob | Veredicto |
|---|---|---|
| 1 | github.create_issue | allow |
| 2 | github.list_issues | allow |
deny:
github.create_issue→ coincide con la regla 1 → allow, se despacha.github.delete_repo→ no coincide con nada → deny por defecto.
firewall deny: …) — la misma forma que devuelve cualquier herramienta que falla
— así el agente puede adaptarse en vez de fallar. (En la superficie inbound un deny
es en cambio un HTTP 400 con el código de error firewall_blocked.)
4. Apretar con argumentos
Un nombre de herramienta en la lista de permitidos todavía puede llamarse con malos argumentos. Acota más añadiendo una cláusulaargs_match (JSONPath + un
operador como eq, contains, regex, in o cidr_match) a la regla, o
poniendo en capa una regla deny por encima del allow para una forma de argumento
específica — por ejemplo, permite github.create_issue pero denylo cuando el
repo objetivo no esté en una lista aprobada. Ver la
referencia de reglas del firewall para el conjunto
completo de operadores.
sanitize redacta los argumentos de una llamada a herramienta antes de
reenviar — nunca toca lo que una herramienta devuelve. Para recortar el contenido
devuelto, ese es un control diferente; ver sanear la salida de
herramientas.5. Despliégalo con seguridad
Cambia una denegación por defecto de servidor entero en producción y arriesgas romper un agente que dependía silenciosamente de una herramienta que olvidaste. Dos ajustes lo reducen de riesgo:shadow_mode — ve los denies sin aplicarlos
shadow_mode — ve los denies sin aplicarlos
Un flag por política que degrada los veredictos enforcing a
audit. Tu valor
por defecto deny y tus reglas deny registran [shadow] would deny … en vez de
bloquear, así puedes validar la lista de permitidos contra el tráfico real
antes de que muerda. Lee más en
modos de cumplimiento.modo observe — aflora las herramientas que te perdiste
modo observe — aflora las herramientas que te perdiste
Un ajuste de espacio de trabajo que registra cada llamada no cubierta como una
brecha en el feed de Herramientas Descubiertas.
Ejecútalo antes de escribir la lista de permitidos para aprender exactamente
qué herramientas llaman tus agentes, luego promueve cada una a una regla allow
explícita.
shadow_mode y la lista de permitidos aplica.
6. Verifica que funciona
Tras aplicar, confirma que las herramientas denegadas realmente se rechazan:- Dry-run un
tools/callcontra la política (Developer+) para ver el veredicto y qué regla — o el valor por defecto — lo produjo, sin enviar tráfico real. Pasa un nombre de herramienta, una superficie y argumentos de muestra; el motor los evalúa y devuelve la traza del veredicto sin registrar un evento. - Vigila los eventos. Cada llamada bloqueada registra un evento de firewall que un Developer+ puede leer en la consola; la página de eventos de auditoría cubre el feed y sus campos.
Relacionado
Conectar un servidor MCP
Registra un servidor antes de poder listar sus herramientas como permitidas.
Firewall: servidores MCP
El comportamiento en tiempo de ejecución del gateway y los veredictos por
llamada.
Referencia de reglas del firewall
El DSL completo de reglas — globs, args_match, egress, sanitize.
Llamadas a herramienta peligrosas
La amenaza que una lista de permitidos está construida para contener.
Límites de egress
Gobierna dónde puede alcanzar una herramienta permitida.
Guardrails vs. firewall
Cuándo recurrir a la política de contenido vs. la política de herramientas.