A Microsoft anunciou a disponibilidade geral do Microsoft Execution Containers (MXC) em 7 de outubro de 2026. Para equipes que executam comandos propostos por um agente de IA, a questão prática é quais arquivos e conexões de rede o comando precisa acessar e qual backend MXC pode impor esses limites. A publicação de lançamento descreve o objetivo de contenção; a documentação para usuários do repositório apresenta os detalhes de configuração. Este guia segue esses documentos. A BIG CHANGE não instalou o MXC nem executou uma carga de trabalho em ambiente contido.

A grande mudança

  • O que mudou: Os desenvolvedores podem enviar um comando e sua política de recursos para uma única interface do SDK MXC, que seleciona um backend de host compatível. O lançamento de 7 de outubro oferece um caminho documentado de integração para ferramentas de agentes, em vez de depender da obediência voluntária do modelo à política.
  • Por que isso importa: Uma equipe pode permitir que um comando de programação acesse o diretório de trabalho e, ao mesmo tempo, manter outros locais de arquivos e conexões de saída fora da autoridade da carga de trabalho. O efeito depende do backend e do host selecionados; por isso, a equipe precisa verificar o que o backend realmente aplica antes de confiar em uma restrição.
  • O que observar: Os modos de criação de políticas da Microsoft ajudam a diagnosticar operações bloqueadas em hosts Windows ProcessContainer compatíveis. A próxima decisão prática é saber se cada permissão proposta é necessária e se a execução em produção usa o modo de aplicação após restringir a política.

Comece pelo host e pelo comando

O MXC é uma biblioteca integrada ao aplicativo que inicia a carga de trabalho. Seu README lista SDKs para Rust, .NET e Node, além de executáveis nativos para aplicativos que não podem incorporar um SDK. O pacote Node inclui recursos nativos de runtime e exige Node.js 24 ou posterior; no Windows, o repositório especifica Node 24.21.0 ou posterior, ou 26.8.0 ou posterior, para transferência nativa por stdio. A API pública é importada de @microsoft/mxc-sdk/v1, não da raiz do pacote. O pacote .NET também inclui recursos nativos. O crate Rust compila o SDK, o mecanismo e os backends selecionados no aplicativo que o utiliza. Executáveis nativos exigem uma compilação do repositório para a plataforma correspondente.

Escolha o backend antes de escrever uma política. O repositório lista processcontainer como padrão no Windows 11, bubblewrap como padrão no Linux e seatbelt como padrão no macOS. O Windows também oferece wslc e isolation_session; windows_sandbox, microvm e hyperlight estão marcados como experimentais. O Linux exige o runtime selecionado, como o Bubblewrap para seu backend padrão. A tabela de versões do Windows apresenta as compilações mínimas para ProcessContainer e IsolationSession. Valide a disponibilidade do host e o suporte à política solicitada na máquina que executará o trabalho.

Anote o comando real, o diretório de trabalho, os arquivos que ele precisa ler e alterar e os destinos de rede necessários. Trate esses itens como entradas da política fornecidas pelo aplicativo ou pelo operador. Segundo a Microsoft, a política fica fora da carga de trabalho do agente, então o código gerado não pode ampliar as próprias permissões. A saída normal do comando inclui stdout, stderr e status de saída, além de avisos ou metadados opcionais retornados pelo SDK. Um relatório de atividade só está disponível nos modos de diagnóstico documentados em hosts Windows ProcessContainer compatíveis.

Declare uma política restrita com o SDK Node

O guia do SDK de Node documenta este formato V1. Instale o SDK em um aplicativo que execute uma versão compatível do Node:

Terminal
npm install @microsoft/mxc-sdk

Este exemplo adapta a amostra da Microsoft que executa até o fim e solicita acesso somente de leitura ao diretório atual do aplicativo, ao mesmo tempo que bloqueia conexões de saída. O comando apenas imprime uma linha, portanto não testa nenhuma das duas restrições. É um ponto de partida documentado, não um teste da BIG CHANGE. Substitua o comando e os caminhos pelos da carga de trabalho a ser contida; use readwritePaths apenas nos diretórios que ela precisa alterar.

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 retorna stdout e stderr capturados, código de saída, estado de timeout e avisos. Um acesso a arquivo bloqueado pode parecer um erro comum de acesso negado para a carga de trabalho; uma saída bem-sucedida, por si só, não prova que todas as restrições pretendidas foram testadas. Para atender ao critério de sucesso da tarefa, execute uma carga de trabalho confiável que use um recurso permitido e faça, separadamente, uma tentativa deliberada de acesso a um recurso não autorizado no backend compatível escolhido. Confira o resultado da operação e os diagnósticos antes de aplicar a política a comandos gerados por agentes. As amostras do SDK incluem permissões de sistema de arquivos, bloqueio de rede, captura de saída e registro de negações. Elas exigem um host preparado. A BIG CHANGE não executou essas etapas.

Para usuários do executor nativo, o esquema JSON estável é 1.0.0; uma solicitação completa exige version, seleção de contenção e process.commandLine. O esquema de desenvolvimento atual é 1.1.0-alpha. O SDK V1 escolhe o próprio contrato de comunicação; portanto, não inclua uma versão do esquema nativo no ContainerRequest tipado. O guia do esquema também informa que campos antigos, como network.defaultPolicy e allowedHosts, foram descontinuados. A política atual usa network.egress e network.ingress direcionais; regras diretas e um proxy de runtime têm comportamentos e suporte de backend diferentes.

Diagnostique as negações e depois aplique a política

A tabela de modos de 7 de outubro da Microsoft distingue três resultados. O modo de aplicação bloqueia acessos não autorizados e não produz relatório de atividade. O modo Learning bloqueia e registra acessos não autorizados. O modo Permissive registra o acesso que a política negaria, mas permite que continue. A referência da Microsoft para captura de negações limita esses recursos de Learning aos caminhos Windows ProcessContainer baseados em AppContainer. Outros hosts não passam a oferecer relatórios equivalentes só por aceitarem um campo de política compartilhado.

Para uma ferramenta confiável durante a criação da política, o executor nativo do Windows oferece um fluxo --audit capaz de gerar artefatos de política. A Microsoft alerta que ele desativa a segurança do sandbox para a carga de trabalho analisada e, por isso, não é adequado a comandos não confiáveis. Quando o host oferece suporte, uma captura que nega e registra é uma opção de diagnóstico mais segura: a tentativa continua bloqueada e o relatório mostra o que foi negado. Analise cada caminho ou capacidade registrado em relação à tarefa, conceda apenas o necessário ao comando e execute a carga de trabalho final no modo de aplicação. Os relatórios podem revelar nomes de recursos sensíveis; trate-os com o devido cuidado.

A escolha do backend muda o que a política pode garantir. O guia do esquema diz que isolation_session não consegue restringir a rede e exige uma configuração explicitamente sem restrições de rede. Também informa que Windows ProcessContainer e macOS Seatbelt aplicam restrições de interface, enquanto outros backends não as implementam; WSLC e IsolationSession recusam políticas de interface fornecidas. O guia do Seatbelt afirma que o perfil nativo do macOS não consegue filtrar hosts remotos individuais, e o guia do Bubblewrap descreve os pré-requisitos de runtime e rede do Linux. Portanto, a aceitação de um campo JSON por vários tipos de SDK não comprova aplicação equivalente em todos eles. Consulte o guia do backend escolhido e valide a solicitação no host de destino.

O repositório da Microsoft usa a licença MIT, mas a documentação para usuários não informa o preço do pacote MXC. Host, computação e qualquer provedor de modelos têm custos próprios. O anúncio do Windows classifica o MXC como disponível em geral, mas algumas opções de backend continuam experimentais e o esquema nativo de desenvolvimento está em alfa. Considere separadamente esses estágios ao decidir onde executar uma carga de trabalho.

Fontes e leituras adicionais