Cómo implementar MCP con seguridad en entornos corporativos

Un dato debería bastar para disipar cualquier ilusión de que MCP es "solo otro protocolo simple de conexión": una investigación académica reciente (MCPSHIELD) mapeó más de 177.000 herramientas MCP registradas y encontró "7 threat categories and 23 distinct attack vectors organized across four attack surfaces". Ningún mecanismo de defensa aislado, según ese mapeo, cubre más del 34% de la superficie de amenaza identificada. Implementar MCP en producción corporativa exige tratar la seguridad como parte del diseño, no como una capa añadida después.

Autenticación: OAuth 2.1 como estándar, no como opción

GitHub recomienda OAuth 2.1 como base de autenticación para MCP servers remotos, con un endpoint /.well-known/oauth-protected-resource para divulgar qué servidores de autorización se soportan. Los tokens JWT deben validarse contra el endpoint JWKS del proveedor OAuth, verificando la expiración y la reivindicación de audiencia (aud) - esto garantiza que un token emitido para un servidor no se reutilice en otro. La propia especificación de MCP ya incorpora "authorization server discovery" y "dynamic client registration" para automatizar esta conexión.

Aislamiento multi-tenant

En escenarios con múltiples usuarios o equipos, GitHub recomienda extraer la identidad del usuario directamente de los claims del token OAuth (como sub), mapear esa identidad a un perfil interno con permisos específicos, y garantizar que cada consulta a base de datos o llamada a API esté aislada por usuario - no por una instancia compartida del servidor.

Rate limit y gateway

Un AI gateway delante de los MCP servers cumple varias funciones: limitar la tasa contra clientes agresivos, validar tokens JWT antes de que la solicitud llegue al servidor, añadir cabeceras de seguridad contra vulnerabilidades web comunes, e implementar circuit breakers para evitar fallos en cascada cuando un componente empieza a fallar.

Gestión de secretos

La recomendación es evitar variables de entorno en producción y usar servicios dedicados (Azure Key Vault, AWS Secrets Manager), combinados con "workload identities" - acceso sin credenciales de larga duración - y principio de mínimo privilegio: cada instancia solo accede a los secretos que realmente necesita.

Observabilidad como requisito de seguridad, no solo de rendimiento

GitHub recomienda structured logging con IDs de correlación únicos por solicitud, distributed tracing vía OpenTelemetry, y captura específica de eventos de seguridad: intentos de autenticación, fallos de autorización, patrones inusuales de uso. La frase que resume la filosofía del artículo: "empezar con la seguridad como fundamento, no como una idea posterior."

Lo que MCPSHIELD revela sobre la insuficiencia de medidas aisladas

El punto más importante de la investigación académica no es la lista de vulnerabilidades - es la constatación de que autenticación, autorización, validación de input y observabilidad, aplicadas de forma aislada, no bastan. La arquitectura que propone MCPSHIELD combina control de acceso basado en capacidades, atestación criptográfica de herramientas, rastreo de flujo de información y aplicación de políticas en tiempo de ejecución - y aun esa combinación alcanza solo un 91% de cobertura teórica contra las amenazas mapeadas, no el 100%.

Una checklist de implementación

1. Definición de herramientas - cada tool expuesta vía MCP debe tener alcance mínimo, no acceso total a un sistema
2. Autenticación - OAuth 2.1, validación de JWT contra JWKS, verificación de audiencia
3. Autorización por alcance - identidad del usuario extraída del token, no asumida por el servidor
4. Validación de inputs - nunca confiar en parámetros que vienen del agente sin sanitización
5. Políticas de uso de herramientas - rate limit y circuit breaker en el gateway
6. Auditoría - logging estructurado con correlación, eventos de seguridad capturados aparte
7. Segregación por entorno - aislamiento multi-tenant real, no solo lógico
8. Gestión de secretos - sin credenciales de larga duración, sin variables de entorno en producción
9. Observabilidad - distributed tracing, alertas para picos de error y anomalías
10. Proceso de aprobación de nuevas tools - ninguna herramienta nueva expuesta sin revisión, dado que ya hay 23 vectores de ataque catalogados en la superficie actual del protocolo

Fuentes

• GitHub - How to build secure and scalable remote MCP servers - https://github.blog/ai-and-ml/generative-ai/how-to-build-secure-and-scalable-remote-mcp-servers/
• Anthropic - Donating the Model Context Protocol and establishing the Agentic AI Foundation - https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
• Arxiv - MCPSHIELD - https://arxiv.org/abs/2604.05969