La ola de lanzamientos de Microsoft Entra de agosto de 2026 entró en su última semana con dos actualizaciones que, en apariencia, no están relacionadas, pero que en realidad comparten un hilo común: ambas destacan cómo la infraestructura de autenticación de Entra ID actúa como factor determinante para el ecosistema más amplio de IA y desarrollo.

La primera es el anuncio de disponibilidad general del Servidor MCP Remoto de Azure DevOps que, a pesar de la etiqueta de GA, incluye una advertencia importante: la implementación de OAuth de Entra ID carece de soporte para los mecanismos de registro de clientes que los asistentes de codificación de IA de terceros necesitan para conectarse. La segunda es la confirmación final del estado de explotación de CVE-2026-69836, la vulnerabilidad de RCE de severidad máxima en Entra ID divulgada a principios de semana.

Esto es lo que cambió, por qué es importante y qué debería hacer su organización al respecto.

1. El Servidor MCP Remoto de Azure DevOps Alcanza GA, pero los Clientes de IA de Terceros No Pueden Conectarse

Publicado: 5 de agosto de 2026 (anuncio de GA); ampliamente reportado del 21 al 23 de agosto de 2026 Estado: Disponibilidad general (con limitaciones significativas)

Microsoft anunció la disponibilidad general del Servidor MCP Remoto de Azure DevOps, que proporciona un endpoint alojado por Microsoft en https://mcp.dev.azure.com/{organization} mediante HTTP streamable. El servidor da a los asistentes de IA acceso a los work items, pull requests, repositorios, wikis y pipelines de Azure DevOps sin que cada desarrollador necesite instalar y operar un servidor MCP local.

El problema: la brecha de OAuth de Entra ID

El anuncio principal de GA oculta una limitación significativa que la propia documentación de Microsoft reconoce: los clientes MCP de terceros (Claude Desktop, Claude Code, ChatGPT y Cursor) no pueden conectarse al servidor remoto porque Microsoft Entra ID aún no admite los mecanismos de registro de clientes OAuth que esos clientes requieren.

El problema se desglosa en dos brechas específicas:

  1. Registro Dinámico de Clientes (DCR): el mecanismo que permitiría a un cliente de terceros registrarse automáticamente ante el servidor de autorización de Entra ID. La especificación MCP del 28 de julio de 2026 dejó obsoleto el DCR, marcándolo para su eliminación después del verano de 2027.

  2. Documentos de Metadatos de ID de Cliente (CIMD): el nuevo mecanismo preferido en la especificación MCP, en el que un cliente publica sus metadatos de registro en una URL conocida. Entra ID tampoco lo admite todavía.

Microsoft afirma que está trabajando con el equipo de Entra para habilitar el soporte, pero no ha publicado un cronograma. El propio blog del equipo de Azure DevOps confirma que la limitación está del lado de Entra.

Qué funciona hoy

Los clientes de primera parte de Microsoft se conectan sin configuración adicional:

  • Visual Studio Code con GitHub Copilot
  • Visual Studio
  • Microsoft Foundry (a través de su catálogo de herramientas)
  • Copilot Studio
  • GitHub Copilot CLI
  • Aplicación GitHub Copilot

Estos clientes utilizan identidades de aplicaciones OAuth previamente registradas que Microsoft ya ha configurado en Entra ID.

Qué no funciona

Los asistentes de codificación de IA de terceros que dependen del auto-registro o del descubrimiento de metadatos no pueden completar el flujo de OAuth contra Entra ID:

  • Claude Desktop y Claude Code (Anthropic)
  • ChatGPT (OpenAI)
  • Cursor

Los desarrolladores que usan estas herramientas deben seguir ejecutando el Servidor MCP de Azure DevOps local, que requiere instalación y mantenimiento en cada máquina de desarrollador y utiliza tokens de acceso personal (PAT) para la autenticación en lugar de Entra ID.

Restricción permanente: solo organizaciones respaldadas por Entra

Más allá de la brecha de autenticación de clientes, el servidor remoto tiene un requisito arquitectónico permanente: la organización de Azure DevOps debe estar respaldada por un tenant de Microsoft Entra. Las organizaciones independientes de Azure DevOps que utilizan cuentas Microsoft para la identidad no son compatibles y no lo serán; Microsoft presenta esto como un requisito de diseño de la arquitectura autenticada por Entra, no como una limitación temporal.

Las organizaciones con tenants independientes de Azure DevOps más antiguos que quieran usar el servidor MCP remoto deben migrar primero a una organización respaldada por Entra.

Por qué esto es importante para los equipos de identidad

Esta situación es notable porque convierte la hoja de ruta de Entra ID en una dependencia directa del ecosistema MCP en general. La especificación MCP se está alejando del Registro Dinámico de Clientes y avanzando hacia los Documentos de Metadatos de ID de Cliente, pero Entra ID no admite ninguno de los dos hoy. Eso significa que:

  • Los flujos de trabajo de desarrollo asistido por IA que utilizan herramientas que no son de Microsoft están bloqueados en la capa de identidad, no en la capa de protocolo
  • La gobernanza empresarial de las herramientas de codificación de IA se vuelve más difícil, no más fácil, cuando el endpoint alojado solo puede atender a clientes de Microsoft
  • La transición de la especificación MCP crea un objetivo en movimiento: para cuando Entra añada soporte de DCR, la especificación podría ya haberlo dejado obsoleto por completo

Para las organizaciones que estandarizan con Claude, ChatGPT o Cursor para el desarrollo asistido por IA, el mensaje es claro: las capacidades de OAuth de Entra ID son el cuello de botella, y no hay un cronograma publicado para una solución.

Qué debería hacer su organización

  1. Si usa las herramientas de IA de primera parte de Microsoft: puede adoptar el servidor MCP remoto de inmediato. Añada la URL del endpoint a la configuración de su cliente y asegúrese de que su organización de Azure DevOps esté respaldada por Entra.

  2. Si usa herramientas de IA de terceros (Claude, ChatGPT, Cursor): continúe usando el Servidor MCP de Azure DevOps local. Planifique una transición cuando Entra ID añada soporte de CIMD, pero no se haga ilusiones: no se ha publicado ningún cronograma.

  3. Si tiene una organización independiente de Azure DevOps: migre a una organización respaldada por Entra si desea usar el servidor MCP remoto en el futuro. Esto es un requisito previo, no una limitación temporal.

  4. Para los administradores de identidad: haga seguimiento de la hoja de ruta de registro de clientes OAuth de Entra ID. Esto es ahora un factor determinante para la interoperabilidad de MCP, y sus desarrolladores preguntarán al respecto cuando intenten conectar sus herramientas de IA.

2. CVE-2026-69836: Estado de Explotación Final Confirmado — No Explotado

Publicado: Divulgación inicial el 20 de agosto de 2026; correcciones de estado el 21 y el 24 de agosto de 2026 Estado: Totalmente mitigado por Microsoft; no explotado en la naturaleza

El 24 de agosto de 2026, Help Net Security publicó una actualización con marca de tiempo que confirma el estado final de explotación de CVE-2026-69836, la vulnerabilidad de ejecución remota de código de severidad máxima (CVSS 10.0) en Microsoft Entra ID que se divulgó el 20 de agosto.

Qué sucedió

La vulnerabilidad, descubierta por Robert Fitzpatrick (Ingeniero Principal de Seguridad de Microsoft), era un problema de deserialización de datos no confiables (CWE-502) en Entra ID que podría haber permitido a un atacante no autenticado ejecutar código a través de la red sin interacción del usuario. Microsoft asignó la puntuación máxima de CVSS 3.1 de 10.0 con el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

El aviso inicial de Microsoft listaba el estado de explotación como “Sí”, lo que generó una atención significativa de la comunidad de seguridad. El 21 de agosto, después de una consulta de The Hacker News, Microsoft corrigió el estado a “No”. El 24 de agosto llegó la confirmación final:

“Cuando Microsoft publicó el aviso de CVE-2026-69836, afirmó que el error había sido explotado. Desde entonces, la compañía cambió el estado de explotación a ’no’ y confirmó a Help Net Security que la vulnerabilidad no fue explotada en la naturaleza.” — Help Net Security, actualizado el 24 de agosto de 2026

El JSON del aviso de MSRC ahora incluye el resumen: “Se corrigió ‘Explotado’ a ‘No’. Esta vulnerabilidad no fue explotada en la naturaleza. Este es solo un cambio informativo.”

Qué significa esto

  • No se requiere ninguna acción del cliente — Microsoft mitigó por completo la vulnerabilidad en el lado del servicio. No hay parche, KB ni cambio de configuración que los clientes deban implementar.
  • No hay evidencia de explotación — A pesar de la etiqueta inicial de “explotado”, la vulnerabilidad nunca fue explotada realmente en la naturaleza. La corrección ahora es final y está confirmada.
  • La iniciativa de transparencia funciona — Microsoft publicó el CVE únicamente por transparencia bajo su iniciativa “Toward Greater Transparency: Unveiling Cloud Service CVEs”. Para los servicios en la nube donde el proveedor aplica parches del lado del servidor, la divulgación tradicional de CVE no aplica, pero Microsoft decidió publicarlo de todos modos.
  • La diligencia debida sigue siendo recomendada — Aunque no hubo explotación, los equipos de seguridad deberían revisar igualmente los registros de inicio de sesión de Entra, los registros de auditoría y las asignaciones de roles privilegiados en busca de anomalías durante la ventana previa a la mitigación, como higiene estándar.

Por qué importa la confusión

La etiqueta inicial de “explotado” generó una cobertura significativa de los medios de seguridad (BleepingComputer, The Register, The Hacker News, CybersecurityNews). La corrección a “no explotado” recibió menos cobertura, lo que crea el riesgo de que las organizaciones que operan con base en los informes iniciales tengan una imagen de amenaza inexacta.

Para las organizaciones que activaron procedimientos de respuesta a incidentes con base en el estado inicial de “explotado”, la confirmación final proporciona un cierre: la vulnerabilidad era real y grave, pero se detectó y corrigió antes de que se produjera cualquier explotación.

El Hilo Común: Entra ID como Guardián de la Plataforma

Lo que conecta estas dos historias es que ambas demuestran cómo las capacidades de Entra ID — o su falta — determinan directamente el acceso al ecosistema en general. La utilidad del Servidor MCP de Azure DevOps para las herramientas de IA de terceros no está limitada por el protocolo MCP ni por la API de Azure DevOps, sino por el soporte de registro de clientes OAuth de Entra ID. El impacto de la vulnerabilidad CVE-2026-69836 no se contuvo con parches de los clientes, sino con la capacidad de Microsoft para mitigar problemas en su propia infraestructura de identidad.

En ambos casos, Entra ID es el guardián. Cuando funciona, todo lo que está aguas abajo funciona. Cuando tiene brechas — ya sea en el registro de clientes OAuth o en la validación de deserialización — los efectos se propagan hacia las herramientas de desarrollo, los agentes de IA y la postura de seguridad empresarial.

Esta es la realidad de la identidad nativa de la nube: el proveedor de identidad no es solo un servicio de autenticación, es una dependencia de la plataforma. Las organizaciones que construyen sobre Entra ID deberían hacer seguimiento no solo de los anuncios de funciones, sino también de las brechas y limitaciones.

Fechas Clave a Seguir

  • 1 de septiembre de 2026: las passkeys se convierten en el método predeterminado en Entra ID; comienza la habilitación automática para los usuarios de SMS/voz
  • 18 de septiembre de 2026: Microsoft publica los detalles de los socios de telecomunicaciones para las organizaciones que necesiten SMS/voz después del retiro
  • 5 de octubre de 2026: comienza la campaña de registro de SSPR (autoservicio de restablecimiento de contraseña)
  • 26 de octubre de 2026: las propiedades de posicionamiento CSS personalizadas se retiran globalmente en la marca de Entra ID
  • 30 de octubre de 2026: se abre la configuración de los socios de telecomunicaciones
  • 3 de noviembre de 2026: el operador de reglas MemberOf se retira en los grupos dinámicos, las unidades administrativas (AUs) y la gestión de derechos
  • 9 de noviembre de 2026: aplicación de SSPR: solo se aceptan métodos registrados explícitamente
  • 1 de febrero de 2027: la autenticación SMS/voz alojada por Microsoft se retira por completo (sin opción de exclusión)

Siga a Kevin en X en https://x.com/kkaminsk para obtener actualizaciones y análisis diarios de Microsoft Entra.