Edición en Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Cómo configurar una política MXC para comandos generados por agentes

> El SDK MXC de Microsoft permite a los desarrolladores declarar un comando y sus políticas de archivos y red. Esta guía, basada únicamente en documentación, muestra cómo crearla con Node V1, los modos de diagnóstico y los límites de los backends.

By BIG CHANGE Editorial

Published: 2026-10-08T05:14:55.341Z
Updated: 2026-10-08T05:14:55.341Z
Canonical: https://bigchange.ai/blog/mxc-agent-command-containment-guide

![Conceptual charcoal illustration of a small computer with an external drive connected and a network cable lying unplugged beside its port.](https://bigchange.ai/api/media/file/mxc-explicit-connections-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no MXC product interface, hardware, security test or enforcement result is depicted.

Microsoft anunció la disponibilidad general de Microsoft Execution Containers (MXC) el 7 de octubre de 2026. Para los equipos que ejecutan comandos propuestos por un agente de IA, la pregunta práctica es a qué archivos y conexiones de red necesita acceder el comando, y qué backend de MXC puede imponer esos límites. La [publicación de lanzamiento](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) describe el objetivo de contención; la [documentación para usuarios del repositorio](https://github.com/microsoft/mxc) ofrece los detalles de configuración. Esta guía sigue esos documentos. BIG CHANGE no instaló MXC ni ejecutó ninguna carga de trabajo dentro de un entorno contenido.

## El gran cambio

- **Qué cambió:**  Los desarrolladores pueden pasar un comando y su política de recursos a una única interfaz del SDK MXC, que selecciona un backend de host compatible. El lanzamiento del 7 de octubre convierte esta integración documentada en una opción para herramientas de agentes, en lugar de confiar en que un modelo obedezca voluntariamente una política.
- **Por qué importa:**  Un equipo puede permitir que un comando de programación acceda a su directorio de trabajo y, al mismo tiempo, dejar fuera de su alcance otros archivos y conexiones salientes. El resultado depende del backend y del host elegidos, así que el equipo debe comprobar la aplicación efectiva del backend antes de confiar en una restricción.
- **Qué conviene observar:**  Los modos de configuración de políticas de Microsoft ayudan a diagnosticar operaciones bloqueadas en hosts Windows ProcessContainer compatibles. La siguiente decisión práctica es si cada permiso propuesto resulta necesario y si, una vez ajustada la política, la ejecución de producción usa el modo de aplicación.

## Empieza por el host y el comando

MXC es una biblioteca integrada en la aplicación que inicia la carga de trabajo. Su [archivo README](https://github.com/microsoft/mxc) enumera los SDK de Rust, .NET y Node, además de ejecutables nativos para aplicaciones que no pueden integrar un SDK. El paquete de Node incluye recursos nativos de tiempo de ejecución y requiere Node.js 24 o posterior; en Windows, el repositorio especifica Node 24.21.0 o posterior, o 26.8.0 o posterior, para la transferencia nativa por stdio. La API pública se importa desde `@microsoft/mxc-sdk/v1`, no desde la raíz del paquete. El paquete de .NET también incluye recursos nativos. La biblioteca de Rust compila el SDK, el motor y los backends elegidos dentro de la aplicación que la consume. Los ejecutables nativos requieren una compilación del repositorio para la plataforma correspondiente.

Elige el backend antes de redactar una política. El repositorio indica que `processcontainer` es el predeterminado en Windows 11, `bubblewrap` es el predeterminado en Linux y `seatbelt` es el predeterminado en macOS. Windows también ofrece `wslc` y `isolation_session`; `windows_sandbox`, `microvm` y `hyperlight` figuran como experimentales. Linux requiere el entorno de ejecución seleccionado, como Bubblewrap para su backend predeterminado. La [tabla de versiones de Windows](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) indica las compilaciones mínimas para ProcessContainer e IsolationSession. Hay que validar en la máquina que ejecutará el trabajo tanto la disponibilidad del host como la compatibilidad con la política solicitada.

Anota el comando concreto, el directorio de trabajo, los archivos que debe leer, los que debe modificar y los destinos de red que necesita. Trata esos datos como entradas de política proporcionadas por la aplicación o por el operador. Microsoft afirma que la política se sitúa fuera de la carga de trabajo del agente, de modo que el código generado no puede ampliar sus propios permisos. La salida prevista del comando incluye stdout, stderr y el código de salida habituales, además de advertencias o metadatos opcionales del SDK. Solo se ofrece un informe de actividad en los modos de diagnóstico documentados y en hosts Windows ProcessContainer compatibles.

## Declara una política pequeña con el SDK de Node

La guía del SDK de [Node](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) documenta esta estructura V1. Instala el SDK en una aplicación que use una versión de Node compatible:

```bash
npm install @microsoft/mxc-sdk
```

Este ejemplo adapta la muestra de ejecución hasta completar de Microsoft y solicita acceso de solo lectura al directorio actual de la aplicación, a la vez que deniega las conexiones salientes. El comando solo imprime una línea, así que no prueba ninguna de las dos restricciones. Es un punto de partida documentado, no una prueba de BIG CHANGE. Sustituye el comando y las rutas por la carga de trabajo que quieras contener; usa `readwritePaths` únicamente para los directorios que deba modificar.

```typescript
import { getPlatformSupport, run } from '@microsoft/mxc-sdk/v1';
import type { ContainerRequest } from '@microsoft/mxc-sdk/v1';

if (!getPlatformSupport().isSupported) {
  throw new Error('MXC is not available on this host');
}

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  filesystem: { readonlyPaths: [process.cwd()] },
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const result = await run(request);
console.log(result.stdout, result.stderr, result.exitCode, result.warnings);
```

`run` devuelve stdout y stderr capturados, el código de salida, el estado de tiempo agotado y las advertencias. Para la carga de trabajo, un acceso a archivos bloqueado puede parecer un error corriente de acceso denegado; una salida correcta no demuestra por sí sola que se hayan probado todas las restricciones previstas. Para cumplir el criterio de éxito del encargo, ejecuta una carga de trabajo de confianza que use un recurso permitido y, por separado, una prueba deliberada de acceso a un recurso sin permiso en el backend compatible elegido. Comprueba la operación y los diagnósticos antes de aplicar la política a comandos generados por agentes. Las [muestras del SDK](https://github.com/microsoft/mxc/blob/main/samples/README.md) incluyen permisos de archivos, bloqueo de red, captura de salida y registro de denegaciones. Requieren un host preparado. BIG CHANGE no ejecutó ninguno de esos pasos.

Para quienes usan el ejecutor nativo, el [esquema JSON estable](https://github.com/microsoft/mxc/blob/main/docs/schema.md) es `1.0.0`, y una solicitud completa necesita un `version`, una selección de contención y `process.commandLine`. El esquema de desarrollo actual es `1.1.0-alpha`. El SDK V1 elige por sí mismo el contrato de transmisión, así que no incluyas una versión del esquema nativo en el `ContainerRequest`. La guía del esquema también indica que campos antiguos como `network.defaultPolicy` y `allowedHosts` ya están retirados. La política actual usa `network.egress` y `network.ingress`; las reglas directas y un proxy de tiempo de ejecución se comportan de forma distinta y tienen diferente compatibilidad entre backends.

## Diagnostica las denegaciones y luego aplica la política

La [tabla de modos del 7 de octubre](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) de Microsoft distingue tres resultados. El modo de **aplicación** bloquea el acceso no concedido y no produce un informe de actividad. El modo de **aprendizaje** bloquea el acceso y registra los intentos no concedidos. El modo **permisivo** registra el acceso que la política habría denegado, pero permite que continúe. La [referencia para capturar denegaciones](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) de Microsoft limita esas funciones de aprendizaje a las rutas ProcessContainer basadas en AppContainer de Windows. Otros hosts no obtienen informes equivalentes solo por aceptar un campo de política común.

Para una herramienta de confianza durante la configuración de políticas, el ejecutor nativo de Windows admite un flujo `--audit` que puede generar artefactos de política. Microsoft advierte que desactiva la seguridad del entorno aislado para la carga de trabajo analizada, por lo que no es apto para comandos no confiables. Una captura que deniega y registra es una vía de diagnóstico más segura cuando el host la admite: el acceso intentado sigue bloqueado y el informe señala qué se denegó. Revisa cada ruta o capacidad registrada frente a la tarea, concede solo lo que el comando necesita y ejecuta la carga de trabajo final en modo de aplicación. Los informes pueden revelar nombres de recursos confidenciales; trátalos con el cuidado correspondiente.

La elección del backend determina qué garantías puede ofrecer la política. La [guía del esquema](https://github.com/microsoft/mxc/blob/main/docs/schema.md) indica que `isolation_session` no puede restringir la red y requiere una configuración de red explícitamente no restringida. También indica que Windows ProcessContainer y macOS Seatbelt aplican las restricciones de interfaz; otros backends no las implementan, y WSLC e IsolationSession rechazan las políticas de interfaz suministradas. La [guía de Seatbelt](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) explica que el perfil nativo de macOS no puede filtrar hosts remotos concretos, y la [guía de Bubblewrap](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) describe los requisitos de red y del entorno de ejecución en Linux. Por tanto, que un campo JSON sea aceptado por varios tipos de SDK no demuestra que se aplique igual en todos ellos. Comprueba la guía del backend elegido y valida la solicitud en el host de destino.

El repositorio de Microsoft tiene licencia MIT, pero la documentación para usuarios no indica un precio del paquete MXC. El host, la computación y cualquier proveedor de modelos tienen sus propios costes. El anuncio de Windows califica MXC como disponible de forma general, mientras que varias opciones de backend siguen siendo experimentales y el esquema nativo de desarrollo está en fase alfa. Ten en cuenta por separado esas etapas de lanzamiento al decidir dónde ejecutar una carga de trabajo.

## Fuentes y lecturas adicionales

- [Blog para desarrolladores de Windows de Microsoft, 7 de octubre de 2026](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) establece la afirmación del lanzamiento, el uso previsto con agentes y las definiciones de los tres modos. Es la descripción del producto de Microsoft, no una prueba de seguridad de BIG CHANGE.
- [README del repositorio MXC](https://github.com/microsoft/mxc) enumera los SDK, los backends predeterminados de cada host, los backends experimentales, los requisitos de compilación y la vía del ejecutor nativo. El contenido cambia junto con el repositorio; los detalles se comprobaron el 8 de octubre de 2026.
- [Guía para usuarios del SDK de Node](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) especifica los requisitos de Node, la importación V1, la solicitud tipada y la salida capturada. El código anterior adapta su ejemplo; no se ejecutó aquí.
- [Guía del esquema de configuración](https://github.com/microsoft/mxc/blob/main/docs/schema.md) distingue el JSON nativo estable `1.0.0` del `1.1.0-alpha` mutable, y documenta los campos de política y sus límites específicos por backend.
- [Referencia del modo de aprendizaje y la captura de denegaciones](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) documenta los diagnósticos de Windows ProcessContainer y advierte sobre la auditoría permisiva. Sus informes dependen del host y del modo.
- [Guías de backend](https://github.com/microsoft/mxc/tree/main/docs/backends) y la [tabla de versiones de Windows](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) son las referencias que deben consultarse para cada host; este artículo no certifica ninguna configuración en el equipo de los lectores.

## Sources

- [Lanzamiento de Microsoft Execution Containers](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) — Anuncio de disponibilidad general, límites de la carga de trabajo y los recursos, y definiciones de los tres modos; las afirmaciones del proveedor no son pruebas independientes.
- [README del repositorio MXC](https://github.com/microsoft/mxc) — SDK, backends predeterminados, etiquetas de backends experimentales, vía del ejecutor nativo, licencia del código fuente y requisitos de compilación.
- [README del SDK MXC de Node](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) — Importación V1, versión mínima de Node, solicitud tipada, salida de ejecución y descubrimiento del host. El ejemplo se adaptó; no se ejecutó.
- [Guía del esquema MXC](https://github.com/microsoft/mxc/blob/main/docs/schema.md) — Contratos estables de JSON nativo 1.0.0 y de desarrollo 1.1.0-alpha, política de red y límites de backend e interfaz.
- [Guía de captura de denegaciones de MXC](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) — Comportamiento de Learning y Permissive en Windows ProcessContainer, advertencia de seguridad sobre --audit y límites de salida.
- [Muestras del SDK MXC](https://github.com/microsoft/mxc/blob/main/samples/README.md) — Índice oficial de muestras de sistema de archivos, red, salida capturada y captura de denegaciones.
- [Compatibilidad de versiones de Windows con MXC](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) — Compilaciones mínimas de Windows para ProcessContainer e IsolationSession.
- [Guía del backend Bubblewrap de MXC](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) — Requisitos del backend predeterminado de Linux y compatibilidad de red.
- [Guía del backend Seatbelt de MXC](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) — Límites del perfil nativo de macOS y del filtrado de hosts remotos.