Microsoft ha anunciado en Build 2026 los Microsoft Execution Containers (MXC): una capa de ejecución para encerrar agentes de IA en Windows y WSL, con políticas que limitan qué pueden tocar. Suena a respuesta sensata al caos de agentes autónomos que borran carpetas, instalan cosas raras o acceden a datos que no deberían. Pero yo no me trago el titular tan rápido.
El problema no es que la idea sea mala. El problema es quién la vende, cómo la empaqueta y qué partes del discurso dejan fuera. Porque si llevas años montando webs, gestionando hosting y viendo cómo las pymes adoptan herramientas sin leer la letra pequeña, este tipo de anuncios te suena familiar: prometen control sin explicarte el coste real de implementarlo.
La noticia concreta es esta: en junio de 2026 Microsoft presenta MXC como SDK en preview, integrado con Agent 365, Defender, Entra, Intune y Purview. Los agentes locales —OpenClaw, GitHub Copilot CLI, Claude Code y compañía— podrían ejecutarse dentro de contenedores con políticas definidas por el desarrollador y aplicadas por el sistema operativo. Requiere virtualización (VBS y SLAT), llegará primero a Windows 11 24H2 Enterprise y Pro, y la integración completa con la pila de seguridad de Microsoft está prevista para julio en preview.
En papel, bien. En la práctica, varias cosas me chirrían.
El contenedor no arregla la intención del agente
MXC limita el alcance de lo que un agente puede hacer a nivel de sistema: archivos, procesos, red. Eso ayuda contra el escenario clásico de «el bot ha borrado mi proyecto» o «ha intentado instalar un paquete malicioso». Pero no resuelve el problema de fondo: el modelo sigue decidiendo qué hacer dentro de los límites que le dejes. Si le das acceso a tu carpeta de facturas y permiso de escritura en el CRM, el contenedor no te salva de que el agente envíe un email equivocado a un cliente con tono pasivo-agresivo o clasifique mal un lead.
En mi experiencia, la mayoría de desastres con IA en entornos de pyme no vienen de exploits técnicos sofisticados. Vienen de permisos demasiado amplios y de confiar en la salida del modelo como si fuera un compañero senior que nunca se equivoca. MXC no corrige eso; solo acota el radio de la explosión.
Políticas definidas por el desarrollador… en un ecosistema que va a toda prisa
Microsoft dice que los desarrolladores definen qué restringir y Windows aplica eso en runtime. Traducción: la seguridad depende de que cada proveedor de agente configure bien sus contenedores. ¿Cuántos plugins de WordPress has visto con permisos excesivos? ¿Cuántas integraciones SaaS piden acceso a todo «por si acaso»? El patrón se repite. Cuando la carrera es sacar agentes autónomos antes que la competencia, la configuración conservadora suele perder contra la demo que impresiona al inversor.
Además, la promesa de anotar funciones con capacidades MXC en el Copilot Runtime SDK para generar políticas en build time suena elegante, pero estamos en preview. Las empresas que más necesitan esto —pymes sin equipo de seguridad— son las que menos van a dedicar tiempo a calibrar políticas granulares.
Vendor lock-in disfrazado de plataforma segura
No me malinterpretes: tener aislamiento a nivel de SO es mejor que ejecutar agentes con permisos de administrador en un portátil de comercial. Pero MXC vive dentro del ecosistema Microsoft. Agent 365, Defender, Entra, Intune, Purview. Si ya estás en ese stack, encaja. Si no, te quedas con la sensación de que la «seguridad para agentes» es otro argumento más para migrar todo a Windows Enterprise y suscripciones.
Cloud Native Now resume bien el timing: las empresas quieren agentes locales por privacidad y latencia, pero les preocupa perder control. Microsoft entra ahí con una narrativa de confianza. Lo que no te cuentan en el keynote es cuánto cuesta alinear MXC con tu infraestructura actual si no eres una corporación con CISO y presupuesto de compliance.
La paradoja de Claude Fable 5 en la misma semana
Mientras Microsoft vende jaulas para agentes, Anthropic lanza Claude Fable 5: un modelo orientado a tareas largas y autónomas, disponible en Foundry y otras plataformas, con capacidades de nivel Mythos y salvaguardas configurables. Es decir, el mercado empuja en dos direcciones a la vez: más autonomía y más contención. Las empresas quieren que el agente haga el trabajo de un junior durante horas, pero también quieren que no toque nada fuera de su sandbox.
Esa tensión no la resuelve un SDK de contenedores. La resuelve (mal o bien) tu política interna: qué delegas, quién revisa, qué queda prohibido aunque el modelo «pueda» hacerlo. Y ahí la mayoría de equipos que conozco siguen improvisando.
Qué haría yo si gestionas webs o proyectos tech
Primero, separa agentes de producción de agentes de prueba. Nada de dar acceso al servidor de un cliente para «probar Copilot». Segundo, exige registro de acciones: qué archivos tocó, qué APIs llamó, qué cambios propuso. Tercero, no confundas contenedor con auditoría. Puedes encerrar al agente y aun así no saber por qué tomó una decisión. Cuarto, si estás en Windows Enterprise y ya usas Intune/Defender, sí merece la pena seguir el preview de MXC; si no, no compres el stack entero solo por esto.
MXC puede ser una pieza útil. Pero presentarlo como la respuesta definitiva al riesgo de los agentes autónomos es vender la cerradura sin mencionar que la ventana sigue abierta si tú se la dejas.
Si mañana un agente con acceso a tu WordPress pudiera actualizar plugins, limpiar caché y responder tickets dentro de un contenedor Microsoft, pero sin registro detallado de cada cambio, ¿le darías permiso en producción o lo dejarías en un staging aislado aunque el demo impresione a dirección?