Por Que Seus Agentes de IA Precisam de Uma Casa Própria: MicroVMs ao Resgate

Serei direto: agentes de IA para programação são impressionantes. Eles resolvem bugs, escrevem funcionalidades e refatoram código num ritmo que, há poucos anos, a gente só via em ficção científica. Mas tem um detalhe que pouca gente comenta — esses caras também conseguem acessar coisas que você definitivamente não quer que eles toquem.

Vai deixar ele explorar seu cluster Kubernetes? Pode fazer. Quer que ele dê SSH em servidores de produção? Sem problemas. Rodar comandos com privilégios de root? Se você permitir, sim.

O ponto-chave aqui é: você quer toda essa força computacional, mas também quer dormir tranquilo sabendo que seu ambiente de produção está protegido. A solução? Isolamento — e mais especificamente, usar microVMs para dar a esses agentes um cantinho só deles no seu sistema.

O Lado Inconveniente da Realidade

Vamos ser sinceros: rodar agentes de IA em modo automático é basicamente executar código não confiável na sua máquina. As empresas que desenvolvem essas ferramentas não estão tentando roubar suas credenciais — isso não faz parte do modelo de negócio delas. Porém, a internet é criativa, e técnicas como injeção de prompt e slopsquatting estão cada vez mais sofisticadas.

Esses agentes têm proteções internas, claro. Mas proteções não são muros intransponíveis, e novas vulnerabilidades aparecem o tempo todo. Basta ver as recentes brechas de sandbox — elas mostram que ferramentas leves como bwrap, embora úteis, não são fortalezas impenetráveis.

Containers são outra opção, mas tem um problema: eles compartilham o kernel do host. Vulnerabilidades recentes no kernel demonstraram potencial de escalação de privilégios, o que significa que um atacante determinado pode conseguir escapar do isolamento do container. Para uma barreira de segurança, isso não é ideal.

É aí que as microVMs entram como alternativa interessante. Diferente dos containers, cada microVM roda seu próprio kernel. Mesmo que alguém encontre uma vulnerabilidade no kernel, fica preso dentro daquela microVM específica. É segurança por isolamento — e funciona muito bem na prática.

O Que São MicroVMs, Exactly?

Se você conhece máquinas virtuais tradicionais, já entende o conceito: isolamento total com kernel próprio, recursos de sistema próprios, tudo próprio. A desvantagem sempre foi que VMs são pesadas — levam minutos para inicializar, consomem RAM significativa, e geralmente parecem um canhão para matar uma mosca.

MicroVMs invertem essa lógica. Mantêm os benefícios de segurança das VMs tradicionais (kernel separado, isolamento forte) mas inicializam em centenas de milissegundos em vez de minutos. Você ganha a barreira de segurança de uma VM com o consumo de recursos mais próximo de um container.

No Fedora Linux, existe uma solução elegante usando o runtime krun para o Podman. Isso significa que você pode usar o mesmo fluxo de trabalho que já conhece para containers, mas com isolamento de microVM por baixo dos panos. Sem ferramentas novas para aprender, sem configuração complexa — basta trocar o runtime.

Mãos à Obra: Instalação

Instalar o runtime krun no Fedora é simples:

dnf install crun-krun

Com isso instalado, rodar uma microVM é praticamente igual a rodar um container normal:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Pronto. Agora você tem uma microVM totalmente isolada rodando Fedora. Mesmo fluxo que você já conhece, mas com barreiras de segurança mais robustas.

Detalhes Práticos para Não Esquecer

MicroVMs não são containers comuns, então alguns pontos merecem atenção:

Reserve recursos suficientes. Os padrões podem ser modestos demais para um agente de IA que precisa compilar código, rodar testes e gerenciar arquivos do projeto. Use anotações do krun para garantir CPU e RAM adequadas — caso contrário, pode enfrentar kills por OOM no pior momento possível.

Verifique a versão do libkrun. Versões anteriores à 1.8 têm um bug que atrapalha a entrada de teclado. Se você não conseguir pressionar Enter no seu agente de IA, provavelmente é isso. Atualize para evitar dores de cabeça.

O tratamento de usuários é diferente. A microVM sempre inicializa como root, independente da diretiva USER que você colocou no Dockerfile. Você vai precisar trocar de usuário manualmente depois ou incluir essa troca no seu script de entrypoint.

Setup Completo: Claude Code no Sandbox

Vamos a um exemplo real: isolar o Claude Code para um projeto Python usando uv para gerenciamento de pacotes. Vamos usar Podman Compose para orquestrar tudo.

Primeiro, instale o Podman Compose:

dnf install podman-compose

O setup tem três arquivos: Dockerfile, docker-compose.yaml e um script de entrypoint.

O Dockerfile

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Cria grupo e usuário com UID/GID do host
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Ferramentas que mudam pouco
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# RPMs que mudam com frequência
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

Alguns pontos importantes aqui: criamos um usuário sem privilégios, instalamos as ferramentas necessárias (uv e Claude Code), e organizamos o Dockerfile para que dependências que mudam bastante fiquem no final. Isso otimiza o cache de build — você não vai precisar reinstalar o uv cada vez que adicionar um novo pacote.

O Compose File

O docker-compose.yaml cuida de montar o diretório do seu projeto, definir labels do SELinux e configurar alocação de recursos. É aqui que as microVMs diferem um pouco dos containers comuns — você precisa lidar com tradução de UID/GID e pedidos explícitos de recursos de hardware.

O Script de Entrypoint

O entrypoint cuida da troca de usuário que mencionamos antes. Como microVMs sempre inicializam como root, esse script precisa trocar para seu usuário sem privilégios antes de entregar o controle para o shell ou para o agente de IA.

Vale a Pena Todo Esse Trabalho?

Com certeza. Veja o retorno: você usa agentes de IA poderosos sem dar a eles acesso irrestrito à sua estação de trabalho, suas credenciais de cluster ou seu ambiente de produção. O isolamento é real — kernel separado, namespace separado, tudo separado.

A complexidade de setup é mínima comparada aos benefícios de segurança. E uma vez que você tem a infraestrutura pronta, criar ambientes isolados para agentes vira algo corriqueiro.

Para desenvolvedores e equipes que lidam com codebases sensíveis, fazem deploy em clusters de produção, ou trabalham em indústrias reguladas, isso não é opcional — é essencial. Agentes de IA são ferramentas, e como toda ferramenta poderosa, precisam de medidas de segurança adequadas.

Para Terminar

MicroVMs no Fedora Linux representam um meio-termo prático entre a segurança da virtualização completa e a praticidade dos containers. Inicializam rápido, isolam bem, e se integram perfeitamente com fluxos de trabalho existentes do Podman.

Se você está usando agentes de IA no seu workflow de desenvolvimento, especialmente em modo automático, considere dar a eles um sandbox de microVM. Seu eu do futuro — e seu time de segurança — vão agradecer.

As ferramentas existem. A documentação é sólida. E a tranquilidade? Essa não tem preço.