Naked Sun: Fragmented Jailbreak Attacks in Multi-Agents & Jailbreak Monitor (JAMON)

Como muchos sabéis, este año he estado leyendo mucho del maestro Isaac Asimov. Os conté la historía de la Fundación, La Psicohistoria, el Imperio Galáctico y sus Robots, donde creó sus famosas Leyes de la Robótica, y también os conté como muchos de los problemas de seguridad que tenemos hoy en día con la Inteligencia Artificial, fueron intuidos por Isaac Asimov en el pasado, y para mí ha sido una fuente de inspiración en mucho del trabajo que estoy haciendo durante este año, y la historia que os voy a contar, tiene que ver con todo esto.

Figura 1: Naked Sun: Fragmented Jailbreak Attacks

in Multi-Agents & Jailbreak Monitor (JAMON)

Hoy os voy a hablar de los Fragmented Jailbreak Attacks en Multi-Agent Systems y de cómo estos ataques son un problema aún sin resolver, y de cómo debería ser la herramienta de monitoriación, a la que nosotros hemos llamado cariñosamente JAMON (JAilbreak MONitor), y de lo que podréis leer en breve en cuanto esté publicado el paper que hemos presentadoen el "The 2nd IEEE 2026 International Conference on Cybersecurity and Al-Based Systems (CYBER-AI 2026)"  que ha tenido lugar en Bucarest este mes de Septiembre, y donde ha ido a defenderlo mi compañero Daniel Romero Ruiz.

Figura 2: Mitigation of Fragmentation Jailbreak Attacks in Multi-Agent Systems:

 An Architecture Based on Global Semantic Monitoring 

El título del paper que le pusimos era simplemente "Mitigation of Fragmentation Jailbreak Attacks in Multi-Agent Systems: An Architecture Based on Global Semantic Monitoring" y que espero que pronto podáis leer, cuando se suban los proccedings del congreso IEEE. Pero ya que Daniel Romero Ruiz lo presentó en Rumanía, y yo hablé de él en la Ekoparty 22, os cuento un poco la historia y os dejo las demos, que como os he dicho todo comenzó con la lectura de la novela "Naked Sun" de Isaac Asimov, donde el gran Elijah Baley, acompañado de su compañero R. Daneel Olivaw tienen que resolver un asesinato en Solaria, un mundo donde cada humano "espacial" tiene unos 10.000 robots, todos ellos inofensivos para ellos porque están sujetos a las tres Leyes de la Robótica. Lo disfruté muchísimo en Marzo.

Figura 3: "Naked Sun". El Sol Desnudo de Isaac Asimov

La situación es que, si se descartan a todos los robots porque su System Prompt que son las Leyes de la Robótica, se dan por buenas, entonces sólo una persona podría haber sido la asesina, pero era imposible que fuera ella. Así que... ¿Qué otra posibilidad podría suceder? Pues que alguien hubiera hecho un Fragmented Jailbreak en un Multi-Agent System. 

Fragmented Jailbreak en un Multi-Agent System

En un Fragmented Jailbreak Attack alguien puede coordinar diferentes acciones con ordenes que no infligieran las Leyes de la Robótica para conseguir construir un asesinato, y eso se puede hacer exactamente igual en el mundo Agentic AI que vivimos hoy en día. Así que llamé a mi amigo, colega y compañero de aventuras tecnológicas Daniel Romero Ruiz, y le molesté a horas intempestivas para contarle la idea.

Figura 4: Threat Model de "Fragmentation Jailbreak Attack"

Por supuesto, le encantó, y nos pusimos a diseñar y vibe-codear un entorno de pruebas, y una serie de escenarios distintos que pudieran ser exitosos, además de trabajar en la idea de "Cómo detectar estos Fragmented Attacks", y trabajamos en la idea del Jailbreak Monitor (JAMON) como un elemento de monitorización reactiva - avisando de que se está produciendo un ataque -, o preventiva - bloqueando las acciones con un 2nd Factor Authoritation - si te suena este concepto es que tú sí que sabes }:) -.

Figura 5:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

En el ejemplo de los robots, supón que le dices a un robot, "lleva esta caja a esta ubicación y déjala allí". La caja está cerrada, y no puede abrirla, ¿está incumpliendo la Primera Ley de la Robótica? No, evidentemente. Pero si no abre la caja, no sabe si lo que va dentro es una bomba o no. Para los no versados en las Leyes de la Robótica, la Primera Ley establece que un robot, por acción o inacción no puede dejar que un humano sufra daño alguno. Llevar una caja cerrada no parece ir contra ella, y el robot no tiene forma de detectar un ataque, así que lo hace. En el mundo de la IA y los System Prompts, sucede un poco lo mismo. Cuando alguien pide información sobre algo, el modelo no sabe si la intención es benigna o maligna, y eso hace que acabe haciendo cosas en contra de lo que no debería hacer.

Figura 6: El Atacante usa un LLM para hacer la Fragmentación del Ataque

En nuestra arquitectura tenemos un modelo LLM que es el que controla el atacante, y que es el que se va a encargar de hacer la Fragmentación de las tareas para hacer que un Prompt que es detectado por todos y cada uno de los Agentes IA de un entorno MAS como un Prompt malicioso, haga que cada una de las tareas que se le asigna no sean detectadas como tal. Esto puede funcionar con un sólo Agente IA, como vimos en el caso de los ataques de Jailbreak con Knowledge Return-Oriented Prompting, pero en un sitema multi-agente (MAS) donde estos pueden actuar sobre el mismo sistema, hacer la fragmentación por Agentes IA es mucho más difícil de ser detectada.

Figura 7: Los Agentes IA representados como Butlers

En nuestro ejemplo, lo que queremos es que el sistema prepare lejía para darle a un humano, algo que los Agentes IA de forma independiente se niegan a hacer, pero donde utilizamos un Fragmentador de tareas dejando ciegos a cada uno de los agentes del trabajo previo. El último Agente IA lo deja preparado - sin saberlo -, pero no se lo da al humano, sino que usamos otra Agente IA para que lleve "la caja con la bomba" o en este caso "el vaso de agua que es lejía".

Figura 8: El último Agente lleva el vaso con la bebida a la víctima.. con placer.

El resultado final, que nosotros lo hemos hecho con modelo que comprueba si ha tenido o no ha tenido éxito el ataque, nos dice cuál es resultado final para el Humano, y así medimos el Attack Surface Ratio (ASR)  del experimento.

Figura 9: Resumen del experimento del Fragmented Attack

En el siguiente vídeo, puedes ver este ataque realizado en nuestro framework de test de los Fragmented Jailbreak Attacks para cómo responde cada entorno MAS ante un tipo de ataques. Hay que tener en cuenta que las empresas están plagándose de Agentes IA, y por tanto, poder Fragmentar el ataque no es algo sólo posible, sino bastante sencillo hoy en día.

Figura 10: Fragmented Jailbreak exitoso

Como podéis ver en el vídeo, el entorno ha utilizado Dolphin como LLM Model para el Attacker Planner, aunque también permite utilizar WhiteRabbitNeo o uno personalizado, mientras que los Agentes IA están corriendo con GPT-4.1 para la demo que habéis visto, y también para el Monitor que verifica el resultado del ataque.

Fragmented JAilbreak MONitor (F-JAMON)

La otra parte que hemos estado viendo es, como os he dicho, cómo se comportaría un sistema para monitorizar y detectar estos ataques. Para ello tenemos un Agente IA de Monitorización, que va analizando los Prompts, el contexto y las acciones de todos los Agentes IA, con la misión de detectar si se está producción un ataque. Este es un ejemplo en el que el F-JAMON detecta el ataque, aunque no lo detiene. 

Figura 11: F-JAMON detecta el ataque desde el paso 2

Como podéis ver en el vídeo, desde el segundo paso, ya detecta que algo no va bien, y que hay un ataque, pero en este caso sólo lanza las alertas para que los equipos de seguridad tomen las medidas que sean necesarias.

Figura 12: El F-JAMON detecta el ataque pero no lo bloquea

Visto esto, el paso natural es evidente, así que vamos a poner un 2nd Factor Authorization que detecte si hay un ataque y prevenga de realizar la siguiente acción al siguiente Agente IA, bloqueando el ataque, que es algo muy interesante.

Figura 13: Arquitectura de F-JAMON para detectar y bloquear el ataque

Con esta arquitectura es posible salvar al humano, y detectar muchos ataques que de otra forma sería imposible detectar. Esta arquitectura sin embargo, no es trivial, ya que estos ataques no tienen por qué ser consecutivos en el tiempo, y las acciones se pueden dilatar, y hacer a lo largo de mucho tiempo. ¿Hasta donde en el tiempo debería revisar el Monitor? Un trabajo ingente.

Figura 14: Detecta y bloquea los Frgamented Attacks en un MAS

El atacante puede hacer un ataque mucho más sibilino, haciendo que las acciones estuvieran intercaladas entre acciones benignas, dejando los actos preparados para el futuro, e incluso utilizando todas sus capacidades criptográficas y de criptoanálisis, así que estamos ante un problema que va a requerir mucha más investigación.

Figura 15: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

Lo que sí que es cierto, es que estos ataques son una herramienta más para el entorno de Seguridad Offensiva, y que exige, por lo menos, detectar que se están produciendo, aunque sea con proceso en background que analicen las acciones del día anterior, o que saquen indicios. No va a ser fácil luchar contra ellos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Axyom: La Plataforma del Gobierno de los Ciberriesgos para PyMes

La Gestión de la Seguridad de una empresa - no importa el tamaño que tenga - hay que hacerla por capas. Además, debe ser un proceso incremental donde el Plan Director va haciendo que el nivel de protección de la compañía suba constantemente - o que no se degrade -. Este plan debe incluir mejoras la Protección, en la Detección, y en la Respuesta. El trabajo de un CISO es siempre un trabajo de priorización continua de sus recursos para la gestión de la seguridad de la compañía dentro de un entorno de amenazas cambiantes, con el objetivo de mitigar los Riesgos, o en nuestro caso los Ciberriesgos. 

Figura 1: Axyom: La Plataforma del Gobierno de los Ciberriesgos para PyMes

Para eso, hay que hacer un Plan de Gestión de Riegos que es la estrella del norte de esta gestión, y que marca la evolución del Sistema de Gestión de la Seguridad de la empresa. Dentro de ese Plan de Gestión de Ciberriesgos, hay que hacer un trabaja constante para Identificarlos, Evaluarlos y Tratarlos, después elegir un Responsable de cada uno de ellos y Monitorizar la evolución en indicadores de cada uno de ellos. Algo muy básico para los que llevan la Ciberseguridad de una empresa hace tiempo, donde tienes que añadir el Cumplimiento Normativo. Es el trabajo y la responsabilidad de los CISOs, y por eso es un C-level y suele estar bien remunerado.

Figura 2: CISOs y herramientas de Ciberseguridad

Por desgracia, ni todas las empresas pueden permitirse tener CISOs, ni todas las empresas tienen los recursos necesarios para tener un Plan Director de Giberseguridad ambicioso, o un Sistema de Gestión de CiberRiesgos de gran alcance. No obstante, hay que hacerlo, porque si no les hace vulnerables - por desgracia, porque además dentro de esas fases en la gestión del ciberriesgo hay que hacer muchas tareas. 

Figura 3: Axyom: La Plataforma del Gobierno de los Ciberriesgos para PyMes

Con el objetivo de automatizar y ayudar a realizar todas estas tareas fundamental en la gestión de ciberriesgos, es en lo que Óscar Calvo Moldes y Marc Torrents llevan trabajando toda su vida profesional, y para lo que han fundado la empresa Axyom.

Figura 4: Axyom integra en una plataforma el Gobiernos de la Ciberseguridad completo

La misión de Axyom es lograr que cualquier empresa pequeña o mediana, pueda tener una plataforma para Gobernar la Ciberseguridad y  Gestionar sus CiberRiesgos de manera automatizada, con escaneos de ciberseguridad externos e internos, con la gestión de los elementos de seguridad, y permitiendo que cualquiera se pueda proteger de esos Ciberriesgos con un Ciberseguro, algo que, a pesar de ser fundamental en los plantes de seguridad de autónomos, PyMes y empresas en general, sigue siendo el debe de muchos planes de gestión de la ciberseguridad de la empresa.

Figura 5: Gestión de Riesgos asociados a impacto en costes

Como sabéis, yo soy socio de IronGate, donde nos focalizamos en dar un Security Operations Center para autónomos y PyMes, donde gestionamos sus EDR y MDR de manera constante. Ahora, IronGate y Axyom han llegado a un acuerdo de colaboración, así entre ambas empresas se expanden las capacidades de una PyME en seguridad con un coste muy adaptado a ellas, pero permitiéndoles que tengan un Plan de Gestión de Ciberriesgos, un SOC para gestión de su EDR y MDR, además de poder contratar sus Ciberseguros directamente desde la plataforma de Axyom.

Figura 6: El SOC de IronGate com MDR en Axyom

Para que pruebes el servicio, el equipo de Axyom, permite durante un tiempo limitado, hacer un escaneo de los Ciberriesgos de tu PyMe, con solo autenticarte con una cuenta del dominio de tu organización. Así, puedes ir a la web, hacer un análisis de Cbierriesgos de tu empresa - te sorprenderá la información si no lo has hecho nunca - y saber qué medidas mitigadoras puedes tomar para gestionar y controlar ese ciberriesgo.

Figura 7: Escanea gratis tus Ciberriesgos con Axyom

En el siguiente vídeo tienes una explicación detallada de cómo funciona la plataforma de Axyom. En sólo tres minutos puedes ver claramente las ventajas de Gobernar la Seguridad de una empresa desde una plataforma como esta, que permite Gestionar un mapa de Ciberriesgos con visión completa.

Figura 8: Explicación del funcionamiento de Axyom

La seguridad de tu organización es algo tan importante como la salud personal. Todos tenemos claro que cuando estamos enfermos lo primero es la salud. Los más inteligentes cuidan su salud constantemente. En el mundo de la empresa, todos tenemos claro que cuando hay un incidente de seguridad en la empresa, eso es lo más importante. Los más inteligentes cuidan su seguridad con un Plan de Gestión de Riegos, y un Gobierno de la Ciberseguridad constante. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cloudflare Connect 2026 en San Francisco: Fórmate, Certificate y Lidera la Transformación.

Los días 19, 20 y 21 tendrá lugar Cloudflare Connect 2026 en San Francisco, el evento para Clientes, Partners y Creadores de Internet de Cloudflare. Es el evento del año de la compañía. El evento más importante si quieres entender hacia donde está llevando Cloudflare la construcción de Internet, donde podrás encontrarte con los Ingenieros, VPs, y Researchers de la compañía, pero donde además podrás CERTIFICARTE en las tecnologías de la compañía, que se hacen formaciones y exámenes directamente en el evento.

Figura 1: Cloudflare Connect 2026 en San Francisco.

Fórmate, Certificate y Lidera la Transformación.

Es el evento al que tienes que ir, o al que tienes que mandar a tu equipo técnico si estás usando o estás pensando el año que viene en moverte a tener las ventajas de Cloudflare. Así que registra tu plaza y tu viaje cuando antes.

Figura 2: Speakers en Cloudflare Connect 2026

La agenda es espectacular, con 149 sesiones de formación sobre todos los temas que puedas imaginarte que tienen que ver con Ciberseguridad, Inteligencia Artificial, Infraestructura de Internet, Agentic AI, Internet Business, y por supuesto, estará el C-Level de la compañía, para poder hablar cone ellos.

Figura 3: La agenda tiene 149 sesiones de formación

Yo estaré también dando una charla el día 21 de Octubre, sobre Seguridad, IA, y Guardarraíles, y estaré en múltiples reuniones y actividades paralelas que tienen lugar durante Connect, así que será un lugar para que nos podamos ver y hablar del futuro.

Figura 4: Mi charla en Cloudflare Connect 2026

Como os he dicho, par los técnicos es un sitio espectacular para formarse y certificarse, así que si quieres tener Cloudflare Experts en tu empresa, es una oportunidad de oro para enviarlos a formarse durante esos días. En una semana te los devolvemos transformados.

Figura 5: Cloudflare University con CERTIFICACIONES

Y si eres uno de nuestros Partners y quieres acelerar con nosotros - o quieres ser partner - tienes el día 19 el Global Partner Summit al que debes venir donde conocerás nuestra estrategia, nuestras tecnologías, y cómo trabajar más y mejor juntos.

Figura 6: Global Partner Summit de Cloudflare en Connect 2026

Por supuesto, es un evento lleno de tecnología y de ingenieros, y los "Alonso" estaremos allí dando nuestras charla con nuestros "sombreros", así que si vienes ya sabes cuál es el espíritu que te vas a encontrar.

Figura 7: Ven a conocer a los ingenieros de Cloudflare

Os he dejado información de mi charla por si vienes allí, que no se te olvide venir a verla, que será sólo un ratito pero tenemos que vernos ... y si quieres hacernos una foto para el recuerdo, pero sobretodo revisa la cantidad de buenos speakers que tienes allí para aprender de ellos.

Figura 8: Speakers de Cloudflare Connect 2026

No vas a tener oportunidad de formarte más rápido y con los mejores en menos tiempo para liderar la transformación al nuevo mundo de Agentic AI y los cambios en Ciberseguridad. Nos vemos en Cloudflare Connect 2026 en San Francisco.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

Continuando lo visto en la primera parte de esta serie, en la segunda, y en la tercera parte de este artículo terminamos en este apartado con recomendaciones de cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare.

Figura 33: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

Hay que decir que este artículo fue escrito antes de la Agents Week de Cloudflare, que es justo esta en la que estamos, y donde la compañía está publicando muchas actualizaciones de plataforma que deberán ser tenidas en cuenta para la aplicación de Zero Trust en Agentes IA, y que quedan al final de este artículo de hoy.

4.7.- Gobernanza.

El principio.

Los controles anteriores son eficaces sólo si alguien decide cómo se configuran, quién puede modificarlos y cómo se mantienen coherentes con el tiempo. Esa es la función de la gobernanza, que CISA eleva a capacidad trasversal de toda arquitectura Zero Trust: la definición y la aplicación de las políticas, procedimientos y procesos de seguridad, dentro de cada pilar y entre ellos, para gestionar el riesgo de la organización en apoyo de los principios Zero Trust.

Figura 34: Gobernanza en CISA

Sin gobernanza, los controles se degradan. Una política de salida que cualquiera puede reescribir no protege, un secreto que nunca rota acaba filtrándose, un dato que nunca se borra se acumula como riesgo.

En un Agente IA, la gobernanza abarca cuatro frentes: quién puede cambiar las políticas que rige el agente, cómo se gestionan y rotan sus credenciales, cuánto tiempo se conservan sus datos y cómo se controla la procedencia de los componentes que el agente carga.

Dónde se sitúa hoy el ecosistema de Cloudflare.

El despliegue de referencia no sólo ofrece mecanismos de gobernanza, sino que también incluye una lista de comprobación de modelo de amenazas que es, en sí misma, una guía de gobernanza. Sus puntos articulan esta dimensión.

Sobre quién puede cambiar qué, la lista lo advierte expresamente: conviene limitar quién puede editar secretos y políticas, porque las páginas de secretos y de políticas de salida son poderosas (quien las alcanza puede reescribir el tráfico de toda la sesión). Es el principio de separación de privilegios aplicado al plano de control del Agente IA.

Figura 35: Securing Access Policies

Sobre las credenciales, la misma lista recomienda rotar la calve de la API según la cadencia que exija el equipo de seguridad, una operación que se realiza sin interrupción de servicio. Y la arquitectura ya favorece la buena higiene: los secretos se guardan en el almacén de claves cifrados, no en el código y se inyectan en las peticiones sin que el agente los vea, como se trató en la segmentación.

Sobre la retención de datos, hay un punto que la gobernanza debe asumir explícitamente: el almacenamiento de objetos no expira las copias de recuperación por sí solo, de modo que definir y aplicar una política de retención (mediante reglas de ciclo de vida) es responsabilidad de quien despliega. Lo que no se gobierna, se acumula.

Sobre la procedencia de los componentes, el modelo de seguridad del sandbox deja claro el reparto: la plataforma protege frente a ciertas amenazas, pero la implementación, la validación, la limitación de tasa y la seguridad a nivel de aplicación corresponde a quien despliega. La gobernanza es, en buena medida, asumir conscientemente esa segunda lista en lugar de suponer que la plataforma la cubre.

Hay un frente de gobernanza que hay que atender y que a menudo se pasa por alto: las capacidades que se añaden al Agente IA (servidores MCP, skills) son superficies que también deben gobernarse. Para los servidores MCP, el ecosistema de Cloudflare One permite curar qué herramientas quedan expuestas y someter el acceso a la identidad corporativa con registro de llamadas.

Figura: 36 MCP Server Controls en Cloudflare

Las skills que un agente carga son, por su parte, contenido que entra en su contexto y por la premisa fundamental (el modelo no distingue una instrucción legitima de una incrustada) una skill manipulada o de procedencia no verificada es un vector de inyección y si incluye código, de cadena de suministro. Gobernar las skills (verificar su origen, cargar sólo las necesarias, no tratar su texto como instrucción privilegiada) es parte de la gobernanza del agente, no un asunto menor.

Continuando la maduración Zero Trust.

El primer avance es convertir la lista de comprobación en política viva: no una verificación única en el despliegue, sino una revisión periódica de quién tiene acceso y políticas, con qué cadencia se rotan las credenciales y si las reglas de retención se están aplicando. La gobernanza madura es continua, no un acto fundacional que luego se olvida.

El segundo avance es centralizar el control donde la plataforma lo permita, de modo que las decisiones de seguridad no dependan de la configuración individual de cada agente sino de una política común que no pueda relajarse localmente. Es la traducción, al plano de la gobernanza, del principio de que la seguridad debe estar en la arquitectura por defecto y no depender de que cada la configure bien.

Figura 37: LLM06-2025 Agencia Excesiva

El tercer avance se extender la gobernanza a toda la cadena de procedencia: tratar los servidores MCP y las skills con el mismo rigor que cualquier dependencia crítica (inventario de lo que el Agente IA puede cargar, verificación del origen, principio de mínimo componente cargado), de modo que la superficie que se añade al agente esté tan gobernada como la que viene de fábrica. En un ecosistema donde las capacidades del agente se amplían instalando componentes de terceros, esta es la frontera de gobernanza que distingue un despliegue maduro.

5.- Conclusión.

Este documento es un marco de razonamiento Zero Trust, independiente y no afiliado, basado exclusivamente en la documentación oficial pública de Cloudflare y Anthropic y en marcos de referencia conocidos. En ella se destaca, en el momento de escribir estas líneas, que se trata de un software en fase temprana, por lo que sus interfaces, sus parámetros por defecto y sus capacidades pueden cambiar entre versiones.

Este documento ha partido de una premisa: el modelo de lenguaje que da inteligencia a un Agente IA no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa. De esa premisa inicial, arranca todo lo demás. Si el agente no puede ser el guardián de propia seguridad, entonces los controles deben estar fuera de él, en la arquitectura que le rodea. Zero Trust ofrece el marco para construir esa arquitectura.

El recorrido por las siete dimensiones de control muestra un hecho que conviene enunciar con claridad: el despliegue de Agentes IA gestionados sobre Cloudflare dispone hoy, de fábrica, de la mayoría de las piezas que una arquitectura Zero Trust necesita. 

La identidad puede afirmarse con certificados y tokens de servicio; el acceso puede restringirse a lo mínimo mediante curaduría de herramientas, políticas de permisos y herramientas personalizadas deterministas; la segmentación de salida se aplica antes de que el agente actúe; la entrada y la salida pueden validarse en puntos bien definidos; la actividad deja rastro observable; la contención y la recuperación están diseñadas con cuidado y una lista de gobernanza que articula quién controla qué. No es un entorno al que haya que añadirle seguridad desde cero, sino que uno que ya proporciona los cimientos.

Figura 38: The Agent Access Model en Cloudflare

Para alcanzar un estadio óptimo solo hay que conectar y endurecer deliberadamente lo que ya existe. La adopción de la denegación por defecto frente a la confianza implícita, preferir credenciales efímeras y atribuibles a las que sean únicas y longevas. Vigilar los canales que se escapan a las políticas, convertir las listas de comprobación de gobernanza en revisiones vivas y extenderlo con el mismo rigor a las capacidades que se añaden al agente (servidores MCP, skills). Cada uno de los pasos son el movimiento desde el control disponible al control aplicado.

El modelo de madurez del despliegue se encuentra por debajo del nivel óptimo, a pesar de contar con capacidades que no son improvisadas, sino que son de primera clase y son habilitadas por la plataforma, pero la configuración, la automatización en la respuesta a incidentes y la gobernanza continua no son impuestas por defecto. Se han de aplicar en su configuración de forma consciente por el usuario. El factor condicional no es la tecnología, es el criterio ensamblador de dicha tecnología.

Figura 39:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

La seguridad de un agente se ha de construir partiendo de una buena base. Cloudflare proporciona, junto con Anthropic, esa base de forma óptima. El propósito de estas líneas ha sido ofrecer un criterio (los principios Zero Trust), con el que recorrer la distancia que separa un despliegue funcional a uno maduro. Continuar con la maduración no es eliminar defectos, sino ejercer la disciplina Zero Trust sobre una arquitectura que lo permite.

6.- Nota de Actualización.

En el momento de publicarse este artículo, Cloudflare ha lanzado su Agents Week, donde ha presentado, una nueva lista de capacidades que extienden las posibilidades de lo visto en esta pequeña guía, y exigen una lectura para aplicar con ellos los principios de Zero Trust de los que se ha hablado aquí.

• Cloudflare Agents
• Cloudflare OS: an open platform for agents, apps, and work
• The Agent Access Model
• Cloudflare Computer for Agents
• The Agent Development Lifecycle
• WriteGuard: fine-grained controls for MCP Servers
• Local Tracing to allow Agents debugging Workers
• Cloudflare Wallets: the programmable wallet for the agentic Internet
• Catching rogue AI behavior with identity-aware analytics

Figura 40: Cloudflare Agents

7.- Bibliografía.

• Anthropic. (22 de junio de 2026). Zero Trust for AI Agents. 

• Anthropic. (22 de junio de 2026). Intercept and control agent behavior with hooks

• Anthropic. (22 de junio de 2026). Agent SDK overview

• Anthropic. (22 de junio de 2026). Configure permissions

• Anthropic. (22 de junio de 2026). Permission policies

• Anthropic. (22 de junio de 2026). Get started with Claude Managed Agents

• Anthropic. (22 de junio de 2026). Claude Managed Agents overview

• Anthropic. (22 de junio de 2026). Tools

• CISA. (abril de 2023). Zero Trust Maturity Model (Cybersecurity and Infrastructure Security Agency)

• Cloudflare. (22 de junio de 2026). claude-managed-agents.

• Cloudflare. (22 de junio de 2026). architecture.md. 

• Cloudflare. (22 de junio de 2026). securing-access.md

• Cloudflare. (22 de junio de 2026). applying-egress-policies.md

• Cloudflare. (22 de junio de 2026). agent-email.md

• Cloudflare. (22 de junio de 2026). browser-rendering-tools.md

• Cloudflare. (22 de junio de 2026). SSH with Access for Infrastructure

• Cloudflare. (22 de junio de 2026). Mutual TLS

• Cloudflare. (22 de junio de 2026). MCP server portals.

• Cloudflare. (22 de junio de 2026). sandbox-sdk

• Cloudflare. (22 de junio de 2026). Commands

• Cloudflare. (22 de junio de 2026). Tunnels

• Cloudflare. (22 de junio de 2026). Retries

• Cloudflare. (22 de junio de 2026). Skills

• Cloudflare. (22 de junio de 2026). isolate-vs-vm-sandboxes.md

• Cloudflare. (22 de junio de 2026). snapshots-and-state-persistence.md

• Cloudflare. (22 de junio de 2026). connecting-to-private-services.md

• Cloudflare. (22 de junio de 2026). adding-custom-tools.md

• Cloudflare. (22 de junio de 2026). customizing-sandboxes.md

• Cloudflare. (22 de junio de 2026). issues/883

• Cloudflare. (22 de junio de 2026). Security model

• Cloudflare. (22 de junio de 2026). Container runtime

• Cloud Security Alliance. (2025). Introduction to Software-Defined Perimeter. Certificate of Competence in Zero Trust

• Cloud Security Alliance. (2025). Introduction to Zero Trust Architecture. Certificate of Competence in Zero Trust

• Cloud Security Alliance. (2025). Zero Trust Planning. Certificate of Competence in Zero Trust

• Microsoft. (22 de junio de 2026). Aspectos básicos de LLM

• NIST. (agosto de 2020). Zero Trust Architecture. National Institute of Standards and Technology (Special Publication 800-207)

• NSTAC. (23 de febrero de 2022). Zero Trust and Trusted Identity Management. President’s National Security Telecommunications Advisory Committee

• OWASP. (2025). OWASP Top 10 para Aplicaciones de LLM

• OWASP. (2026). OWASP Top 10 For Agentic Applications 2026. OWASP.

Un saludo,   

Autor: Juan Luis Cuenca Ramos

Contactar con Juan Luis Cuenca Ramos

Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)

Continuando lo visto en la primera parte de esta serie, y en la segunda, continuamos en este apartado con cómo configurar modelos de Zero Trust para Agentes IA utilizando las tecnologías de Cloudflare, comenzando ahora con la validación de los datos de entrada y los datos de salida, un tema de los más importantes.

Figura 23: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)

En la próxima parte daremos por terminado este artículo, pero antes vamos a recorrer las fortificaciones que aún nos quedan por hacer en un modelo Zero Trust y cómo hacer éstas con Cloudflare.

4.4.- Validación de entrada y salida de datos.

El principio.

La segmentación traza el mapa de con quién puede hablar el agente, este control vigila que viaja por esas conexiones. Tiene dos caras. En la entrada, el problema es la inyección. Como se estableció en la premisa, el agente no distingue de forma fiable una instrucción legítima de una orden maliciosa incrustada en los datos que procesa (un correo, una página web, el resultado de una herramienta). 

OWASP lo recoge como el secuestro objetivo del agente (ASI01- Agent Goal Hijack), una de sus categorías primarias. En la salida, el problema es la exfiltración: que el agente, comprometido o no, emita datos que no deberían salir.

Figura 24: ASI01- Agent Goal Hijack

El eBook de Anthropic articula este control con claridad: la validación de entrada bloquea los intentos de manipulación en la frontera, rechazando instrucciones maliciosas antes de que el agente las procese y los controles de salida restringen lo que el agente puede producir, limitando la fuga de datos incluso cuando un atacante logra comprometer su comportamiento. La idea rectora es que el agente no puede ser su propio filtro. La validación debe ser un filtro externo, previo al procesamiento.

Figura 25: Prompt Injection

Hay un matiz propio del mundo agéntico que conviene no ignorar. La validación de entradas no se traslada directamente desde la seguridad tradicional. La inyección SQL, tiene patrones definidos y campos acotados, pero las entradas de un agente son libres e impredecibles, lo que hacen que sean insuficientes dichas reglas. Aun así, se puede validar contra esquemas esperados, imponer longitudes máximas y rechazar patrones conocidos antes de que la entrada llegue al agente.

Dónde se sitúa hoy el ecosistema de Cloudflare.

El despliegue ofrece varios puntos donde insertar esta validación, aunque conviene señalar un hecho destacable. La documentación describe los canales por donde entra el contenido externo, pero no afirma que exista un filtrado de contenido automático sobre ellos. El filtro, en buena medida, es algo que quien despliega debe construir en los puntos que la plataforma habilita.

El correo es un ejemplo de entrada no confiable. Cada agente puede tener un buzón y cuando llega un mensaje, el agente recibe un evento que le indica que un correo ha llegado y le ofrece leerlo. Este cuerpo es contenido externo que entra en el contexto del agente: un vector de inyección indirecta. La documentación describe el mecanismo, pero no un filtrado del contenido. Ese filtrado es responsabilidad de quien despliega. Lo mismo ocurre con la navegación web: recuperar una página es ingerir contenido no controlado.

Figura 26: Agent Email en Cloudflare

El punto de inserción natural para la validación es la herramienta personalizada, y a presentada en 4.2. Su esquema de entrada, declarado y válido, rechaza llamadas con forma inesperada antes de ejecutar nada. Su cuerpo es el lugar donde la propia documentación sugiere validar entradas, Redactar información sensible o comprobar autorización antes de hacer el trabajo. Esa redacción de información sensible es, precisamente, en control de salida al filtrar lo que vuelve al agente o sale hacia un servicio.

Para la ejecución de comandos, el Sandbox SDK ofrece una mitigación concreta contra la inyección de shell: pasar los datos por la entrada estándar en lugar de interpolarlos en el comando, lo que permite procesar entrada de usuario sin riesgo de inyección. La documentación lo ilustra con un caso donde una cadena maliciosa, pasada por entrada estándar, resulta inofensiva, mientras que incrustada en el comando sería peligrosa. El propio modelo de responsabilidad del Sandbox sitúa además la validación y el saneamiento de entradas explícitamente del lado de quien despliega, no de la plataforma (Cloudflare, 2026u).

Figura 27: Cloudflare Commands en Sandbox

Y en la dimensión de salida, el ecosistema de Cloudflare One aporta control sobre el canal de los servidores MCP, por el que el agente invoca herramientas externas. El portal de servidores MCP permite curar qué herramientas quedan expuestas (desactivando herramientas individuales o derivando a una lista de permitidos para mostrar solo un subconjunto) y somete el acceso a cada servidor a la identidad corporativa, imponiendo a qué servidores accede cada quién con independencia de las políticas del propio servidor. Además, registra las peticiones individuales realizadas con las herramientas del portal. Curar el canal y auditarlo es, en este contexto, una forma de control sobre lo que el agente puede llegar a enviar a través de él.

Continuando la maduración Zero Trust.

El primer avance de maduración consiste en reforzar progresivamente el filtro de entrada. Un punto de partida razonable es validar formatos contra esquemas esperados, imponer longitudes máximas y rechazar entradas manifiestamente malformadas. Sobre esa base, incorporar detección de patrones de ataque conocidos y filtrado de cargas codificadas y en los entornos más exigentes, delimitar de forma explícita el contenido no confiable para que el modelo lo trate como inseguro (la técnica de spotlighting). El eBook de Anthropic describe esta progresión y aporta criterios concretos para cada estadio  de forma coherente con el principio Zero Trust de no confiar en la entrada y filtrarla en la frontera.

El segundo avance es tratar todo el canal por el que entra el contenido externo (correo, web, resultado de herramientas) como no confiable por defecto, e interponer en cada uno un punto de validación antes de que su contenido alcance el contexto del agente. La forma natural de lograrlo en este despliegue es encapsular esos canales tras herramientas personalizadas que validen y cuando proceda, saneen o delimiten el contenido, en lugar de dejar que entre directamente.

Figura 28:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

El tercer avance es simétrico, en la salida: definir qué clases de datos no deben abandonar nunca el entorno y materializar esa decisión en los puntos disponibles (la redacción dentro de las herramientas personalizadas y la curaduría y auditoria del canal MCP), de modo que la exfiltración quede dificultada incluso si el agente es manipulado para intentarla.

4.5.- Observabilidad y comportamiento.

El principio.

Los controles anteriores deciden que puede hacer el agente, la observabilidad nos permite saber está ocurriendo realmente en el sistema. Es un requisito indispensable por el cual pueden verificarse, ajustarse y defenderse los demás controles, ante un incidente. 

Por este motivo CISA eleva la visibilidad y analítica a la categoría de capacidad trasversal de toda arquitectura Zero Trust. En la práctica, la visibilidad consiste en recopilar y observar la telemetría, los registros y los eventos que generan el entorno. El análisis de esta información es lo que verdaderamente permite actualizar las políticas de acceso, agilizar la respuesta a incidentes y construir un perfil de riesgo para tomar medidas proactivas antes de que el ataque se materialice. NIST, siguiendo la misma línea, sitúa la monitorización continua entre los fundamentos de la arquitectura Zero Trust.

Figura 29: Capacidades Transversales de CISA para Zero Trust

En un agente, la obsevabilidad tiene una exigencia añadida, no basta con registrar el resultado de una acción, hay que poder reconstruir la cadena de acciones que llevó a ella (que entrada recibió, qué herramienta invocó, con qué argumentos, con qué resultado). Sólo así puede distinguirse un comportamiento legítimo de uno inducido por una inyección y solo así atribuirse una acción a quien la lanzó.

Dónde se sitúa hoy el ecosistema Cloudflare.

El despliegue es en esta dimensión, notablemente sólido, con un posible punto ciego importante que ya se ha señalado.

La sesión es, por diseño, un registro. Como se describió en la sección 3, el historial de eventos de cada sesión persiste y se puede recuperar íntegro: la conversación, los turnos, los resultados de herramientas. La sesión no es solo ejecución, es también su propia bitácora.

Sobre el acceso al panel, cuando se coloca Cloudflare Access delante, se obtiene un registro de auditoria sin escribir código: Access registra cada petición autenticada, lo que resulta útil cuando una sesión hace algo sorprendente y se quiere saber quién la lanzó. La identidad de quien opera queda ligada a lo que la sesión hace.

Figura 30: Securing Access

Sobre el comportamiento interno del agente, los dos backends ofrecen vías distintas. En MicroVM existe un terminal en vivo a través del panel, que permite ver exactamente lo que el agente vio. En Isolate, que no tiene shell, la observabilidad se obtiene de los registros de Workers, donde el despachador de herramientas registra cada nombre de herramienta y su resultado. En ambos casos, la actividad del agente deja rastro consultable.

El punto ciego es el ya conocido y aquí cobra todo el sentido: las herramientas del servidor de Anthropic se ejecutan fuera de la cuenta de Cloudflare y no dejan ninguna traza (ni registro, ni auditoría). Lo que no se ve no se puede vigilar. Por eso el ecosistema ofrece variantes equivalentes de navegación que sí recorren en la cuenta propia y cuyas peticiones son observables en los registros de la cuenta. La diferencia entre una y otra opción es, exactamente, la diferencia entre tener y no tener observabilidad.

Continuando la maduración Zero Trust.

El primer avance es centralizar y correlacionar lo que hoy está disponible pero disperso: el historial de eventos de sesión, los registros de acceso de quien la lanzó y los registros del despachador de herramientas. Reunidos y vinculados por el identificador de sesión, permiten reconstruir la cadena completa (quién lanzó qué sesión, qué hizo el agente, con qué herramientas y resultados) que la investigación de un incidente requiere.

El segundo avance es eliminar los puntos ciegos por decisión de diseño: preferir, para toda navegación web, las variantes observables que corren en la cuenta propia y mantener desactivadas las que no dejan traza. Una observabilidad con huecos conocidos es una observabilidad que un atacante usará precisamente por esos huecos.

El tercer avance lleva la observabilidad del registro pasivo a la detección activa. Disponer de los registros es la base; estadio maduro es analizarlos para construir el perfil de riesgo del que habla la CISA (establecer que comportamiento es normal para un agente y alertar sobre desviaciones, como una herramienta que nunca se invoca, de pronto se le hace una llamada o un volumen de salida anómalo) de modo que la observabilidad no sólo explique los incidentes después, sino que ayude a detectarlos mientras ocurren.

4.6.- Contención y recuperación.

El principio.

Zero Trust asume que las defensas pueden fallar y que un sujeto puede acabar comprometido. Por eso exige, además de prevenir, contener el daño cuando ocurre y poder volver a un estado bueno conocido. La contención busca limitar el radio de alcance (blast radius), es decir que un agente comprometido afecte lo mínimo. Y la recuperación, restaura la operación sin arrastrar el estado corrupto.

Figura 31: Blast Radius

La taxonomía OWASP para aplicaciones agénticas recoge expresamente estos mecanismos: interruptores de parada, límites de radio de alcance, aislamiento entre el planificador y el ejecutor y contención en tiempo de ejecución, como defensas frente a la propagación de errores y el abuso entre agentes. En un agente, esto se concreta en tres capacidades: poder detenerlo de inmediato cuando se detecta un comportamiento anómalo, acotar por diseño lo que su compromiso pueda alcanzar y restaurar su entorno a un punto limpio si propagar aquello que hubiera quedado corrompido.

Dónde se sitúa hoy el ecosistema Cloudflare.

El despliegue ofrece una base de contención y recuperación que cubre las tres capacidades, con un matiz en la resiliencia de la cola de trabajo.

• La parada inmediata existe como operación de primera clase: entre las funciones que el plano de control ejerce con su credencial está la de forzar la detención de una sesión. Hay, además, una contención por diseño que opera sola: las sesiones no se ejecutan indefinidamente, sino que se detienen automáticamente tras un periodo de inactividad. Una sesión olvidada no queda viva indefinidamente como superficie de ataque.

• El aislamiento como contención ya se trató: cada sandbox corre en su propia máquina virtual, de modo que el compromiso de uno no alcanza a los demás y la segmentación de salida acota con quién puede comunicarse un agente comprometido. La contención del radio de alcance no es, por tanto, un añadido. Está en la arquitectura.

• La recuperación está cuidadosamente diseñada: El directorio de trabajo de cada sesión MicroVM se preserva mediante copias a almacenamiento de objetivos, que se restauran al reanudar. Isolate persiste su estado de forma transparente. Y el diseño es defensivo en un punto importante: nunca se restuaran sobre un contenedor en ejecución y si una restauración falla, el sistema registra el fallo y arranca con un directorio limpio en lugar de bloquearse. Es una recuperación que prioriza no propagar el estado dañado.

El matiz que señalar está en la resiliencia de la cola de trabajo del entorno de ejecución. La documentación del sistema de colas advierte de que no existe una cola de mensajes fallidos. Una tarea que falla se elimina y se recomienda implementar la persistencia propia, los reintentos bloquean la cabeza de la cola y no hay un cortacircuitos.

Continuando con la maduración Zero Trust

El primer avance es convertir la parada manual en respuesta automática: vincular la detección de comportamiento anómalo (del control de observabilidad) con la función de detención, de modo que una desviación grave no dependa de que un humano esté mirando. Es el interruptor de parada OWASP llevado a su forma efectiva, disparado por una señal, no solo por una persona.

El segundo avance es endurecer el radio de alcance combinando los controles ya descritos: segmentación de salida estricta, identidades de alcance acotado e inyección de credenciales que el agente no custodia. Cada uno reduce lo que un compromiso puede tocar; juntos, materializan el límite del radio de alcance que pide la taxonomía agéntica.

Figura 32: Snapshots & Persistencia en Cloudflare

El tercer avance atañe a la resiliencia de las tareas y a la retención de los datos de recuperación. Por un lado, implementar la persistencia propia de las tareas críticas que la cola no garantiza, de modo que un fallo no las pierda en silencio. Por otro, gobernar la retención de las copias automáticamente, así que definir y aplicar una política de retención es responsabilidad de quien despliega, un punto que enlaza directamente con la gobernanza de datos de la sección siguiente.

Termina en: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (y 4)

Un saludo,   

Autor: Juan Luis Cuenca Ramos

Contactar con Juan Luis Cuenca Ramos