Outbound Workers Autenticação Zero Trust para Agentes de IA em Sandboxes da Cloudflare

O Problema de Autenticação para Agentes de IA

Agentes de IA — sejam baseados em LLMs como Claude ou modelos customizados — estão cada vez mais sendo usados para automatizar tarefas: responder a mensagens de chat, atualizar quadros Kanban, comentar em issues do GitHub, e muito mais. Mas quando você executa esses agentes em um sandbox (uma microVM para segurança e isolamento), enfrenta um desafio fundamental: como autenticar o agente sem expor segredos?

Os métodos tradicionais têm desvantagens:

• Tokens de API injetados via variáveis de ambiente são simples, mas inseguros — um sandbox comprometido pode exfiltrar o token. Você precisa de rotação e expiração, o que adiciona sobrecarga operacional.
• Tokens de identidade de workload (OIDC) melhoram a segurança atestando a identidade do agente, mas muitos serviços não têm suporte OIDC de primeira classe, forçando você a construir serviços customizados de troca de tokens.
• Proxies customizados oferecem máxima flexibilidade, mas são difíceis de configurar — interceptar todo o tráfego de egresso, escrever regras dinâmicas e manter a performance não é trivial.

Os novos outbound Workers da Cloudflare para Sandboxes e Containers visam resolver isso de forma elegante. Eles são proxies de egresso programáticos que rodam na mesma máquina que o sandbox, são escritos em JavaScript simples e se integram perfeitamente com o ecossistema Workers.

Vamos mergulhar em como eles funcionam e por que são importantes para o desenvolvimento assistido por IA. Para contexto sobre a tendência mais ampla de codificação assistida por IA, confira nossa análise sobre Vibe Coding e suas armadilhas.

Como os Outbound Workers Funcionam: Exemplos de Código

Os outbound Workers interceptam todas as requisições HTTP(S) que saem do sandbox. Você define um handler — uma simples função JavaScript — que pode logar, modificar ou bloquear requisições. Aqui está o padrão básico:

class MySandboxedApp extends Sandbox {
  static outbound = (req, env, ctx) => {
    // Loga todas as requisições de saída
    console.log(`Requisição de saída: ${req.method} ${req.url}`);

    // Bloqueia requisições que não sejam GET
    if (req.method !== 'GET') {
      return new Response('Não Permitido', { status: 405 });
    }

    // Prossegue com a requisição
    return fetch(req);
  };
}

Injeção de Credenciais Zero Trust

A funcionalidade matadora: injetar segredos sem que o agente nunca os veja. Use outboundByHost para mirar domínios específicos:

class OpenCodeInABox extends Sandbox {
  static outboundByHost = {
    "meu-vcs-interno.dev": (request, env, ctx) => {
      const headersWithAuth = new Headers(request.headers);
      headersWithAuth.set("x-auth-token", env.SECRET);
      return fetch(request, { headers: headersWithAuth });
    }
  };
}

O agente no sandbox nunca tem acesso a env.SECRET — o proxy adiciona o token em tempo real. Isso é zero trust: nenhum token é concedido à workload não confiável.

Você também pode tomar decisões por container usando o ID do container:

static outboundByHost = {
  "meu-vcs-interno.dev": async (request, env, ctx) => {
    // KV é criptografado em repouso e em trânsito
    const authKey = await env.KEYS.get(ctx.containerId);
    const requestWithAuth = new Request(request);
    requestWithAuth.headers.set("x-auth-token", authKey);
    return fetch(requestWithAuth);
  }
};

Mudanças Dinâmicas de Política

Os outbound Workers podem ser alterados em tempo de execução. Por exemplo, permitir NPM e GitHub apenas durante a instalação de dependências, depois bloquear o egresso:

class MySandboxedApp extends Sandbox {
  static outboundHandlers = {
    async allowHosts(req, env, { params }) {
      const url = new URL(request.url);
      const permitido = params.allowedHostnames.includes(url.hostname);
      if (permitido) {
        return await fetch(newRequest);
      } else {
        return new Response(null, { status: 403 });
      }
    },
    async noHttp(req) {
      return new Response(null, { status: 403 });
    }
  };
}

async function configurarSandboxes(req, env) {
  const sandbox = await env.SANDBOX.getByName(userId);
  // Passo 1: Permitir apenas GitHub e NPM
  await sandbox.setOutboundHandler("allowHosts", {
    allowedHostnames: ["github.com", "npmjs.org"]
  });
  await sandbox.gitClone(userRepoURL);
  await sandbox.exec("npm install");
  // Passo 2: Bloquear completamente
  await sandbox.setOutboundHandler("noHttp");
}

Esse padrão minimiza a superfície de ataque — abra a rede apenas para o necessário, depois feche.

Limitações e Considerações

Embora os outbound Workers sejam poderosos, não são uma bala de prata:

• Complexidade do MITM TLS: Para inspecionar corpos de requisições HTTPS (para logging ou modificação), você precisa de interceptação TLS. A Cloudflare lida com isso usando CAs efêmeras por sandbox, mas isso adiciona overhead e requer configuração adequada de confiança de certificado.
• Overhead de performance: Embora o proxy rode na mesma máquina, toda requisição de saída agora passa por um handler JavaScript. Para cenários de alta taxa de transferência, faça benchmarks cuidadosos.
• Vendor lock-in: Esse recurso é específico da plataforma Cloudflare. Se você precisa de portabilidade, considere abstrair a camada de proxy.
• Complexidade de debug: Quando as requisições falham, rastrear o problema através do proxy pode ser mais difícil do que depurar uma chamada direta.

Próximos Passos para Aprendizado

• Mão na massa: Experimente o Guia de Introdução aos Sandboxes da Cloudflare para construir seu primeiro outbound Worker.
• Aprofundamento: Explore os pacotes @cloudflare/sandbox e @cloudflare/workers-sandbox para recursos avançados como troca dinâmica de handlers.
• Leitura relacionada: Se você é novo em padrões de desenvolvimento assistido por IA, nossa prévia do Python 3.15 Alpha 3 cobre melhorias na linguagem que podem simplificar ferramentas de agentes.

Conclusão

Os outbound Workers para Sandboxes da Cloudflare oferecem uma solução pragmática para o desafio de autenticação no desenvolvimento de agentes de IA. Combinando princípios de zero trust (sem exposição de tokens), flexibilidade (handlers JavaScript) e integração profunda com o ecossistema Workers (KV, R2, Durable Objects), eles permitem que desenvolvedores construam egresso seguro, observável e dinamicamente controlável para workloads em sandbox.

À medida que os agentes de IA se tornam mais autônomos, padrões de segurança como este se tornarão essenciais. Comece a experimentar com outbound Workers hoje — seu futuro agente agradecerá.