Saltar al contenido principal
Un servidor MCP de terceros es un paquete sin revisar de herramientas, una credencial en vivo y un alcance de red fresco. En el momento en que un agente marca uno directamente, nadie está vigilando la llamada — y “el servidor cambió sus herramientas después de que lo aprobaste” es un ataque real, no algo hipotético. Antes de apuntar un agente a un servidor que otra persona opera, quieres un pre-vuelo repetible. Esta página es ese pre-vuelo: una lista de verificación corta y ordenada para evaluar conexiones a servidores mcp en OrcaRouter usando controles que ya existen — evaluación por llamada, lista de permitidos de denegación por defecto, límites de egress, credenciales cifradas y cuarentena de skills. Cada paso enlaza al how-to enfocado para profundidad. Ejecútala una vez por cada nuevo servidor; re-ejecuta los pasos sensibles a la deriva cada vez que el servidor cambie.
Cada paso de configuración aquí se hace desde la consola (o la API REST con tu token de sesión/acceso) y está restringido por rol. Solo las rutas del gateway del firewall y las llamadas de relay /v1/* llevan una clave de estilo sk-orca-....

​
1. La lista de verificación para evaluar conexiones a servidores mcp

Trabaja de arriba abajo. Los primeros tres pasos son obligatorios para cualquier servidor que no operes tú mismo; el resto lo endurece.

1. Sondea antes de confiar

Descubre la lista de herramientas real y la alcanzabilidad antes de escribir una sola regla.

2. Deniega por defecto, luego lista de permitidos

Permite solo las herramientas que revisaste; todo lo demás se deniega.

3. Cifra la credencial

Almacena la autenticación así está cifrada en reposo, enmascarada en lectura, nunca vista por el modelo.

4. Restringe el egress

Restringe dónde pueden alcanzar las herramientas del servidor en la red.

5. Pon en cuarentena las skills autoinstaladas

Retén cualquier cosa que el agente instale por su cuenta hasta que un humano la revise.

6. Sombra primero, luego vigila

Despliega en solo-auditoría, luego lee eventos y anomalías antes de aplicar.

​
2. Sondea antes de confiar

No puedes revisar herramientas que nunca has visto, y la lista de herramientas anunciada de un servidor es lo más propenso a cambiar bajo tus pies. Registra el servidor, luego sondéalo — el gateway ejecuta un MCP initialize + tools/list contra el endpoint y devuelve las herramientas reales con sus esquemas de entrada, más un status de alcanzabilidad de ok, degraded o down. 
# Ruta de consola, llamada con tu token de sesión/acceso (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Lee cada nombre de herramienta y qué aceptan sus argumentos. Un servidor que anuncia un shell.exec o un http_fetch que no esperabas es un hallazgo, no un detalle — ese es todo el punto de sondear primero.
Re-sondea cada vez que un servidor cambie de manos o sospeches deriva. Una nueva herramienta apareciendo en la lista — el “rug pull” — es exactamente lo que estás vigilando. Ver Defensa contra rug-pull.
La referencia completa de registro y sondeo vive en Firewall: servidores MCP; el recorrido de extremo a extremo es Conectar un servidor MCP.

​
3. Deniega por defecto, luego lista de permitidos las herramientas que revisaste

Una lista de permitidos es la diferencia entre “el servidor puede hacer seis cosas” y “el servidor puede hacer lo que su operador decida mañana”. Establece el default_verdict de la política en deny, luego añade una regla por herramienta que revisaste y en la que confías. Como el gateway pone cada herramienta en el espacio de nombres <server>.<tool>, puedes acotar reglas a un servidor sin tocar los otros. 
// Política en la superficie mcp: deny por defecto, allow solo lo que revisaste.
// tool_name_glob soporta un comodín de segmento completo: "github.*" (prefijo),
// "*.exec" (sufijo), o "*.shell.*" (infijo). Globs de mitad de segmento como
// "github.get_*" caen a una coincidencia exacta y no se expanden.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Ahora github.create_issue se ejecuta, github.get_issue se ejecuta, y un github.delete_repo recién introducido se deniega hasta que lo hayas revisado y permitido. Un tools/call denegado vuelve al modelo como un error de herramienta (firewall deny: …) — el agente se adapta en vez de fallar. Ver Lista de permitidos de herramientas MCP para la receta completa, y Reglas del firewall para el DSL de coincidencia.

​
4. Cifra la credencial — nunca hagas tu propia autenticación a mano

Un servidor de terceros casi siempre necesita una credencial, y una credencial es lo que menos quieres sentado en texto plano o llegando al modelo. Registra la autenticación del servidor a través de OrcaRouter así está cifrada en reposo, enmascarada en lectura, e inyectada solo en tiempo de despacho. auth_mode es uno de none, bearer, oauth o basic: 
# Ruta de consola, UserAuth, Developer+.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}"
  }'
La credencial se cifra y se enmascara en el momento en que se almacena — nunca llega al modelo ni al cliente, y en lectura solo ves la máscara. En una actualización, haz eco de la máscara de vuelta para mantener el valor almacenado; envía un auth_json fresco solo cuando estés rotando. Ver Autenticar y Rotación de credenciales.

​
5. Restringe el egress: ¿dónde pueden alcanzar sus herramientas?

Los veredictos por llamada deciden qué herramienta se ejecuta; el egress decide dónde puede alcanzar. Una herramienta que “devuelve datos” y una herramienta que “exfiltra tus secretos al host de un atacante” pueden ser la misma herramienta con un argumento diferente — el control de egress es lo que las distingue. El gateway ya valida cada endpoint remoto y su IP de marcado resuelta contra una política SSRF en cada salto, rechazando los rangos de intranet y la dirección de metadatos de la nube y re-verificando la IP para derrotar el DNS rebinding. Encima de eso, autora tu propia regla de deny de egress para los hosts y CIDRs que este servidor nunca debería tocar: 
// Una regla de stage egress acota su veredicto al destino saliente.
// egress_json lleva listas de permitidos + denegados de host/CIDR.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
No hay preset que te entregue reglas CIDR — autoras la lista de deny de host/CIDR tú mismo, acotada a lo que este servidor legítimamente necesita. Ver Límites de egress y Exfiltración de datos.

​
6. Pon en cuarentena lo que el agente instala por su cuenta

El servidor que registraste es un riesgo; las skills, los servidores MCP BYO y los plugins que un agente autoinstala después son otro. OrcaRouter escanea cada capacidad instalable, le asigna una banda de riesgo, y deriva un modo de cumplimiento — allow, quarantine o block — que cabalga encima de cada veredicto de regla. Cualquier cosa auto-detectada en el primer uso se pone en cuarentena hasta que un humano la revise: una capacidad que nadie aprobó no obtiene un pase libre solo porque escaneó benigna. Una capacidad quarantine escala cualquier cosa por debajo de un deny a pending_approval, así que sus herramientas se ejecutan solo después de que hayas mirado.
No intentes registrar cada skill a mano. Pre-aprueba las que confías y deja que el resto sea auto-detectado y puesto en cuarentena — luego revisa a partir de datos reales. El modo se aprieta más en un re-escaneo, nunca más flojo. Ver Firewall: skills y Envenenamiento de herramientas MCP.

​
7. Sombra primero, luego vigila el rastro

No cambies un servidor recién nacido directo a enforcing. Pon la política en modo sombra — los veredictos enforcing se degradan a audit y se registran como [shadow] would … — así puedes ver qué habría sido bloqueado antes de que realmente lo sea. Cuando el rastro de auditoría se vea bien, deja caer el modo sombra y aplica. Después de que está en vivo, los controles siguen vigilando:
Cada llamada gobernada registra su veredicto, superficie y regla coincidente. Léelos para confirmar que la lista de permitidos y las reglas de egress se comportan como se pretende. Ver Auditar eventos MCP.
Picos de tasa y coste contra una línea base aprendida, más bucles de reintento y rutas de herramienta novedosas, afloran como anomalías — legibles por cualquier Member.
Activa el modo observe para registrar como brechas las llamadas que una política aún no cubre, así aprietas a partir de lo que un agente realmente hace, no de conjeturas.

​
8. El camino rápido: elige un nivel de autonomía

Si prefieres no construir a mano los pasos 3–5 para un servidor en el que no confías del todo, aplica un nivel de autonomía y edita desde ahí. Los niveles escriben filas de política y guardrail reales y editables — son un punto de partida, no una caja negra:
NivelQué establece
permissiveModo observe activado — registra todo, no aplica nada.
balancedPolítica de auditoría por defecto que deniega shell destructivo, más el guardrail PII Shield en modo solo-marcar.
tightPolítica de denegación por defecto que deniega shell destructivo y herramientas con forma de fetch (http_fetch/web_search/fetch_url/request — el vector SSRF), más los guardrails PII Shield y Secrets Blocker aplicados. Los secretos en argumentos los atrapa el guardrail Secrets Blocker sobre la solicitud, no una regla de tool-arg.
Para un servidor de terceros que aún estás evaluando, empieza en tight, sondea, luego relaja herramientas específicas a una lista de permitidos. El deshacer de un clic restaura la instantánea previa a la aplicación.
Las lecturas de configuraciones, políticas, herramientas descubiertas, anomalías, servidores MCP registrados y skills están abiertas a cualquier Member; las lecturas de evento, run y agregado requieren Developer+, y cada escritura requiere Developer+. Revelar la clave en texto plano de un token también es Developer+.

​
9. Dónde ir a continuación

Conectar un servidor MCP

Registra, sondea y expone un servidor a través del gateway.

Lista de permitidos de herramientas MCP

Deniega por defecto un servidor y permite solo las herramientas revisadas.

Defensa contra rug-pull

Atrapa un servidor o skill que cambia después de que lo aprobaste.

Resumen de seguridad de MCP

El mapa completo de la superficie de gobernanza de MCP.
¿Nuevo en el modelo? Lee Guardrails vs. firewall para dónde encaja la gobernanza de MCP, luego Agencia excesiva y Llamadas a herramienta peligrosas para las amenazas que esta lista de verificación cierra.