Firewall: Servidores MCP

El Model Context Protocol (MCP) permite a los agentes llamar a herramientas hospedadas por servidores externos. Eso es potente y peligroso a partes iguales: cada servidor MCP al que un agente se conecta es un nuevo conjunto de herramientas, credenciales y alcance de red que nadie revisó. El gateway MCP del Firewall pone un único punto de estrangulamiento auditado delante de todos ellos. Registras cada servidor MCP una vez; el gateway expone sus herramientas a tus agentes bajo una sola conexión y ejecuta cada tools/call a través del motor del firewall antes de que llegue al servidor real.

1. Qué te da la gobernanza de MCP

Un gateway, cada servidor. Tu agente se conecta a un endpoint. El gateway agrega las herramientas de cada servidor registrado alcanzable, con espacio de nombres <server>.<tool>, así que github.create_issue y shell.exec aparecen lado a lado bajo una sola conexión MCP.
Política en cada llamada. Cada tools/call se evalúa primero por tu política. Una llamada bloqueada vuelve al modelo como un error de herramienta (firewall deny: …), no un fallo de transporte, así que el agente puede reaccionar en vez de fallar. sanitize reescribe los argumentos antes de reenviar; pending_approval retiene la llamada.
Protegido contra SSRF. Los endpoints remotos se validan contra la política SSRF del gateway — los rangos de intranet y las direcciones de metadatos de la nube se bloquean, y la IP de marcado resuelta se reverifica para derrotar el DNS rebinding, en cada salto incluyendo las redirecciones.
Credenciales cifradas. Los secretos de autenticación del servidor se cifran en reposo y se enmascaran en lectura. El gateway los inyecta en tiempo de despacho; nunca llegan al modelo ni al cliente.

2. Dos tipos de servidor

Tipo	`endpoint`	Comportamiento
BYO (bring-your-own)	Una URL streamable-HTTP	El gateway proxea `tools/call` a tu servidor MCP remoto.
Incluido	vacío	El servidor MCP en proceso de OrcaRouter. Registrado para que sea visible y gobernable; no es sondeable por separado.

3. Registrar un servidor

Un registro de servidor lleva:

Campo	Notas
`name`	Clave de negocio, única por espacio de trabajo, ≤ 128 caracteres. Sin `.` — es el separador de espacio de nombres `<server>.<tool>`.
`endpoint`	La URL del servidor MCP (≤ 512 caracteres). Vacío para el servidor incluido.
`auth_mode`	`none` (por defecto), `bearer`, `oauth` o `basic`.
`auth_json`	Credenciales específicas del modo (ver abajo). Requerido siempre que `auth_mode` no sea `none`.
`enabled`	Por defecto `true`. Un servidor deshabilitado se omite del gateway por completo.
`status`	Alcanzabilidad — `ok` (por defecto), `degraded` o `down`. Establecido por el sondeo.

Formas de credencial por modo:

// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""

Una solicitud de registro se ve así:

curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'

Un nombre duplicado en el mismo espacio de trabajo devuelve HTTP 409 (el mismo nombre en un espacio de trabajo diferente está bien).

Los secretos nunca se almacenan en texto plano. auth_json se cifra en reposo con una clave de secretos del espacio de trabajo. Si esa clave no está configurada, la escritura se rechaza en vez de persistir una credencial sin cifrar. En lectura, los secretos y el endpoint se enmascaran; haz eco de la máscara de vuelta en una actualización para mantener el valor almacenado. Cambiar entre dos modos de autenticación con credenciales requiere un auth_json fresco (el texto cifrado está atado en forma a su modo).

4. Probe — descubre sus herramientas

Antes de poder escribir reglas contra las herramientas de un servidor, necesitas conocer sus nombres. Sondea (probe) el servidor:

curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."

El gateway ejecuta un initialize + tools/list de MCP contra el endpoint (usando las credenciales descifradas, acotado en 10s), registra el status de alcanzabilidad y una marca de tiempo, y devuelve las herramientas anunciadas con sus esquemas de entrada:

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}

Ahora puedes autorar reglas como tool_name_glob: github.* sabiendo exactamente qué acepta github.create_issue. El servidor incluido (endpoint vacío) no es sondeable y devuelve un 400.

5. Ciclo de vida y aplicación

Habilitado vs. deshabilitado. Un servidor deshabilitado se elimina del registro en tiempo de ejecución — sus herramientas desaparecen del gateway y sus credenciales nunca se descifran. Ese es el interruptor de apagado.
Alcanzabilidad. status (ok / degraded / down) refleja el último sondeo; un servidor inalcanzable se omite cuando el gateway construye su conjunto de herramientas.
Veredicto por llamada. En el despacho el motor devuelve un veredicto para la llamada <server>.<tool> específica con sus argumentos:
- allow / audit → reenviado (audit registra, igual permite).
- sanitize → reenviado con argumentos reescritos.
- deny / pending_approval / cualquier cosa desconocida → bloqueado como un error de herramienta. (A través del gateway unificado, una llamada retenida aflora como un error permanente en vez de hilar el id de aprobación — usa el hook de evaluación cuando necesites el apretón de manos de aprobación.)
La eliminación es una eliminación suave; el espacio del nombre se libera inmediatamente para que puedas reregistrar bajo el mismo nombre.

Cada cambio invalida la caché de herramientas por espacio de trabajo del gateway inmediatamente, así que un servidor recién registrado, deshabilitado o resondeado surte efecto en la siguiente conexión en vez de tras un TTL de caché.

6. Conectar un cliente

Apunta cualquier cliente MCP al endpoint del gateway con un token con alcance de gateway de firewall:

https://api.orcarouter.ai/api/v1/firewall/mcp

El gateway habla streamable HTTP (mensajes POST, GET para el stream SSE, DELETE para terminar una sesión) y se identifica como orcarouter-firewall-gateway. Anuncia las herramientas de cada servidor habilitado y alcanzable bajo el espacio de nombres <server>.<tool>, reexponiendo el esquema de entrada de cada herramienta textualmente. Un token sin el alcance de gateway de firewall obtiene 403 — acuña un token de gateway dedicado para esto.

API reference

Consola (con alcance de espacio de trabajo, RBAC)

Método y ruta	Rol	Propósito
`GET /api/workspace/firewall/mcp_servers`	Member	Lista servidores (secretos enmascarados, endpoint redactado).
`GET /api/workspace/firewall/mcp_servers/:id`	Member	Un solo servidor, enmascarado.
`POST /api/workspace/firewall/mcp_servers`	Developer+	Registrar un servidor (409 en nombre duplicado).
`PUT /api/workspace/firewall/mcp_servers`	Developer+	Actualizar un servidor (id en el cuerpo).
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	Eliminación suave; libera el nombre.
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	Sondear alcanzabilidad + descubrir herramientas.

Gateway (token con alcance de gateway de firewall)

Método y ruta	Propósito
`ANY /api/v1/firewall/mcp`	El endpoint unificado de despacho del gateway MCP.
`GET /api/v1/firewall/mcp_servers`	Registro en tiempo de ejecución (autenticación descifrada, solo servidores habilitados) para un proxy de SDK.
`POST /api/v1/firewall/evaluate`	Evaluar un solo `tools/call` antes de despacharlo tú mismo.

FAQ

¿Por qué enrutar MCP a través de OrcaRouter siquiera?

Para que haya un solo lugar que vea cada llamada a herramienta. Sin un gateway, cada agente se conecta a cada servidor MCP directamente — sin política compartida, sin rastro de auditoría, sin protección SSRF, y con credenciales dispersas por las configuraciones de los agentes. El gateway centraliza todo eso: una conexión, una política, un log auditado, secretos cifrados inyectados en el despacho.

¿Qué pasa cuando vuelve una llamada MCP bloqueada?

El modelo la recibe como un error de herramienta (firewall deny: <reason>), la misma forma que obtendría de cualquier herramienta que falla. Eso permite al agente adaptarse — probar otro enfoque, preguntar al usuario o detenerse — en vez de tratarlo como un fallo de transporte.

¿Puedo gobernar la misma herramienta de forma diferente por servidor?

Sí — para eso es el espacio de nombres <server>.<tool>. Una regla con tool_name_glob: trusted.* puede hacer allow mientras community.* se auditea o se pone en pending_approval. Combínalo con un glob de nombre de skill para un alcance aún más fino.

¿Protege el gateway contra SSRF?

Sí. Las URLs de endpoint y sus IPs de marcado resueltas se validan contra la política SSRF en el registro y en cada salto de despacho — los rangos de intranet y la dirección de metadatos de la nube se rechazan, y la IP resuelta se reverifica para derrotar el DNS rebinding. Combínalo con una regla de egress para gobernar dónde pueden alcanzar las herramientas.

Véase también

¿Quieres profundizar en la seguridad de agentes? Las guías de Protege tus agentes (Zero Trust) sitúan esta función dentro de un flujo de trabajo de confianza cero.

Protege servidores MCP (Zero Trust)

Conecta, autentica y gobierna servidores MCP bajo una postura de confianza cero.

Lista de verificación de confianza MCP

Qué verificar antes de confiar en un servidor MCP de terceros.

​1. Qué te da la gobernanza de MCP

​2. Dos tipos de servidor

​3. Registrar un servidor

​4. Probe — descubre sus herramientas

​5. Ciclo de vida y aplicación

​6. Conectar un cliente

​API reference

​Consola (con alcance de espacio de trabajo, RBAC)

​Gateway (token con alcance de gateway de firewall)

​FAQ

​Véase también