Sandboxing y egress

Qué recursos puede alcanzar el código ejecutado por un agente y qué puede enviar fuera: filesystem, runtime, credenciales y egress.

Actualizado 6 oct 2026

Los permisos del agente deciden si una acción puede empezar. El sandboxing controla qué puede alcanzar su ejecución una vez iniciada, y el egress limita por dónde puede comunicarse fuera del entorno.

Esta separación importa porque una acción legítima puede ejecutar código inesperado. Autorizar npm test no implica que cada dependencia, script o subproceso lanzado durante los tests sea confiable.

Frontera de ejecución

La frontera de ejecución puede limitar:

Qué partes del filesystem son visibles y cuáles se pueden modificar.
Qué procesos e interfaces del host están disponibles.
Qué credenciales y variables entran en el entorno.
Qué sockets, dispositivos u otros recursos atraviesan el aislamiento.
Qué conexiones de red pueden iniciarse.

El control útil es el que sigue aplicándose aunque el proceso ejecutado intente hacer algo distinto de lo previsto por la tool call original.

Filesystem y resolución de rutas

Un coding agent suele necesitar lectura y escritura sobre el workspace. Eso no exige exponer también el directorio personal, configuración del host o almacenes de credenciales.

La distinción entre lectura y escritura es importante. Proteger ~/.ssh contra modificaciones no protege una clave si el proceso todavía puede leerla y dispone de un canal para enviarla. Una frontera más fuerte deja el secreto fuera del entorno: si la credencial nunca se monta ni se introduce como variable, el código del sandbox no puede leerla directamente.

Las restricciones también tienen que aplicarse sobre la ruta efectiva. Un fichero dentro de un directorio permitido puede ser un symlink hacia una ubicación externa. Una implementación que valida el path aparente antes de resolver el enlace puede terminar cruzando la frontera que intentaba proteger.

Por eso el control debe resolver el recurso real y comprobar después si sigue dentro del área permitida.

Aislamiento del runtime

El filesystem es solo una parte. Un sandbox puede separar procesos, interfaces del sistema operativo y otros recursos mediante mecanismos del propio OS, contenedores o máquinas virtuales.

Estas opciones proporcionan fronteras distintas. Un contenedor suele compartir kernel con el host; una VM puede tener kernel, filesystem y tabla de procesos propios. La elección concreta importa menos que comprobar qué recursos siguen inaccesibles si el comando autorizado acaba ejecutando código arbitrario.

La restricción debe propagarse a los procesos que nazcan dentro del entorno. Si npm test lanza Node.js y este crea otro proceso, ese subproceso no debería escapar de las mismas reglas por el simple hecho de no ser la tool call inicial.

También hay que revisar las excepciones deliberadas: montar una carpeta del host, exponer un socket privilegiado o introducir una credencial amplía la superficie efectiva del sandbox.

Egress de red

Egress es el tráfico iniciado desde el entorno hacia otros sistemas. Para un agente puede ser una petición HTTP, una conexión de una dependencia, una API o cualquier socket que pueda abrir el proceso.

Si un proceso puede leer un secreto y dispone de red arbitraria, no necesita una tool llamada exfiltrate: Python, curl, una librería o una dependencia pueden proporcionar el canal. La política de red puede bloquear por defecto, permitir destinos concretos o forzar el tráfico a través de un proxy que inspeccione la operación.

Dominios permitidos

Permitir un hostname sigue dejando disponibles las operaciones que ofrece ese servicio. Un mismo dominio puede aceptar requests de lectura, escritura o uploads asociados a cuentas distintas.

Anthropic documentó un caso donde api.anthropic.com necesitaba estar permitido para el funcionamiento del producto. Contenido malicioso utilizó esa ruta autorizada para subir ficheros a una cuenta controlada por el atacante. El problema no era que el dominio estuviera mal identificado, sino que el control no distinguía suficientemente qué operación y credencial se estaban utilizando.

Ese tipo de caso obliga a mirar más allá de la allowlist y comprobar el efecto disponible en cada destino autorizado.

Ejemplo: coding agent

Supongamos que un agente recibe:

Ejecuta los tests del repositorio y corrige los fallos.

El entorno le proporciona el workspace con lectura y escritura, Bash, las dependencias necesarias y acceso de red al registry del proyecto. El directorio personal y las credenciales de GitHub quedan fuera del sandbox.

Figura 1. El código se ejecuta dentro del sandbox; la frontera limita los recursos locales que puede alcanzar y la política de egress restringe sus destinos externos.

El agente decide correctamente ejecutar npm test, pero durante la ejecución se carga una dependencia comprometida que intenta leer una clave SSH, buscar tokens en variables de entorno y enviarlos a un servidor externo.

Aquí no hace falta que el modelo se equivoque. La seguridad depende de lo que el proceso pueda alcanzar:

Si $HOME no está expuesto y las credenciales nunca entraron en el entorno, esos secretos no están disponibles.
Si existe algún dato sensible legible pero el destino externo está bloqueado, falta el canal de salida.
Si coinciden datos legibles y egress arbitrario, la ejecución autorizada dispone de una ruta de exfiltración.

El sandbox protege también frente al código que el agente ejecuta de forma legítima como parte de una tarea: tests, builds, scripts y dependencias tienen que quedar sujetos a la misma frontera.

Una prompt injection puede manipular qué acción solicita el modelo y los permisos pueden decidir si esa acción comienza. Sandboxing y egress cubren el paso siguiente: qué puede hacer realmente la ejecución una vez autorizada.