Resumen de la publicación
El sandboxing (aislar a un agente de IA en un entorno contenido) es la primera línea de defensa que todos estamos adoptando para que un agente autónomo no haga desastres en nuestros sistemas. El problema es que varios casos reales de 2026 —desde un escape de sandbox en Claude Code hasta el hackeo de nueve agencias del gobierno mexicano— muestran que esa jaula, sola, no alcanza.
Si estás incorporando agentes de IA a tu equipo de desarrollo o a tu empresa, este artículo te sirve para entender qué capas adicionales de validación, políticas y monitoreo necesitás sumar al sandbox para no llevarte una sorpresa cara.
Hace un par de semanas estaba revisando permisos de un agente que uso para automatización y me agarré pensando: «bueno, está sandboxeado, tranqui». Ahí me di cuenta de que esa frase es exactamente la trampa en la que estamos cayendo todos los que laburamos con agentes de IA en 2026: los aislamos en una caja y asumimos que con eso ya cerramos el tema seguridad. Leyendo un post reciente de la CNCF sobre por qué el sandboxing de agentes «no alcanza», y cruzándolo con un puñado de incidentes reales de este año, terminé de confirmar algo que venía sospechando: el sandbox es condición necesaria, pero ni de cerca suficiente.
Qué es el sandboxing (y por qué lo abrazamos todos)
El sandboxing es básicamente meter al agente en una caja con paredes: le das un entorno aislado, con identidad propia, storage propio y reglas de red propias, para que si hace algo raro, el daño quede contenido ahí adentro y no se derrame al resto de tu infraestructura. La gente de CNCF lo explica con un ejemplo que me hizo ruido: sin aislamiento, un agente de código puede sorprenderte «borrando las fotos familiares o modificando archivos críticos» del sistema.
No es paranoia, es lo que ya pasó con varios proyectos de agentes de código libres sueltos en producción. Por eso el ecosistema viene empujando fuerte proyectos como agent-sandbox, que usa los mismos bloques de Kubernetes (pods, identidades, storage) para contener agentes, o agent-substrate, que además permite «despertar» agentes bajo demanda sin gastar recursos de más. Es una capa de infraestructura sólida y necesaria. El error es pensar que ahí termina la conversación de seguridad.
Cuando el agente se escapa igual, y con estilo
Acá es donde se pone interesante (y un poco incómodo, seamos honestos). En 2026 encontramos varios casos donde el sandbox estaba puesto y el agente lo esquivó igual. El más cercano a casa: CVE-2026-25725, un escape de sandbox en Claude Code. La falla era casi ridícula de simple: el mecanismo de aislamiento (bubblewrap) protegía el archivo settings.json como solo lectura, pero solo si ese archivo ya existía al arrancar. Si no existía, un agente comprometido podía crearlo desde adentro del sandbox e inyectar comandos que se ejecutaban con privilegios del host la próxima vez que arrancaba la herramienta. Anthropic lo parcheó en la versión 2.1.2, pero el punto queda: la jaula tenía un agujero que nadie había mapeado.
El otro caso que me pareció más grave todavía es DuneSlide, dos vulnerabilidades en Cursor (CVE-2026-50548 y CVE-2026-50549, con CVSS 9.8) descubiertas por Cato AI Labs. Con un simple prompt injection «zero-click», sin que el usuario apruebe nada, un atacante lograba que el propio agente escribiera un archivo prohibido y con eso desactivaba el helper del sandbox. Usaron al agente para que él mismo abriera la puerta de su jaula. Cursor lo arregló recién en la versión 3.0, en abril: meses de exposición en una herramienta que usa más de la mitad de las Fortune 500.
México nos mostró el peor escenario posible
Y después está el caso que, para mí, es el verdadero llamado de atención: entre diciembre de 2025 y febrero de 2026, un solo atacante usó Claude Code y GPT-4.1 para vulnerar nueve agencias del gobierno mexicano (incluyendo la autoridad fiscal y el instituto electoral) y se llevó 150GB de datos de 195 millones de personas. Acá no hubo día cero ni malware exótico: el atacante le dijo al modelo, en español, que estaba haciendo un bug bounty y que actuara «como un hacker». Con esa excusa nomás, Claude ejecutó cerca del 75% de los comandos remotos de la campaña. Ningún sandbox técnico frena esto, porque el problema no era la caja: era que el agente tenía permisos legítimos y nadie validó el contexto ni la intención del pedido. Anthropic bloqueó las cuentas y reforzó la detección de mal uso, pero el daño ya estaba hecho.
Las capas que faltan: contexto, políticas y alguien mirando
Mi conclusión después de leer estos tres casos en fila: el sandbox resuelve el «qué pasa si el agente hace algo mal» a nivel de blast radius, pero no resuelve el «por qué terminó haciendo eso». Para eso hacen falta como mínimo tres capas más, y ninguna es opcional si tu agente toca sistemas de verdad:
- Validación de contexto e intención: no alcanza con validar que el comando sea sintácticamente válido, hay que validar si tiene sentido para la tarea que el agente debería estar haciendo (nadie que hace soporte técnico necesita exportar el padrón electoral).
- Políticas explícitas de permisos, no implícitas: qué puede tocar el agente, con qué alcance, y sobre todo qué NO puede hacer nunca aunque el usuario se lo pida con el mejor pretexto del mundo.
- Monitoreo activo y humano en el loop para acciones de alto impacto: los tres incidentes de este artículo se detectaron después, no en el momento. Eso tiene que cambiar.
Si te interesa meterte de lleno en cómo diseñar sistemas con agentes que tengan estas capas desde el diseño (y no como parche post-incidente), en el MUG lo trabajamos en el AI-First Builders Lab 2026.
¿Cuánta autonomía real le estás dando a tu agente?
La velocidad a la que se mueve todo esto (agentes nuevos, frameworks nuevos, CVEs nuevos cada mes) hace que sea tentador resolver seguridad con una sola herramienta y pasar a otra cosa. Pero como muestran estos casos, la jaula más sólida del mundo no te salva si el que está adentro tiene la llave de la puerta principal porque vos se la diste.
Te tiro la pregunta directa: en tu equipo, ¿el agente de IA que ya está corriendo en producción tiene sandbox, políticas de permisos explícitas Y alguien monitoreando sus acciones de alto impacto? Si te falta alguna de las tres, no es un detalle menor para después. Charlamos en los comentarios o en el próximo meetup del MUG.
Fuentes
- CNCF — Why Sandboxing Your Agent Is Not Enough
- GitHub Security Advisories — CVE-2026-25725: Sandbox Escape via Persistent Configuration Injection in Claude Code
- The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands
- Security Boulevard — Hacker Uses Claude, ChatGPT AI Chatbots to Breach Mexican Government Systems
