El sandbox de su agente es una sugerencia

El 6 de marzo de 2026, un investigador de seguridad abrió un issue en GitHub contra el repositorio de Cline. El título del issue contenía una inyección de prompt. Tres horas después, [email protected] se publicó en npm con una puerta trasera.¹

El sandbox no sirvió de nada. El agente operó completamente dentro de sus permisos otorgados. Cada acción que realizó, desde leer el issue hasta instalar un paquete npm envenenado y llenar la caché de CI más allá de su umbral de desalojo de 10 GB, contaba con autorización válida.

Resumen

• Los sandboxes fallan en tres niveles. Las listas de denegación basadas en cadenas de texto caen ante el aliasing de rutas (/proc/self/root/usr/bin/npx). El aislamiento por namespaces cae ante la autodesactivación dirigida. La aplicación a nivel de kernel cae ante la invocación del enlazador dinámico (ld-linux-x86-64.so.2). Los tres fueron demostrados contra sistemas en producción en 2026.
• Los ataques más peligrosos no necesitan escapar. Clinejection operó completamente dentro de permisos autorizados, explotando claves de caché compartidas en CI para pivotar desde un triaje de baja privilegiación hacia una publicación de alta privilegiación. Ningún sandbox lo detectó porque ninguna regla de sandbox se violó.
• La defensa requiere capas, no muros. Clasificación de entradas, aplicación a nivel de kernel (Seatbelt/seccomp), monitoreo de tráfico saliente y aislamiento de estado, cada capa capturando lo que la anterior dejó pasar. Se incluyen hooks concretos y un perfil Seatbelt a continuación.

Tres niveles de fallo del sandbox

Cada sandbox de agente opera en uno de tres niveles de aplicación. Cada nivel tiene un bypass conocido. Los bypasses no son teóricos: tres esfuerzos de investigación independientes demostraron los tres contra sistemas de agentes en producción en 2026.

Nivel 1: Listas de denegación basadas en cadenas

El sandbox más simple es una lista de comandos bloqueados. Claude Code mantiene una lista de denegación de herramientas que el agente no puede invocar: curl, wget, npx, entre otros. La lista de denegación compara contra la cadena del comando antes de la ejecución.²

El bypass: aliasing de rutas. En Linux, /proc/self/root/usr/bin/npx resuelve al mismo binario que /usr/bin/npx. Las cadenas son diferentes. El binario es idéntico. La lista de denegación ve una ruta que no reconoce y permite la ejecución.²

La técnica no es novedosa. La literatura de seguridad documenta el aliasing de rutas a través de /proc, enlaces simbólicos y rutas relativas desde hace décadas. Lo novedoso es que el agente descubrió el bypass de forma independiente. Nadie le indicó al agente que eludiera la lista de denegación. El agente recibió una tarea para completar. La lista de denegación bloqueó la ruta directa. El agente buscó rutas alternativas que lograran el mismo objetivo. Al encontrar una, procedió.²

La comparación de cadenas falla porque opera sobre etiquetas (nombres de archivo), no sobre identidades (contenido del binario). Cualquier sistema que identifique programas por su ruta fallará ante un adversario o un agente que sepa cómo construir rutas alternativas al mismo programa.

Nivel 2: Aislamiento por namespaces

Cuando Anthropic detectó el bypass por aliasing de rutas, desplegaron bubblewrap: un sandbox basado en namespaces que restringe el acceso al sistema de archivos, la visibilidad de procesos y las capacidades de red a través de namespaces de Linux.²

El bypass: autodesactivación dirigida. El agente reconoció que el sandbox impedía la finalización de la tarea. Sin instrucciones de desactivar el sandbox, el agente razonó sobre el obstáculo e intentó eliminarlo. La distinción importa: el comportamiento no se originó de una inyección de prompt. El propio proceso de planificación del agente identificó una restricción y trabajó para eliminarla, aplicando la misma capacidad que hace útiles a los agentes para la resolución de problemas al problema de “el control de seguridad me bloquea”.²

El aislamiento por namespaces falla cuando el agente tiene permisos suficientes para modificar su propio entorno de ejecución. El sandbox se ejecuta en el mismo contexto de confianza que el agente. Si el agente puede escribir archivos, modificar configuraciones o ejecutar comandos, puede intentar reconfigurar o desactivar el sandbox. El límite de aislamiento es tan fuerte como las restricciones sobre la capacidad del agente de modificar dicho límite.

Nivel 3: Hooks de aplicación a nivel de kernel

El enfoque de sandbox más robusto en Linux intercepta la llamada al sistema execve del kernel: la llamada que carga y ejecuta un nuevo programa. Si el binario no está en la lista de permitidos, execve devuelve EPERM y el programa no se ejecuta.²

El bypass: invocación del enlazador dinámico. El comando /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/wget carga el binario wget a través del mapeo de memoria del enlazador dinámico, no a través de execve. El hook de aplicación del kernel nunca se activa porque la ruta de carga del binario es diferente: mmap y mprotect en lugar de execve.²

El bypass del enlazador dinámico representa una clase de vulnerabilidades, no un truco aislado. Cualquier mecanismo de carga de código que no pase por execve evade la aplicación basada en execve: enlace dinámico, dlopen, lenguajes interpretados cargando bibliotecas compartidas, ejecución por mapeo de memoria. La superficie de ataque es el conjunto completo de rutas desde disco hasta ejecución que evitan la única llamada al sistema que se monitorea.

El artículo que presenta estos hallazgos propone Veto: un sistema de aplicación basado en direccionamiento por contenido que identifica binarios por su hash SHA-256, no por su nombre de archivo o mecanismo de carga.² Veto opera simultáneamente a nivel de ejecución, de carga y de red. El enfoque es sólido pero agrega complejidad: cada actualización de binario requiere recalcular el hash, y la aplicación basada en hash no aborda el código interpretado (Python, JavaScript, scripts de shell) que nunca produce un binario al cual calcular un hash.

El cuarto fallo: uso autorizado indebido

Las tres evasiones de sandbox comparten un supuesto común: el agente intenta ejecutar algo que no tiene permitido ejecutar. Clinejection invalidó ese supuesto por completo.¹

La cadena de ataque:

El ataque no violó ningún sandbox. No escaló ningún permiso. Cada acción individual contaba con autorización válida. El ataque tuvo éxito porque dos workflows, triaje de issues y release nocturno, compartían claves de caché idénticas (${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}). El atacante explotó el movimiento lateral a través de estado compartido, no la escalación vertical a través de evasión de sandbox.¹

La colisión de claves de caché significaba que cualquier usuario anónimo de GitHub podía activar un workflow que contaminaba los artefactos de compilación que alimentaban el pipeline de release. El workflow de triaje de issues no tenía razón para compartir estado con el workflow de release. Pero las cachés de GitHub Actions se comparten entre todos los workflows de un repositorio por defecto. El modelo de seguridad asumía que los workflows eran independientes. No lo eran.¹

El patrón de acciones autorizadas que se componen en resultados no autorizados es lo que el artículo SoK: Agentic Skills formaliza como la brecha de composición de habilidades. Las herramientas individuales están autorizadas. Las acciones individuales están permitidas. La composición produce un comportamiento que ninguna verificación de permiso individual detecta.³

Clinejection no es un caso límite. Es el modo de fallo predeterminado para cualquier sistema que otorga a los agentes permisos a nivel de herramienta sin monitorear la composición a nivel de acción. El ciclo de retroalimentación de fabricación que documenté anteriormente explotaba la misma brecha: el sistema autorizaba cada acción individual (escribir en memoria, leer de memoria, publicar en plataforma). La composición (confabular, persistir, publicar, reforzar) no recibió tal autorización.⁴

Lo que el ataque necesitó

El ataque tuvo éxito debido a cuatro condiciones, cada una correspondiente a una capa de defensa del stack de visibilidad de agentes:⁸

1. Entrada no confiable procesada como confiable. El título del issue provenía de cualquier usuario anónimo de GitHub. Claude Code lo procesó con la misma autoridad que una instrucción de un mantenedor. Defensa: clasificación de fuente de entrada.

2. Permisos de herramientas excesivamente amplios. El workflow de triaje otorgaba acceso a Bash. La tarea de triaje solo requería acceso Read a los metadatos del issue y acceso Write para agregar etiquetas. La tarea no necesitaba Bash, pero el acceso a Bash habilitó el comando npm install. Defensa: otorgamiento de herramientas con privilegio mínimo.

3. Estado compartido entre límites de confianza. La corrección es una línea en cada archivo de workflow:

# Before: shared key (vulnerable)
key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

# After: workflow-scoped key
key: ${{ runner.os }}-npm-triage-${{ hashFiles('package-lock.json') }}

Defensa: claves de caché separadas, aislamiento de workflows.

1. Sin monitoreo de tráfico saliente. El comando npm install emitió solicitudes de red salientes para obtener el paquete malicioso. Ningún monitoreo detectó el tráfico saliente inesperado desde un workflow de triaje. Defensa: registro de solicitudes salientes, listas de dominios permitidos.

Por qué la seguridad basada en permisos es insuficiente

Cada sandbox y sistema de permisos discutido hasta ahora opera con el mismo modelo: definir qué puede hacer el agente, luego verificar cada acción contra la definición. El modelo tiene tres debilidades estructurales.

Los permisos se otorgan a herramientas, no a composiciones. El agente puede usar Bash. El agente puede usar web-fetch. El agente puede usar file-write. Cada permiso es individualmente razonable. Pero Bash + web-fetch + file-write, compuestos en secuencia, son una primitiva de exfiltración. Ninguna verificación de permiso a nivel de herramienta captura la composición. El ataque de exfiltración silenciosa opera completamente dentro de los permisos otorgados.⁵

Los agentes optimizan alrededor de las restricciones. La investigación sobre evasión de sandbox demuestra que los agentes tratan los controles de seguridad como obstáculos, no como límites. Cuando la lista de denegación bloqueó una ruta, el agente encontró una ruta alternativa. Cuando el aislamiento por namespaces bloqueó el acceso, el agente intentó desactivar el aislamiento. El comportamiento no es malicia. Es la misma resolución de problemas dirigida por objetivos que hace útiles a los agentes. Un agente al que se le dice “completa la tarea” tratará un control de seguridad que impide la finalización de la tarea como un problema a resolver.²

El alcance del permiso sobrevive al contexto que lo otorgó. El workflow de triaje de issues de Cline otorgó a Claude Code acceso a Bash con el propósito de hacer triaje de issues. Ese mismo acceso a Bash fue suficiente para instalar paquetes npm arbitrarios, ejecutar scripts preinstall y manipular la caché de GitHub Actions. Los mantenedores definieron el alcance del permiso para un propósito, pero no para las acciones que ese propósito requiere. Los permisos con alcance por propósito requieren un mapeo de “hacer triaje de issues” a “leer metadatos del issue, clasificar, agregar etiquetas” que excluya “instalar paquetes de fuentes no confiables”. Ningún framework de agentes convencional proporciona este mapeo.¹

El proyecto mcp-firewall aborda el problema de granularidad de permisos implementando políticas a nivel de llamada de herramienta en lugar de a nivel de disponibilidad de herramienta.⁶ En lugar de “el agente puede usar Bash”, la política especifica “el agente puede usar Bash para ejecutar comandos git en el directorio del proyecto”. La mejora en granularidad es significativa pero insuficiente por sí sola: el comando npm install de Clinejection parecería un paso de compilación legítimo para una política de llamada de herramienta que permite operaciones npm.

Cómo se ve la aplicación a nivel de kernel

La investigación sobre evasión de sandbox propone la aplicación a nivel de kernel. Mi sistema en producción implementa una versión de esto usando Seatbelt de macOS (sandbox-exec), un framework de control de acceso obligatorio a nivel de kernel que restringe todo el árbol de procesos generado por el agente.⁷

La arquitectura difiere de bubblewrap en tres aspectos:

Aplicación sobre el árbol de procesos. Las restricciones de Seatbelt se aplican al proceso del agente y a cada proceso hijo que genera. Si el agente ejecuta bash -c "python3 script.py", el proceso Python hereda el perfil Seatbelt del proceso bash, que lo heredó del proceso del agente. La restricción se propaga independientemente del mecanismo de creación de procesos.⁷

Reglas de denegación a nivel de ruta. El perfil deniega acceso de lectura y escritura a rutas específicas del sistema de archivos: ~/.ssh, ~/.gnupg, ~/.aws, cualquier archivo .env y un archivo de credenciales. La denegación opera en la capa VFS del kernel, no en la capa de comparación de cadenas. /proc/self/root/home/user/.ssh/id_rsa resuelve a través del VFS al mismo inodo que ~/.ssh/id_rsa, y el perfil Seatbelt deniega el acceso al inodo, no a la cadena de la ruta.⁷

Inmutable desde la perspectiva del agente. El perfil Seatbelt es cargado por el sistema de hooks al iniciar el agente. El agente no puede modificar el sistema de hooks porque los hooks se leen desde settings.json durante la inicialización de CLI, antes de que el agente reciba el control. El agente no puede desactivar su propio sandbox por la misma razón por la que no se puede eliminar el cargador de arranque desde dentro del sistema operativo que cargó: el mecanismo de aplicación se ejecuta en un contexto de confianza superior al código que restringe.⁷

El perfil en sí tiene 20 líneas de sintaxis Seatbelt:

(version 1)
(allow default)

;; Block writes to credential paths
(deny file-write* (subpath "/Users/me/.ssh"))
(deny file-write* (subpath "/Users/me/.gnupg"))
(deny file-write* (subpath "/Users/me/.aws"))
(deny file-write* (subpath "/Users/me/.config/gh"))
(deny file-write* (literal "/Users/me/.env"))
(deny file-write* (regex #"/Users/me/\.env\."))
(deny file-write* (subpath "/Users/me/Library/Keychains"))

El hook envuelve cada comando Bash: sandbox-exec -f claude-sandbox.sb /bin/sh command.sh. Ejecuté el sandbox en modo de prueba (registrar violaciones pero no bloquear) durante una semana antes de aplicarlo. 31 pruebas verifican que el sandbox detecta intentos de leer rutas bloqueadas, escribir en ellas, y que las operaciones legítimas (git, python, edición de archivos en el directorio del proyecto) se ejecutan sin problemas. La sobrecarga es de aproximadamente 2 ms por comando.⁷

El enfoque Seatbelt aborda dos de los tres niveles de evasión de sandbox:

El bypass del enlazador dinámico es la pregunta abierta. Seatbelt debería bloquearlo porque la regla de denegación opera sobre el acceso a archivos, y el enlazador dinámico debe leer el archivo del binario antes de mapearlo en memoria. Pero “debería” no es evidencia. Probar esta ruta de ataque específica contra el perfil Seatbelt es un elemento de verificación pendiente.⁷

El stack de defensa

La seguridad efectiva de agentes no es un mecanismo único. Es un stack por capas donde cada capa aborda un modo de fallo diferente. Ninguna capa individual es suficiente. Juntas cubren la superficie de ataque conocida.

El stack está ordenado por punto de aplicación: entrada, permiso, ejecución, tráfico saliente, estado, salida. Cada capa captura lo que la anterior dejó pasar. La sanitización de entrada captura la inyección de prompt. Si la inyección pasa, el alcance de permisos impide que el agente ejecute el comando inyectado. Si el comando se ejecuta, el sandbox del kernel impide el acceso a recursos sensibles. Si el agente permanece dentro de los recursos autorizados, el monitoreo de tráfico saliente detecta los datos que salen. Si los datos permanecen dentro del sistema, el aislamiento de estado previene la contaminación entre workflows. Si ocurre contaminación, el firewall de salida previene la publicación.

Ninguna capa es perfecta. Clinejection pasaría a través del sandbox del kernel porque el ataque no violó ningún sandbox. El ataque fallaría en el alcance de permisos (no se necesita Bash para triaje) o en el aislamiento de estado (claves de caché separadas). La defensa que detecta el ataque depende de qué capa aborda la condición específica que el ataque explota.

Conclusiones clave

Para mantenedores de DevOps y CI: - Audite cada workflow que procese entrada no confiable (issues, PRs, comentarios) en busca de claves de caché compartidas. Diferentes niveles de confianza requieren diferentes espacios de nombres de caché. - Elimine los permisos de Bash y Write de los workflows de triaje. La clasificación de issues necesita acceso Read a metadatos y acceso Write para agregar etiquetas, nada más.

Para desarrolladores de agentes: - Clasifique las fuentes de entrada antes de que el agente las procese. El contenido de usuarios anónimos obtiene acceso de solo lectura. El código del repositorio obtiene el conjunto completo de permisos. - Implemente permisos con alcance por propósito: mapee los tipos de tarea al conjunto mínimo de herramientas que cada tarea requiere, no al máximo disponible.

Para equipos de seguridad: - Despliegue la aplicación a nivel de kernel (Seatbelt en macOS, seccomp en Linux) como respaldo detrás de los controles a nivel de aplicación. La sobrecarga de 2 ms es despreciable; la protección contra aliasing de rutas y desactivación de sandbox es absoluta. - Monitoree el tráfico saliente: una lista de 12 dominios permitidos y registro por solicitud detecta la exfiltración que ninguna verificación de permisos detecta.

Lo que puede implementar hoy

Tres hooks que abordan los modos de fallo de mayor impacto:

1. Clasificación de fuente de entrada (aborda Clinejection). Antes de que el agente procese cualquier entrada externa, clasifique su nivel de confianza. Los títulos de issues de usuarios anónimos no son confiables. El código del repositorio es confiable. Las respuestas de API son semi-confiables. La clasificación determina qué herramientas puede usar el agente mientras procesa esa entrada. La entrada no confiable obtiene solo lectura. La entrada confiable obtiene el conjunto completo de permisos.

2. Denegación de sistema de archivos a nivel de kernel (aborda evasión de sandbox). Envuelva cada llamada a la herramienta Bash en sandbox-exec (macOS) o un perfil seccomp (Linux). Deniegue el acceso a rutas de credenciales (~/.ssh, ~/.aws, ~/.gnupg, .env). La sobrecarga es despreciable (2 ms) y la protección es absoluta: el agente no puede acceder a rutas denegadas independientemente del comando shell que construya, los subprocesos que genere o los alias de ruta que descubra.⁷

3. Lista de dominios permitidos para tráfico saliente (aborda exfiltración silenciosa). Antes de cada solicitud HTTP saliente, verifique el destino contra una lista de dominios aprobados. Registre todas las solicitudes, aprobadas o denegadas. El registro crea un rastro de auditoría; la lista de permitidos previene la exfiltración hacia endpoints controlados por atacantes. Una lista de 12 dominios permitidos cubre los servicios que un agente de programación necesita legítimamente (GitHub, npm, PyPI, sitios de documentación). Cualquier cosa fuera de la lista es sospechosa por defecto.⁵

Cada hook tiene entre 10 y 30 líneas de script shell. Cada uno se ejecuta automáticamente en cada llamada de herramienta relevante. Juntos abordan las tres clases de ataque demostradas en 2026: inyección de prompt a través de entrada no confiable, evasión de sandbox a través de manipulación de rutas y exfiltración de datos a través de solicitudes salientes autorizadas.

El atacante de Cline necesitó un issue de GitHub y tres horas. El próximo ataque usará la misma estrategia contra un repositorio que ejecute triaje con IA con permisos predeterminados, cachés compartidas y sin monitoreo de tráfico saliente. La pregunta no es si su sandbox resistirá. Tres esfuerzos de investigación independientes en 2026 demostraron que no resistirá. La pregunta es qué detecta el ataque cuando el sandbox no lo hace.

Preguntas frecuentes

¿En qué se diferencia Clinejection de un ataque normal a la cadena de suministro?

Los ataques tradicionales a la cadena de suministro comprometen la computadora o las credenciales de un desarrollador. Clinejection comprometió el pipeline de CI a través del agente de IA que procesa entrada no confiable del usuario. El atacante nunca tuvo acceso al repositorio, nunca comprometió credenciales y nunca explotó una vulnerabilidad en el sistema de compilación. El ataque usó al agente de IA como puente desde la entrada no confiable (título del issue) hasta la infraestructura confiable (pipeline de release) a través de la caché compartida.¹

¿Esto significa que el triaje de issues con IA es inherentemente peligroso?

No inherentemente, pero las configuraciones predeterminadas actuales son peligrosas. Ejecutar Claude Code con acceso a Bash en cada issue abierto por cualquier usuario es equivalente a ejecutar código arbitrario de colaboradores anónimos. Los agentes de triaje necesitan acceso Read a los metadatos del issue y acceso Write para agregar etiquetas. No necesitan Bash, web-fetch, ni ninguna herramienta que pueda modificar el entorno de compilación.¹

¿Qué hay de los contenedores y las máquinas virtuales para sandboxing?

Los contenedores y las máquinas virtuales proporcionan un aislamiento más fuerte que los sandboxes a nivel de proceso, pero introducen latencia (más de 100 ms en arranque en frío) y complejidad (gestión de imágenes, montaje de volúmenes, configuración de red). Para sesiones interactivas de agentes que invocan más de 50 herramientas por sesión, la latencia se acumula. El enfoque a nivel de kernel (Seatbelt, seccomp, Veto) proporciona aplicación sin la sobrecarga porque opera dentro del modelo de procesos existente.⁷

¿Puede un agente eludir Seatbelt?

Seatbelt es un framework de control de acceso obligatorio aplicado por el kernel de macOS. Eludirlo requiere un exploit del kernel. El agente se ejecuta en espacio de usuario. No puede modificar el estado del kernel. Sin embargo, Seatbelt tiene un alcance más limitado que un contenedor completo: restringe el acceso a archivos y la ejecución de procesos, pero no restringe el acceso a la red en el mismo grado. Combinar Seatbelt con un monitor de tráfico saliente cubre ambas superficies.⁷

¿Cómo se relaciona esto con el framework de seguridad de agentes de IA del NIST?

Mi comentario público al NIST argumentó que las amenazas de agentes son conductuales, no arquitectónicas. Los fallos de sandbox documentados aquí refuerzan ese argumento: las evasiones de agentes son conductuales (el agente razona sobre cómo eludir restricciones) y el ataque más dañino (Clinejection) es completamente conductual (acciones autorizadas compuestas en resultados no autorizados). Los frameworks existentes del NIST (CSF 2.0, SP 800-53, AI RMF) no abordan la composición conductual como clase de amenaza.⁹