La adopción de nuevas tecnologías en el ámbito empresarial siempre conlleva una serie de desafíos, sobre todo cuando se trata de protocolos y especificaciones que involucran seguridad y manejo de identidades. En la actualidad, el Model Context Protocol (MCP) ha generado gran expectativa dentro del ecosistema de inteligencia artificial y agentes autónomos, pero también ha dejado en evidencia problemas críticos de seguridad al ser implementado en compañías con infraestructuras complejas. La reciente introducción de la autorización basada en la especificación OAuth 2.1 dentro del protocolo MCP ha creado un escenario en el que, lejos de simplificar, el proceso se vuelve confuso y difícil de adaptar para entornos empresariales. Este análisis ofrece una mirada detallada al caos que representa la especificación de autorización MCP para las empresas y expone alternativas para enfrentar estos obstáculos manteniendo altos estándares de seguridad.
El MCP fue originalmente diseñado para facilitar la comunicación entre agentes inteligentes y sus recursos, prometiendo una interacción fluida y segura. No obstante, esta idealización choca con la realidad de las aplicaciones empresariales cuando se trata de brindar escalabilidad, interoperabilidad y control riguroso sobre el acceso a los datos. Hasta la fecha la mayoría de experimentos en inteligencia artificial con MCP han utilizado el transporte stdio con una relación 1:1 entre cliente y servidor MCP, pero las empresas requieren algo más flexible. Quieren implementar servidores MCP de forma remota y gestionar la autorización para asegurar que solo los propietarios legítimos accedan a sus datos valiosos. Para resolver esta carencia, la especificación MCP incorporó la autorización basada en OAuth 2.
1, lo que implica que ahora las implementaciones deben soportar áreas críticas como PKCE (Proof Key for Code Exchange), registro dinámico del cliente y metadatos del servidor de autorización. A primera vista, podría parecer un paso positivo hacia una seguridad más robusta; sin embargo, este enfoque presenta una serie de inconvenientes que no se ajustan a las mejores prácticas en seguridad corporativa. El principal problema deriva de que la especificación MCP confunde dos roles esenciales en OAuth: el del servidor de recursos y el del servidor de autorización. En el modelo tradicional, estas funciones están claramente separadas para permitir escalabilidad y reducción de la complejidad, pero MCP exige que el servidor asuma ambas responsabilidades. Esta duplicidad genera consecuencias significativas.
Por un lado, el servidor MCP debe convertirse en un componente con estado que gestione tokens, códigos de autorización, registros de clientes y ciclos de vida de credenciales. Esto implica que el servidor debe disponer de bases de datos seguras, mecanismos para validar y revocar tokens, además de gestionar flujos delicados que suelen estar a cargo de servidores dedicados de identidad, como Auth0, Keycloak u Okta. Esta carga extra de responsabilidad no solo dificulta el desarrollo e implementación, sino que afecta directamente la escalabilidad y la resistencia del sistema. Por otra parte, la especificación de MCP obliga a que cada servidor exponga sus propios endpoints /authorize, /token y /register, o bien implemente el protocolo de metadatos para descubrir estos puntos dinámicamente. Esta fragmentación va en contra de la arquitectura común en empresas, donde existe un único proveedor de identidad (IdP) centralizado que se encarga de autenticar y autorizar usuarios.
La dispersión de puntos de autorización multiplica el esfuerzo para los equipos de seguridad y eleva el riesgo de inconsistencias y vulnerabilidades. Dicho de otro modo, el MCP fuerza a que en el ecosistema existan múltiples servidores de autorización aislados, cada uno con su propia gestión de tokens. Esto bloquea el flujo natural de integración con sistemas corporativos, que confían en mantener un control unificado y auditable sobre las credenciales y los accesos. Algunos defensores del MCP argumentan que emitir tokens propios en los servidores MCP ofrece una ventaja al limitar el ámbito de permisos concedidos, lo que significa que si un token de MCP resulta comprometido, el daño se restringe frente al acceso completo que otorga un token original. Aunque resulta una medida de mitigación válida, también complica de manera innecesaria la arquitectura y aumenta la superficie de ataque, además de requerir que los servidores mantengan estados y bases de datos altamente seguras.
Una solución tentativa es delegar la funcionalidad completa al proveedor de identidad de la empresa, es decir, que el servidor MCP se limite a actuar únicamente como un servidor de recursos. En esta modalidad, el servidor no manejaría las credenciales ni emitiría tokens, sino que se apoyaría en un IdP centralizado que expondría sus endpoints reconocidos de OAuth. El servidor MCP simplemente validaría los tokens que llegan y aplicaría políticas de autorización basadas en esos tokens. Esta alternativa es coherente con las mejores prácticas de la industria y facilita la escalabilidad y auditoría, pero la especificación actual de MCP presenta importantes obstáculos para implementarla sin desviarse del estándar. En concreto, el MCP impone que, en caso de utilizar un servidor de autorización externo, el servidor MCP debe mantener un sistema para mapear tokens de terceros a tokens emitidos por el MCP y gestionar sus ciclos de vida.
Esto significa que los servidores seguirían siendo estado-dependientes y responsables de un manejo complejo de credenciales, lo que incrementa la dificultad de cumplimiento, auditoría y operación. Además, las tareas de validación y seguridad anexas, tales como verificar el estado de los tokens originarios, manejar renovaciones y controlar revocaciones, recaen en los servidores MCP, aumentando la carga de infraestructura segura necesaria y la latencia. Esto resulta especialmente problemático en ambientes dedicados a servicios escalables en la nube, donde la preferencia está en servidores sin estado para permitir despliegues rápidos y balanceo eficiente. Por otro lado, la cuestión de cómo el servidor MCP comunica al cliente cuál es el servidor de autorización autorizado para la solicitud es motivo de debate. Una propuesta tecnológica prometedora en la comunidad es utilizar la cabecera HTTP WWW-Authenticate para indicar dinámicamente, al rechazar una solicitud con token inválido o expirado, la dirección URI del servidor de autorización.
Esta técnica permitiría una mayor flexibilidad en la gestión del flujo OAuth sin forzar que cada servidor implemente sus propios endpoints, facilitando la integración. Frente a esta problemática, la comunidad y expertos reconocidos como Christian Posta impulsan la revisión de la especificación MCP para alinear mejor el modelo de autorización con el ecosistema empresarial. La meta es permitir que el protocolo conserve su utilidad para escenarios avanzados de agentes AI, pero sin sacrificar la robustez, escalabilidad y seguridad que requieren las empresas que operan a gran escala. Mientras tanto, las empresas enfrentan un dilema importante. Por un lado, desearían aprovechar las capacidades de MCP para mejorar la interoperabilidad de sus agentes inteligentes y herramientas asociadas; por otro, no pueden comprometer la seguridad ni la operatividad crítica que brinda un sistema de autorización consolidado.
Por ello, la recomendación general es adaptar las implementaciones MCP siguiendo principios sólidos: mantener los servidores MCP como servidores de recursos sin estado, utilizar los sistemas de identidad existentes y emplear proxies o gateways de API para offload de validación o transformación de tokens. La integración de otros estándares complementarios como SPIFFE para autenticación mutua mediante certificado o MTLS ofrece además un nivel adicional de protección entre componentes, esencial para entornos empresariales que requieren trazabilidad y defensa en profundidad. En conclusión, la especificación de autorización MCP, en su estado actual, representa un desafío considerable para la adopción empresarial. Su diseño que fusiona roles típicamente separados genera complejidades técnicas y de seguridad que no se condicen con las mejores prácticas corporativas. Sin embargo, la discusión activa en la comunidad y las propuestas en desarrollo apuntan a una evolución del estándar que garantice compatibilidad con infraestructuras de identidad modernas y robustas.
Hasta entonces, las organizaciones deben evaluar cuidadosamente la arquitectura a implementar, apostando por separar responsabilidades, aprovechar sistemas de identidad centralizados y proteger los recursos a través de mecanismos reconocidos y confiables. El futuro del MCP en el mundo empresarial dependerá en gran medida del éxito en resolver esta encrucijada de seguridad y escalabilidad.
