- O software de IA precisa de características de sistema operacional que vão além de simplesmente chamar modelos, oferecendo segurança, isolamento, escalabilidade e portabilidade; para isso, propõe-se o conceito de uma máquina virtual dedicada a modelos de IA (MVM)
- Assim como a Java Virtual Machine (JVM) viabilizou segurança de memória e o princípio de “escreva uma vez, execute em qualquer lugar”, uma VM para IA também garante substituibilidade e interoperabilidade ao separar o modelo da lógica de integração
- A VM define um conjunto de instruções padrão para chamadas de modelo, chamadas de ferramentas, armazenamento de resultados, entrada do usuário e desvios condicionais, permitindo restringir e rastrear com segurança o comportamento do modelo
- Pesquisas e iniciativas existentes, como as chamadas estruturadas de ferramentas da OpenAI, o MCP da Anthropic, o FIDES/AC4A da Microsoft e runtimes open source, já mostram a direção da padronização
- Uma VM de IA bem definida pode viabilizar mais segurança e privacidade, monitoramento de desempenho, validação de saídas e a criação de um ecossistema cross-platform, consolidando-se como infraestrutura essencial para tornar sistemas de IA mais confiáveis e seguros
Introdução
- Modelos de IA vêm sendo usados em software para diversas finalidades, como copilotos de aplicação, integração com IDEs e uso de ferramentas via protocolo MCP
- Esses avanços aumentam a necessidade de garantir privacidade, segurança e funcionamento correto
- Segurança e privacidade precisam ser garantidas desde a fase de projeto do sistema; adicioná-las depois não é suficiente
- Inspirando-se na Java Virtual Machine (JVM), propõe-se a importância de uma máquina virtual padronizada para modelos de IA
- A JVM fornece um ambiente de execução confiável por meio de segurança de memória, controle de acesso e verificação de bytecode
- Isso tornou possível “escrever uma vez e executar em qualquer lugar”
O papel da máquina virtual para modelos de IA (MVM)
- A MVM funciona como um software intermediário entre o modelo de IA e o ambiente externo
- Ex.: quando o usuário insere o prompt “reservar voo”, a MVM o encaminha ao modelo, incluindo contexto adicional
- Se o modelo responder “usar ferramenta de reserva”, a MVM verifica a lista de ferramentas permitidas antes de decidir se fará a chamada
- Isso garante que o modelo não realize chamadas não autorizadas
- Todo sistema comercial de IA precisa de um software de controle semelhante
- A MVM define um conjunto de instruções, por exemplo:
- autenticar, carregar, inicializar e descarregar modelos
- chamar o modelo com contexto
- fazer o parsing da saída do modelo
- autenticar, carregar e chamar ferramentas, fazer o parsing dos resultados e armazená-los na memória
- solicitar entrada do usuário, adicionar memória de histórico, condicionais e outras estruturas de controle
Pesquisas existentes e necessidade
- Protocolo estruturado de chamada de ferramentas da OpenAI: fornece integração clara de ferramentas por meio de uma API de function calling baseada em JSON e especificações OpenAPI
- MCP (2024) da Anthropic: um protocolo aberto para conectar assistentes de IA a dados externos
- É comparado a uma “porta USB-C para aplicações de IA”, oferecendo uma interface universal
- Já apresenta casos de adoção rápida, inclusive entre grandes empresas
- Orquestradores de segurança – FIDES & AC4A (2025):
- FIDES (Microsoft Research): impõe políticas de fluxo de informação, rastreia rótulos de confidencialidade de dados e adiciona ações de “inspeção”
- AC4A: gerencia ferramentas e dados em uma hierarquia no estilo de sistema operacional e impõe um modo de operação de privilégio mínimo
- Esses projetos mostram o potencial de uma MVM com segurança e controle de acesso incorporados
- Runtimes de agentes open source: langchain, Semantic Kernel, llguidance oferecem serviços de runtime para apoiar o desenvolvimento estável de aplicações de IA
- A especificação de uma MVM exige que os dados de treinamento do modelo reflitam a especificação da interface, tornando necessária uma coevolução entre modelo e MVM
Benefícios da MVM
- Separação de responsabilidades: separa a lógica do modelo da lógica de integração, transformando o modelo em um componente substituível
- Isso preserva a interoperabilidade ao trocar por um novo modelo ou migrar de plataforma
- Segurança e governança embutidas: a MVM garante segurança por meio de verificação de permissões, logs de auditoria e proteções
- Como no AC4A, a MVM atua como guardiã para conter comportamentos inesperados
- Rastreamento transparente de desempenho: diagnósticos em runtime fornecem visibilidade sobre desempenho do modelo, consumo de recursos e nível de acesso a dados
- Com benchmarks, é possível comparar precisão, utilidade e responsividade
- Validação da saída do modelo: tecnologias como provas de conhecimento zero podem verificar a integridade da saída, reforçando confiança e responsabilização
Conclusão
- Uma máquina virtual para modelos de IA é necessária para reduzir a complexidade dos sistemas de IA e aumentar a interoperabilidade
- Ela fortalece segurança, privacidade, portabilidade e confiabilidade, além de acelerar o desenvolvimento e ampliar a escalabilidade do ecossistema
- Com base em pesquisas de empresas de tecnologia, startups e academia, a especificação de MVM pode oferecer um padrão para que modelos de IA interajam de forma segura e fluida
- O objetivo é construir, em colaboração com a comunidade, um consenso sobre a necessidade da especificação de MVM e os elementos que ela deve incluir
1 comentários
Comentários no Hacker News
Acho que este texto carece de explicações concretas, então não dá para saber exatamente o que está propondo. VM (Virtual Machine), no fim das contas, está associada a conjunto de instruções, fluxo de controle, registradores etc., mas este texto só foca em autorização. No fim, parece estar falando de 'algo parecido com sandbox, jail ou container que permita ao modelo interagir com o mundo externo'
Fico na dúvida se ele está realmente falando de um motor de execução de VM, ou de um Docker para LLM. No geral, parece mais uma ideia bem embalada do que algo substancial. Acho que um sistema de empacotamento mal projetado pode virar um desastre. Basta olhar para as várias experiências de empacotamento em Python
Ao ver a palavra VM, imediatamente senti que ela estava bem próxima de sandbox. Como o texto também fala em 'isolamento', não achei ambíguo nem senti falta de informação. Dito isso, a tese do autor é óbvia demais, e a solução é incompleta. Mesmo se você colocar isso num sandbox em nível de OS ou hardware, ainda é problemático se o agente encontrar algo como uma AWS CLI com IAM mal configurado. Os limites remotos também são complicados. Não encontrei nenhum insight novo. Não acho que a escolha de termos seja o problema
Pela definição dada no texto, daria para dizer que os agentes de IA atuais já estão rodando em VMs. Por exemplo, um host MCP pode pedir a aprovação do usuário para executar algo, ou é possível definir regras como no Claude Code, que aprovam automaticamente comandos que sigam certos padrões
Acho que a questão essencial não é quais ferramentas dar ao LLM, mas quais ações ele deve poder realizar. Por exemplo, num cenário de reserva de passagem aérea, eu quero que o LLM compare preços em vários sites e até faça o pagamento. Mas não quero que ele escolha inutilmente uma passagem de 37 horas só porque custa 3 dólares a menos. Numa consulta de benefícios, ele só deveria poder ver os meus dados, e não os de um colega. Mesmo com a mesma ferramenta, o escopo das permissões muda. Um profissional de RH naturalmente pode ver as informações dos funcionários que administra, mas aí surgem questões adicionais como trilhas de auditoria. Ou seja, mais importante do que a ação é a intenção (
intent). O ideal é colocar o LLM como representante do usuário, dentro da mesma caixa de permissõesNo fim, isso é um capability security model. Você precisa passar explicitamente ao agente de software as capabilities às quais ele pode acessar, e tornar fisicamente impossíveis as ações fora dessa lista. Mas, na prática, não existe nenhum OS mainstream que implemente esse modelo. Houve muitas pesquisas e tentativas (exemplos de OS: EROS, Fuchsia, Sandstorm), mas nada disso teve muito sucesso no mercado. Então, na prática, o jeito mais próximo é usar uma VM e colocar nela apenas as ferramentas necessárias. Isso não é perfeito, porque as próprias ferramentas são genéricas demais em comparação com capabilities reais. Software construído sob o princípio do menor privilégio costuma fracassar com frequência no mercado
O importante não é quais ações uma ferramenta pode executar, mas a combinação entre os dados aos quais ela tem acesso e as ações que pode realizar. Como não dá para prever perfeitamente o comportamento do LLM, ele não deve ser tratado como confiável. Por exemplo, você pode permitir ao LLM acesso apenas a sites de reserva de voo, mas sem repassar SSN, informações de conta bancária e afins. Isso é um problema de proveniência de dados e permissões. Quanto mais sensível for a tarefa, mais restrições ela precisa; quanto menos sensível, mais ações podem ser permitidas. Os dados precisam carregar informações de permissão, e um mediator deve limitar quais dados e ações uma nova tarefa gerada (
spawn) pode receber. Exemplo: se uma tarefa de planejamento de viagem gerar uma subtarefa de busca de passagens, o mediator deve passar para a subtarefa apenas dados não sensíveis, como parte do itinerário, e bloquear o acesso a dados sensíveisDá para ver o agente LLM como outro usuário, igual ao usuário humano. Ele tem permissões diferentes conforme o contexto (
context). Por exemplo, em uma pasta de código-fonte ele pode ter leitura e escrita, e em outra apenas leitura. As permissões do agente LLM variam por projeto, e são a interseção ou subconjunto das permissões do usuário. Basicamente há três tipos de permissão: Allow, Deny e Ask (pedir autorização). Quando necessário, ele pergunta ao usuário se pode prosseguir. O problema é que as permissões existentes em OSs, apps e dados ainda não são granulares o bastante. Até o git deveria ser projetado para permitir apenas certos comandos, em vez de acesso total. Hoje os aplicativos tentam imitar isso no espaço do usuário, de forma meio improvisada. O fluxo lembra osudo. Se eu iniciar um app como meu usuário de agente LLM, as permissões são concedidas ou restringidas conforme aquele contexto. Ele só pode agir dentro do que eu permito e quando eu peço. Mas, no momento, cada app agentic precisa implementar esse processo por conta própria, então isso deveria virar um serviço sistemático do OS. Como paliativo, dá para contornar criando e apagando contas temporárias de usuário por contexto do agente, comunicando-se apenas por IPC ou redeTenho dúvidas se esse modelo realmente funcionaria. Mesmo que o LLM consiga fazer algo, os sites podem detectar isso, ajustar preços ou quebrar as árvores de decisão. Nesse caso, seria muito melhor se todos os sites simplesmente oferecessem APIs para LLM, ou algo como 'rss + json'. Assim como BBS e sistemas de menu por SMS, bastaria fornecer dados simples e opções de escolha, o que é ideal para LLM. O mesmo vale para publicidade. Não faz sentido mostrar anúncios para um LLM; pior, anúncios feitos para enganar LLM podem ser ainda mais eficazes. Por exemplo, numa busca de voos, um anúncio pode seduzir o LLM e convencê-lo de que meu produto é o melhor. Como a IA ainda é simples, seria até curioso ver anúncios voltados especificamente para IA
Se for possível definir e impor o que é uma “boa resposta”, talvez nem seja necessário usar o próprio LLM. No caso de RH, dá para perguntar diretamente a intenção, mas com LLM isso é difícil porque ele não tem intenção própria
Outro dia vi um post no HN dizendo que o John Carmack desperdiçou tempo e dinheiro na Meta tentando criar o XROS. O texto de hoje, ao contrário, parece defender com força a necessidade de um ‘novo OS’. VM não é um OS completo, mas se diferencia por poder ser algo leve e aproveitar OSs e codebases já existentes
Os dois textos falam de coisas completamente diferentes. Na verdade, nem acho que este texto defenda fortemente a necessidade de VMs ou de um novo OS. No fim, tudo gira em torno de access control
Em XR, o foco era performance e dev experience, enquanto no lado de LLM a questão central é justamente como fazer sandboxing e simplificar o acesso a ferramentas e dados. Há muito trabalho para evitar que o LLM estrague o ambiente de execução ou corrompa dados, e ter um padrão reduziria o custo de retreinamento e facilitaria o uso dos modelos de outras pessoas. Em XR, se fosse só um SDK, treinamento talvez bastasse, mas em IA os custos de P&D e compute são muito maiores
WebAssembly já fornece sandbox por padrão, então eu diria que já chegamos à metade do caminho. O que falta é uma interface clara para transferir dados e permissões entre instâncias, além de um modo de uma instância criar outra
Não acho que este texto justifique escrever um novo OS. Construir um ambiente de execução para IA e projetar do zero um OS otimizado para IA são coisas completamente diferentes
Depois de ler o texto com atenção e ver os links de referência, fiquei com a sensação de que ele está apontando para um problema mais fundamental do que simplesmente “uma VM para IA”. Só a VM não basta para garantir a segurança de workflows com LLM. O workflow de nível mais alto precisa acessar rede, PII, credentials e outros dados e tarefas sensíveis, e LLMs são vulneráveis a prompt injection e problemas de consistência. Colocar o LLM dentro de uma VM, por si só, não resolve isso. É preciso fazer particionamento por unidade de trabalho — workflow, dados e computação — para que apenas subtarefas mínimas acessem informações limitadas: isso é 'controle de fluxo de informação'. Só o subconjunto responsável por tarefas sensíveis deve ser confiado e validado separadamente. O ponto central aqui são os “Secure Orchestrators” mencionados no texto e o artigo FIDES. No fim, a “VM” é apenas executar uma tarefa dentro de um container que recebeu permissões e dados limitados. O orchestrator cria esse container, atribui as permissões corretas e ainda precisa rotular os dados produzidos com sensibilidade (
taint-tracking). No geral, acho mais adequado enfatizar “partitioning”, “isolation” e as questões de dados do que a expressão “VM for AI”Isso soa parecido com o Microsoft Wassette
O objetivo deveria ser eliminar a própria ideia de workflow. Na combinação LLM+VM, o simples ato de fornecer ferramentas ao LLM já é um workflow. Esse método às vezes funciona bem, mas tem limites para tarefas que exigem ferramentas ou exceções não definidas de antemão. Além disso, uma abordagem baseada em workflow dificilmente escapa de limitações lineares (ou de DAGs, com loops incluídos). O próximo passo é não fornecer ferramentas prontas, e sim deixar o próprio LLM criar as ferramentas sob demanda sempre que precisar. Alguns problemas exigem uma abordagem de brute force
Enquanto lia, tive a sensação de que muitos textos de hoje em dia parecem ter sido escritos por IA. Do ponto de vista de hospedagem, já é um grande desafio simplesmente executar agentes de IA de forma estável em qualquer ambiente. Como desenvolvedor, uso rootless docker devcontainer no WSL; algum malware talvez consiga escapar, mas ainda assim sinto que essa abordagem é mais segura do que a via de VM. Além disso, ela traz vantagens como reprodutibilidade e separação de ambiente, e se a IA bagunçar meu ambiente, basta recriar o container
Se você olhar para as formas comercialmente mais avançadas de deploy de modelos, quase todas as características citadas no texto, como isolamento, já estão implementadas. Não é no nível de um OS, mas funcionalmente é parecido. Ainda assim, isso não basta. Para um agente funcionar de verdade, ele precisa de acesso a recursos importantes, e conceder exatamente o mínimo necessário é muito mais difícil do que isolar o próprio LLM. O modelo correto para segurança de LLM é o de 'untrusted userspace'. Não é preciso projetar o OS inteiro
Concordo com a ideia de que o isolamento de LLM deve ser tão rigoroso quanto o nível de projeto de uma VM. É a mesma razão pela qual OSs tradicionais aplicam esse tipo de conduta com rigor. Recentemente organizei algumas ideias neste blog. A abordagem compara o modo de operação de LLMs com processos e tarefas de OS tradicionais, e as principais abstrações não são difíceis de implementar — dá para unificar a interface de chat/tool de 8 backends de LLM e centralizar a aprovação de ferramentas. Ainda não implementei o modelo de capabilities, mas, pela minha experiência passada com OSs (VSTa), isso parece natural. Um LLM deve poder delegar a outro um subconjunto das permissões que possui, e eu já construí uma ferramenta de delegation
Acho que criar uma nova máquina abstrata, como uma VM, só aumenta a complexidade. Já temos contas, permissões de leitura/escrita/execução de arquivos, e acesso temporário ou remoto pode ser coberto com access tokens. Acho que qualquer capability model pode ser implementado suficientemente com esses conceitos. Prefiro simplificar as ferramentas que já existem. Em vez de esperar por uma transformação fundamental de todo o software, acho que este momento — em que todo mundo está experimentando coisas novas — deveria ser usado para reduzir complexidade desnecessária e tornar tudo mais simples. Por exemplo, transformar um servidor MCP em uma ferramenta CLI simples para o Claude leva 10 minutos. Isso já me parece suficientemente útil
O modelo de segurança dos OSs desktop modernos é absurdamente insuficiente para os tempos atuais. Entregar todas as permissões sem praticamente nenhum aviso ou confirmação ao usuário chega perto da insanidade. Se o usuário realmente quiser um ambiente sem restrições, ele deveria poder escolher isso, mas o padrão precisa ser o menor privilégio. Cada programa deveria receber apenas permissões específicas por domínio. Por exemplo, uma ferramenta de visualização de uso de disco talvez precise de acesso amplo ao sistema de arquivos, mas não precisa de acesso à rede local nem à internet
A maior força de uma VM é limitar o raio de dano. Um agente bom pode usar zero days dentro do sistema e comprometê-lo com facilidade. Mesmo só com permissões de usuário isso já é perigoso, e é muito difícil limitar o conhecimento do agente como se fosse um firewall, porque há muitos meios de contorno na internet. Esses sistemas vão ficar muito bons em invadir sistemas, então serão necessários mecanismos de segurança extremamente robustos
Em ambientes com LLM, a ideia de leitura única ('temporary read') não se sustenta. No instante em que algo entra no contexto, é preciso assumir que os dados podem vazar para qualquer lugar conectado até que o agente morra e o contexto seja apagado. Isso vale tanto com VM quanto sem VM; VM sozinha não é solução de segurança
Concordo em grande parte. Muitos riscos de segurança existem independentemente de haver VM ou não. Daqui para frente, defense in depth vai ficar ainda mais importante, mas hoje já existem meios fáceis demais para que atacantes usem agentes de IA para prejudicar usuários
No momento em que você permite uma ferramenta de edição de arquivos, na prática perde quase toda a segurança
Acho que o Fuchsia pode ser um OS realista para controlar o comportamento de modelos de IA. Como é um object capability OS, cada componente (processo) só pode acessar capabilities explicitamente concedidas
Quando o ChatGPT executa código (por exemplo, ao processar um CSV), parece rodar em uma VM com acesso apenas a ferramentas e bibliotecas específicas, disco em sandbox e sem acesso à internet. No fim, já estamos indo para algo bem parecido com isso
Devin e OpenHands são parecidos. Num projeto-piloto de IA que conduzi alguns meses atrás, “executar o agente em uma VM (por padrão)” era um elemento central
É uma pilha com Kubernetes baseado em AKS (Azure Kubernetes),
gvisore Jupyter por cimaNão necessariamente. Por exemplo, se você imaginar duas IAs (como o ChatGPT) rodando na mesma máquina, não existe nenhum padrão nem interoperabilidade em termos de colaboração ou operação conjunta.