1. Por qué el gateway es el punto de inspección correcto
La mayoría de los controles de seguridad viven en la aplicación: envoltorios de biblioteca, hooks de framework de agentes, SDKs por proveedor. Esos controles tienen un fallo estructural fatal — se rompen tan pronto como añades un segundo proveedor, cambias de framework o dejas que un agente auto-instale una nueva skill. El gateway no tiene ninguna de esas costuras. Cada llamada que emite tu agente, independientemente del modelo, proveedor o cómo llegó la capacidad de la herramienta, pasa por un único punto antes de que nada llegue al upstream. Esa es la única capa donde puedes hacer una garantía: si ocurrió, el gateway lo vio. OrcaRouter usa esa posición para dos pasadas de aplicación distintas:- Los guardrails examinan texto — el prompt que envía tu agente y la
respuesta que devuelve el modelo. Un bloqueo de guardrail devuelve HTTP
400
guardrail_blockedy no cuesta cuota. - El Firewall juzga acciones — las herramientas que llama un agente, los
servidores MCP que alcanza y los destinos de red que reporta. Un deny del
firewall devuelve HTTP 400
firewall_blockeden la superficie inbound, o un error de herramienta en la superficie MCP, para que el modelo vea el rechazo y pueda razonar sobre él.
https://api.orcarouter.ai/v1 exactamente como antes.
2. Las cuatro superficies de aplicación
El Firewall evalúa cada llamada a herramienta contra exactamente una superficie — el punto en el ciclo de vida de la llamada donde el gateway la ve.| Superficie | Lo que ve el gateway |
|---|---|
inbound | Las herramientas que tu agente anuncia al modelo en la solicitud — las definiciones de herramienta. Bloquear aquí evita que el modelo elija alguna vez una herramienta peligrosa. |
response | Los tool_calls que el modelo emite en su respuesta — las acciones elegidas por el modelo antes de que se despachen. |
mcp | Un tools/call despachado a través del gateway MCP del Firewall o evaluado vía el hook del SDK — la llamada en el momento del despacho. |
egress | Un destino de red saliente (host / IP / CIDR) que reporta una herramienta — la superficie de SSRF y exfiltración de datos. |
input (el prompt y los mensajes de la solicitud) y
output (el texto de respuesta del modelo). Una sola solicitud puede pasar
por todas ellas.
3. Detección en el primer uso
La detección ocurre en el gateway, en el primer uso — no en el momento de
instalación. Una herramienta, servidor MCP o skill que un agente auto-instala
se captura la primera vez que su llamada cruza el gateway. Esto es deliberado:
el gateway es el único punto de estrangulamiento que ve cada proveedor, cada
agente y cada llamada independientemente de cómo llegó la capacidad. Esperar
la detección en tiempo de instalación perdería las capacidades cargadas en
tiempo de ejecución.
4. Lo que el gateway no puede ver
La garantía de inspección cubre las llamadas que cruzan el gateway. No se extiende a una herramienta que tu agente ejecuta completamente dentro de su propio proceso — una que lee un archivo local, llama a una función de biblioteca o ejecuta un subproceso sin enviar nunca un mensaje al gateway. Este es un límite honesto, no un fallo de diseño. El objetivo de diseño es hacer del gateway el camino auditado para las llamadas que importan — las que tienen consecuencias en el mundo real:| Dónde se ejecuta | ¿Lo ve el gateway? | Cómo cerrar la brecha |
|---|---|---|
Llamada a herramienta mediada por modelo (el modelo emite tool_calls) | Sí — superficie response | No se necesita acción; ya está gobernado. |
| Despacho MCP a través del gateway MCP del Firewall | Sí — superficie mcp | No se necesita acción; ya está gobernado. |
Tu agente llama a POST /api/v1/firewall/evaluate antes del despacho | Sí — evaluado en línea | Ya está gobernado vía el hook de evaluación. |
| La herramienta se ejecuta en proceso, sin contacto con el gateway | No | Enruta el despacho MCP y las herramientas que llaman a la red a través del gateway en vez de llamarlas directamente desde el proceso del agente. |
5. Control de acceso por rol en los datos de inspección
El acceso a las superficies de inspección está restringido por rol dentro de tu espacio de trabajo:| Capacidad | Rol mínimo |
|---|---|
| Leer coincidencias de guardrail, políticas del firewall y herramientas descubiertas | Member |
| Leer los feeds de Events & Runs del firewall | Developer |
| Crear o cambiar guardrails, políticas del firewall, reglas | Developer |
Exportaciones de cumplimiento, texto plano de clave con alcance de gateway de firewall, flag is_firewall_gateway | Admin |
Un token con alcance de gateway de firewall (la clave usada para llamar a
/api/v1/firewall/evaluate y el gateway MCP) requiere el rol Admin para
crear. Una clave API regular devuelve 403 en esas rutas.6. Dónde ir a continuación
La pila de controles
El camino completo de la solicitud — clave, guardrails, modelo, firewall,
auditoría — en un diagrama.
Responsabilidad compartida
Qué asegura el gateway y qué permanece en tu aplicación.
Agent Firewall
Crea políticas, configura superficies y gobierna llamadas a herramienta en
profundidad.