Control de Egresos en Sandboxes con Workers: Proxy Programable para Agentes LLM

El problema fundamental que aborda esta innovación es la gestión segura y flexible del egreso de red para cargas de trabajo no confiables, como los agentes de IA en entornos sandboxed. A medida que los Large Language Models (LLMs) se integran en flujos de trabajo automatizados, la necesidad de controlar estrictamente sus interacciones con servicios externos se vuelve crítica. Los métodos tradicionales de autenticación (tokens API, OIDC) presentan limitaciones en seguridad, flexibilidad o complejidad de integración, especialmente en escenarios donde la granularidad de permisos es vital y la confianza en el workload es mínima.

La solución propuesta, 'Outbound Workers', resuelve esto al interponer un proxy programable en el camino de cada solicitud de egreso. Este proxy, ejecutándose en el mismo host que el sandbox, permite interceptar, modificar, denegar o registrar el tráfico HTTP/S de manera transparente para la aplicación. Esto habilita un modelo de seguridad 'zero-trust' donde las credenciales sensibles nunca son expuestas al agente, y las políticas de acceso pueden ser dinámicas y adaptadas a cada contexto, mitigando riesgos de exfiltración de datos o acciones no autorizadas.

Arquitectura del Sistema

La arquitectura se basa en la intercepción del tráfico de red saliente de un entorno sandboxed (microVM o contenedor) a través de un 'Outbound Worker'. Este Worker es una función JavaScript que se ejecuta en el runtime de Cloudflare (workerd) en la misma máquina que el sandbox. La intercepción se logra mediante la configuración de reglas de red (ej. nftables con TPROXY en entornos de desarrollo local) que redirigen el tráfico HTTP/S coincidente hacia el Worker.

Para el tráfico HTTPS, se implementa un proxy 'Man-in-the-Middle' (MITM) transparente. Se genera una Autoridad de Certificación (CA) efímera y una clave privada únicas para cada instancia de Sandbox, y esta CA se instala y confía dentro del sandbox. El proceso de red aislado de Cloudflare realiza el handshake TLS, crea un certificado hoja usando la CA efímera y el SNI del ClientHello, y luego invoca al Worker configurado para manejar la solicitud HTTPS descifrada. Las credenciales sensibles (como tokens de autenticación) se inyectan en las cabeceras de la solicitud dentro del Worker, sin que el código del sandbox tenga acceso directo a ellas. La API ctx.container expone métodos como interceptOutboundHttp y interceptOutboundHttps para configurar dinámicamente qué tráfico interceptar y qué Worker usar, permitiendo reglas basadas en hostnames, rangos IP o patrones glob. La comunicación entre el contenedor y el Worker es 'authless' pero segura, ya que ocurre localmente en la misma máquina.

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

class MySandboxedApp extends Sandbox {
  static outbound = (req, env, ctx) => {
    if (req.method !== 'GET') {
      console.log(`Container making ${req.method} request to: ${req.url}`);
      return new Response('Not Allowed', { status: 405, statusText: 'Method Not Allowed'});
    }
    return fetch(req);
  };
}

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

async function setUpSandboxes(req, env) {
  const sandbox = await env.SANDBOX.getByName(userId);
  await sandbox.setOutboundHandler("allowHosts", {
    allowedHostnames: ["github.com", "npmjs.org"]
  });
  await sandbox.gitClone(userRepoURL);
  await sandbox.exec("npm install");
  await sandbox.setOutboundHandler("noHttp");
}

Fundamentos Teóricos

Este enfoque se alinea con principios de seguridad de red y aislamiento de procesos que tienen raíces profundas en la investigación de sistemas operativos y seguridad. La idea de interponer un componente de confianza para mediar las interacciones de un proceso no confiable se remonta a conceptos como los 'reference monitors' de Anderson (1972) y el modelo Bell-LaPadula (1973), que buscan asegurar que todas las operaciones de acceso a recursos sean mediadas, a prueba de manipulaciones y verificables.

La implementación de un proxy de egreso programable también resuena con los principios de 'least privilege' y 'zero trust' en la seguridad de sistemas distribuidos. El 'least privilege' (Saltzer y Schroeder, 1975) dicta que cada entidad debe tener solo los permisos necesarios para realizar su tarea. Al no otorgar tokens directamente al agente y en su lugar inyectarlos en el proxy, se minimiza la superficie de ataque. El modelo 'zero trust' (Forrester Research, 2010s) postula que ninguna entidad, interna o externa, debe ser confiada por defecto, requiriendo verificación continua. El Outbound Worker actúa como un punto de aplicación de políticas 'zero trust' en el perímetro del sandbox, validando y autorizando cada solicitud de egreso.