Si llevas un tiempo leyendo este blog, sabes que me gusta correr agentes de IA en mi propio servidor. También sabes que me han quemado los dedos más de una vez: un agente que se escapó por DNS para preguntarle a otro chatbot, otro que pidió acceso a disco completo como si nada, y una colección de créditos API que murieron en batalla. Por eso cuando vi que Microsoft lanzó Microsoft Execution Containers (MXC), una capa de contención para agentes, no lo leí como anuncio corporativo: lo leí como alguien que lleva años armando rejas con lo que tenía a mano.
La idea: el agente no puede ser su propia autoridad de seguridad
Esa frase resume todo el anuncio. En palabras claras: no le pidas por favor que no pase de la raya, dibuja la raya y enciérralo. En MXC declaras en un JSON qué archivos puede tocar el agente, a qué destinos de red puede conectarse y si puede mirar el escritorio. Después el sistema operativo hace cumplir eso, independiente de lo que el modelo decida. Hasta ahí, eso es lo que cualquiera que corre agentes en Linux hace a mano con namespaces, bubblewrap, usuarios dedicados y tokens de solo lectura. La diferencia es que Microsoft lo empaquetó multiplataforma y open source, con backends según la carga: sandbox de proceso para Windows, macOS y Linux; contenedor de sesión con escritorio aislado solo en Windows; WSL para toolchains de Linux; y microVM experimental para lo pesado.
El modo Learning es lo que me convence
Porque lo difícil nunca fue la reja: fue saber adónde ponerla. Si le restringes todo al agente de golpe, se cae a la mitad de la tarea y tú no tienes idea de qué permiso faltaba. MXC trae tres modos: enforcement (bloquea), permissive (permite todo pero anota) y learning (bloquea lo no autorizado y deja un reporte JSON con los recursos que el agente intentó usar). Ese reporte es oro puro. Es exactamente la técnica que uso con los agentes de mi servidor: primero corren en modo observación con credenciales mínimas, después reviso los logs, y recién ahí corto los accesos que no ocuparon. Aquí está formalizado y con reporte automático, y eso mata de raíz la excusa de «no sé qué permisos necesita».
Lo que falta ver
Mi escepticismo habitual sigue en pie. Primero: esto ordena el mundo Windows, donde la mayoría de la gente Trabaja todo con el mismo usuario administrador; en mi caso, la comparación honesta es contra bubblewrap y un usuario dedicado en el VPS, y ahí la ventaja de MXC es la comodidad, no la seguridad. Segundo: que GitHub Copilot, Codex y Replit ya lo soporten está bien, pero la contención en el cliente no arregla el problema del otro lado: un agente con permisos mínimos igual puede hacer daño dentro de su reja si la reja está mal escrita. La política se convierte en el nuevo punto débil, y una política mal escrita es la misma wea que un firewall con el 0.0.0.0/0 en allow. Tercero: la identidad de agente —separar qué hizo el agente de qué hizo el humano— viene después vía Entra, y esa es la parte que de verdad importa cuando tienes diez cron de agentes corriendo en el mismo equipo y necesitas saber cuál la embarró.
Aun así, la dirección es correcta. La industria por fin está aceptando que la pregunta correcta no es si le confías a tu agente, sino cuánta caja necesita para funcionar. Yo llevo años dándole cajas chicas a los míos. Ahora vienen de fábrica.
Fuente: Microsoft Execution Containers: Policy-driven containment for AI agents, del Windows Developer Blog.
Fuente de inspiración: Microsoft Execution Containers: Policy-driven containment for AI agents
