A Microsoft colocou seu agente de IA em um sandbox (MXC explicado + demonstração real)

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Microsoft just sandboxed your AI agent (MXC explained + real demo) · Canal: Prompt Engineer 48 · 04:40 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Ferramentas de desenvolvimento com IA, Mercados e economia, Segurança de IA

Resumo

Agentes de programação podem ter acesso a arquivos, rede e configurações de produção, mesmo quando isso não é necessário para a tarefa. O vídeo apresenta o MXC (Microsoft Execution Containers), uma camada que aplica políticas de isolamento a código e agentes. Uma demonstração no Windows mostra restrições de leitura, escrita e acesso à rede. O apresentador também destaca limitações atuais do SDK e recomenda começar com um contêiner de processo e uma política que negue acesso por padrão.

Pontos-chave

Prompts que pedem ao agente para evitar certos arquivos não são uma barreira de segurança.
Com o MXC, é possível definir políticas para contenção, processos, sistema de arquivos, rede e interface do usuário.
O agente não pode alterar a própria política de segurança.
O MXC oferece quatro backends: contêiner de processo, contêiner de sessão, contêiner WSL e micro VM experimental.
Os modos de operação incluem enforcement, learning e permissive, com diferentes formas de aplicar ou registrar violações da política.
Na demonstração, o sandbox bloqueia a leitura de um arquivo externo à pasta autorizada e a escrita em uma pasta somente leitura.
Uma regra de rede pode impedir ou permitir conexões de saída, como uma solicitação para example.com.
O SDK está em prévia pública, algumas funcionalidades têm limitações e os backends mais fortes são experimentais.
Para agentes que acessam arquivos ou credenciais reais, a recomendação é começar com um contêiner de processo e negar acesso por padrão.

Capítulos

Início	Capítulo	Resumo
00:00	O problema do acesso irrestrito	O vídeo explica como um agent com acesso amplo pode alterar arquivos e configurações que não deveriam fazer parte da tarefa.
00:30	Como funciona o MXC	O MXC aplica políticas a processos, arquivos, rede e interface, com diferentes backends e modos de operação.
02:03	Demonstração de restrições	Testes no Windows mostram o bloqueio de leitura fora da pasta autorizada, escrita em pasta somente leitura e acesso de rede não permitido.
03:37	Adoção, vantagens e limitações	O apresentador cita produtos que já usam ou anunciaram o MXC, aponta vantagens e descreve limitações da prévia.
04:40	Recomendação final	Para agents que acessam arquivos ou credenciais reais, a sugestão é começar com um contêiner de processo e negar acesso por padrão.

Citações

Prompts que dizem “por favor, não mexa nesta pasta” não são uma barreira de segurança. — 00:30

O agent não pode alterar a própria política. — 01:00

Essa única linha é toda a diferença entre um agent que pode exfiltrar dados e um que não pode. — 03:06

Conter não é desconfiar do modelo. É definir o tamanho do raio de impacto. — 03:37

Se o seu agent acessa arquivos ou credenciais reais, sim. Comece com um contêiner de processo e uma política que negue acesso por padrão. — 04:40

Conceitos e entidades

Microsoft Execution Containers (MXC) (ferramenta): Camada de execução orientada por políticas que isola código não confiável ou gerado dinamicamente.
Microsoft (empresa): Empresa que desenvolveu e lançou o MXC.
agent harness (conceito): Estrutura que envolve e executa um agent, podendo também ser submetida às políticas do MXC.
Windows 11 (ferramenta): Sistema operacional usado na demonstração prática do MXC.
WSL (ferramenta): Ambiente usado por um dos backends do MXC para toolchains de Linux.
GitHub Copilot (ferramenta): Produto citado no vídeo como um dos que já usam o MXC.
OpenClaw (ferramenta): Produto citado no vídeo como um dos que já usam o MXC.
OpenAI Codex (ferramenta): Produto citado no vídeo como um dos que já usam o MXC.
Replit (empresa): Nome citado entre os que já usam o MXC.
LM Studio (ferramenta): Produto citado no vídeo como um dos que já usam o MXC.
Unsloth (empresa): Nome citado no vídeo como um dos que já usam o MXC.
Perplexity (empresa): Empresa citada entre as que anunciaram o uso do MXC.
NVIDIA (empresa): Empresa que integrou o Open Shell, acrescentando gerenciamento de credenciais e registro de auditoria.
OpenShell (ferramenta): Camada integrada pela Nvidia que adiciona gerenciamento de credenciais e registro de auditoria.

Tradução completa (pt-BR)

00:00 Seu agent de programação com IA tem o mesmo acesso que você: aos seus arquivos, à sua rede, às configurações de produção, e decide sozinho o que fazer com tudo isso. A Microsoft acabou de lançar uma solução, chamada MXC. Aqui está o problema. Digamos que você peça a um agent para atualizar seu site. Para isso, ele precisa do repo e das ferramentas de build, mas também pode ler a configuração do seu servidor de produção e, um dia, decide alterá-la. A escolha pareceu razoável para o agent. Mas nunca foi isso que você pretendia permitir.

00:30 Então, hoje você tem duas opções ruins. Dar acesso irrestrito ao agent e torcer para que nada dê errado, ou bloqueá-lo e perder a produtividade que fez os agents valerem a pena. Prompts que dizem “Por favor, não mexa nesta pasta” não são uma barreira de segurança. MXC significa Microsoft Execution Containers. É uma camada de execução orientada por políticas para código não confiável ou gerado dinamicamente. Saída de modelo, plugins, ferramentas, o agent harness ou o agent inteiro: você declara

01:00 o que a carga de trabalho precisa — arquivos e destinos de rede —, e o MXC aplica esse limite. O agent não pode alterar a própria política. A política abrange cinco áreas: contenção, que define qual ambiente de isolamento usar; processo, o comando e seu ambiente; sistema de arquivos, o que pode ser gravado, é somente leitura ou inacessível; rede, entrada e saída, incluindo loopback; e interface do usuário, a área de trabalho e a área de transferência. Um esquema JSON e um SDK em Rust, .NET e Node. Por baixo disso, há quatro backends. Um

01:31 contêiner de processo, que usa app container no Windows, seatbelt no macOS e bubble wrap no Linux. Um contêiner de sessão, com identidade e área de trabalho próprias. Um contêiner WSL para toolchains Linux. E uma micro VM experimental para as cargas de trabalho mais arriscadas. Você escolhe o nível de proteção; a política permanece a mesma. Também há três modos. O modo de aplicação aplica a política. O modo de aprendizado bloqueia o que não foi permitido e registra isso em um relatório de atividade JSON, para que você veja por que algo falhou. E o modo permissivo deixa tudo passar, mas registra o que a política teria negado.

02:03 É assim que você cria uma política sem ficar no chute. Chega de slides, vamos executar. Este é meu próprio laptop com Windows 11, build 26.300. Instalei o SDK oficial de Node pelo NPM, versão 0.8. Primeiro, a verificação da plataforma: backend compatível, contêiner de processo, restrições da interface, área de transferência, injeção de entrada e troca de área de trabalho — tudo pode ser bloqueado. Demonstração um: sistema de arquivos. Dei a esta sandbox acesso somente para leitura a uma pasta. Ler o arquivo dentro dela funciona. Agora eu

02:35 peço que leia secret.env, que fica ao lado daquela pasta, não dentro dela. O acesso é negado. Mesmo comando, mesma máquina, sem truques sofisticados. A política decidiu. Demonstração dois: a mesma pasta somente para leitura, mas agora o agent tenta gravar um arquivo nela. Echo jogo da velha em evil.text: o acesso é negado de novo. Somente leitura significa somente leitura. O agent pode olhar, mas não pode mexer. Demonstração três: a rede. O mesmo comando curl acessando example.com. Com a saída de rede

03:06 configurada para negar, ele falha. Código de saída seis: não foi possível resolver o host. Altero uma linha na política para permitir, executo o mesmo comando e ele retorna HTTP 200. Essa única linha é toda a diferença entre um agent que pode exfiltrar dados e um que não pode. Aqui está essa ideia em uma imagem. O agent tenta ler suas chaves SSH: bloqueado. Tenta enviar dados para um servidor desconhecido: bloqueado. Grava no repo que recebeu: permitido. Contenção não tem a ver com desconfiar do modelo. Tem a ver com definir o raio de impacto como um número

03:37 que você escolheu. E isso não é um brinquedo de laboratório. A Microsoft diz que GitHub Copilot, OpenClaw, OpenAI Codex, Replit LM Studio e Unsloth já usam a tecnologia. Cloud Code Box, Perplexity e outros foram anunciados. A Nvidia integrou o Open Shell por cima, adicionando gerenciamento de credenciais e registro de auditoria. O que eu gosto: uma política em Windows, macOS e Linux. Aplicação real no nível do sistema operacional, não um prompt. O agent não pode editar a própria política. Os modos de aprendizado e permissivo tornam prático escrever políticas

04:09 em open source sob a licença MIT, e a solução escala de um processo até uma VM. O que observar: o SDK está em prévia pública, e os esquemas ainda podem mudar antes da versão 1.0. O relatório de atividade só funciona em contêineres de processo no Windows. As listas de permissão e bloqueio de hosts ainda não são aplicadas no Windows. Só é possível permitir ou bloquear por padrão. Os backends mais robustos são experimentais, e o pacote NPM publicado não correspondia aos exemplos no repo. Então, espere alguns percalços. Então, você deveria usar? Se o seu agent

04:40 acessa arquivos ou credenciais reais, sim. Comece com um contêiner de processo e uma política que negue por padrão. Os links para o blog e o repo estão na descrição. Se isso foi útil, curta e inscreva-se. Vejo você no próximo vídeo.

Transcrição original

[00:00] Your AI coding agent has the same access you do, your files, your network, your production config, and it decides what to do with all of it on its own. Microsoft just shipped a fix, and it is called MXC. Here is the problem. Say you ask an agent to update your website. To do that, it needs the repo and the build tools, but it can also read your production server configuration, and one day it decides to change it. The choice looked reasonable to the agent. It was never what you meant to allow.

[00:30] So, today you have two bad options. Give the agent unrestricted access and hope nothing goes wrong, or block it and lose the productivity that made agents worth using in the first place. Prompts that say, “Please do not touch this folder.” are not a security boundary. MXC stands for Microsoft Execution Containers. It is a policy-driven execution layer for untrusted or dynamically generated code. Model output, plugins, tools, the agent harness, or the whole agent, you declare

[01:00] what the workload needs, files and network destinations, and MXC enforces that boundary. The agent cannot change its own policy. The policy covers five areas: containment, which isolation environment to use, process, the command and its environment, file system, what is writable, read-only, or inaccessible, network, inbound and outbound, including loopback and user interface, the desktop and the clipboard, one JSON schema, and one SDK in Rust, .NET, and Node. Under that, there are four backends. A

[01:31] process container, which uses app container on Windows, seatbelt on macOS, and bubble wrap on Linux. A session container with its own identity and desktop. A WSL container for Linux toolchains. And a micro VM experimental for the riskiest workloads. You pick the strength, the policy stays the same. There are also three modes. Enforcement applies the policy. Learning blocks what is not granted and records it in a JSON activity report, so you can see why something failed. And permissive lets everything through, but records what the

[02:03] policy would have denied. That is how you author a policy without guessing. Enough slides, let us run it. This is my own Windows 11 laptop build 26,300. I installed the real node SDK from NPM version 0.8. First, the platform check supported back-end process container, the UI restrictions, clipboard, input injection, desktop switching, all blockable. Demo one, the file system. I gave this sandbox read-only access to one folder. Reading the file inside it works. Now I

[02:35] ask it to read secret.env, which sits next to that folder, not inside it. Access is denied. Same command, same machine, no fancy tricks. The policy decided. Demo two, same read-only folder, but now the agent tries to write a file there. Echo pound into evil.text, access is denied again. Read-only means read-only. The agent can look, it cannot touch. Demo three, the network. Same curl command hitting example.com. With egress

[03:06] set to deny, it fails. Exit code six, could not resolve host. I flip one line in the policy to allow, same command, and it returns HTTP 200. That one line is the whole difference between an agent that can exfiltrate data and one that cannot. Here is that idea as a picture. The agent tries to read your SSH keys, blocked. It tries to post to an unknown server, blocked. It writes to the repo it was given, allowed. Containment is not about distrusting the model. It is about making the blast radius a number

[03:37] you chose. And this is not a lab toy. Microsoft says GitHub Copilot, OpenClaw, OpenAI Codex, Replit LM Studio, and Unsloth already use it. Cloud Code Box, Perplexity, and others are announced. Nvidia integrated Open Shell on top, adding credential management and audit logging. What I like. One policy across Windows, macOS, and Linux. Real OS level enforcement, not a prompt. The agent cannot edit its own policy. Learning and permissive modes make writing policy

[04:09] practical, open source under MIT, and it scales from a process all the way up to a VM. What to watch. The SDK is public preview and schemas can still change before 1.0. The activity report only works on Windows process containers. Host allow and block lists are not enforced on Windows yet. Only default allow or block. The strongest backends are experimental and the published NPM package did not match the samples in the repo. So, expect some friction. So, should you use it? If your agent

[04:40] touches real files or real credentials, yes. Start with a process container and a deny by default policy. Links to the blog and the repo are in the description. If this was useful, like, subscribe, and I will see you in the next one.