Saltar al contenido principal
Un agente MCP es un agente con alcance. Cada servidor Model Context Protocol al que se conecta es un conjunto fresco de herramientas, credenciales y destinos de red que nadie revisó — y el agente puede incorporar uno nuevo en mitad de la ejecución. Esta receta muestra los cuatro movimientos que convierten una configuración MCP desbordada en una gobernada en el gateway alojado: un único gateway MCP auditado, cuarentena de skills, denegación de egress y autenticación de servidor cifrada. Configuras todo ello desde la consola (o la API REST) contra tu espacio de trabajo. Tu agente sigue hablando MCP exactamente como antes.

​
1. Por qué asegurar un agente MCP

Apunta un agente a cinco servidores MCP directamente y tienes cinco límites de confianza, cinco almacenes de credenciales y cero rastro de auditoría compartido. El tools/call que lee un registro de cliente y el que ejecuta un comando shell parecen idénticos al modelo, y un servidor de la comunidad puede solicitar silenciosamente shell.exec y un alcance de red externo la primera vez que carga. La solución es hacer de OrcaRouter el único punto de estrangulamiento que cada llamada cruza. Para asegurar el tráfico de un agente MCP de extremo a extremo enrutas todo el despacho MCP a través del gateway MCP del Firewall, así que cada tools/call se evalúa por política antes de alcanzar el servidor real — con las skills puntuadas por riesgo, el egress gobernado y las credenciales cifradas en reposo.
Esto es una receta — cose características existentes en una pasada de endurecimiento concreta. Para la referencia completa, sigue los enlaces hacia Firewall, Servidores MCP y Skills.

​
2. Empieza desde la línea base de Agentes Seguros

Antes de autorar nada a medida, establece una postura. En la consola abre Firewall → Posture y aplica el nivel de autonomía balanced (rol Developer). En una transacción audita las llamadas a herramientas y marca PII mientras deniega las acciones más destructivas — vigilas antes de aplicar ampliamente, con deshacer de un clic. Cuando los feeds de Events y Runs se vean bien, pasa a tight: default-deny, shell destructivo denegado, egress con forma de SSRF denegado, más los guardrails PII Shield y Secrets Blocker aplicados. Ese único interruptor es el suelo sobre el que esta receta construye.
¿Prefieres escalar sin voltear todo el espacio de trabajo? Autora las reglas de abajo en una política nombrada y activa su modo shadow — evalúa y registra pero degrada cada veredicto de aplicación a audit (razón prefijada [shadow] would …) hasta que estés seguro. Ver modos de aplicación.

​
3. Enruta cada tools/call a través de un gateway MCP

Registra cada servidor MCP una vez; el gateway agrega sus herramientas bajo una única conexión (con espacio de nombres <server>.<tool>) y ejecuta cada tools/call a través del motor del firewall. Registra un servidor desde la consola (o la API REST, Developer+): 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
Luego apunta tu cliente MCP al gateway — no a los servidores upstream — usando una clave dedicada con alcance de gateway de firewall: 
https://api.orcarouter.ai/api/v1/firewall/mcp
Ahora github.create_issue y shell.exec aparecen lado a lado bajo una conexión, y cada despacho se evalúa antes de ejecutarse. Una llamada bloqueada vuelve al modelo como un error de herramienta (firewall deny: …), no como un fallo de transporte, así que el agente puede adaptarse.
Una clave de relay normal obtiene 403 en la ruta de gateway /api/v1/firewall/mcp. Acuña un token de gateway dedicado (is_firewall_gateway) para la conexión MCP; leer el texto plano de esa clave de gateway requiere Admin+.
Antes de poder escribir reglas contra las herramientas de un servidor, sondéalo (probe) para descubrir sus nombres y esquemas: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. Pon en cuarentena las skills que el agente incorpora

El gateway MCP gobierna llamadas; la gobernanza de skills gobierna las capacidades que un agente carga. Cada skill instalable, servidor MCP propio o plugin se escanea en una banda de riesgo y un modo de aplicación que cabalga encima de cada veredicto de regla:
ModoEfecto en tiempo de ejecución
allowLos veredictos de regla deciden; la skill no añade nada.
quarantineCualquier cosa por debajo de deny se retiene para pending_approval.
blockLas herramientas de la skill son denegadas a la fuerza.
El punto para un agente MCP: una capacidad que nadie aprobó no obtiene un pase libre. Cuando un agente auto-instala algo y sus herramientas cruzan el gateway por primera vez, el Firewall lo auto-detecta y lo pone en cuarentena hasta que un humano lo revise — incluso si escaneó limpio. Pre-aprueba los servidores en que confías; deja que el resto aterrice en la cola de revisión.
Mantén balanced/observe activado mientras aprendes qué instala realmente tu agente, luego promociona las skills confiables a allow y deja la cola larga en cuarentena. Ver Skills.

​
5. Deniega el egress con forma de SSRF

Una herramienta MCP comprometida o confundida que alcanza hacia cloud-metadata o un host de intranet es la ruta clásica de exfiltración. Dos capas lo cubren. Primero, el gateway valida cada endpoint MCP remoto y su IP de marcado resuelta contra una política SSRF en el registro y en cada salto de despacho — los rangos de intranet y la dirección de cloud-metadata se rechazan, re-verificados para derrotar el rebinding de DNS. Eso viene integrado; no lo configuras. Segundo, el nivel de autonomía tight incluye un preset de egress SSRF que deniega los nombres de herramienta con forma de fetch — http_fetch, web_search, fetch_url, request y sus formas con espacio de nombres <server>.* — así que una herramienta cuyo trabajo entero es “ve a obtener esta URL” se detiene antes de marcar. Para gobernar a dónde pueden alcanzar las herramientas por destino, autora tu propia regla egress con una lista de denegación de host/CIDR — esa es la superficie para fijar el alcance saliente: 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
Ningún preset incluye reglas de egress CIDR — el preset SSRF coincide con nombres de herramienta, no destinos. Autora la denylist de host/CIDR tú mismo cuando necesites control a nivel de destino. Ver listas de egress y detener la exfiltración.

​
6. Mantén cifradas las credenciales del servidor

El auth_json de cada servidor MCP está cifrado en reposo y enmascarado en lectura; el gateway inyecta credenciales en tiempo de despacho, así que nunca alcanzan el modelo o el cliente. Valores auth_mode soportados:
{ "token": "…" } — un token bearer estático, enviado como Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — OAuth de credenciales de cliente; el gateway obtiene y refresca el token.
{ "username": "…", "password": "…" } — autenticación HTTP Basic.
"" — un servidor sin autenticación. El valor por defecto.
En lectura el secreto se enmascara; devuelve el eco de la máscara en la actualización para mantener el valor almacenado. El status del servidor (ok / degraded / down) del último probe te dice si es alcanzable antes de que dependas de él.

​
7. Añade un guardrail de contenido en la solicitud

El Firewall gobierna acciones; emparéjalo con un Guardrail para que el texto que se mueve a través de tu agente MCP también se cribe. El preset Secrets Blocker captura credenciales en una solicitud antes de que el modelo — o cualquier herramienta — las vea, y un PII Shield enmascara identificadores a la entrada. Ambos vienen activados con el nivel de autonomía tight, o adjunta un guardrail nombrado a la clave de relay del agente vía guardrail_id.
El veredicto sanitize del firewall redacta los argumentos de la llamada a herramienta, nunca el contenido que una herramienta devuelve. Elimina secretos de la solicitud con el guardrail Secrets Blocker; sanea los argumentos que un agente emite con una regla de firewall. Cubren mitades diferentes del flujo.

​
8. Verifica y vigila

Confirma que la política hace lo que esperas antes de confiar en ella, luego mantén un ojo en los feeds:

Prueba una llamada a herramienta

Ejecuta en seco un tools/call de muestra contra tu política y ve el veredicto, la regla coincidente y la razón — nada despachado, nada registrado.

Herramientas descubiertas

Cada herramienta que el espacio de trabajo ha visto, marcada covered o gap — autora reglas directamente desde tráfico MCP real.

Events & Runs

Cada despacho, su veredicto y la superficie que tocó, agregado por ejecución de agente.

Feed de anomalías

Picos de tasa/coste, bucles de reintento y rutas de herramienta novedosas contra una línea base aprendida.

​
9. Dónde ir a continuación

Envenenamiento de herramientas MCP

El modelo de amenazas detrás de la cuarentena y el gateway MCP.

Agencia excesiva

Por qué el default-deny y el HITL importan para el uso autónomo de herramientas.

Receta de agente autónomo

Endurece un agente de alta autonomía de extremo a extremo.

Detener la exfiltración

Asegura el egress saliente en profundidad.