Vercel Sandbox agora controla a rede, não só o processo

Rodar código não confiável com segurança sempre foi um problema de isolamento. A tese que a Vercel defende em seu changelog, assinado por Brandon Tuttle, engenheiro de compute, é que esse isolamento vinha sendo pensado pela metade: separar o processo do host resolve o que o código pode tocar na máquina, mas não o que ele consegue alcançar (ou atacar) pela rede.

A frase-síntese do texto é direta: isolamento sem controle de egress contém o processo, não as consequências. E isso ganha peso agora que agentes de IA leem arquivos, executam comandos, instalam pacotes e geram programas próprios.

Por que uma microVM não basta

O exemplo do artigo é o cenário típico de 2026: um agente que lê um repositório e roda código gerado. Uma injeção de prompt escondida numa issue, num log, numa dependência ou no próprio código-fonte pode instruir esse agente a vazar dados privados. E aqui está o ponto que muda a cabeça de quem projeta esses ambientes: o programa gerado não precisa escapar da microVM. Com tráfego de saída irrestrito, ele simplesmente manda pra um servidor externo tudo o que conseguir ler.

A mesma saída de rede serve para escanear redes internas, exfiltrar credenciais ou chamar uma API autenticada. Do ponto de vista do atacante, cruzar a fronteira da VM pode ser desnecessário. Como o texto resume, sem fronteira de rede é "apenas meia sandbox".

A Vercel cita pesquisa de segurança recente para reforçar que um bypass de rede equivale, na prática, a um escape de sandbox. Os caminhos que falham quase nunca são o kernel ou a VM: são um resolver DNS deixado disponível num ambiente supostamente desconectado, uma allowlist vazia que falha aberta, um hostname interpretado de forma diferente entre a engine de política e o proxy, ou um serviço de pacotes confiável transformado em relay. A fronteira de segurança real, argumentam, inclui DNS, proxies, serviços de identidade e cada destino intencionalmente permitido.

O que muda para quem desenvolve serverless e edge

O recado prático para times brasileiros que já operam funções serverless e edge é sobre estratégia de isolamento. Desconectar totalmente a sandbox fecha o buraco, mas inviabiliza casos reais: clonar repositório, instalar dependência, chamar um modelo de IA, consultar um banco, subir o resultado. A proposta é conectividade seletiva, concedendo só o que o workload precisa:

• Liberar um provedor de IA, e nenhum outro destino público.
• Liberar um bucket de object storage específico, não a rede inteira da nuvem.
• Alcançar um serviço privado enquanto bloqueia o resto do espaço de endereços privados.
• Instalar dependências no setup confiável e remover o acesso ao registry antes de o código gerado rodar.

Um detalhe importante de design: domínios e CIDRs resolvem problemas diferentes. Políticas por domínio são precisas para serviços modernos cujos IPs mudam ou que servem muitos hostnames num mesmo endereço; políticas por CIDR funcionam entre protocolos e controlam infraestrutura fixa e redes privadas. E a conectividade pode ser temporária, mudando ao longo do ciclo de vida do workload sem reiniciar nada.

Como o firewall funciona por baixo

O firewall da Vercel Sandbox roda no host, fora da microVM, onde o código de dentro não consegue modificar nem desligar. O networking do Linux redireciona conexões TCP de saída e queries DNS para o firewall de forma transparente, sem precisar configurar proxy no workload.

Para conexões restritas por domínio, o firewall inspeciona o começo do handshake TLS e extrai o SNI (Server Name Indication) para identificar o hostname antes de abrir a conexão upstream. Conexões TLS permitidas passam sem descriptografia: o firewall lê só o handshake não criptografado necessário para aplicar a política. Quando é preciso inspecionar ou modificar a requisição HTTP, ele termina o TLS seletivamente usando uma CA exclusiva daquela sandbox.

Credenciais fora do compute não confiável

Esse é o ponto mais interessante da abordagem. Uma credencial numa variável de ambiente ou arquivo é um bearer token transferível: qualquer programa dentro da sandbox lê, e código malicioso pode copiar para um serviço externo e usar depois que a sandbox já morreu.

A Vercel injeta a credencial na fronteira de rede do host. Para um destino configurado, o firewall termina o TLS, adiciona ou substitui o header de autenticação e abre uma nova conexão TLS com o serviço upstream. A credencial nunca entra na microVM e o firewall só a envia ao destino configurado. Dá para restringir ainda mais por path, método, query ou headers, de modo que o código gerado receba permissão para enviar resultado a um endpoint sem poder ler outros recursos da mesma API.

O exemplo da fonte mostra uma política que libera só ai-gateway.vercel.sh e injeta o Authorization sem colocar o token dentro da sandbox, com tudo mais negado por padrão. A política também pode ser trocada em tempo de execução via sandbox.update({ networkPolicy: 'deny-all' }).

O argumento de fundo é que segurança pertence ao baseline: a Vercel diz ter liberado o firewall de egress completo para todas as Sandboxes, sem exigir upgrade. Vale a leitura da documentação do firewall para quem for adotar. A conclusão que fica: uma sandbox não se define só por onde o código roda, mas por o que ele consegue alcançar.

Fonte: Vercel Changelog