Saltar al contenido principal
Un agente que habla el Model Context Protocol (MCP) es solo tan seguro como los servidores a los que se conecta. Cada servidor MCP es un nuevo conjunto de herramientas, una nueva credencial y un nuevo alcance de red — y en el momento en que un agente marca uno directamente, nadie está vigilando la llamada. Ese es el problema entero que mcp security tiene que resolver: no “¿es segura esta herramienta?” sino “¿quién gobierna todas ellas, en cada llamada, con un solo rastro de auditoría?”. La respuesta de OrcaRouter es un único punto de estrangulamiento auditado. Registras cada servidor MCP una vez; los agentes se conectan a un gateway; y cada tools/call se ejecuta a través del motor del firewall antes de que llegue al servidor real. Esta página es el mapa de esa superficie — el gateway, el veredicto por llamada, la gobernanza de skills, el egress y las credenciales cifradas — con enlaces al how-to enfocado para cada una.
Cada acción de gestión aquí se configura desde la consola (o la API REST con tu token de sesión/acceso) y está restringida por rol. Solo las llamadas de relay /v1/* y las rutas del gateway del firewall llevan una clave de estilo sk-orca-....

​
1. Por qué mcp security necesita un gateway

Apunta diez agentes a cinco servidores MCP comunitarios directamente y obtienes lo peor de cada mundo: sin política compartida, sin rastro de auditoría, credenciales copiadas en diez configuraciones de agente, y una herramienta llamada shell.exec a una redirección de tu endpoint de metadatos de la nube. El gateway colapsa todo eso en una única conexión gobernada.

Una conexión, cada servidor

Los agentes se conectan a un único endpoint. El gateway agrega las herramientas de cada servidor habilitado y alcanzable bajo un espacio de nombres <server>.<tool>.

Política en cada llamada

Cada tools/call se evalúa por tu política de firewall antes del despacho.

Credenciales cifradas

Los secretos de autenticación del servidor se cifran en reposo, se enmascaran en lectura y se inyectan en el despacho — nunca llegan al modelo ni al cliente.

Egress bajo control

El endpoint de un servidor registrado se valida contra rangos de IP privados y de metadatos de la nube por defecto. Para destinos por herramienta, aplica la lista de denegación de egress SSRF de base o autora tus propias reglas de host/CIDR.
Para los fundamentos detrás de todo esto, ver Asegurar agentes de IA y Por qué zero trust.

​
2. Los cuatro bloques de construcción

La gobernanza de MCP en OrcaRouter son cuatro piezas que cooperan. Elige la que coincida con la pregunta que intentas responder.
Un único endpoint al que tus agentes se conectan en vez de marcar servidores directamente. Agrega las herramientas de cada servidor registrado, con espacio de nombres <server>.<tool>, y reexpone el esquema de entrada de cada herramienta textualmente. Empieza en Conectar un servidor MCP y Autenticar; la referencia completa vive en Firewall: servidores MCP.
El gateway ejecuta cada tools/call a través del firewall en la superficie mcp y devuelve un veredicto — allow, audit, deny, sanitize o pending_approval — antes del despacho. Ver Lista de permitidos de herramientas MCP y Sanear argumentos de herramientas.
Las capacidades que un agente autoinstala — skills, servidores MCP BYO, plugins — se escanean, se les asigna una banda de riesgo y se les da un modo de cumplimiento (allow / quarantine / block) que cabalga encima de cada veredicto de regla. Ver Firewall: skills y Defensa contra rug-pull.
El secreto de autenticación de cada servidor se cifra en reposo y se enmascara en lectura. Ver Autenticar y Rotación de credenciales.

​
3. Cómo se evalúa un tools/call

Cuando un agente llama a una herramienta a través del gateway, la llamada no va directa al servidor. Se coteja contra tu política de espacio de trabajo, el modo de cumplimiento de la skill propietaria se aplica encima, y solo un veredicto allow / audit / sanitize llega al servidor real.
VeredictoLo que ve el agente
allow / auditReenviado. audit además registra un evento.
sanitizeReenviado con los argumentos redactados (nunca el resultado).
deny / pending_approvalDevuelto como un error de herramienta, así el agente puede adaptarse en vez de fallar.
Una llamada MCP bloqueada vuelve como un error de herramienta (firewall deny: …), la misma forma que devuelve cualquier herramienta que falla — el agente puede reintentar de otra manera, preguntar al usuario o detenerse. No es un fallo de transporte.
El vocabulario de veredictos, las superficies y la coincidencia de reglas están documentados por completo bajo Firewall y Reglas del firewall; el modelo conceptual está en Modos de cumplimiento y Cómo inspecciona OrcaRouter.

​
4. Registrar un servidor (un ejemplo concreto)

Registras cada servidor una vez. Un registro de servidor lleva un name (único por espacio de trabajo, sin .), un endpoint, un auth_mode (none / bearer / oauth / basic) y sus credenciales cifradas. Haz esto desde la consola — la escritura requiere Developer+. 
# Ruta de consola, llamada con tu token de sesión/acceso (UserAuth).
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\"}",
    "enabled": true
  }'
Luego sondéalo para descubrir sus herramientas y registrar la alcanzabilidad (ok / degraded / down): 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Ahora puedes escribir reglas contra github.* sabiendo exactamente qué acepta github.create_issue. El recorrido de extremo a extremo vive en Conectar un servidor MCP.
Los secretos nunca se almacenan en texto plano. auth_json se cifra en reposo y se enmascara en lectura; en una actualización, haz eco de la máscara de vuelta para mantener el valor almacenado. Ver Rotación de credenciales.

​
5. Conectar un agente al gateway

Una vez registrados los servidores, apunta cualquier cliente MCP al gateway con una clave con alcance de gateway de firewall (un token sin ese alcance obtiene 403): 
https://api.orcarouter.ai/api/v1/firewall/mcp
El gateway habla streamable HTTP y anuncia las herramientas de cada servidor habilitado y alcanzable bajo el espacio de nombres <server>.<tool>. Un SDK que proxea las llamadas él mismo puede leer el registro en tiempo de ejecución desde GET /api/v1/firewall/mcp_servers con el mismo token de gateway.

​
6. Restringe lo que las herramientas pueden alcanzar

Los veredictos por llamada gobiernan qué herramienta se ejecuta; los controles de egress gobiernan dónde puede alcanzar. Dos capas cooperan. Primero, cuando el gateway se conecta al endpoint de un servidor registrado, esa URL se valida contra rangos privados (RFC1918), loopback, link-local y de metadatos de la nube por defecto — y el host se resuelve por DNS, así que un nombre que resuelve hacia un rango bloqueado también se rechaza. Así que un servidor BYO apuntado a 169.254.169.254 o una dirección de intranet se rechaza a menos que lo hayas incluido explícitamente en la lista blanca. Segundo, para destinos por herramienta, una regla de egress lleva una lista de permitidos/denegados de host/CIDR cotejada contra el destino saliente de la llamada en la superficie egress. La plantilla de caso de uso de base trae una regla de denegación de egress lista para usar cuya lista ya cubre los rangos privados, loopback, link-local y de metadatos de la nube (incluidos 169.254.169.254 y metadata.google.internal), así que aplicarla te da defensa contra SSRF/metadatos sin autorar CIDRs a mano.
SSRF y egress son la diferencia entre “esta herramienta devolvió datos” y “esta herramienta exfiltró tus secretos al host de un atacante”. Aplica la lista de denegación de egress de base y añade tus propias reglas de host/CIDR — ver Límites de egress y Exfiltración de datos.

​
7. Vigílalo: eventos, runs y anomalías

Cada llamada gobernada deja un rastro. Los eventos del firewall registran el veredicto, la superficie y la regla coincidente; los runs agrupan las llamadas de una sesión; y el feed de anomalías marca picos de tasa y coste contra una línea base aprendida. Las lecturas de configuraciones, políticas y herramientas descubiertas están abiertas a cualquier Member; las lecturas de evento/run/agregado requieren Developer+.

​
8. 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 que has revisado.

Defensa contra rug-pull

Gobierna servidores y skills que cambian después de que los aprobaste.

Firewall: servidores MCP

La referencia completa de campos y rutas.
¿Nuevo en el modelo? Lee Guardrails vs. firewall para ver dónde encaja la gobernanza de MCP, luego Envenenamiento de herramientas MCP y Agencia excesiva para las amenazas que cierra.