En pocas palabras: El 18 de junio de 2026, el Model Context Protocol declaró estable Enterprise-Managed Authorization (EMA): el empleado se loguea una sola vez con el identity provider corporativo y accede a todos los servidores MCP, sin autorizar cada uno. Ya la usan Anthropic, Microsoft y Okta.
El 18 de junio de 2026 el equipo del Model Context Protocol declaró estable la extensión Enterprise-Managed Authorization (EMA), la pieza que habilita autenticación centralizada MCP: un empleado inicia sesión una sola vez con el identity provider de la empresa y queda conectado a todos los servidores MCP que necesita, sin autorizar cada uno por separado. Ya la adoptan Anthropic, Microsoft y Okta.
La autenticación centralizada MCP (Enterprise-Managed Authorization) es una extensión del Model Context Protocol que permite a una organización gestionar el acceso a sus servidores MCP desde un único identity provider corporativo (vía OIDC). En lugar de que cada usuario autorice cada servidor de forma individual, la empresa define la política una vez y los usuarios heredan el acceso al loguearse. La desarrolla la comunidad del MCP, el protocolo abierto creado por Anthropic.
En 30 segundos
- Qué pasó: la extensión Enterprise-Managed Authorization del MCP pasó a estado estable el 18 de junio de 2026.
- Qué resuelve: elimina los prompts de consentimiento repetidos al conectar servidores MCP en entornos empresariales.
- Cómo funciona: un solo login con el identity provider (Okta) conecta todos los servidores autorizados, sin OAuth por app.
- Quién la usa: Anthropic, Microsoft y Okta, más un número creciente de servidores MCP.
- Para quién importa: equipos de seguridad que necesitan política consistente y un audit trail unificado.
¿Cuál es el problema que resuelve Enterprise-Managed Authorization?
Ponele que sos parte de un equipo de 200 personas y la empresa quiere que todos usen cinco servidores MCP: uno para el CRM, otro para el repositorio de código, otro para los tickets, otro para la base de datos interna y otro para el calendario. Con el modelo viejo, cada una de esas 200 personas tiene que autorizar cada uno de esos cinco servidores. A mano. Uno por uno.
Hacé la cuenta: son mil autorizaciones manuales para algo que debería ser una decisión de la empresa, no de cada empleado. Lo explicamos a fondo en nuestra guía sobre seguridad empresarial.
El anuncio oficial es directo sobre el dolor: “la autorización y los prompts de consentimiento repetidos de los servidores MCP conectados son uno de los mayores puntos de fricción a la hora de gestionar la conectividad en entornos empresariales”. Y lo dividen en dos problemas concretos:
- Cada empleado autoriza cada servidor por su cuenta: conectás servicio tras servicio, en un proceso manual que no escala cuando hay decenas de servidores y cientos de personas.
- Los equipos de seguridad no pueden imponer una política consistente: el acceso termina siendo lo que cada usuario autorizó, sin control central ni un registro de auditoría unificado.
Ese segundo punto es el que de verdad preocupa a un CISO. Si no hay control central, nadie puede responder con certeza quién tiene acceso a qué. Y en una auditoría, “no sé” no es una respuesta que zafe.
¿Qué es el Model Context Protocol y por qué importa acá?
El Model Context Protocol (MCP) es un protocolo abierto, impulsado por Anthropic, para conectar asistentes de IA con herramientas y fuentes de datos externas. Un “servidor MCP” es básicamente un conector: expone una herramienta (tu CRM, tu base de datos, tu sistema de tickets) de forma que un modelo como Claude pueda usarla de manera estandarizada.
El tema es que cuando empezás a sumar servidores MCP en una organización, el modelo de seguridad original se queda corto. Según el anuncio, ese modelo “fue diseñado para tener alcance por usuario y atado a las convenciones de autenticación interactiva tradicional”. Funciona bien cuando vos, como individuo, decidís qué toca tus datos. Para una flota de servidores repartidos en una arquitectura empresarial, no. Complementá la lectura en nuestra guía de ChatGPT.
¿Cómo funciona el Zero-Touch OAuth en MCP?
La idea central es “autorizá una vez, heredá en todos lados”. La empresa controla el acceso a los servidores MCP desde su identity provider de confianza, ese mismo que ya usás para entrar al mail corporativo o a las apps internas vía single sign-on.
¿Y qué ve el empleado? Casi nada, y eso es justo el punto. En el primer login, los servidores MCP que necesita ya quedan conectados. Sin OAuth por aplicación. Sin configurar nada como paso aparte. Eso es lo que llaman “zero-touch”: el usuario no toca nada, la conexión está hecha cuando llega.
Por dentro, la autorización se apoya en el identity provider corporativo (los flujos basados en OIDC son el estándar acá). La empresa define qué grupos acceden a qué servidores, y cuando el usuario se autentica una vez, ese login arrastra el acceso a todo lo que su rol tiene habilitado. La política vive en un solo lugar, no desperdigada en mil consentimientos individuales.
¿Qué empresas están detrás de esta autorización centralizada?
Según el anuncio oficial del MCP, la extensión “está siendo adoptada por Anthropic, Microsoft, Okta y un número creciente de servidores MCP”. Cada nombre pesa por un motivo distinto.
- Anthropic: es quien creó el MCP y desarrolla Claude. Que empuje el estándar de auth empresarial era esperable, porque sus clientes corporativos son los que más sienten la fricción.
- Microsoft: sumó soporte para EMA en Visual Studio Code, directamente en el IDE. Que un cliente tan usado adopte el estándar muestra que el flujo ya está llegando a las herramientas donde la gente realmente trabaja.
- Okta: es uno de los identity providers más usados para single sign-on. Su adopción confirma que el flujo OIDC del lado del IdP funciona en la práctica, no solo en el spec.
Que un creador de modelos, un gigante de plataforma y un especialista en identidad estén alineados en el mismo estándar es la señal más fuerte de que esto no es un experimento. Es la base sobre la que se va a construir la conectividad MCP en empresas. Ya lo cubrimos antes en en nuestro análisis de modelos de lenguaje.
¿Cuáles son los beneficios reales para equipos grandes?
Volvamos al ejemplo de las 200 personas y los 5 servidores. Con autorización centralizada MCP, esas mil autorizaciones manuales se convierten en una sola configuración del lado de la empresa. La diferencia no es cosmética, es de orden de magnitud.
- Menos fricción de onboarding: una persona nueva entra, se loguea y ya tiene sus servidores MCP conectados. Cero pasos de “ahora andá autorizando uno por uno”.
- Seguridad consistente: el acceso lo define el identity provider, no el criterio de cada usuario. Si alguien deja la empresa y se desactiva su cuenta en el IdP, pierde el acceso a todo de una.
- Audit trail unificado: hay un registro central de quién accede a qué, que es exactamente lo que pedía el equipo de seguridad y que el modelo viejo no podía dar.
- Menos carga administrativa: los servidores se gestionan como política, no como una pila de tickets de soporte para resetear consentimientos.
Diferencia entre autenticación per-user y autorización centralizada
Acá conviene verlo lado a lado. La cuenta es simple: con N usuarios y M servidores, el modelo per-user te pide hasta N por M autorizaciones; el centralizado, una sola configuración.
| Dimensión | Autenticación per-user (modelo tradicional) | Autorización centralizada (EMA) |
|---|---|---|
| Quién autoriza | Cada empleado, servidor por servidor | La empresa, una vez, desde el IdP |
| Cantidad de pasos | Hasta N usuarios × M servidores | 1 configuración centralizada |
| Control de seguridad | Lo que cada usuario haya autorizado | Política consistente impuesta por seguridad |
| Audit trail | Fragmentado, sin vista unificada | Registro central completo |
| Onboarding | Manual, repetido por cada servicio | Zero-touch en el primer login |
| Mejor para | Escenarios de consumidor individual | Despliegues empresariales |
Ojo con una cosa: el modelo per-user no está “mal”. Para un usuario individual que decide qué toca sus datos personales, está perfecto. El propio anuncio lo aclara. El problema aparece cuando intentás estirar ese diseño de consumidor a una empresa de cientos de personas. Ahí no escala.
Requisitos técnicos para implementar Enterprise-Managed Authorization
Si querés llevar esto a tu organización, lo que vas a necesitar se arma en pocos bloques. No hay magia, pero sí hay que tener el terreno preparado. Esto se conecta con lo que analizamos en según cubrimos sobre OAuth en Google.
- Un identity provider compatible con OIDC: Okta es el identity provider soportado confirmado hasta ahora. Si ya usás single sign-on corporativo, probablemente ya tengas la base.
- Servidores MCP que soporten la extensión: el spec ya es estable, pero cada servidor tiene que implementar EMA. El anuncio habla de un número creciente, así que vale verificar servidor por servidor.
- Integración con el directorio corporativo: los grupos y roles del IdP son los que van a definir quién accede a qué. Sin eso ordenado, la política central no tiene de dónde agarrarse.
- Una etapa de testing y rollout: probar con un grupo chico antes de abrir a toda la empresa. Si corrés esto sobre infraestructura propia, conviene tener el hosting y los dominios bien gestionados; para proyectos en Argentina, donweb.com cubre esa parte.
Errores comunes al adoptar autenticación centralizada MCP
- Pensar que reemplaza al identity provider: no. EMA se apoya en tu IdP existente, no lo sustituye. Si tu identity provider está mal configurado, el problema se hereda hacia abajo.
- Migrar todos los servidores de golpe: abrir el acceso centralizado a 200 personas y 10 servidores el primer día es pedir un dolor de cabeza. Arrancá con un grupo piloto y un par de servidores, medí, y después escalá.
- Descuidar el mapeo de roles: si todos los empleados terminan en un mismo grupo con acceso a todo, perdés la mitad del beneficio de seguridad. La gracia es que el acceso refleje el rol real de cada persona.
- Asumir que cualquier servidor MCP ya lo soporta: la extensión es estable, pero la adopción por servidor es gradual. Verificá compatibilidad antes de prometer el flujo zero-touch al equipo.
Preguntas Frecuentes
¿Qué es Enterprise-Managed Authorization para MCP?
Es una extensión del Model Context Protocol, estable desde el 18 de junio de 2026, que permite a una organización gestionar de forma centralizada el acceso a sus servidores MCP desde un único identity provider. Los empleados se conectan a todos los servidores autorizados con un solo login, sin OAuth por aplicación.
¿Cuál es la diferencia entre OAuth tradicional y centralizado?
En el modelo tradicional cada usuario autoriza cada servidor por separado, lo que genera hasta N usuarios por M servidores autorizaciones manuales. En el centralizado, la empresa define la política una sola vez en su identity provider y los usuarios heredan el acceso al loguearse, con audit trail unificado.
¿Quién está usando MCP con autenticación centralizada?
Anthropic, Microsoft y Okta adoptaron la extensión Enterprise-Managed Authorization, junto a un número creciente de servidores MCP. Anthropic creó el protocolo, Microsoft sumó soporte para EMA en Visual Studio Code y Okta es uno de los identity providers más usados para single sign-on.
¿Cómo implemento Zero-Touch OAuth en mi empresa?
Necesitás un identity provider compatible con OIDC (como Okta), servidores MCP que soporten la extensión EMA, y la integración con tu directorio corporativo para mapear grupos y roles. Conviene empezar con un grupo piloto y pocos servidores antes de abrirlo a toda la organización.
¿Por qué Anthropic y Microsoft adoptan esta tecnología?
Porque sus clientes empresariales son los que más sufren la fricción de autorizar servidor por servidor y la falta de control central. Anthropic, como creador del MCP, necesita que el protocolo escale en empresas, y Microsoft sumó soporte para EMA en Visual Studio Code, llevándolo directamente al IDE.
Conclusión
Lo que cambió el 18 de junio de 2026 es concreto: la autorización empresarial del MCP dejó de ser una promesa y pasó a estado estable, con tres pesos pesados (Anthropic, Microsoft y Okta) ya arriba. El cuello de botella que frenaba la adopción de servidores MCP en empresas, esos mil consentimientos manuales y la falta de control central, tiene ahora una respuesta de estándar.
¿Qué hacer si esto te toca? Si tu organización ya usa single sign-on con Okta, andá revisando qué servidores MCP soportan la extensión y planificá un piloto chico. La fricción que hoy frena el despliegue de IA con herramientas internas es justo la que esto ataca. Y cuanto antes ordenes los roles en tu IdP, más limpio te va a salir el rollout.