0Pricing
AI Agents · Aula

Isolamento por VM para agentes de código de alta segurança

gVisor, microVMs Firecracker e isolamento em nível de hardware para agentes.

Isolamento por VM para agentes de código de alta segurança é uma aula grátis de AI Agents no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de AI Agents, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de AI Agents inclui 4 aulas no total.

Além do Docker: isolamento mais forte

Os contêineres padrão do Docker compartilham o núcleo do sistema hospedeiro. Uma exploração do núcleo dentro do contêiner pode escapar para a máquina hospedeira. Para a execução de código com alta segurança, são necessárias camadas de isolamento mais fortes.

Duas abordagens importantes são: gVisor (proxy de núcleo no espaço do usuário) e Firecracker (microVMs leves).

Como o gVisor funciona

O gVisor insere um componente no espaço do usuário chamado Sentry entre o contêiner e o núcleo do sistema hospedeiro. As chamadas de sistema do contêiner vão para o Sentry, que reimplementa um subconjunto seguro em Go, em vez de usar o núcleo real.

O ambiente de execução é chamado de runsc (contêiner executado em ambiente isolado).

# Configure Docker to use gVisor runtime (runsc)
# /etc/docker/daemon.json:
# {
#   "runtimes": {
#     "runsc": { "path": "/usr/local/bin/runsc" }
#   }
# }

import docker
client = docker.from_env()

output = client.containers.run(
    'python:3.12-slim',
    'python -c "print(\"hello from gVisor\")"',
    runtime='runsc',          # use gVisor
    network_disabled=True,
    auto_remove=True
)
print(output.decode())

Interceptação de chamadas de sistema pelo gVisor

Quando o código dentro do contêiner chama open(), read() ou socket(), o gVisor intercepta a chamada de sistema e decide se deve permiti-la, emulá-la ou bloqueá-la.

Chamadas de sistema sensíveis, como ptrace ou a criação de soquetes brutos, são bloqueadas por padrão, eliminando vetores comuns de exploração.

# gVisor blocks dangerous syscalls like ptrace.
# This code would fail inside a gVisor container:
#
# import ctypes
# libc = ctypes.CDLL(None)
# libc.ptrace(...)   # EPERM: Operation not permitted
#
# Normal Python I/O and computation works fine:
# open(), read(), write(), socket() (if network enabled)
# are all emulated safely by Sentry.
print('gVisor intercepts syscalls before they reach the host kernel')

Compromisso de desempenho do gVisor

Toda chamada de sistema passa pelo Sentry, em vez de ir diretamente para o núcleo. Isso acrescenta uma sobrecarga de aproximadamente 10–30% em cargas de trabalho intensivas em E/S. Para cálculos limitados pela CPU, a sobrecarga é muito menor.

O tempo de inicialização é semelhante ao do Docker comum — milissegundos.

import time
import docker

client = docker.from_env()

start = time.time()
client.containers.run('python:3.12-slim', 'python -c "pass"',
                      runtime='runsc', auto_remove=True)
print(f'gVisor startup: {time.time()-start:.2f}s')   # ~0.3-0.8s

start = time.time()
client.containers.run('python:3.12-slim', 'python -c "pass"',
                      auto_remove=True)
print(f'Docker startup: {time.time()-start:.2f}s')   # ~0.1-0.3s

MicroVMs do Firecracker

O Firecracker adota uma abordagem completamente diferente: executa cada carga de trabalho em uma máquina virtual completa com seu próprio núcleo. A VM é inicializada em aproximadamente 50 ms e usa apenas cerca de 5 MB de memória adicional.

Como as VMs têm um núcleo completamente separado, não há uma superfície de ataque de núcleo compartilhado.

# Firecracker is controlled via a REST API on a Unix socket.
# Python SDK example (firecracker-python-sdk or direct HTTP):

import requests_unixsocket

session = requests_unixsocket.Session()
base = 'http+unix://%2Ftmp%2Ffirecracker.socket'

# Boot the microVM
session.put(f'{base}/boot-source', json={
    'kernel_image_path': '/opt/kernel/vmlinux',
    'boot_args': 'console=ttyS0 reboot=k panic=1 pci=off'
})
session.put(f'{base}/actions', json={'action_type': 'InstanceStart'})
print('MicroVM booted in ~50ms')

Modelo de segurança do Firecracker

As VMs do Firecracker têm uma superfície de ataque mínima por projeto. O VMM expõe apenas 5 tipos de dispositivos (virtio-net, virtio-block, serial, RTC, teclado). Sem USB, sem barramento PCI e sem BIOS.

Cada VM é isolada no nível do hipervisor — uma exploração do núcleo dentro da VM não consegue alcançar a máquina hospedeira.

# Firecracker security properties:
# 1. Each microVM has its own Linux kernel instance
# 2. Guest-to-host attack surface is tiny (5 device types)
# 3. The VMM (Virtual Machine Monitor) runs unprivileged
# 4. No shared memory between VMs
# 5. Snapshot/restore: freeze a running VM, clone it for next request

# Used in production by:
# - AWS Lambda (each function invocation = Firecracker microVM)
# - Fly.io (each app container)
# - Replit (code execution)
print('Firecracker: full VM isolation at container startup speed')

Kata Containers: combinando as duas abordagens

O Kata Containers usa uma VM leve (pode usar Firecracker ou QEMU), mas expõe a interface padrão de contêineres OCI. O usuário executa comandos normais do Docker; o Kata gerencia a camada de VM de forma transparente.

import docker
client = docker.from_env()

# Kata Containers registered as 'kata-runtime' in daemon.json
output = client.containers.run(
    'python:3.12-slim',
    'python -c "import platform; print(platform.node())"',
    runtime='kata-runtime',   # each container = a VM
    mem_limit='256m',
    network_disabled=True,
    auto_remove=True
)
print(output.decode())  # unique VM hostname

Escolha do nível de isolamento adequado

O ambiente isolado adequado depende do seu modelo de ameaças e do seu orçamento de latência:

  • Docker (runc): rápido, baixa sobrecarga, núcleo compartilhado — adequado para código confiável ou levemente filtrado
  • gVisor (runsc): filtragem de chamadas de sistema, mesmo formato de imagem, sobrecarga moderada — bom equilíbrio
  • Firecracker/Kata: isolamento completo por VM, inicialização em 50 ms — para código de usuário não confiável em escala

Tabela de segurança versus latência de inicialização

A profundidade do isolamento e a velocidade de inicialização são inversamente relacionadas. Escolha com base na latência aceitável para o caso de uso do seu agente.

# Isolation vs Latency summary:
#
# Runtime          | Isolation     | Startup  | Overhead
# -----------------|---------------|----------|----------
# runc (Docker)    | Namespace      | ~100ms   | ~0%
# gVisor (runsc)   | Syscall filter | ~300ms   | ~15-30%
# Kata Containers  | Full VM        | ~500ms   | ~10%
# Firecracker      | Full VM        | ~50ms    | ~5%
# QEMU KVM         | Full VM        | ~1-2s    | ~5%
#
# For interactive agent tools: gVisor is usually the sweet spot.
# For high-throughput batch jobs: Firecracker snapshots.

ISOLATION_OPTIONS = {
    'runc (Docker)':   {'isolation': 'Namespace',      'startup': '~100ms', 'overhead': '~0%'},
    'gVisor (runsc)':  {'isolation': 'Syscall filter',  'startup': '~300ms', 'overhead': '~15-30%'},
    'Kata Containers': {'isolation': 'Full VM',         'startup': '~500ms', 'overhead': '~10%'},
    'Firecracker':     {'isolation': 'Full VM',         'startup': '~50ms',  'overhead': '~5%'},
    'QEMU KVM':         {'isolation': 'Full VM',        'startup': '~1-2s',  'overhead': '~5%'},
}

for runtime, info in ISOLATION_OPTIONS.items():
    print(f"{runtime:<17} | {info['isolation']:<14} | startup {info['startup']:<7} | overhead {info['overhead']}")

Pré-inicialização de ambientes isolados

Inicializar uma VM do zero para cada solicitação do agente acrescenta latência. Os sistemas de produção pré-inicializam um conjunto de ambientes isolados inativos. Quando chega uma solicitação, um ambiente isolado pronto é reservado, usado e depois destruído (nunca reutilizado).

import queue, threading

SANDBOX_POOL_SIZE = 5
pool = queue.Queue()

def pre_warm():
    'Start a sandbox and put it in the pool.'
    container = client.containers.create(
        'python:3.12-slim',
        'tail -f /dev/null',
        runtime='runsc',
        mem_limit='256m',
        network_disabled=True
    )
    container.start()
    pool.put(container)

# Pre-warm the pool at startup
for _ in range(SANDBOX_POOL_SIZE):
    threading.Thread(target=pre_warm, daemon=True).start()

def claim_sandbox():
    return pool.get(timeout=5)  # blocks until one is ready

Captura e restauração para obter escala

O Firecracker permite capturar em disco o estado de uma VM em execução. A captura inclui o estado da memória, o estado dos dispositivos e os registradores da CPU. A restauração a partir da captura leva aproximadamente 10 ms — muito menos que uma inicialização do zero.

Esse padrão permite inicializar um interpretador Python uma vez, capturar seu estado e restaurá-lo para cada solicitação.

# Firecracker snapshot workflow:
# 1. Boot microVM, run Python interpreter, wait for REPL ready
# 2. Pause VM
# 3. Create snapshot
#    PUT /snapshot/create { snapshot_path, mem_file_path }
# 4. For each request:
#    PUT /snapshot/load { snapshot_path, mem_file_path }
#    # VM resumes from paused state with Python already loaded
#    # Send code via stdin/virtio-serial, read output
# 5. Discard VM after request (never reuse)

print('Snapshot restore: ~10ms vs 50ms cold boot for Firecracker')

Qual componente o gVisor insere entre o contêiner e o núcleo do sistema hospedeiro?

O modelo de isolamento do gVisor depende de um componente específico que intercepta chamadas de sistema. Compreender essa arquitetura é fundamental para avaliar suas garantias de segurança.

Recapitulação do isolamento por VM

Para a execução de código de agente com alta segurança, vá além do Docker padrão e use gVisor (interceptação de chamadas de sistema, baixa sobrecarga) ou Firecracker (VM completa, inicialização em 50 ms, aproximadamente 5 MB de memória adicional).

O compromisso é sempre entre profundidade do isolamento e latência de inicialização. Conjuntos pré-inicializados e capturas de VMs podem recuperar boa parte do custo de latência em produção.

Perguntas Frequentes

A aula “Isolamento por VM para agentes de código de alta segurança” é grátis?

Sim — o texto completo de “Isolamento por VM para agentes de código de alta segurança” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de AI Agents, atualize para CoddyKit PRO. O curso de AI Agents inclui 4 aulas no total.

O que vou aprender em “Isolamento por VM para agentes de código de alta segurança”?

gVisor, microVMs Firecracker e isolamento em nível de hardware para agentes. Você pratica AI Agents com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar AI Agents?

Nenhuma experiência prévia é necessária. AI Agents no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.

Quanto tempo leva a aula “Isolamento por VM para agentes de código de alta segurança”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de AI Agents?

Sim. Cada aula de AI Agents inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Ambientes isolados para agentes baseados em Docker
  2. Isolamento por VM para agentes de código de alta segurança
  3. E2B e serviços de ambientes isolados na nuvem
  4. Políticas de segurança para execução de código
← Voltar para AI Agents