Durante dos décadas firmé qué software podía tocar las máquinas de las que era responsable. El modelo era simple: una app corría con los permisos del usuario, y si se portaba mal, se portaba mal con toda la autoridad que ese usuario tenía. Lo tolerábamos porque las aplicaciones eran mayormente deterministas — podías razonar sobre lo que iban a hacer. Los agentes de IA rompen ese supuesto. Un agente genera código nuevo en cada prompt, lee archivos, llama servicios y encadena operaciones a una velocidad para la que ningún proceso de revisión fue diseñado. Así que la pregunta que Microsoft está respondiendo ahora a nivel del sistema operativo es la misma que me quitó el sueño más de una vez: ¿cómo dejás que un agente haga trabajo útil sin entregarle las llaves completas de la sesión del usuario?
En Build 2026, el 2 de junio, Microsoft presentó Microsoft Execution Containers (MXC) — una capa de ejecución basada en políticas integrada en Windows (y WSL) que permite a developers e IT declarar exactamente qué puede leer, escribir y alcanzar un agente, y después hace cumplir esas restricciones en runtime. El encuadre importa: esto no es un servicio de contenedores en la nube. Es contención empujada hacia adentro del propio sistema operativo, más cerca de cómo un SO móvil regula lo que una app puede hacer que de cómo veníamos haciendo sandboxing de código en un proceso de Python o una VM en la nube.
Qué es MXC realmente
La idea central es la contención como primitiva fundamental. El argumento de Microsoft es que el comportamiento de un agente es dinámico y se genera en runtime, así que los viejos supuestos de seguridad — confiá en el binario, confiá en la sesión del usuario — ya no se sostienen. MXC le da al developer una capa de abstracción sobre los mecanismos de aislamiento subyacentes, de modo que declarás intención (“este agente puede leer estos directorios y alcanzar estos dominios, nada más”) y Windows se encarga de la aplicación de bajo nivel.
Microsoft lo plantea como un “composable sandbox” con un espectro de niveles de contención:
- Process isolation — contención liviana y rápida para correr código generado por el modelo dentro de un límite de proceso dedicado que restringe el acceso a archivos y red. Este es el caso del inner loop del developer, donde no te podés permitir latencia. GitHub Copilot CLI es el primer adoptante, usando process isolation de MXC para restringir lo que su código generado dinámicamente puede ejecutar.
- Session isolation — separa la ejecución del agente del desktop, el clipboard, los dispositivos de entrada y las sesiones activas del humano, corriéndolo bajo una identidad distinta, local o respaldada por Entra. Esto mitiga el UI spoofing, la inyección de input y la fuga de datos entre sesiones, y está pensado para agentes de larga duración trabajando al lado tuyo.
El gancho enterprise es Agent 365, que apila Microsoft Entra (identidad), Intune (políticas de dispositivo), Defender (protección contra amenazas) y Purview (gobernanza de datos) sobre MXC — agendado para preview en julio. Eso es lo que le permite a IT gestionar la contención de agentes de forma centralizada a lo largo de una flota, en lugar de confiar en que cada developer la configure correctamente.
Dónde esto es un beneficio real — si funciona como está definido
Quiero ser preciso con ese condicional, porque el propio repositorio de MXC en GitHub advierte que los profiles actuales todavía no deberían tratarse como límites de seguridad. Esto es software en early preview. Así que todo lo que sigue es la promesa, no todavía el producto probado. Con esa salvedad dicha de frente, acá es donde una contención de este tipo cambia genuinamente el cálculo:
- Agentes de codeo sobre repos reales. Dejás que un agente refactorice un servicio o expanda la cobertura de tests, pero su proceso solo puede tocar el directorio del proyecto y alcanzar tu registry de paquetes — no tus claves SSH, no tu
.envcon credenciales de producción, no dominios de salida arbitrarios. Si un prompt injection intenta que el agente exfiltre un secreto, la política es lo que dice que no, sin importar lo que el modelo “decidió” hacer. - Automatización de larga duración al lado del usuario. Un agente de procesamiento de datos corre durante horas bajo su propia identidad de sesión, aislado de tu desktop interactivo. No puede leer tu clipboard, no puede inyectar pulsaciones de teclado en tus apps abiertas, y cada acción que toma queda atribuida a su identidad en el log de auditoría — así que cuando algo sale mal, podés distinguir la actividad del agente de la del humano. Para cualquiera que alguna vez intentó reconstruir la línea de tiempo de un incidente, esa atribución por sí sola vale muchísimo.
- Gobernanza de flota. A través de Entra e Intune, IT define un único sobre de políticas — “los agentes del grupo de finanzas no pueden alcanzar internet” — y se hace cumplir en cada máquina, de forma centralizada, en lugar de vivir en archivos de config dispersos. Esta es la parte que, en mis años de CIO, habría sido la diferencia entre “permitimos agentes” y “prohibimos agentes porque no los podemos controlar”.
- Contención de agentes de terceros y open source. Microsoft está usando OpenClaw, un framework de agentes open source, como banco de pruebas: la lógica es que si un agente totalmente abierto puede contenerse dentro de los límites de MXC, la contención es lo bastante robusta para cualquier cosa. La compañía también dice que el descubrimiento y la gestión de agentes locales se está expandiendo a GitHub Copilot CLI y Claude Code.
La parte que vale la pena leer dos veces
Lo que distingue esto del típico anuncio de plataforma aspiracional es la lista de partners. Microsoft nombró cinco compañías que ya están construyendo sobre MXC: OpenAI (explorando patrones para que los agentes generen y corran código de forma segura), NVIDIA (trayendo su framework de agentes OpenShell a Windows sobre MXC), Manus, Nous Research (creador del agente Hermes) y el proyecto OpenClaw. Tao Zhang, Chief Product Officer de Manus, describió MXC como una forma basada en políticas de definir y hacer cumplir los límites de acceso de un agente en runtime. Dillon Rolnick, CEO de Nous Research, lo puso de la manera más concisa: los agentes locales de ejecución continua necesitan aislamiento intencional, y los developers necesitan confiar en que esos controles van a sostenerse.
Que OpenAI y NVIDIA — competidores en las capas de modelo y silicio — estén construyendo sobre un plano de contención de Microsoft te dice lo que Microsoft realmente está haciendo. No está tratando de ganar el agente. Está tratando de ser la capa de confianza debajo del agente de todos. Vale la pena notarlo al pasar: Manus es una startup de origen chino, lo que hace de su presencia en una primitiva de seguridad enterprise de Microsoft su propia pequeña señal de lo borderless que se volvió el ecosistema de agentes.
Y acá está la tensión estratégica con la que querría que todo líder técnico se siente un rato. El sandbox del navegador nunca fue caridad — fue la precondición para correr código web no confiable a escala global. Los permisos móviles hicieron viables las app stores. La contención de agentes puede ser el trato equivalente para la automatización con IA. Pero la preocupación es el lock-in disfrazado de seguridad: si los agentes mejor gobernados son los que corren sobre el SDK de Microsoft, las identidades de Microsoft, el plano de políticas de Microsoft y las Cloud PCs de Microsoft, las empresas ya estandarizadas en Microsoft 365 e Intune pueden encontrarse empujadas hacia un stack de agentes integrado verticalmente — y las que no lo están van a estar haciéndose preguntas difíciles sobre interfaces abiertas y paridad de terceros.
Mi lectura: la primitiva es la idea correcta. La contención debería vivir en el SO — ahí es donde es exigible y donde sobrevive al propio agente siendo comprometido. Lo que hay que vigilar no es si MXC funciona. Es si la capa de gobernanza se mantiene lo bastante abierta como para que “seguro” y “solo-Microsoft” no se vuelvan calladamente la misma palabra. Por ahora es early preview, los límites de seguridad están explícitamente no garantizados, y la prueba real llega cuando alguien corra una flota de estos en una red de producción. Pero la dirección está fijada, y es la correcta.