Windows Execution Containers: aislar los agentes autónomos a nivel del SO
El SDK MXC de Microsoft (junio de 2026) traslada la contención de agentes al propio Windows: aislamiento de proceso y de sesión, identidad por agente y política aplicada en ejecución.
¿Qué es esto?
El 2 de junio de 2026, en Build 2026, Microsoft publicó Windows platform security for AI agents, anunciando una versión preliminar temprana del SDK Microsoft Execution Containers (MXC): una capa de ejecución multiplataforma y guiada por políticas para agentes de IA en Windows y WSL. El planteamiento es estructural: en lugar de pedir a cada framework de agente que reinvente su sandbox, MXC hace descender la contención, la identidad y la aplicación de políticas al sistema operativo, donde se aplican de forma coherente en tiempo de ejecución.
Este enfoque responde a un problema que cubrimos desde muchos ángulos: un agente autónomo que lee archivos, invoca herramientas y genera su propio código en ejecución hereda toda la autoridad de la sesión del usuario, salvo que algo la acote activamente. MXC es el intento de Microsoft de convertir esa frontera en una primitiva de primera clase del SO, y no en un añadido acoplado a posteriori sobre cada aplicación.
Cómo funciona
La idea central, que Microsoft llama sandbox componible, se resume en un único modelo de política y un único SDK que se proyectan sobre distintos mecanismos de aislamiento según el riesgo de la carga de trabajo. El desarrollador declara qué restringir, y Windows lo aplica, sin que nadie tenga que programar a mano el aislamiento de bajo nivel. La versión preliminar incluye dos niveles de contención.
El aislamiento de proceso es el nivel ligero. Ejecuta el código generado por el modelo dentro de una frontera de proceso dedicada que restringe el acceso a archivos y dominios de red fuera de la política definida, manteniendo ágil el bucle de desarrollo. GitHub Copilot CLI ya ha adoptado este modo para limitar lo que puede alcanzar su código generado dinámicamente.
El aislamiento de sesión es el nivel reforzado. Separa la ejecución del agente del escritorio interactivo del usuario, el portapapeles, la interfaz y los dispositivos de entrada, mitigando la suplantación de interfaz, la inyección de entradas y la fuga de datos entre sesiones. Un punto clave: las sesiones se ejecutan bajo cuentas de usuario distintas; Windows asigna a cada agente una identidad local o respaldada por Entra y atribuye toda su actividad a esa identidad, de modo que las acciones humanas y las del agente quedan claramente separables y auditables. La política de acceso se aplica a través de Microsoft Entra e Intune, lo que permite a las empresas gobernar las barreras de forma centralizada.
La hoja de ruta extiende el mismo SDK a micro-VM (aislamiento respaldado por el hipervisor para cargas de mayor riesgo o código no confiable, presentado explícitamente como respuesta a investigaciones que muestran que los LLM desarrollan capacidades de evasión de sandbox), a contenedores Linux vía WSL y a Windows 365 for Agents, donde el radio de impacto de un agente comprometido se limita a un Cloud PC desechable. El SDK es público en GitHub.
Por qué importa
La contención es una de las tres patas de la tríada letal: si un agente que ingiere contenido no confiable y puede actuar ha de ser seguro, algo tiene que acotar el significado del verbo «actuar». Históricamente esa tarea recaía en cada framework, de forma desigual, y por eso se repiten los RCE de agentes de código y los fallos de frontera de privilegios. Estandarizar la contención a nivel del SO, con una identidad por agente que hace atribuibles las acciones, es el tipo de cambio estructural que eleva el nivel mínimo para todos, en lugar de parchear un producto cada vez.
Las salvedades son igualmente estructurales. MXC es una versión preliminar temprana, el soporte inicial de sesión es no interactivo y la frontera más robusta —la micro-VM— sigue en la hoja de ruta, no en producción. La propia Microsoft describe el aislamiento de proceso como de robustez moderada; no es un muro de hipervisor. Y la contención a nivel del SO aborda la pata de acción de la tríada, no la de inyección: un agente confinado por una política aún puede ser inducido a usar mal la autoridad que esa política le concede. La nueva detección de inyección de prompts de Windows Defender es un control complementario, no un sustituto de tratar el contenido recuperado como no confiable.
Defensas
Trate MXC como un cimiento sobre el que construir, no como una garantía acabada. Ajuste el nivel de contención a la carga: aislamiento de proceso para agentes de código ágiles, aislamiento de sesión (con su cuenta de usuario distinta y auditabilidad completa) para automatización de larga duración que corre junto a un humano, y prevea aislamiento de micro-VM o Cloud PC cuando un agente procese datos sensibles o ejecute código no confiable. Siempre que sea posible, dé a cada agente su propia identidad y aplique una política de archivos y red de mínimo privilegio a través de Entra e Intune, para que la actividad del agente sea atribuible y revocable con independencia del usuario. Mantenga la defensa en profundidad: combine la contención con controles del lado de la entrada —tratamiento del contenido no confiable, filtrado de salidas y detección de inyección—, porque un agente bien confinado todavía puede ser engañado para desviar sus capacidades autorizadas. Por último, dado que estas funciones viven en compilaciones Insider y versiones preliminares, pruébelas antes de depender de ellas, y no deje que «aplicado por el SO» se convierta en una excusa para conceder a un agente más autoridad de la que necesita.
Estado
MXC se anunció el 2 de junio de 2026 en Build 2026 por Dana Huang y Logan Iyer (Microsoft), con el SDK publicado como versión preliminar temprana en GitHub y el aislamiento de proceso/sesión previsto para compilaciones Windows Insider poco después de Build. Es una contribución defensiva de plataforma, no una divulgación de vulnerabilidad: no hay CVE ni exploit asociado. Entre los socios del ecosistema citados por Microsoft figuran GitHub Copilot CLI (aislamiento de proceso, ya disponible), OpenShell de NVIDIA, OpenClaw, Codex de OpenAI, Manus y Hermes Agent de Nous Research. Léase como señal de que la contención de agentes pasa de la improvisación a nivel de framework hacia una primitiva del SO: una dirección que conviene seguir, y poner a prueba, antes de confiarle nada.