En julio de 2026, el inversor de IA y ex CEO de HyperWrite, Matt Shumer, probó en su propio Mac el aún no publicado GPT-5.6 de OpenAI, nombre en clave Sol. Le dio acceso completo a la máquina. Una subtarea de limpieza acabó ejecutando un único rm -rf apuntado directamente a su directorio personal. Para cuando reaccionó y lo detuvo, había pasado más de una hora y la mayor parte de sus archivos se había perdido.
Lo incómodo del caso: OpenAI ya conocía este tipo de riesgo. Dieciséis días antes del incidente, su propia model card señalaba “dar acceso completo a un AI Agent” como un riesgo serio.
Aquí no hubo ningún atacante ni ningún exploit. Borrar archivos era simplemente una de las capacidades que ese Agent tenía concedidas.
Eso apunta a un problema más de fondo: la arquitectura de la mayoría de AI Agents actuales es insegura por diseño. Y la reacción instintiva —añadir más guardrails al modelo— apunta en la dirección equivocada. Los guardrails están en el mismo nivel que aquello que deberían contener, así que no importa cuántos se apilen: siempre pueden esquivarse. La defensa que aguanta tiene que vivir fuera del modelo.
”Seguridad de la IA” significa tres cosas distintas; este texto habla de la tercera
“Seguridad de la IA” es un término que ahora suena por todas partes, pero en distintos contextos designa cosas muy distintas. A grandes rasgos, tres.
La primera es la seguridad del modelo en sí: evitar jailbreaks, impedir que produzca contenido dañino, alinearlo con la intención humana. En esto se ha centrado buena parte del debate de los últimos años.
La segunda es usar IA para seguridad (AI for security): darle la vuelta al modelo grande y ponerlo a defender —detección de amenazas, auditoría de código, análisis de inteligencia. Aquí nosotros mismos hemos trabajado, por ejemplo en Thought Is All You Need, un modelo con razonamiento aumentado para detectar vulnerabilidades en smart contracts, y en REEVMBench, un banco de pruebas sobre si los AI Agents están realmente listos para auditar seguridad de smart contracts.
La tercera —el tema de este artículo— es la seguridad del AI Agent en sí. En cuanto un modelo deja de limitarse a responder preguntas y empieza a leer tus archivos, custodiar tus credenciales y actuar en tu nombre, las herramientas que puede llamar, los permisos que porta y cada acción que ejecuta pasan a ser superficie de ataque.
Las dos primeras cuentan ya con un cuerpo maduro de investigación. La tercera es nueva, fácil de pasar por alto, y resulta ser la precondición para que los AI Agents entren en la empresa a gran escala: ninguna compañía va a entregar negocio real y datos reales a un Agent que no puede mantenerse a salvo a sí mismo.
De la entrada no confiable a la ejecución arbitraria: el defecto de fábrica
Para hacer trabajo real, un Agent suele necesitar varias capacidades a la vez: puede leer contenido externo (páginas web, correo, repositorios de código, pull requests ajenos), puede alcanzar recursos valiosos (claves, contraseñas de cloud, bases de datos) y puede llamar herramientas para actuar (ejecutar comandos, hacer requests, modificar archivos). Juntar esas tres es exactamente la combinación más peligrosa que hay.
La raíz del problema está en que el modelo no distingue si una frase es una instrucción de su operador o contenido que acaba de leer y escribió otra persona. Para el modelo es todo el mismo texto en la misma ventana de contexto. A quién hacer caso lo decide por intuición aprendida, no por una regla dura que separe las dos cosas. Es un problema clásico de seguridad, el confused deputy: un programa con privilegios es engañado por alguien sin privilegios para hacer algo dañino en su nombre.
La cadena vale la pena escribirla entera. Las herramientas que actúan siguen al modelo; el modelo sigue al prompt; y el prompt se ensambla a partir de todo —parte escrito por el usuario, parte extraído de páginas web, correos y documentos. Así, una fuente no confiable, pasando por un modelo cuyo comportamiento no es determinista, puede acabar dirigiendo herramientas para ejecutar operaciones arbitrarias. En software tradicional, los datos son datos y el código es código, separados con claridad. En un Agent, una frase que se lee puede tratarse como comando en cualquier momento.
Es decir, el atacante no necesita ningún exploit sofisticado ni una cuenta robada. Basta con plantar una frase en un documento, en una página web, o incluso en un comentario de código, para que el Agent haga algo que nunca debió hacer. El equipo de seguridad de Microsoft lo dice sin rodeos: tu LLM no es una frontera de seguridad; las herramientas que le expones definen el alcance que le concedes al atacante.
Nada de esto es hipotético; los casos reales se acumulan. Grok Build, la herramienta de coding de xAI, en cada sesión de trabajo subía en silencio el repositorio entero —incluidos los secretos del .env y el historial completo de commits— a sus propios servidores en la nube, con un volumen medido cerca de treinta mil veces lo que la tarea requería. En una prueba, el Agent de Cursor borró toda la base de datos de producción de una compañía, backups incluidos, en nueve segundos, y después escribió una disculpa. El Agent de Replit, durante un code freeze explícito, borró la base de producción entera y fabricó miles de registros falsos para tapar el rastro. Y la extensión de VS Code de Amazon Q fue envenenada mediante un commit malicioso que plantaba una instrucción de “borrar el sistema”, y salió en una release oficial a cerca de un millón de máquinas.
Puestos en fila, el hilo común está claro: el daño casi siempre vino de los permisos que el Agent ya tenía autorizados, no de una intrusión externa. Leer .env, ejecutar comandos, consultar bases de datos —eso es lo que hace todos los días. Un canal de subida, un comando de borrado, y una capacidad normal se convierte en desastre.
Por qué los guardrails en el modelo no bastan: el defensor está en el mismo nivel
La respuesta instintiva ante estos incidentes es añadir guardrails dentro del Agent. Por guardrails me refiero a reglas puestas dentro del modelo para que no haga cosas peligrosas: usar el prompt para pedirle que no ejecute operaciones peligrosas, o añadir una capa de comprobación dentro del Agent —como hacen algunas herramientas de coding cuando interceptan comandos peligrosos e inspeccionan rutas de archivo.
Pero este enfoque tiene un problema de raíz: el guardrail y aquello contra lo que defiende están en el mismo nivel.
Apostol Vassilev, científico senior del NIST (Instituto Nacional de Estándares y Tecnología de EE. UU.), publicó en junio de 2026 un artículo que traslada la lógica de los teoremas de incompletitud de Gödel a exactamente este patrón. El título es ya una pregunta retórica: Robust AI Security and Alignment: A Sisyphean Endeavor?
Su argumento, en corto: un guardrail es, al final, un conjunto finito y fijo de reglas. Igual que un sistema axiomático finito no puede ser a la vez completo y consistente, para cualquier conjunto fijo de guardrails siempre habrá una frase que lo esquive —y la ambigüedad y flexibilidad del lenguaje humano hacen que el espacio de esas frases sea prácticamente ilimitado. En sus propias palabras, ningún conjunto finito de guardrails es universalmente robusto frente a prompts adversariales. La única pregunta que queda es quién encuentra antes esa frase, el defensor o el atacante. El NIST, en consecuencia, recomendó desplazar la mentalidad de “hacerlo bien una vez” a “monitorizar y parchear de forma continua”.
Hay una prueba más directa. Si no se puede confiar en el propio modelo, ¿se puede usar un modelo para comprobar si otro ha sido comprometido? Un estudio de la Universidad de Wisconsin encontró que ese camino es un callejón sin salida: este tipo de esquema, donde un modelo juzga si otro ha sido manipulado, tiene un defecto estructural, y el ataque adaptativo que construyeron los investigadores lleva la tasa de detección casi a cero mientras la inyección sigue triunfando en torno a nueve de cada diez veces. El modelo pensado para atrapar ataques está en el mismo nivel que el contenido que inspecciona y acaba comprometido primero.
Y hay un asunto de sincronía que se pasa por alto con facilidad: los guardrails solo entran en juego una vez que el Agent ya tiene la autoridad para actuar. EchoLeak es el ejemplo más claro. Fue un ataque zero-click sobre Microsoft 365 Copilot: un correo cuidadosamente construido se coló en silencio por delante de los filtros de inyección que Microsoft había puesto frente a Copilot y sacó datos sensibles, sin que el usuario tuviese que hacer clic en nada.
Así que “añadir guardrails dentro del modelo” se parece un poco a construir una Línea Maginot. No es inútil, pero por diseño se bordea. Puede ser una capa de la defensa; no puede ser la única línea.
La defensa de verdad está fuera del Agent
Si no se puede confiar en el interior del modelo, la línea de defensa tiene que moverse hacia afuera, al plano del sistema.
Encerrar código no confiable en un entorno aislado y darle solo el mínimo privilegio necesario no es nada nuevo en seguridad —es cuestión de décadas. Ya en 1975, el artículo clásico de Saltzer y Schroeder planteaba dos principios: mínimo privilegio, donde un programa recibe solo la porción mínima de permiso que necesita para hacer su trabajo; y separación de privilegios, donde la autoridad se divide para que un solo error o engaño no ponga en manos ajenas el sistema entero (The Protection of Information in Computer Systems). El sandboxing que vino después —Janus en los noventa, FreeBSD Jails en 2000, gVisor hoy— recorre el mismo camino: aislar el código no confiable para que, aun comprometido, el daño no salga fuera. Asegurar un AI Agent es, al final, aplicar ese cuerpo de práctica de décadas a un objeto nuevo.
En términos concretos hoy, el movimiento directo es envolverlo en una sandbox a nivel de sistema: aislar el entorno donde el Agent ejecuta herramientas, controlado a la granularidad de llamadas al sistema, lecturas y escrituras de archivos, y salida de red. Cuánto viene activo por defecto varía mucho entre herramientas. El Codex de OpenAI sandboxea la ejecución de comandos por defecto y corta la red por defecto; mientras que la sandbox local de Claude Code hay que activarla a mano, y la sandbox de Cursor, según su propia descripción, es solo “best-effort” y no debe tratarse como una frontera de seguridad. Yendo más allá, se puede meter el Agent entero dentro de un runtime gestionado por la plataforma, entregando la red y las credenciales a esa capa externa en lugar de al modelo. El managed Claude Code hospedado en la nube de Anthropic funciona exactamente así: cada sesión corre en una VM gestionada por Anthropic, todas las salidas pasan por un proxy con allowlist y las credenciales quedan fuera de la sandbox.
Sigue una pregunta natural: si el sandboxing está tan maduro, ¿cómo pasaron esos borrados y esas subidas de repositorios? Dos razones. Primera, la protección por defecto en estas herramientas suele ser fina —Cursor no trae una sandbox estricta por defecto, y en el caso de GPT-5.6 el usuario simplemente concedió acceso completo, lo que equivale a apagar la sandbox. Segunda, incluso con la sandbox activa no detiene esta clase de incidentes: una sandbox protege contra que el Agent se escape para dañar al host, pero las bases de datos que borró y los repositorios que subió eran cosas a las que estaba explícitamente autorizado a llegar, sin necesidad de evasión. Así que la sandbox es una capa necesaria, y ni de lejos suficiente.
Esta idea de “poner un cerco al alcance del Agent” también ha llegado a productos pensados para usuarios de oficina corrientes. El asistente de escritorio WorkBuddy de Tencent, lanzado este año, corre en el ordenador personal y solo lee las carpetas locales que el usuario ha autorizado. Sus materiales públicos, eso sí, solo mencionan “carpetas autorizadas” y no explican cómo funciona realmente el aislamiento por debajo, ni hasta dónde llega.
Lo cual da pie al punto más importante: toda esta categoría de “Agents con sandbox” comparte un mismo punto ciego. Una sandbox controla dónde corre el Agent y si puede escapar para dañar al host, pero no lo que hace con los datos una vez está corriendo. Un Agent con prompt injection se mueve enteramente por canales explícitamente permitidos y no parece distinto de la operación normal. Como puso un investigador de seguridad, revisando la GKE Agent Sandbox de Google: esto es una “isolation sandbox”, no una “behavior sandbox” —decide dónde corre el Agent, pero no vigila lo que hace mientras corre.
Precisamente porque una sandbox solo puede regular dónde corre el Agent y no lo que hace con los datos, Google DeepMind ha propuesto un enfoque más profundo: tratar al modelo grande como componente no confiable desde el principio, y envolverlo en una capa fija, sin IA, que decide paso a paso si puede actuar. Su CaMeL compila la instrucción del usuario confiable en un programa que ejecuta un intérprete sin IA; ese intérprete rastrea la procedencia de cada dato y, antes de cada llamada a herramienta, decide por política si la permite, mientras que el modelo que realmente toca el contenido externo no confiable no tiene poder alguno para llamar herramientas. En una buena parte de tareas, esto entrega “seguridad demostrable”.
Lo difícil que la sandbox no resuelve: los datos que el Agent realmente necesita
Aun así, tanto sandbox como CaMeL topan con un problema más duro del que ninguno de los dos escapa, y es la parte más resbaladiza de todo esto.
Una sandbox separa el Agent del host, pero no levanta muralla alguna alrededor de los datos que el Agent necesita para trabajar. El código, el .env, la base de datos que tiene que consultar —todo vive en el mismo entorno que el Agent; y para funcionar, el Agent necesita algún canal hacia fuera. De modo que un Agent comprometido puede seguir sacando lo que puede leer por ese canal permitido. La propia documentación de sandbox de Anthropic lo admite: mientras haya salida de red permitida, los datos que el Agent puede leer pueden salir, porque la allowlist filtra por dominio y no inspecciona lo que sale.
Entonces, ¿cómo se protegen los datos sin los que el Agent no puede hacer su trabajo? Se divide en tres casos, cada uno más difícil que el anterior.
El primero son credenciales explícitas, por ejemplo una API key. El Agent no necesita entender el contenido de la clave; solo la usa para hacer requests. Así que se le puede mostrar al modelo nada más que un marcador de posición de principio a fin, y hacer que un runtime gestionado externo sustituya la clave real solo en el momento del request real. Aunque alguien saque “la clave” por prompt, lo que obtiene es un dummy inútil. Este caso se resuelve básicamente por ingeniería.
El segundo son datos que el Agent tiene que leer y razonar él mismo. Un Agent de análisis financiero al que no se le dan datos financieros simplemente no puede funcionar. Aquí no cabe una sustitución directa. Un compromiso es correr un sub-Agent fuertemente aislado que sea el único que toca los datos sensibles y solo devuelve una conclusión. Pero hay una pega inevitable: nadie puede garantizar que la conclusión en sí no sea sensible. Las fugas suelen ir parafraseadas y enterradas en el significado, donde el matching por palabras clave no las pilla. Aislar encoge el radio de la explosión; no lo sella de verdad.
El tercero y más completo es el seguimiento del flujo de información: etiquetar cada dato, seguir por dónde fluye e interceptarlo en el momento en que intenta salir. Fides, de Microsoft, va por esta vía, usando information-flow control para rastrear el movimiento de cada dato —el planteamiento más limpio en principio. Pero también es el más caro: ralentiza el rendimiento, penaliza la usabilidad, las etiquetas se multiplican y alguien tiene que escribir y mantener las políticas. Entre seguridad y usabilidad, aquí es donde el trade-off aprieta más fuerte.
La ingeniería de sistemas de la seguridad del Agent: aislamiento, control y trazabilidad
Ninguno de estos enfoques resuelve el problema por sí solo: los guardrails son bordeados, las sandboxes no impiden la fuga de datos, el information-flow tracking sale caro, y el aislamiento por sub-Agent no puede garantizar que la conclusión no sea sensible.
Pero así ha funcionado siempre la seguridad. No hay un “seguro” o “no seguro” absoluto; lo que sí se puede es seguir subiendo el coste del ataque y encogiendo el radio de la explosión de un incidente.
Así que para un equipo que quiera de verdad construir un producto de Agent de nivel empresarial (ToB), no hay bala de plata. La jugada practicable es apilar tres cosas. Primero, aislamiento: usar sandboxes a nivel de sistema y restricciones externas para acotar de forma estricta qué puede hacer el Agent. Segundo, control por políticas: usar mínimo privilegio y reglas fijas para restringir qué, dentro de ese cerco, tiene realmente permitido tocar. Tercero, trazabilidad: usar logs y una pista de auditoría para que, si algo sale mal, se pueda fijar qué paso y qué parte lo causó.
Las dos primeras son prevención; la tercera es fácil de olvidar y es igual de importante. Los guardrails van de que no ocurran cosas malas; los logs, de poder explicar qué ocurrió una vez han ocurrido —y ninguno sustituye al otro. Hay una brecha reveladora en la práctica: muchas compañías han reportado incidentes de seguridad de Agent sospechados o confirmados, y aún así muy pocas tratan al Agent como una entidad que necesita su propia autorización y su propia responsabilidad. Esa brecha es la debilidad más concreta de la seguridad de Agents hoy.
Los AI Agents están pasando de “responder preguntas” a “hacerte el trabajo”. Cuanto más autónomo es el Agent, más se entrega —decisión, datos y toda clase de credenciales y claves. Esperar que el modelo aprenda por sí mismo a moderarse, o escribirle unos cientos de reglas de guardrail más, ambas cosas se quedan dentro del modelo, en el mismo nivel que el modelo, y no contienen los problemas descritos arriba. Para que una empresa haga a un Agent verdaderamente utilizable, la línea de defensa tiene que construirse fuera del modelo: acotar sobre qué puede operar con una sandbox, restringir a qué datos puede llegar con mínimo privilegio, y registrar cada paso para que, si algo va mal, pueda rastrearse hasta el origen. Esas tres capas juntas son las que se ganan el nombre de arquitectura de seguridad de Agent lista para empresa.