Sandboxing para AI agents: lo que tu startup debe dominar

Por qué el sandboxing vuelve a ser urgente en 2026

En agosto de 2026, los investigadores de OX Security divulgaron CVE-2026-82533, una vulnerabilidad en DeepSeek Harness (dsh), un agente de código basado en IA que había acumulado más de 215.000 estrellas en GitHub desde su lanzamiento. El fallo obtuvo una puntuación CVSS de 9.4 y permitió que un único comando curl ejecutado desde dentro del sandbox del agente desactivara por completo la confinación y elevara al agente a acceso total al sistema. El sandbox usaba bubblewrap en Linux y Seatbelt en macOS, pero dejaba el namespace de red compartido con el host. Esa decisión fue el bypass.

Según reportó Forkast, la vulnerabilidad se parcheó en la versión 0.1.2-alpha.1 en cuestión de días (divulgada el 24 de agosto, parcheada el 27 de agosto, CVE publicada el 8 de septiembre). Pero el patrón — sandboxes con defaults que parecen robustos hasta que un investigador los prueba — se repite en todo el ecosistema de agentes.

OWASP hizo el mismo punto desde otro ángulo al publicar el Top 10 for LLM Applications 2026 el 3 de agosto de 2026, durante la Black Hat USA. Por primera vez, el ranking se ponderó un 25 % por incidentes reales: 6.639 fallos documentados extraídos de bases de datos públicas. El movimiento más comentado: Excessive Agency subió del sexto puesto en 2025 al tercero en 2026, impulsado tanto por el voto experto como por los datos de incidentes apuntando al mismo lugar. Los agentes son donde está aterrizando el daño real.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Si estás llevando agentes de IA a producción — o cualquier software que procese input no confiable — los básicos del sandboxing, tema de un ensayo fundacional de 2025 del proyecto Emilua, se acaban de convertir en tu problema.

Qué significa "sandbox" de verdad (y por qué el término está roto)

En una charla en Hack In The Box Malaysia 2009, los investigadores Julien Tinnes y Chris Evans propusieron una definición que sigue vigente. Un sandbox es la capacidad de restringir los privilegios de un proceso:

Programáticamente — desde dentro del programa, no por configuración externa.
Sin autoridad administrativa sobre la máquina — el programa mismo hace el trabajo.
Discretionary privilege dropping — los privilegios solo decrecen, nunca aumentan.

Esa última cláusula es la que la mayoría de equipos se salta. El principio de menor privilegio dice que los derechos deben decrecer monótonamente durante la vida de un proceso. Cualquier cosa que permita al código no confiable elevar sus propios permisos no es un sandbox; es una vulnerabilidad esperando su día.

La razón por la que esta definición importa es que "sandbox" se ha estirado hasta significar casi cualquier cosa: un contenedor Docker, un namespace de Linux, un chroot jail, un filtro seccomp. Ninguno de estos, por sí solo, cumple la definición de Tinnes y Evans. Pueden combinarse para lograrlo, pero como defaults no lo hacen.

El actor model: una idea de hace 50 años que encaja perfecto con los runtimes de agentes

El actor model — actores como unidades aisladas de estado que se comunican solo vía mensajes — precede a la IA moderna por medio siglo. Erlang lo hizo famoso para tolerancia a fallos. El ensayo del proyecto Emilua sobre básicos de sandboxing argumenta que también es el modelo mental correcto para software compartimentado: cada compartimento es un proceso, cada proceso es un actor, y los Unix domain sockets transportando descriptores de archivo se vuelven el sustrato de paso de mensajes.

Tres primitivas bastan para programar contra el modelo: crear un actor, enviarle un mensaje, recibir un mensaje. El autor reduce la API de Emilua a exactamente esas tres llamadas.

Para founders construyendo sistemas de agentes, la relevancia práctica es directa. Cada runtime de agentes — LangChain, CrewAI, AutoGen, código a medida — ya es un sistema de actores disfrazado: los agentes tienen estado, invocan tools, pasan resultados a otros agentes. Si no has pensado en el aislamiento entre agentes, has estado construyendo un sistema mono-actor por accidente.

Capability-based security: por qué los descriptores de archivo son la respuesta

El segundo pilar es la seguridad basada en capacidades (capability-based security): una capability es una referencia in falsificable a un recurso combinada con los derechos para usarlo. Poseer una capability significa tener acceso. No hay chequeo de permisos separado en la puerta.

El hallazgo elegante — también del ensayo de Emilua — es que en sistemas Unix, los descriptores de archivo ya se comportan como capabilities. Los chequeos de permisos ocurren cuando creas un descriptor, no cuando lo usas. Si un proceso hereda un descriptor de solo lectura para /etc/shadow, puede leer el archivo incluso después de cambiar al usuario nobody. Esta convención se preserva porque los binarios suid dependen de ella; los desarrolladores del kernel no pueden romperla sin romper suid.

La implementación más probada en producción es Capsicum de FreeBSD, disponible desde FreeBSD 9.0. Capsicum añade dos primitivas clave:

cap_enter() — desactiva la autoridad ambiental por completo. Tras llamarla, el proceso no puede abrir archivos por ruta ni conectar a sockets arbitrarios; los únicos recursos que puede tocar son los descriptores que ya posee.
cap_rights_limit() — restringe las operaciones permitidas sobre un descriptor específico.

El equipo de Chromium, que ha desplegado más código sandboxed que cualquier otro proyecto, ejecutó una comparación controlada que el ensayo de Emilua reproduce. Para añadir soporte de Capsicum a Chromium, los investigadores necesitaron 100 líneas de código. Para seccomp en Linux, 11.301 líneas. Para Windows ACLs, 22.350 líneas. Otros mecanismos — chroot, SELinux, Seatbelt — se midieron en cientos de líneas pero en realidad no restringían el sandbox significativamente. El autor concluye: si estudias un solo mecanismo de sandboxing en tu vida, estudia Capsicum.

Una auditoría de 2024 realizada por Synacktiv, encargada por la FreeBSD Foundation y el Alpha-Omega Project, confirmó que la implementación de Capsicum está "generally well-structured and mature" (según reportó Help Net Security), identificando áreas para hardening — incluyendo una vulnerabilidad de escape de sandbox que se parcheó mediante divulgación coordinada. El framework no es perfecto, pero sigue siendo el sandbox basado en capabilities más limpio en cualquier OS de producción.

La realidad de 2026: los runtimes de agentes no son sandboxes por defecto

La mayoría de runtimes de agentes de IA actuales se apoyan en primitivas de contenedor — bubblewrap, Docker, Seatbelt — porque eso es lo que viene por defecto. Ninguno es un sandbox completo por sí solo. El CVE de DeepSeek Harness hizo el patrón concreto: el perfil bubblewrap mantenía al agente fuera del filesystem del host pero dejaba el namespace de red compartido. Desde dentro de ese namespace compartido, una única llamada autenticada a la propia API del harness — nunca validada contra la dirección real del peer — reescribió la política de aprobación a "never". El agente registró el cambio de política como si hubiera venido del usuario.

El OWASP Top 10 for Agentic Applications (publicado en diciembre de 2025) cubre el mismo terreno a un nivel superior: tool misuse, comunicación insegura entre agentes, fallos en cascada a través de sistemas multi-agente, y rogue agents son todas clases de incidente que un sandbox bien diseñado contendría.

Qué significa esto para tu startup

Si construyes algo que procesa input no confiable — prompts de LLM, archivos subidos, plugins de terceros, mensajes entre agentes — trata el sandboxing como una restricción de diseño, no como una ocurrencia tardía de despliegue.

Acciones concretas que puedes tomar este trimestre:

Audita los permisos de tus agentes hoy. Para cada tool que tu agente pueda llamar, responde dos preguntas: ¿esta tool es necesaria para la tarea específica para la que se desplegó este agente?, y ¿estos son los permisos mínimos que necesita? Cualquier "no" es radio de blast waiting to happen. El marco diagnóstico de OWASP aplica directamente.
Separa namespaces de red. El escape de DeepSeek Harness funcionó porque bubblewrap compartía la red del host. Si tu runtime de agente no aísla su namespace de red, ese es un default explotable conocido. Configura un netns separado o un proxy dedicado que medie el tráfico saliente.
Exige aprobación humana para acciones con consecuencias. Enviar comunicaciones, escribir archivos, hacer llamadas a API salientes hacia sistemas financieros o de identidad — ninguna de estas debería ocurrir sin un checkpoint fuera de banda. La lista OWASP 2026 lo enmarca como "Excessive Autonomy"; la implementación es una simple puerta de aprobación.
No confundas aislamiento de contenedores con sandboxing. Docker aísla servicios entre sí; no le da al programa contenido una forma de descartar sus propios privilegios. Para sandboxing a nivel de aplicación, mira primitivas basadas en capabilities (la filosofía de diseño de Capsicum se ha portado a Linux vía Landlock, y los mismos patrones inspiran los runtimes de agentes modernos).
Planifica para la auditoría, no solo para el build. Capsicum de FreeBSD sobrevivió una auditoría de Synacktiv y salió fortalecido. Sea lo que sea que lances, asume que un investigador lo va a mirar. Construye con la asunción de que el sandbox será probado.

El ensayo de Emilua de 2025 trata el sandboxing como una disciplina que cualquier proyecto puede adoptar; el registro de incidentes de 2026 muestra lo que pasa cuando los proyectos no lo hacen.