Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
Sandboxing y egress
Una acción autorizada todavía puede ejecutar código que haga mucho más de lo que su nombre sugiere.
Permitir a un agente lanzar npm test, ejecutar un script o abrir un fichero responde a una pregunta de permisos: si esa acción puede empezar. El sandboxing responde a otra: una vez iniciada la ejecución, qué recursos puede alcanzar realmente.
El egress completa esa frontera controlando las comunicaciones salientes. Un proceso puede estar aislado del resto del host y seguir teniendo una vía de impacto si puede leer información sensible y enviarla a un destino externo.
Por eso ambas dimensiones conviene analizarlas juntas:
ejecución → recursos alcanzables → canal de salida → impacto
Frontera de ejecución
Los permisos del agente determinan si una acción puede empezar. Cuando el proceso arranca, esa decisión ya está tomada. A partir de ahí importan las restricciones que el entorno aplica independientemente de lo que el modelo, el script o uno de sus subprocesos intente hacer.
La frontera de ejecución puede limitar, entre otras cosas:
- Qué partes del filesystem son visibles.
- Qué rutas son de sólo lectura o escritura.
- Qué procesos o interfaces del host están disponibles.
- Qué credenciales entran en el entorno.
- Qué conexiones de red pueden salir.
La propiedad que importa es qué recursos quedan realmente fuera de alcance aunque el proceso ejecutado sea hostil.
Aislamiento del filesystem
Un coding agent suele necesitar acceso de lectura y escritura al workspace. Eso no implica el mismo acceso a todo el host.
Una configuración puede exponer el repositorio con lectura y escritura mientras mantiene fuera de alcance directorios personales, configuración del sistema o almacenes de credenciales. También puede dejar en sólo lectura partes que el agente necesita consultar pero no modificar.
Separar lectura y escritura importa. Impedir modificar ~/.ssh no protege una clave privada si el proceso todavía puede leerla y dispone de un canal para enviarla fuera.
Una frontera más fuerte consiste en evitar que el secreto entre en el entorno. Si una credencial permanece en el keychain del host y nunca se monta ni se expone al proceso, el código ejecutado dentro del sandbox no puede leerla directamente. Mantener credenciales fuera del entorno aislado reduce el blast radius incluso si el código que se ejecuta dentro no es confiable.
Resolución de rutas
Las restricciones del filesystem deben aplicarse sobre el recurso real, no únicamente sobre la ruta recibida por la aplicación.
Un caso clásico son los enlaces simbólicos (symlinks). Un fichero dentro de un directorio autorizado puede apuntar a una ruta situada fuera. Si el sistema valida primero la ruta aparente y resuelve el enlace después, la operación puede terminar cruzando la frontera que pretendía proteger.
Por eso una implementación robusta resuelve la ruta efectiva antes de decidir si está dentro del área autorizada.
La frontera debe validar el recurso que finalmente será alcanzado.
Aislamiento del runtime
El filesystem sólo es una parte del entorno de ejecución.
Un sandbox también puede separar procesos, interfaces del sistema operativo y otros recursos del host. La implementación concreta puede utilizar sandboxing a nivel de sistema operativo, un contenedor o una máquina virtual.
El nivel de aislamiento depende de la implementación. Un proceso restringido puede seguir compartiendo gran parte del host. Un contenedor normalmente introduce namespaces y otros controles pero continúa compartiendo kernel. Una VM puede proporcionar su propio kernel, filesystem y tabla de procesos.
La comparación útil es qué frontera sigue aplicándose incluso si el comando autorizado ejecuta código arbitrario.
Si npm test lanza Node.js, éste ejecuta un subproceso y ese subproceso invoca otra utilidad, la restricción debería seguir afectando a toda la cadena. Un control que sólo inspecciona la primera tool call no es una frontera de ejecución suficiente.
También importan las interfaces que atraviesan deliberadamente el aislamiento. Montar una carpeta del host, exponer un socket privilegiado o introducir una credencial amplía lo que el entorno puede alcanzar. Cada excepción pasa a formar parte de la superficie efectiva del sandbox.
Egress de red
El aislamiento local no controla por sí solo lo que puede salir del entorno.
Egress es el tráfico iniciado desde la ejecución hacia otros sistemas. Para un agente puede incluir una petición HTTP, una conexión de una dependencia, una llamada a una API o cualquier otro canal de red disponible para el proceso.
Desde seguridad existe una relación sencilla:
datos legibles + canal saliente = posible ruta de exfiltración
No hace falta una tool llamada exfiltrate. Si el agente o uno de sus subprocesos puede leer un secreto y dispone de red arbitraria, Python, un cliente HTTP o una dependencia ejecutada durante el build pueden proporcionar el canal.
La política de red puede aplicarse fuera del propio proceso: bloquear la red por defecto, permitir destinos concretos o hacer pasar las conexiones por un proxy que decida cuáles acepta.
Dominios permitidos
Permitir un dominio concede al entorno las operaciones que puedan realizarse a través de ese destino; no convierte esas operaciones en confiables.
Un host autorizado puede ofrecer muchas operaciones distintas, almacenar contenido de múltiples usuarios o permitir uploads hacia cuentas controladas por terceros.
Anthropic documentó un caso en el que api.anthropic.com estaba correctamente permitido porque el producto necesitaba comunicarse con su propia API. Contenido malicioso consiguió utilizar esa misma ruta para subir ficheros a una cuenta controlada por el atacante. El sandbox y la comprobación del dominio funcionaron; la política era demasiado amplia para el efecto que se quería impedir.
El control posterior añadió conocimiento sobre la petición y la credencial utilizada, no sólo sobre el hostname.
El mismo principio aparece en los permisos del agente: tool denegada ≠ capacidad denegada. En red, dominio permitido ≠ operación segura.
Rutas alternativas
La frontera de ejecución debe controlar el efecto final aunque el código encuentre otra forma de expresarlo.
Bloquear curl no elimina el egress si Python puede abrir conexiones y la red continúa disponible. Denegar una tool de filesystem no protege una ruta si el mismo proceso puede acceder a ella mediante una syscall normal. Proteger un directorio por nombre no funciona si un symlink permite resolver hacia fuera.
El sandboxing no debería depender de que el agente elija voluntariamente las tools correctas.
Las reglas de permisos deciden antes de la ejecución qué comandos pueden empezar. El sandbox aplica otra propiedad: el sistema operativo o la capa de aislamiento restringe lo que el proceso puede hacer después de arrancar.
Las dos capas se complementan:
política de permisos → qué acción puede empezar
frontera de ejecución → qué puede alcanzar esa acción aunque haga algo inesperado
Ejemplo: coding agent
Supongamos que un agente recibe esta tarea:
Ejecuta los tests del repositorio y corrige los fallos.
El entorno le proporciona:
- El workspace con lectura y escritura.
- Bash y las dependencias necesarias.
- Acceso de red al registry utilizado por el proyecto.
- Ningún acceso al directorio personal del usuario.
- Ninguna credencial de GitHub dentro del sandbox.
El agente decide correctamente ejecutar npm test.
Durante los tests se carga una dependencia comprometida. Su código intenta leer una clave SSH del usuario, inspeccionar variables de entorno en busca de tokens y enviar cualquier secreto obtenido a un servidor externo.
El modelo ha tomado una decisión correcta y no hay prompt injection. La acción original —ejecutar los tests— era legítima.
A partir de ahí la seguridad depende de la frontera de ejecución.
Si $HOME no es visible y las credenciales nunca entraron en el sandbox, la clave y los tokens no están disponibles para ese proceso. Si existe algún dato sensible legible pero el destino externo está bloqueado por la política de egress, falta el canal necesario para enviarlo. Si tanto los datos como una salida arbitraria están disponibles, la ejecución autorizada tiene un camino hasta el impacto.
La cadena puede expresarse así:
acción autorizada → código no confiable → recurso alcanzable → egress disponible → impacto
El sandbox también limita código, herramientas y dependencias que el agente ejecuta correctamente como parte de una tarea legítima.
Fronteras de seguridad
Prompt injection, permisos y aislamiento controlan propiedades distintas del sistema.
Una prompt injection permite que contenido no confiable altere la decisión del modelo.
Los permisos del agente determinan si la acción solicitada tiene autoridad para ejecutarse.
El sandboxing y el egress limitan qué puede alcanzar esa ejecución y qué puede salir del entorno.
Estas capas pueden aparecer en una misma cadena:
entrada no confiable → decisión manipulada → acción autorizada → ejecución con demasiado alcance → impacto externo
También son independientes. Una prompt injection puede alterar sólo una respuesta sin ejecutar nada. Un agente puede tener permisos excesivos aunque nunca procese contenido malicioso. Una dependencia comprometida puede aprovechar una frontera de ejecución débil aunque el modelo y la política de permisos hayan funcionado exactamente como se esperaba.
Separar las capas permite localizar qué propiedad falló y dónde debe colocarse el control.