A Sandbox da Microsoft para Agentes de IA Chega ao Kernel — e Traz OpenAI e NVIDIA Junto

Durante duas décadas defendi que software deveria tocar as máquinas pelas quais era responsável. O modelo era simples: uma app rodava com as permissões do usuário, e se se comportava mal, se comportava mal com toda a autoridade que esse usuário tinha. Tolerávamos isso porque as aplicações eram majoritariamente determinísticas — você podia raciocinar sobre o que iam fazer. Os agentes de IA quebram esse pressuposto. Um agente gera código novo a cada prompt, lê arquivos, chama serviços e encadeia operações a uma velocidade para a qual nenhum processo de revisão foi projetado. Então a pergunta que a Microsoft está respondendo agora no nível do sistema operacional é a mesma que me tirou o sono mais de uma vez: como você deixa um agente fazer trabalho útil sem entregar as chaves completas da sessão do usuário?

Em Build 2026, em 2 de junho, a Microsoft apresentou Microsoft Execution Containers (MXC) — uma camada de execução baseada em políticas integrada ao Windows (e WSL) que permite aos desenvolvedores e TI declarar exatamente o que um agente pode ler, escrever e alcançar, e depois faz cumprir essas restrições em tempo de execução. O enquadramento importa: isso não é um serviço de contêineres na nuvem. É contenção empurrada para dentro do próprio sistema operacional, mais perto de como um SO móvel regula o que um app pode fazer do que de como estávamos fazendo sandboxing de código em um processo Python ou uma VM na nuvem.

O que é MXC realmente

A ideia central é a contenção como primitiva fundamental. O argumento da Microsoft é que o comportamento de um agente é dinâmico e é gerado em tempo de execução, então os velhos pressupostos de segurança — confie no binário, confie na sessão do usuário — não se sustentam mais. MXC oferece ao desenvolvedor uma camada de abstração sobre os mecanismos de isolamento subjacentes, de modo que você declara intenção (“este agente pode ler estes diretórios e alcançar estes domínios, nada mais”) e o Windows cuida da aplicação de baixo nível.

A Microsoft a apresenta como um “sandbox composável” com um espectro de níveis de contenção:

  • Isolamento de processo — contenção leve e rápida para executar código gerado pelo modelo dentro de um limite de processo dedicado que restringe o acesso a arquivos e rede. Este é o caso do inner loop do desenvolvedor, onde você não pode se permitir latência. GitHub Copilot CLI é o primeiro adotante, usando isolamento de processo do MXC para restringir o que seu código gerado dinamicamente pode executar.
  • Isolamento de sessão — separa a execução do agente do desktop, da área de transferência, dos dispositivos de entrada e das sessões ativas do humano, rodando sob uma identidade distinta, local ou respaldada pelo Entra. Isso mitiga o UI spoofing, a injeção de entrada e o vazamento de dados entre sessões, e é pensado para agentes de longa duração trabalhando ao seu lado.

O gancho enterprise é Agent 365, que empilha Microsoft Entra (identidade), Intune (políticas de dispositivo), Defender (proteção contra ameaças) e Purview (governança de dados) sobre MXC — agendado para preview em julho. É isso que permite à TI gerenciar a contenção de agentes de forma centralizada em uma frota, em vez de confiar que cada desenvolvedor a configure corretamente.

Onde isso é um benefício real — se funcionar conforme definido

Quero ser preciso com esse condicional, porque o próprio repositório de MXC no GitHub avisa que os perfis atuais ainda não devem ser tratados como limites de segurança. Este é software em early preview. Então tudo o que se segue é a promessa, não ainda o produto testado. Com essa ressalva dita antecipadamente, aqui está onde uma contenção deste tipo realmente muda o cálculo:

  • Agentes de codificação em repos reais. Você deixa um agente refatorar um serviço ou expandir a cobertura de testes, mas seu processo só pode tocar o diretório do projeto e alcançar seu registry de pacotes — não suas chaves SSH, não seu .env com credenciais de produção, não domínios de saída arbitrários. Se uma injeção de prompt tenta fazer o agente exfiltrar um segredo, a política é o que diz que não, independentemente do que o modelo “decidiu” fazer.
  • Automação de longa duração ao seu lado. Um agente de processamento de dados roda por horas sob sua própria identidade de sessão, isolado de seu desktop interativo. Não pode ler sua área de transferência, não pode injetar pressionamentos de teclado em seus apps abertos, e cada ação que ele toma é atribuída à sua identidade no log de auditoria — então quando algo dá errado, você pode distinguir a atividade do agente da do humano. Para qualquer um que alguma vez tentou reconstruir a linha do tempo de um incidente, essa atribuição por si só vale muito.
  • Governança de frota. Por meio do Entra e Intune, TI define um único envelope de políticas — “os agentes do grupo de finanças não podem alcançar a internet” — e é feito cumprir em cada máquina, de forma centralizada, em vez de viver em arquivos de config dispersos. Esta é a parte que, nos meus anos de CIO, teria sido a diferença entre “permitimos agentes” e “proibimos agentes porque não conseguimos controlá-los”.
  • Contenção de agentes de terceiros e open source. A Microsoft está usando OpenClaw, um framework de agentes open source, como banco de testes: a lógica é que se um agente totalmente aberto puder ser contido dentro dos limites do MXC, a contenção é robusta o suficiente para qualquer coisa. A companhia também diz que a descoberta e gestão de agentes locais está sendo expandida para GitHub Copilot CLI e Claude Code.

A parte que vale a pena ler duas vezes

O que diferencia isso do anúncio típico de plataforma aspiracional é a lista de parceiros. A Microsoft nomeou cinco companhias que já estão construindo sobre MXC: OpenAI (explorando padrões para que agentes gerem e executem código de forma segura), NVIDIA (trazendo seu framework de agentes OpenShell para Windows sobre MXC), Manus, Nous Research (criador do agente Hermes) e o projeto OpenClaw. Tao Zhang, Chief Product Officer da Manus, descreveu MXC como uma forma baseada em políticas de definir e fazer cumprir os limites de acesso de um agente em tempo de execução. Dillon Rolnick, CEO da Nous Research, colocou da forma mais concisa: agentes locais de execução contínua precisam de isolamento intencional, e os desenvolvedores precisam confiar que esses controles vão se manter.

Que OpenAI e NVIDIA — competidores nas camadas de modelo e silício — estejam construindo sobre um plano de contenção da Microsoft te diz o que a Microsoft realmente está fazendo. Não está tentando ganhar o agente. Está tentando ser a camada de confiança abaixo do agente de todos. Vale a pena notar de passagem: Manus é uma startup de origem chinesa, o que torna sua presença em uma primitiva de segurança enterprise da Microsoft seu próprio pequeno sinal de quão sem fronteiras se tornou o ecossistema de agentes.

E aqui está a tensão estratégica com a qual gostaria que todo líder técnico se sentasse por um tempo. O sandbox do navegador nunca foi caridade — foi a pré-condição para executar código web não confiável em escala global. As permissões móveis tornaram as app stores viáveis. A contenção de agentes pode ser o acordo equivalente para a automação com IA. Mas a preocupação é o lock-in disfarçado de segurança: se os agentes melhor governados são aqueles que rodam sobre o SDK da Microsoft, as identidades da Microsoft, o plano de políticas da Microsoft e as Cloud PCs da Microsoft, as empresas já padronizadas em Microsoft 365 e Intune podem se ver empurradas para um stack de agentes integrado verticalmente — e as que não estão vão estar se fazendo perguntas difíceis sobre interfaces abertas e paridade de terceiros.

Minha leitura: o primitivo é a ideia correta. A contenção deveria viver no SO — é lá que é exigível e onde sobrevive ao próprio agente sendo comprometido. O que há que vigiar não é se MXC funciona. É se a camada de governança se mantém aberta o bastante para que “seguro” e “só-Microsoft” não se tornem silenciosamente a mesma palavra. Por enquanto é early preview, os limites de segurança estão explicitamente não garantidos, e a prova real chega quando alguém rodar uma frota desses em uma rede de produção. Mas a direção está fixada, e é a correta.