Radar Tech: o agente não pode ser a própria autoridade — e a fronteira de execução virou o tema do dia

O dia teve dois lados da mesma moeda. De um lado, a Microsoft anunciou a disponibilidade geral dos Microsoft Execution Containers (MXC): uma camada de execução guiada por política para cargas não confiáveis, feita para conter o que um agente pode acessar e fazer, com a política vivendo fora do agente. Do outro, uma análise de uma campanha de invasões a lojas online mostrou o que acontece quando essa fronteira simplesmente não existe.

O que a MXC muda na conversa

A ideia é direta: um agente não pode ser a própria autoridade de segurança. Ele precisa rodar dentro de um limite definido por um humano ou por uma organização e imposto independentemente do agente. Na prática, o desenvolvedor declara os recursos que a carga precisa — arquivos e destinos de rede — e o mecanismo aplica essa fronteira com o contêiner adequado. A política fica fora do controle da carga, então o modelo, o plugin ou o código gerado não conseguem se conceder acesso adicional.

O exemplo do próprio anúncio é o que todo arquiteto reconhece: um agente de código que precisa ler e escrever no repositório, rodar o build, ler a configuração de produção para entender o deploy — mas não pode alterar essa configuração. Sem fronteira, mudar a configuração pode parecer, do ponto de vista do modelo, o caminho mais rápido para concluir a tarefa. A ação é razoável do ponto de vista do agente e, ainda assim, excede a autoridade que o time pretendia conceder.

O custo de não ter fronteira

A segunda história do dia é o contraponto. Uma campanha documentada de invasões autônomas usou três ferramentas abertas de IA — uma para achar vulnerabilidade, uma para explorar, uma para orquestrar — e atingiu dezenas de lojas online. O detalhe que importa para arquitetura não é a IA: é que a cadeia explorada era feita de falhas conhecidas e encadeáveis. Injeção em um campo de login sem autenticação; códigos de uso único guardados em texto claro no banco, o que anula o segundo fator; upload de imagem sem checagem de extensão; até escalonamento de privilégio por um binário mal configurado. Nada ali é novo. O que mudou foi a velocidade e o custo de encadear tudo isso.

A leitura correta não é "a IA agora invade lojas". É: a mesma superfície que já estava exposta passou a ser explorada por um processo que não cansa, não improvisa mal e roda mais barato do que a defesa. E a resposta de arquitetura não é bloquear agentes — é definir, de forma explícita e imposta de fora, o que cada agente pode alcançar.

O que fica para o time

• Instrução no prompt não é controle. "Peça ao modelo para não tocar em produção" mitiga intenção, não execução. Qualquer injeção no conteúdo que o agente lê, plugin comprometido ou código gerado age dentro do escopo já concedido.
• A fronteira precisa viver fora do agente. Se o próprio agente pode ler, editar ou contornar a política que o restringe, não há fronteira — há recomendação.
• Egress por allow-list, não rede liberada. Um agente autônomo com saída irrestrita é um canal de exfiltração esperando o gatilho.
• Ações irreversíveis pedem aprovação. Destruir dados, apagar backup, mexer em produção, pagar: decisão humana, não autonomia.
• Auditabilidade é parte da fronteira. Uma contenção que não registra por principal não pode ser provada depois do incidente.

A pergunta que sobra para quem opera agentes em produção deixou de ser "qual modelo usar" e passou a ser "qual é a fronteira de execução — e como eu provo que ela nega o que promete negar".