Um agente não pode ser sua própria autoridade de segurança: MXC leva a fronteira ao Windows

Boa parte da segurança de agentes hoje vive em lugares que o próprio agente consegue ler: o system prompt, as descrições das ferramentas, o código da aplicação que envolve o modelo. Isso é um pouco como pedir que o empreiteiro escreva o próprio passe de obra. Funciona até o empreiteiro ficar confuso, ser manipulado ou simplesmente errar.

Em 7 de outubro, a Microsoft colocou os Microsoft Execution Containers (MXC) em disponibilidade geral (GA) no Windows 11, e o design parte da premissa oposta: o agente não vota sobre a própria fronteira.

O que a Microsoft entregou

A Microsoft descreve o MXC como uma camada de execução orientada por política para código não confiável e workloads gerados dinamicamente, o que é uma descrição justa do que um agente de IA produz quando escreve um script e o executa.

• O desenvolvedor declara o que o workload precisa: quais arquivos lê ou escreve, quais destinos de rede alcança, quais processos pode iniciar, se pode tocar a área de trabalho.
• A organização pode restringir isso ainda mais por meio de política de gestão.
• O sistema operacional aplica o resultado. A política fica fora do agente, então uma injeção de prompt que convence o agente a ler uma pasta de credenciais ainda encontra uma porta fechada.

As políticas cobrem contenção, processo, sistema de arquivos, rede e acesso à interface de usuário. Há vários backends de contenção: um container de processo (Windows 11, macOS e Linux), um container de sessão e um container WSL (Windows 11), e um backend microVM que a Microsoft rotula como experimental. Os desenvolvedores recebem um SDK, um esquema de configuração JSON e exemplos no GitHub.

Dois modos importam para quem já tentou escrever política de menor privilégio do zero. O modo Learning ajuda a diagnosticar falhas e a verificar que uma política concede apenas o acesso de que o workload precisa. O modo Permissive observa o que o agente tenta sem aplicar nada. Ambos transformam a escrita de política de adivinhação em observação.

A Microsoft diz que GitHub Copilot, OpenAI Codex, Replit e LM Studio já usam o MXC, e que o Claude Code, da Anthropic, além de Box, Egnyte e Perplexity estão adicionando suporte. O OpenShell, da NVIDIA, está integrado para controles de política.

O que ainda está por vir

O anúncio é cuidadoso quanto a prazos, e você também deveria ser:

• A integração com o Microsoft Entra, para distinguir a atividade do agente da atividade da pessoa que usa o dispositivo, é descrita como futura.
• O Microsoft Agent 365 vai “em breve” estender seus controles a agentes locais, no próprio dispositivo.
• A gestão pelo Intune dos containers de processo do MXC no Windows 11 também é “em breve”.

Enquanto esses itens não chegam, o MXC é uma camada de aplicação forte com uma história mais fina de gestão e identidade. Planeje em torno do que existe hoje.

1. O agente planeja e gera código
2. O desenvolvedor declara o acesso necessário
3. A política da organização restringe
4. O Windows aplica arquivos, rede, processo, UI
5. O modo Learning registra tentativas

• Dentro do agente: O agente planeja e gera código
• Fora do agente: O desenvolvedor declara o acesso necessário · A política da organização restringe · O Windows aplica arquivos, rede, processo, UI · O modo Learning registra tentativas

Não confiável, pode ser manipuladoPolítica escrita por pessoas

Por que isso muda a conversa de segurança

Dois dias atrás defendemos que guardrails de prompt não são uma fronteira de segurança, e que os incidentes com agentes deste ano apontam para contenção em runtime. O MXC é essa ideia entregue como recurso de plataforma no desktop corporativo mais comum.

A fronteira passa a ser revisável. Uma política JSON que lista pastas e destinos de rede é algo que um arquiteto de segurança consegue ler, comparar e aprovar. Um system prompt que diz “nunca acesse arquivos sensíveis” não é.

Agentes de código deixam de ser exceção. Agentes de código rodam em notebooks de desenvolvedores com amplo acesso local, que é exatamente onde os controles corporativos têm sido mais fracos. Um container em nível de sistema operacional dá aos times de endpoint um ponto de controle que eles já conhecem.

Tentativas negadas viram sinais. Quando um agente tenta alcançar um destino fora da sua política, essa tentativa é evidência: de um plano ruim, de uma entrada envenenada ou de uma ferramenta comprometida. Ela pertence ao mesmo pipeline dos outros alertas de endpoint.

O que o MXC não faz é responder quem é o agente. Enquanto a integração com o Entra não sai, a atividade dentro de um container ainda pode ser difícil de separar da atividade do próprio usuário. Como observamos quando o Digital Defense Report da Microsoft colocou identidade de agente ao lado de senhas, a contenção limita o raio de impacto; a identidade é o que torna a atividade atribuível.

O que fazer agora

1. Faça o inventário dos agentes que executam código em endpoints, começando por assistentes de código e ferramentas de automação local.
2. Decida quem é dono da política. Ela deve ficar com a segurança de endpoint, não com quem instalou o agente.
3. Comece no modo Permissive ou Learning em um grupo piloto, e escreva políticas a partir do comportamento observado.
4. Deixe o backend microVM no laboratório até a Microsoft tirá-lo do estágio experimental.
5. Encaminhe as tentativas negadas para o seu monitoramento de segurança e revise-as como qualquer outra anomalia.
6. Não projete pensando na integração com Entra, Agent 365 ou Intune ainda. Acompanhe esses itens e revise o modelo operacional quando saírem.

A conclusão

A mudança útil não é o Windows ter mais um sandbox. É que as permissões de agente estão migrando para uma camada que o agente não consegue reescrever, escrita por pessoas e aplicada pelo sistema operacional. É aí que uma fronteira de segurança pertence.