Blindar un servidor MCP para empresas: SSO, auditoría, gateway

Blindar un servidor MCP para empresas significa llevarlo de una demo que confía en cualquiera que tenga la URL a un servicio que verifica una identidad real en cada llamada, registra qué hizo cada agente y aplica el mínimo privilegio en un gateway. Al terminar esta guía tendrás un servidor MCP que valida un token de acceso OAuth 2.1 en cada petición, enruta el login a través del proveedor de identidad de tu empresa, escribe una línea de auditoría por cada invocación de tool y se sitúa detrás de un gateway que limita a cada agente a las tools que necesita. Esa es la diferencia entre una prueba de concepto y algo que un equipo de seguridad aprobará.

La brecha no es teórica. Una revisión de 2026 sobre 1.000 servidores MCP públicos encontró vulnerabilidades críticas en el 33% de ellos. Endor Labs analizó 2.614 implementaciones MCP: el 82% expone operaciones de archivo propensas a path traversal, el 67% llama a APIs relacionadas con code injection y el 34% toca APIs vulnerables a command injection. El primer servidor malicioso documentado públicamente, postmark-mcp, alcanzó unas 300 organizaciones antes de su divulgación. Y CVE-2025-6514, una command injection en el cliente mcp-remote, muy usado, obtuvo una puntuación de 9.6 en un paquete con más de 437.000 descargas. Un servidor MCP es una superficie de ejecución remota apuntada a tus tools internas. Trátalo como tal.

Qué necesitas antes de empezar

• Un servidor MCP remoto sobre HTTP (los servidores locales solo stdio tienen otro modelo de amenazas y quedan fuera de aquí).
• Un proveedor de identidad empresarial que hable OAuth 2.1 / OIDC: Okta, Microsoft Entra ID, Auth0 o Keycloak sirven.
• Un lugar al que enviar los logs: un SIEM o un sink como Microsoft Sentinel, Splunk o un bucket S3 con retención.
• La capacidad de poner un reverse proxy o un gateway delante del servidor. Puede ser un API gateway existente o un gateway MCP dedicado.

Paso 1: convierte el servidor en un resource server OAuth 2.1

La spec de autorización MCP actual (revisión 2026-07-28) se basa en OAuth 2.1. El servidor MCP actúa como resource server OAuth: no ejecuta el login, valida los tokens de acceso emitidos por un servidor de autorización separado. En concreto, el servidor debe rechazar toda petición sin un bearer token válido, validar el token según la Sección 5.2 de OAuth 2.1 y publicar los Protected Resource Metadata para que los clientes descubran qué servidor de autorización usar. Todos los endpoints de autorización van sobre HTTPS y los clientes deben usar PKCE con SHA-256. El acceso anónimo es el fallo más común que vemos por ahí, así que se empieza aquí.

Paso 2: enruta el login a través de tu proveedor de identidad (SSO)

No construyas tu propio login. Apunta los metadata del servidor de autorización a tu IdP empresarial, de modo que autenticarse en el servidor MCP signifique autenticarse en Okta, Entra o Auth0, con el mismo MFA, los mismos conditional access y el mismo offboarding que tu organización ya usa. Eso es lo que te da el SSO: cuando un empleado se va y TI deshabilita su cuenta, el acceso de su agente al servidor MCP muere con él. Evita las API keys estáticas en producción. Son difíciles de rotar, difíciles de atribuir a una persona y convierten cada línea de log en una línea anónima. Tokens de vida corta con rotación son el estándar empresarial, y encajan con el patrón TTL que usamos para las propias URLs del servidor.

Paso 3: ata cada token a tu servidor, y nunca los pases en passthrough

Es el paso que la mayoría de los tutoriales se salta, y el que detiene los peores ataques. Un agente de IA en una sola sesión puede tocar muchos resource servers, lo que agrava el problema OAuth del confused deputy: un token pensado para un servidor se reutiliza contra otro. La spec cierra la brecha de dos formas. Primero, los clientes DEBEN usar los Resource Indicators (RFC 8707): el cliente nombra tu servidor en la petición de token y el servidor de autorización emite un token cuya audiencia es tu servidor y nada más. Tu servidor luego rechaza todo token no emitido para él. Segundo, la spec dice que el servidor MCP NO DEBE pasar el token del llamante a una API aguas abajo. El token passthrough es el anti-patrón del confused deputy, por nombre. Cuando tu servidor necesita llamar a algo aguas abajo en nombre del usuario, usa Token Exchange (RFC 8693): cambia el token entrante por uno nuevo, ligado a la audiencia, que conserva la identidad del usuario en un actor claim. Mismo usuario, audiencia correcta, sin replay.

Paso 4: pon un gateway delante y limita las tools al mínimo privilegio

Cuando tienes más de un servidor MCP, o más de un puñado de tools, centraliza los controles. Un gateway MCP se sitúa entre agentes y servidores y aplica autenticación, permisos por tool y logging en un solo punto, convirtiendo el sprawl de tools no gobernado en infraestructura gestionada. El gateway es donde aplicas el mínimo privilegio: un agente de soporte obtiene las tools de solo lectura, un agente de billing obtiene la tool de reembolso, y ningún agente obtiene todas las tools solo porque se autenticó. El gateway es también el sitio correcto para hacer el Token Exchange del Paso 3 y para validar los esquemas de entrada de las tools antes de que una llamada llegue al servidor, lo que amortigua las clases de injection que señalaron los datos de Endor Labs.

Paso 5: activa el audit logging estructurado hacia tu SIEM

La aprobación empresarial exige responder a quién accedió a qué, cuándo y por qué. Emite una línea de log estructurada por cada llamada a una tool: el sujeto autenticado, el nombre de la tool, los argumentos (ofuscados donde sean sensibles), el recurso tocado y el resultado. Envía esas líneas al SIEM existente en vez de a un archivo local, para que hereden retención, alertas y búsqueda. Export a Microsoft Sentinel, forwarding a Splunk y archivado en S3 son las rutas comunes, y es lo que pedirá una auditoría SOC 2 o ISO 27001. Los logs también te dan detección de anomalías: un pico en las llamadas de un solo agente, o una tool invocada a las 3 de la madrugada desde una ubicación nueva, es una señal que solo ves si la registraste.

Paso 6: fija y escanea las definiciones de las tools

El tool poisoning y los rug pulls explotan que los agentes confían en las descripciones de las tools. Un servidor puede enviar una descripción inocua, lograr aprobación y luego redefinir en silencio la tool para exfiltrar datos. Defiéndete fijando las definiciones de las tools a una versión, tratando un cambio de descripción como un cambio que requiere revisión y escaneando los servidores MCP de terceros antes de conectarles un agente. Cura un registro interno de servidores aprobados en lugar de dejar que cualquier agente se conecte a cualquier URL. Es governance, no código, pero es el control que habría detenido la integración MCP de WhatsApp que a finales de 2025 envenenaba las descripciones de las tools para extraer historiales de mensajes.

Verificar que funciona

Haz estas comprobaciones antes de decir que el servidor está blindado:

1. Una petición sin token devuelve 401 y la respuesta anuncia el servidor de autorización vía Protected Resource Metadata.
2. Un token emitido para otro recurso es rechazado (prueba tu comprobación de audiencia RFC 8707).
3. Deshabilitar un usuario en el IdP anula el acceso de su agente dentro de la vida del token.
4. Cada llamada a una tool produce exactamente una línea de auditoría en el SIEM, con el sujeto autenticado presente.
5. Un agente autorizado para la tool A no puede invocar la tool B a través del gateway.

Fallos comunes y arreglos

• El servidor acepta cualquier token válido. Validar no basta. Comprueba la audiencia. Un token emitido para otro servicio que comparte tu IdP validará, pero no es para ti.
• Tokens pasados directos a las APIs aguas abajo. Es el anti-patrón del confused deputy que la spec prohíbe. Inserta el Token Exchange en el gateway.
• Audit logs en disco local. Desaparecen con el contenedor y nadie los alerta. Envíalos al SIEM.
• Un scope amplio único para todas las tools. Si autenticarse concede todas las tools, tienes autenticación sin autorización. Separa los scopes por tool o grupo de tools.
• Confiar en servidores de terceros por URL. Una RCE con CVSS 9.6 llegó en un paquete con 437.000 descargas. Verifica antes de conectarte.

Ir más allá

Si aún no has construido el servidor, empieza por nuestra guía sobre cómo construir un servidor MCP para un SaaS Next.js existente, y luego aplica encima esta pasada de hardening. Para los patrones de seguridad a nivel de petición que estos pasos dan por sentados, mira la seguridad de las server actions en Next.js. El hilo conductor es el mismo que gobierna el resto de tu stack: autentica a cada llamante, limita cada permiso, registra cada acción y no confíes en ninguna entrada por defecto.