Un sandbox semántico no es un sandbox: si el agente puede resolver y alcanzar internet, la simulación ya perdió su frontera

Las instrucciones describen un mundo; la red decide cuál mundo existe. Una evaluación puede explicar con precisión que el objetivo es ficticio, que ciertos dominios forman parte del ejercicio y que nada externo debe tocarse. Pero si el runtime mantiene salida abierta a internet, el agente posee una segunda realidad más amplia que la del prompt. Basta una resolución DNS inesperada, un nombre ambiguo o una credencial pública para atravesar la frontera narrativa. Por eso la seguridad no debe preguntar solamente si el modelo entendió el scope. Debe comprobar si la infraestructura hace imposible actuar fuera de él.

La contención fuerte empieza con default deny. Un entorno de red seguro no enumera únicamente lo prohibido; permite solo destinos necesarios. En una evaluación ofensiva, eso puede significar una VPC aislada, DNS interno, repositorios clonados y servicios sintéticos. Si el agente necesita documentación pública, una capa proxy puede proporcionar snapshots o dominios específicos en modo lectura. La política se vuelve auditable porque existe una lista concreta de rutas autorizadas. El agente puede descubrir caminos creativos dentro del lab, pero su creatividad no cambia el conjunto de sockets, credenciales o herramientas que realmente puede alcanzar.

Los nombres de prueba necesitan identidad criptográfica o reservada. Usar una empresa ficticia con un nombre que también existe en internet es un fallo de namespace. El mismo problema aparece en demos empresariales con clientes, correos o cuentas inventadas. Un agente puede buscar datos reales de una persona coincidente. Los entornos maduros usan dominios reservados, datasets con IDs sintéticos y resolutores que nunca consultan DNS público para esos nombres. Así el significado de “cliente de prueba” no depende de que el modelo distinga dos entidades parecidas; está respaldado por un sistema de identidad que no puede colisionar con producción.

Las credenciales también deben ser falsas y de alcance mínimo. Una evaluación no debería necesitar secretos reales para demostrar capacidad. Tokens efímeros, cuentas sandbox y permisos limitados permiten observar el comportamiento sin poner activos productivos al alcance. Incluso si una herramienta encuentra un secreto público, una política de egress debería impedir que lo pruebe contra destinos externos. Esta doble barrera es importante porque ningún control es perfecto. La defensa en profundidad asume que una capa fallará y evita que ese fallo se convierta inmediatamente en un acceso real.

El test del sandbox debe intentar escapar. Muchas organizaciones verifican que una demo funciona dentro del entorno, pero no comprueban activamente la frontera. Un suite de containment puede pedir al agente resolver dominios externos, conectarse a IPs no autorizadas, acceder a metadatos cloud y escribir fuera del filesystem asignado. El resultado esperado es bloqueo determinista con evidencia. Estas pruebas deben repetirse cuando cambia el runtime, la imagen o un conector. El perímetro es código y configuración; puede tener regresiones igual que cualquier otra parte del producto.

Implicación para Goatify. Si usamos control de navegador o agentes que operan cuentas de clientes, necesitamos una primitive de executionscope aplicada por herramienta y red. El usuario puede autorizar Meta Ads, pero eso no significa toda la web. Una habilidad puede recibir una allowlist temporal de dominios, cuentas y acciones. Cuando intenta salir, el runtime rechaza y registra el evento. Comercialmente, podemos demostrar ese límite en vivo. La seguridad deja de ser “confía en que el agente sabe dónde está” y se vuelve “mira cómo la infraestructura le impide cruzar la frontera”.