A Microsoft anunciou a disponibilidade geral do Microsoft Execution Containers (MXC) em 7 de outubro de 2026. Para as equipas que executam comandos propostos por um agente de IA, a questão prática é saber a que ficheiros e ligações de rede o comando precisa de aceder e que backend MXC pode impor esses limites. A publicação de lançamento descreve o objetivo de contenção; a documentação para utilizadores do repositório apresenta os pormenores da configuração. Este guia segue esses documentos. A BIG CHANGE não instalou o MXC nem executou uma carga de trabalho contida.

A grande mudança

  • O que mudou: Os programadores podem fornecer um comando e a respetiva política de recursos a uma única interface do SDK MXC, que seleciona um backend de anfitrião compatível. A versão de 7 de outubro disponibiliza um percurso de integração documentado para ferramentas de agentes, em vez de depender da obediência voluntária do modelo à política.
  • Porque é importante: Uma equipa pode permitir que um comando de programação aceda ao respetivo diretório de trabalho, mantendo outros locais de ficheiros e ligações de saída fora da autoridade da carga de trabalho. O efeito depende do backend e do anfitrião selecionados; por isso, a equipa deve verificar o que o backend realmente aplica antes de confiar numa restrição.
  • O que deve acompanhar: Os modos de criação de políticas da Microsoft ajudam a diagnosticar operações bloqueadas em anfitriões Windows ProcessContainer compatíveis. A próxima decisão prática é saber se cada autorização proposta é necessária e se a execução de produção utiliza o modo de aplicação depois de restringir a política.

Comece pelo anfitrião e pelo comando

O MXC é uma biblioteca integrada na aplicação que inicia a carga de trabalho. O respetivo README lista SDK para Rust, .NET e Node, além de executáveis nativos para aplicações que não podem incorporar um SDK. O pacote Node inclui recursos nativos de execução e requer Node.js 24 ou posterior; no Windows, o repositório indica Node 24.21.0 ou posterior, ou 26.8.0 ou posterior, para a 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 motor e os backends selecionados na aplicação que o utiliza. Os executáveis nativos requerem uma compilação do repositório para a plataforma correspondente.

Escolha o backend antes de escrever uma política. O repositório indica processcontainer como predefinição no Windows 11, bubblewrap como predefinição no Linux e seatbelt como predefinição no macOS. O Windows também disponibiliza wslc e isolation_session; windows_sandbox, microvm e hyperlight estão assinalados como experimentais. O Linux requer o runtime selecionado, como o Bubblewrap para o backend predefinido. A tabela de versões do Windows apresenta as compilações mínimas para ProcessContainer e IsolationSession. Valide a disponibilidade do anfitrião e o suporte da política pedida na máquina que irá executar o trabalho.

Registe o comando efetivo, o diretório de trabalho, os ficheiros que tem de ler e alterar e os destinos de rede de que necessita. Trate-os como dados da política fornecidos pela aplicação ou pelo operador. Segundo a Microsoft, a política está fora da carga de trabalho do agente, pelo que o código gerado não pode alargar as próprias permissões. A saída normal do comando inclui stdout, stderr e o estado de saída, além de avisos ou metadados opcionais devolvidos pelo SDK. Um relatório de atividade só está disponível nos modos de diagnóstico documentados em anfitriões Windows ProcessContainer compatíveis.

Defina uma política restrita com o SDK Node

O guia do SDK de Node documenta esta estrutura V1. Instale o SDK numa aplicação que utilize uma versão compatível do Node:

Terminal
npm install @microsoft/mxc-sdk

Este exemplo adapta a amostra da Microsoft que é executada até ao fim e solicita acesso apenas de leitura ao diretório atual da aplicação, bloqueando simultaneamente as ligações de saída. O comando limita-se a imprimir uma linha, pelo que não testa nenhuma das 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 conter; utilize readwritePaths apenas nos diretórios que tem de 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 devolve stdout e stderr capturados, o código de saída, o estado de timeout e avisos. Um acesso a ficheiros bloqueado pode surgir para a carga de trabalho como um erro normal de acesso recusado; uma saída bem-sucedida não prova, por si só, que todas as restrições previstas foram testadas. Para cumprir o critério de sucesso da tarefa, execute uma carga de trabalho fidedigna que utilize um recurso permitido no backend compatível escolhido e, separadamente, tente de forma deliberada aceder a um recurso não autorizado. Verifique o resultado da operação e os diagnósticos antes de aplicar a política a comandos gerados por agentes. Os exemplos do SDK abrangem permissões do sistema de ficheiros, bloqueio de rede, captura de saída e registo de recusas. Requerem um anfitrião preparado. A BIG CHANGE não executou estes passos.

Para os utilizadores do executor nativo, o esquema JSON estável é 1.0.0; um pedido completo requer version, uma 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 transmissão; por isso, não inclua uma versão do esquema nativo no ContainerRequest tipado. O guia do esquema também indica que campos antigos, como network.defaultPolicy e allowedHosts, foram descontinuados. A política atual utiliza network.egress e network.ingress direcionais; as regras diretas e um proxy de execução têm comportamentos e suporte de backend diferentes.

Diagnostique as recusas e, em seguida, aplique a política

A tabela de modos de 7 de outubro da Microsoft distingue três resultados. O modo Enforcement bloqueia o acesso não autorizado e não produz um relatório de atividade. O modo Learning bloqueia e regista o acesso não autorizado. O modo Permissive regista o acesso que a política recusaria, mas permite que prossiga. A referência da Microsoft à captura de recusas limita estas capacidades Learning aos caminhos Windows ProcessContainer baseados em AppContainer. Os outros anfitriões não passam a produzir relatórios equivalentes apenas por aceitarem um campo de política comum.

Para uma ferramenta fidedigna durante a criação da política, o executor nativo do Windows suporta um fluxo --audit que pode produzir artefactos de política. A Microsoft alerta que este desativa a segurança da sandbox para a carga de trabalho analisada, pelo que não é adequado a comandos não fidedignos. Quando o anfitrião o suporta, uma captura que recusa e regista é o percurso de diagnóstico mais seguro: a tentativa de acesso continua bloqueada e o relatório identifica o que foi recusado. Analise cada caminho ou capacidade registados face à tarefa, conceda apenas o necessário ao comando e execute a carga de trabalho final no modo Enforcement. Os relatórios podem revelar nomes de recursos sensíveis; trate-os em conformidade.

A escolha do backend altera o que a política pode garantir. O guia do esquema indica que isolation_session não consegue restringir a rede e exige uma configuração de rede explicitamente sem restrições. Indica ainda que as restrições da interface são aplicadas por Windows ProcessContainer e macOS Seatbelt, mas não são implementadas pelos restantes backends; WSLC e IsolationSession recusam uma política de interface fornecida. O guia do Seatbelt explica que o perfil nativo do macOS não consegue filtrar anfitriões remotos individuais; o guia do Bubblewrap descreve os pré-requisitos de runtime e rede do Linux. Assim, a aceitação de um campo JSON por vários tipos de SDK não prova uma aplicação equivalente em todos eles. Consulte o guia do backend selecionado e valide o pedido no anfitrião de destino.

O repositório da Microsoft está sob a licença MIT, mas a documentação para utilizadores não indica o preço do pacote MXC. Os custos do anfitrião, da computação e de qualquer fornecedor de modelos são distintos. O anúncio do Windows classifica o MXC como geralmente disponível, embora várias opções de backend continuem experimentais e o esquema nativo de desenvolvimento esteja em alfa. Tenha em conta separadamente estas fases de lançamento ao decidir onde executar uma carga de trabalho.

Fontes e leituras adicionais

  • Microsoft Windows Developer Blog, 7 de outubro de 2026fundamenta o anúncio de lançamento, a utilização prevista com agentes e as definições dos três modos. É a descrição do produto pela Microsoft, não um teste de segurança da BIG CHANGE.
  • README do repositório MXClista SDK, predefinições dos anfitriões, backends experimentais, pré-requisitos de compilação e o percurso do executor nativo. O repositório muda; os detalhes foram verificados em 8 de outubro de 2026.
  • Guia de utilização do SDK Nodeespecifica os pré-requisitos do Node, a importação V1, o pedido tipado e a saída capturada. O código acima foi adaptado da amostra; não foi executado aqui.
  • Guia do esquema de configuraçãodistingue o JSON nativo estável 1.0.0 do 1.1.0-alpha em evolução e documenta os campos de política e os limites específicos de cada backend.
  • Referência do modo Learning e da captura de recusasdocumenta o diagnóstico de Windows ProcessContainer e alerta para a auditoria Permissive. Os relatórios dependem do anfitrião e do modo.
  • Guias dos backends e a tabela de versões do Windows são referências para verificar um anfitrião específico; este artigo não certifica nenhuma configuração na máquina do leitor.