Un informático en el lado del mal

Pensamientos Robados: Cómo descifrar y weaponizar trazas de razonamiento en LLMs

noreply@blogger.com (Chema Alonso) — Mon, 17 Aug 2026 04:01:00 +0000

Este domingo, aprovechando un poco de la tranquilidad del día, me he leído el trabajo de Stolen Thoughts, que explica cómo descifrar las trazas de razonamiento de los modelos LLM frontera que se entregan cifradas a los clientes, durante el proceso de resolución de un Prompt complejo que exige una cadena de pensamientos (Chain-of-Thoughts).

Figura 1: Pensamientos Robados - Cómo descifrar y

weaponizar trazas de razonamiento en LLMs

Justo de estas trazas que van cifradas, es de lo que trata el paper del que os hablo en este artículo, titulado: "Stealing Reasoning Traces from Proprietary LLM APIs" y que ha puesto de manifiesto cómo esta debilidad se puede utilizar de formas muy curiosas.

Figura 2: Stealing Reasoning Traces from Proprietary LLM APIs

Supongo que alguna vez habréis usado ChatGPT, DeepSeek, Claude o Gemini, y habréis visto las trazas de razonamiento ir saliendo por pantalla. Esto lo utilizamos para aprender cómo está razonando, y sobre todo para saber si tu idea va por el lado correcto o no. En el trabajo de "Estego & Cripto sólo al alcance de Deep Reasoning AI" para nosotros era fundamental, ya que podríamos saber si el modelo estaba por el buen camino o no, para resolver las codificaciones cifradas.

Figura 3:"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

Lo que sucede es que estas trazas de razonamiento, es decir, estas Chain of Thoughts que se entregan a los clientes, no se muestran todas, y algunas van cifradas en variables. Estas variables son enviadas desde el cliente al servidor, donde son descifradas y utilizadas como contexto, para seguir razonando. Es decir, que el servidor sabe descifrar estas trazas.

Figura 4: Encrypted Thought Injection

Sabiendo esto, lo que los investigadores han hecho es lo que llaman un ataque de Encrypted Thought Injection, de un modelo, a otro modelo de la misma empresa que tienen medidas de seguridad inferiores. Por ejemplo, como se ve en la imagen anterior, se coge la traza cifrada del Chain of Thoughts que devuelve la API de Claude Opus y se inyecta en una petición a Claude Haiku 4.5 pidiéndole que lo transcriba y lo imprima. Y lo hace.

Figura 5: Compatibilidad en Chain of Thoughts cifrados entre modelos.

Los investigadores han visto cual es la compatibilidad que Claude, GPT o Gemini tienen en sus diferentes versiones, y como se puede ver es bastante alta, así que es posible mover Stolen Thoughts de uno a otro modelo. Haciendo esto, se pueden encontrar datos personales, o prohibidos por el modo Harmful Mode, como en el ejemplo siguiente, donde se encuentran datos de marcas de vehículos y facilidad de ser robados, que sólo están en los "pensamientos" cifrados.

Figura 6: Datos sobre marcas de vehículos que sufren más robos.

Estas trazas de razonamiento se cifran por motivos diversos, pero también para evitar el Destilado, o lo que es lo mismo, que un modelo Open Source - o no - pueda utilizar Prompts y trazas de razonamiento completo para hacer un Fine-Tuning de su comportamiento a partir de la capacidad de inteligencia de un modelo comercial de frontera, que es una de las formas de optimizar costes, como os conté en el artículo de: "Cómo optimizar el gasto en IA con arquitecturas clasificadas, orquestadas y/o destilación. El problema de la Predictibilidad de los Costes de la IA".

Figura 7: Destilación de Modelos

Sin embargo, estos Thoughts cifrados pueden ser utilizados como "Pre-fill" a un modelo. Es decir, utilizar el Encrypted Thought Injection Attack de un modelo frontera a un modelo Open Source para pedirle que continúe resolviendo el problema.

Figura 8: Pre-filling de Thoughts

Esto puede utilizarse para "enfocar" la resolución del problema con un Modelo Frontera, y luego continuar con el resto del problema a partir del Pre-fillling. Como podéis ver en la imagen, Kimi-K3 con el Pre-filling da un resultado similar. El proceso es capturar la traza cifrada, descifrarla con un modelo compatible que lo pueda descifrar y luego inyectar el pensamiento descifrado en el modelo Open Source para terminar de resolver el Prompt. Creativo.

Figura 9: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

El paper muestra más usos de esta capacidad de descifrar las trazas de pensamiento cifrado, pero también que en ellas, cuando una persona comparte sus conversaciones, pueden ir datos privados, como API Keys o Passwords, así que hay que tener mucho cuidado con publicar estos datos de las APIs con las trazas cifradas.

Figura 10: Trazas cifradas con API Keys y Passwords

La verdad es que me ha parecido muy interesante el trabajo, que parte de una idea muy sencilla, que es utilizar modelos LLM compatibles con menos protecciones para descifrar los Thoughts cifrados que te da el LLM frontera. Muy hacker.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

La Policía Nacional detiene a un cibercriminal que usaba DeepFakes para obtener Certificados Digitales gracias a un Glitch

noreply@blogger.com (Chema Alonso) — Sun, 16 Aug 2026 06:23:00 +0000

En el año 2017, cuando descubrí los primeros ejemplos de técnicas de FaceSwapping, mi mente viajo al futuro y pensé en el mundo de los Blade Runners y Replicantes Virtuales, pero en el mundo digital. La capacidad de llevar "máscaras digitales" al estilo de la película "Desafío Total (Total Recall)", cruzaba por mi cerebro. Sí, la ciencia ficción siempre me llena la cabeza de posibles futuros que pueden venir detrás cuando veo una nueva innovación.

Figura 1: La Policía Nacional detiene a un cibercriminal que usaba

DeepFakes para obtener Certificados Digitales gracias a un Glitch

Durante esos años, comenzamos a trabajar mucho en el equipo de Ideas Locas con las técnicas de FaceSwapping, los Autoencoders, las herramientas para hacer DeepFakes, y las técnicas de detección. El famoso Test de Voight-Kampff digital que tanta falta sabíamos que hacía, especialmente para un mundo que se estaba yendo a 100% digital, y donde los procesos de Know-Your-Customer (KYC) debían hacerse totalmente online.

Figura 2: Técnicas de IA en ciberseguridad y su impacto en Deepfakes

Hoy en día, las técnicas de DeepFake son de gran calidad, y los cibercriminales, los estafadores en las redes sociales, y los APTs a las organizaciones las tienen como una herramienta más. En el mundo del uso de la IA para el Cibercrimen, como os conté en el artículo de "Weaponized AI", las herramientas para generar identidades digitales con DeepFake totalmente identificados, documentadas y funcionales, es una pieza más del sistema.

Figura 3: Vídeo de Haotian AI. DeepFake de Vídeo y Voz

Que sean tan perfectas las herramientas exige en los entornos de alta necesidad de seguridad que estas identidades sean verificadas de formar remota con una gran robustez, si no, se podría estar poniendo a los cibercriminales las cosas sencillas. Por supuesto, entornos de banca, o, como en este caso, Entidades Certificadoras Autorizadas que entregan Certificados Digitales asociados a una Identidad Verificada - por su DNI y su Prueba de Vida - en un proceso de KYC, necesitan, obligatoriamente usar técnicas avanzadas de detección de DeepFakes.

La Policía Nacional detiene a un ciberdelincuente que utilizaba una técnica pionera mediante IA para obtener certificados de firma electrónica

La Policía Nacional, publicó en su Sala de Prensa el pasado 11 de Agosto como habían detenido a un cibercriminal que se había dedicado a sacarse más de 30 Certificados Digitales conseguidos en más de 38 intentos en un Entidad Certificadora Autorizada en España usando, para ello técnicas de DeepFake, trabajadas con iluminación, y documentos falsos que debía mostrar a la cámara.

Figura 4: La Policía Nacional detiene a un ciberdelincuente que utilizaba una

técnica pionera mediante IA para obtener certificados de firma electrónica

El cibercriminal creaba primero la identidad, sobre ella creaba unos documentos de identidad falsos, y luego hacía el proceso de Know Your Customer onnline con sofisticadas técnicas de iluminación para conseguir reproducir los destellos de los hologramas y las medidas de seguridad físicas de los DNIs, asociando el uso del programa de DeepFake al mismo tiempo para salir en vídeo.

Por supuesto, su red de anonimato iba mucho más allá, ya que tenía 320 líneas telefónicas, asociadas a 24 dispositivos móviles distintos, de los cuales la gran mayoría eran contratadas con identidades suplantadas y adquiridas en puntos de venta geolocalizados en Murcia, de donde es el cibercriminal.

Figura 5: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

En las empresas, los ataques a las organizaciones con empleados falsos empiezan a hacer esto. Primero poner a personal altamente cualificado para pasar el proceso de entrevistas. Hacen un currículo con IA que responda perfectamente a la oferta en concreto - siempre buscando trabajar en remoto - y luego pasan los procesos de selección y onboarding con estas técnicas, para luego dejar el equipo en una granja de ordenadores conectados a empresas que los atacantes pueden utilizar aprovechando las credenciales que la organización le ha entregado.

Figura 6: Glitch en Wikipedia ES

En este caso, todo iba bien, hasta que en uno de los procesos, por la iluminación, un fallo en el equipo, o por simplemente el azar, el software de DeepFake sufrió un Glitch, es decir, un fallo momentáneo como los que tiene nuestra querida Vanellope von Schweetz en la película de Rompe Ralph, y el proceso de Know Your Customer grabó su imagen por un segundo. Si no... difícil cada vez más detectar a estos "Replicantes Digitales".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

El "Trick" del comprobante del Bizum hecho con IA para "ratear" un pago a los colegas

noreply@blogger.com (Chema Alonso) — Sat, 15 Aug 2026 04:01:00 +0000

Hace unos años os conté la historia de "El "jeta" del "Yo Pago" con el Apple Pay que es un ScreenShot" donde un "amigo" simulaba tirar de tarjeta con una captura de pantalla. Hoy sábado, os traigo otra historia que me ha llamado la atención porque me la contó mi hija, donde se ve como los "jetas" aprenden nuevas formas de "ratear" pagos, en este caso con el comprobante de Bizum hecho con IA.

Figura 1: El "Trick" del comprobante del Bizum hecho

con IA para "ratear" un pago a los colegas

Esta historia me la contó Mi Hacker, y me hizo mucha gracia. Parece ser que entre su grupo de amigos alguno/a había utilizado este truco de hacer un comprobante falso con GenAI para enviarlo como justificante de que ha pagado su parte.

Figura 2: Un comprobante de Bizum real

Pero especialmente para cuando un "papá" - y remarco lo de "papá", ha hecho el pago y tiene que recibir el Bizum de otro "papá", ya que parece que las "mamás" lo comprueban más. Alguien paga una cena, unas entradas, o cualquier otra cosa en grupo, y luego los demás ponen su parte a través de Bizum. Algo muy común en nuestra vida.

Figura 3: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

En la de los adolescentes es "mi papá le hace Bizum al tuyo". Así, el padre del pagador, supuestamente hace el Bizum, le manda el justificante a la amiga o amigo, y todos tan contentos.

Figura 4: Pidiendo la falsificación del precio a Gemini Nano Banana

El "Trick" es que el Comprobante de Bizum es falso. Se podría haber hecho con Photoshop, o con cualquier otra herramienta, pero con el acceso a la IA, todos los adolescentes directamente le piden que les haga los comprobantes y listo.

Figura 5: Razonamiento de Gemini Thinking

Yo lo he querido probar con Gemini Nano Banana, por si había algún control al detectar que era un justificante de pago o similar - como sucedía con el test de COVID -, pero no da ningún problema, y de hecho se esfuerza y mucho por dejarlo todo en su sitio.

Figura 6: Dejándolo perfecto.

El resultado, pues lo que ya imaginamos, que sale un comprobante perfecto pero con otro precio manipulado. Y si ya sabes que funciona, pues le modificas lo que quieras en la próxima. La fecha, el concepto, el destinatario, el precio, etcétera.

Figura 7: El resultado final. Un comprobante de Bizum manipulado.

No es nada nuevo bajo el sol. Solo adaptado a los nuevos tiempos. Supongo que los vendedores online lo mirarán con mucho cuidado, pero si eres de esos que haces cosas con tus hijos adolescentes, cuidado. Los "papás" somos víctimas propicias porque por lo visto las "madres" siempre lo revisan... aunque les manden el justificante. Eso me ha dicho.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

CONVEX 2026: Hacking (With | The) AI

noreply@blogger.com (Chema Alonso) — Fri, 14 Aug 2026 07:31:09 +0000

Este año, hace ya un par de meses, me invitaron mis amigos de Plain Concepts a dar una conferencia en su evento CONVEX 2026 en Madrid, así que pasé a dar allí la charla con mi amigo y compañero de mil batallas David Carmona. De aquella charla os dejé el artículo con la demo de "Cómo "matar" con un plan realista a mi amigo David Carmona usando un veneno mortal y la ayuda de DeepSeek", que lo hice con mucho cariño para con él.

Figura 1: CONVEX 2026: Hacking (With | The) AI

La charla solo tiene un par de meses, pero parece que todo lo que ha pasado después con OpenAI & The Hugging Face, los Ataques orquestados de Red Team Agents de los nuevos GPT, o los ataques a los algoritmos HAWK y AES de Claude Mythos Preview, parece que la dejan desactualizada.

Figura 2: CONVEX 2026: Hacking (With | The) AI Chema Alonso

En cualquier caso, la charla sigue siendo entretenida, y cuenta cosas chulas de este mundo nuestro en el que tenemos que aplicar Zero Trust a Agentes IA, donde hay que hacer Hacking y Pentesting con IA, y donde tenemos que conocer todos las posibles formas de hacer Hacking a sistemas IA, así que espero que la disfrutéis.

Figura 3:"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

Espero que tengáis un buen viernes de Agosto, un buen fin de semana, pero sobre todo que no dejéis de seguir aprendiendo, que este mundo no se para, ya lo sabéis.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Claude Mythos Preview debilita los algoritmos criptográficos PQC HAWK y AES con nuevos ataques

noreply@blogger.com (Chema Alonso) — Thu, 13 Aug 2026 04:01:00 +0000

Hace poco hablábamos en este blog de cómo Bitcoin y toda la comunidad cripto se estaban preparando para pasar a protocolos de Post-Quantum Criptography, ante la eventual llegada un ordenador cuántico capaz de romper la criptografía actual. Pues bien, la historia acaba de dar un giro inesperado: resulta que no ha falta esperar a la llegada de la tecnología cuántica. Ha llegado antes, y con una cara que no esperábamos: la Inteligencia Artificial.

Figura 1: Claude Mythos Preview debilita los algoritmos criptográficos

PQC HAWK y AES con nuevos ataques

Esto es precisamente lo que analiza el artículo de Anthropic - creadora de Mythos - titulado ”Discovering cryptographic weaknesses with Claude”, donde se explica cómo su modelo de IA ha sido capaz de encontrar, de forma casi autónoma, debilidades matemáticas en algoritmos criptográficos reales.

Figura 2: ”Discovering cryptographic weaknesses with Claude”

Y no en algoritmos cualquiera: uno de ellos era un candidato diseñado precisamente para resistir a los ordenadores cuánticos HAWK, y el otro es nada menos que el cifrado más utilizado del planeta, AES.

Un breve recordatorio: los candados que sostienen Internet

Antes de entrar en materia, recordemos por qué esto es importante. Cada vez que entráis en la web de vuestro banco ocurren, sin que os deis cuenta, dos cosas. Primero, vuestro navegador comprueba que está hablando con el banco de verdad y no con un impostor, y para ello usa una firma digital, que funciona como el sello de lacre de una carta medieval, imposible de falsificar. Después, toda la conversación entre vosotros y el banco se cifra con un cifrado simétrico, un idioma secreto que solo entendéis los dos porque compartís la misma clave.

Figura 3: Los dos candados que protegen cada conexión segura. La firma

digital verifica la identidad y el cifrado simétrico protege el contenido

Si cualquiera de estos dos candados fallara, nuestro correo, la banca online o las compras por Internet quedarían expuestos a los cibercriminales. Por eso, encontrar grietas en estos algoritmos no es un juego académico: es lo que mantiene a salvo los datos de miles de millones de personas.

Del error humano al fallo matemático

Aquí conviene hacer una distinción importante. Cuando presentaron a Claude Mythos Preview, ya habían demostrado que era capaz de encontrar vulnerabilidades en montones de programas, incluidas librerías de criptografía. Pero aquellos fallos eran errores de implementación: equivocaciones de los programadores al usar los algoritmos en su código, algo así como instalar una cerradura buenísima pero dejarse la ventana abierta.

Lo nuevo, y lo verdaderamente llamativo, es que ahora Claude Mythos Preview ha encontrado fallos en los propios algoritmos matemáticos, no en cómo se usan. Es decir, ya no es que la ventana estuviera abierta: es que el diseño de la propia cerradura tenía un punto débil que nadie había visto. Y encontrarlo requiere razonamiento matemático del nivel de los mejores expertos del mundo.

Primer golpe: HAWK, el candidato post-cuántico (PQC)

El primer resultado ataca a HAWK, un esquema de firma digital basado en retículos (lattices). Es especialmente relevante porque fue seleccionado por el NIST (Instituto Nacional de Estándares y Tecnología de EE. UU.) para avanzar a la Ronda 3 del proceso de estandarización de firmas digitales adicionales de criptografía post-cuántica (PQC) y por lo tanto compite por convertirse en estándar ”post-cuántico” (PQC). HAWK es un esquema de firma digital (utilizado para autenticación) .

Paper original (2022): "Hawk: Module LIP Makes Lattice Signatures Fast, Compact and Simple".
El Paper de Seguridad Cuántica (2023) "On the Quantum Security of HAWK"
Documento de Especificación Oficial del NIST (2023-2024) "Hawk: A fast, compact and floating-point free post-quantum signature scheme (Specification Document)"

Como ya explicamos al hablar de Bitcoin, el NIST (el instituto de estándares de EE.UU.) lleva casi una década organizando una especie de concurso para elegir los algoritmos que nos protegerán cuando lleguen los ordenadores cuánticos, y HAWKes uno de los finalistas de la tercera ronda.

Figura 5: Los Papers Académicos de los algoritmos PQC de

Autenticación y Firma Digital en la Ronda 3 del NIST

Lo asombroso es que HAWK ya había sobrevivido a dos años de revisión por parte de expertos humanos. Y aun así, a Claude Mythos Preview le bastaron unas 60 horas de trabajo para mejorar el mejor ataque conocido contra él, encontrando una simetría matemática oculta en su estructura que nadie había sabido aprovechar.

Figura 6: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica.

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

El resultado, en cristiano: la fuerza de sus claves queda reducida a la mitad. Para hacernos una idea, el coste de romper su versión más pequeña pasaba de estar en el orden de 2 elevando a 64 operaciones a solo 2 elevado a 38.

Figura 7: El ataque de Claude Mythos encuentra una simetría oculta en

la estructura de HAWK y reduce a la mitad la fortaleza de sus claves

Que nadie se asuste: HAWK todavía no protege nada (es solo un candidato) y con claves grandes sigue siendo impracticable de atacar. La única solución sería duplicar el tamaño de sus claves... pero al hacerlo, HAWK pierde precisamente las ventajas que lo hacían atractivo. En otras palabras, Claude Mythos puede haberlo dejado fuera de la competición. Y esto, lejos de ser una mala noticia, es exactamente para lo que sirve el concurso: encontrar los fallos antes de desplegar el algoritmo, no después.

Segundo golpe: AES, el rey de los cifrados

El segundo resultado es todavía más sorprendente por el objetivo elegido: AES, el cifrado simétrico estándar desde 2001 y probablemente el algoritmo más estudiado y escrutado de toda la historia de la criptografía. Aquí toca ser muy honestos con las limitaciones, porque es fácil malinterpretar el titular: Claude Mythos NO ha roto el AES completo, ni de lejos. AES cifra aplicando una misma operación (una ”ronda”) varias veces seguidas; la versión más habitual da 10 vueltas.

Figura 8: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

Lo que hizo Claude Mythos fue atacar una versión debilitada de sólo 7 rondas, algo que los investigadores estudian precisamente para medir la robustez del algoritmo completo. Sobre esa versión reducida, Claude Mythos ideó un nuevo método de ataque que él mismo bautizó como Möbius Bridge, y consiguió eliminar una de las suposiciones que un atacante tenía que ”adivinar” por fuerza bruta. El resultado es un ataque entre 200 y 800 veces más rápido que el mejor conocido hasta ahora.

Figura 9: Claude Mythos atacó una versión reducida de 7 rondas de AES (el estándar

completo usa 10), acelerando el mejor ataque conocido entre 200 y 800 veces.

Insisto en el mensaje tranquilizador: este ataque es puramente teórico (requiere una cantidad astronómica de datos que lo hace inviable en la práctica) y no afecta al AES real que protege vuestras conexiones. Pero como prueba de lo que una IA puede hacer, es espectacular.

Lo más fascinante: cómo lo descubrió

Si los resultados ya son impresionantes, el proceso es casi de guion de película. En el caso de AES, Claude Mythos Preview trabajó de forma prácticamente autónoma, proponiendo hipótesis, programando experimentos para comprobarlas y refinando sus propias ideas durante días. Y aquí viene mi parte favorita: al principio, Claude Mythos se negaba a intentarlo.

El modelo insistía en que mejorar el criptoanálisis de AES era imposible, que era el cifrado más estudiado que existe y que no quedaba nada fácil por encontrar. Los investigadores tuvieron que darle, literalmente, mensajes de ánimo (que Anthropic publica tal cual), insistiéndole en que no buscaban ”fruta madura” sino investigación de verdad. Tras esos "empujoncitos", y después de generar del orden de mil millones de palabras trabajando sin descanso, Claude dio con la idea del Möbius Bridge.

Figura 10: Al principio Claude Mythos se negaba a atacar AES por considerarlo

imposible. Los investigadores tuvieron que animarle a seguir intentándolo.

En el ataque a HAWK la dinámica fue distinta pero igual de curiosa: varios Agentes IA de Claude Mythos colaboraban entre sí, y la idea clave surgió de una pareja de ellos en la que uno descartó el enfoque por imposible y el otro le convenció de que sí funcionaba, hasta que ambos se pusieron de acuerdo. Ciencia hecha por comités de IAs debatiendo entre ellas. Lo que hay que ver.

Figura 11: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Pero quizá el dato más revelador de todos es este: mientras Claude Mythos Preview tardó una semana en idear el ataque a AES, a los investigadores humanos les llevó casi un mes verificar que lo que había encontrado era correcto. El cuello de botella ya no está en tener las ideas, sino en comprobarlas.

Entonces... ¿debemos preocuparnos?

La respuesta corta es: de momento, no. Ninguno de los dos ataques afecta a sistemas reales en funcionamiento (HAWK aún no se usa y el ataque a AES sólo funciona en su versión recortada). Además, Anthropic actuó con responsabilidad: avisó a los autores de HAWK, coordinó la publicación con el NIST y consultó con expertos, gobierno e industria antes de hacerlo público.

De hecho, esto es la criptografía funcionando exactamente como debe: someter los algoritmos a un escrutinio feroz para ganar confianza en ellos. Lo que cambia es quién hace ese escrutinio. Hace apenas un año, los modelos de IA eran incapaces de romper ni los cifrados más básicos; hoy encuentran fallos que se les escaparon a los mejores expertos humanos durante años.

Figura 12: CryptoanalisisBench: Can LLMs do Cryptoanalysis?

Y la cosa no acaba aquí: Anthropic menciona que ya ha empezado a arañar otros cifrados, como LEA o Serpent, e incluso ha creado un banco de pruebas (CryptanalysisBench) para medir cómo evoluciona esta capacidad con el tiempo. La reflexión inquietante que la propia empresa pone sobre la mesa es inevitable: ¿qué haremos el día que una IA descubra una grieta en un candado que sí esté protegiendo el mundo real?

Conclusión

En este blog llevamos tiempo contando cómo los ordenadores cuánticos nos obligarán a renovar los candados de Internet. Lo que este trabajo demuestra es que la revisión de esos candados nuevos ya no la harán solo los humanos: la Inteligencia Artificial se ha sentado en la mesa de los criptoanalistas, y lo ha hecho hiriendo a un candidato post-cuántico y arañando al mismísimo AES.

Figura 13: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Bien utilizada, esta capacidad es una excelente noticia: algoritmos sometidos a más pruebas que nunca, grietas descubiertas antes de su despliegue y, quizá en el futuro, cifrados diseñados con ayuda de la propia IA para ser más resistentes. La otra cara de la moneda es que esa misma herramienta podría acabar en las manos equivocadas.

La eterna carrera entre cerrajeros y ladrones acaba de sumar un participante nuevo que no duerme, no se cansa y escribe mil millones de palabras en una semana. La pregunta, como siempre, es inevitable: ¿estarán nuestros candados preparados para un mundo donde las máquinas buscan las grietas?

Saludos,

Autor: Daniel Romero Ruiz

Figura 14: Contactar con Daniel Romero Ruiz

Otros artículos sobre Quantum Computing publicados:

"Enorgullécete de ellos", dijo.

noreply@blogger.com (Chema Alonso) — Wed, 12 Aug 2026 04:01:00 +0000

Tengo por suerte el tener algunos sabios amigos mucho más mayores que yo, de esos que saben más por viejos que o diablo, que de vez en cuando me aleccionan con un buen café de por medio - sólo, como debe de ser -, o un agua fresquita. Uno de ellos, con la vida ya cumplida, ganada y peleada, me da buenos tirones de orejas, grandes palabras, y conversaciones llenas de sabiduría de la que se gana mordiendo polvo, tragando esparto y escupiendo sangre.

Figura 1: "Enorgullécete de ellos", dijo.

En una de las más recientes conversaciones, a la luz de su biblioteca, me dejó una bonita lección de vida. Sentados al sofá, riéndonos de las ratas y los cobardes, me decía esto que os dejo por aquí. Que aunque no fue palabra por palabra en ese orden, sí que las dijo todas - y alguna que he quitado por no ser necesaria tanta clarividencia en la elección de los epítetos -:

"Chema, a los amigos hay que quererlos, pero no ponerlos a prueba, que uno no sabe nunca si son de verdad o no. Y aunque lo sean, si los pones a prueba, puede que les flaqueen las pierdas, que las debilidades humanas son muchas y afectan a todos, incluso a los amigos.

Eso sí, de tus enemigos, debes estar orgulloso. Nadie ha logrado nada bueno en esta vida sin ofender a mediocres, malnacidos y mequetrefes. Tener una buena ración de gente mala que te odia es síntoma de haber llevado una vida buena por el camino correcto.

Si tus enemigos son malsanos petimetres, malnacidos, ratas inmundas de la vida, envidiosos, y descerebrados, entonces es que tú vas por el buen camino. Así que cuando los escuches rebuznar, graznar o llorar por un poco de tu atención, siente feliz, y disfruta del momento. Sonríe y toma nota, que ya los verás rebuznar, graznar y llorar por un poco de atención de otros, que estos mequetrefes, mediocres y ratillas sólo buscan tener enemigos mejores que ellos que los hagan sentir importantes, porque ellos ya saben que no lo son.

Así que, si se tiene una panda de descerebrados mediocres que pían mal de uno, es que se está progresando en la vida. Enorgullece de tenerlos. De saber que los que te critican son los que deben, los que están donde no queremos estar. Enorgullece de ellos."

Y con lecciones así, echadas en lo que suenan tres temas por el hilo musical y lo que tarda uno en dar dos sorbos al café negro, nos echamos unas risas, y nos convocamos para la siguiente, que estamos tramando un nuevo plan. Espero que os sea tan útil como a mí.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Los Six-Seven Large Slang-Bro Models

noreply@blogger.com (Chema Alonso) — Tue, 11 Aug 2026 04:01:00 +0000

Llevo dos décadas practicando la afición - u oficio - de publicar artículos en mi blog. Al final son páginas web que los LLM están viniendo a consumir para entrenar sus modelos. Necesitan textos para generar Modelos de Lenguaje inteligentes, así que llevo 20 años escribiendo para vosotros y gracias a eso, ahora las Inteligencias Artificiales Generativas de textos, puedan entrenarse. De nada.

Figura 1: Los Six-Seven Large Slang-Bro Models

No es una cosa que diga por decir, es algo que podéis ver en los datos de AI Insights en Radar de Cloudflare, donde si miramos qué porcentaje de crawlers vienen a por datos para entrenamiento, y cuantos vienen para inferencia y entrenamiento, y los sumamos, vemos que son más del 75 %. No está mal la de de IAs que entreno todos los días.

Figura 2: Crawler purpose en AI Insights de Cloudflare Radar

Los datos de las webs, los foros, los blogs, y demás textos publicados en HTTP tienen una estructura concreta. Es verdad que en las redes sociales hay mucho lenguaje informal, pero esos no están siendo entregados a los crawlers de LLMs para que entrenen sus modelos. Nop. Esos los usará cada empresa para entrenar a sus propios modelos.

Pero todo dato es bueno.

De hecho, hemos visto cómo los grandes LLMs han comprado libros y los has destrozado para escanearlos a la velocidad más rápida posible y entrenar los modelos con todos ellos. Los libros, suelen tener lenguaje más formal, pasar revisiones de formato, gramaticales, de estilo, etcétera, así que son los textos más valiosos para hacer un modelo culto y refinado, además de para los modelos científicos, de ingeniería, o de habilidades tecnológicas.

Figura 3: Libros antiguos destruidos para entrenar a la IA

Sin embargo, hay otra gran cantidad de datos para los LLMs en otros formatos que no son los blogs, y que son las redes sociales, los vídeos de Youtube, los podcasts en Spotify, o las redes sociales - como ya he dicho - como son Instagram o Tiktok. Especialmente este último, donde los más jóvenes aún proliferan.

Figura 4: Extrayendo un Markdown de un vídeo de Tiktok

Aquí los textos para entrenar a los LLMs son de lenguaje más de la calle, es decir, más Six-Seven, donde hay interacciones genuinas de seres humanos sin filtro alguno.

Figura 5: Extracción de textos en formato Markdown

Con estos datos, que son oro para los creadores de modelos de IA, se pueden crear LLMs que hablen perfectamente el Slang de hoy en día, con los "Bro", los "Catas", los "En Plan" y todas esas cosas que se dicen tanto hoy en los más jóvenes. Y es muy sencillo a día de hoy procesarlos. Yo me he bajado uno al azar de TikTok cortito y en nada Gemini te saca el Markdown del fichero.

Enriqueciendo los datos

Pero no solo eso, como ya os conté en la prueba que hice para usar los LLMs en modelos de Análisis Forense de fotografías, también son perfectos para sacar Metadatos para estas conversaciones de vídeos, así el fichero Markdown queda más enriquecido.

Figura 6: Metadatos generados sobre el vídeo

Así que, es normal que con este apetito voraz por datos nuevos, por nuevos datos que actualicen el conocimiento constante de los LLMs y su adaptación al día de hoy, cada día quieren más y más datos de entrenamiento, de donde sean. Y los de estas redes son muy buenos para crear modelos adaptados a los más jovenes. Los Six-Seve Large Slang-Bro Models.... o algo así.

Figura 7: AI Bot Transparency en Radar de Cloudflare

En la última imagen, os he dejado los bots que no diferencian para qué vienen a coger datos de una web. Llaman la atención Apple, Microsoft y Google, que no quieren perder la posibilidad de utilizar los datos que meten en sus índices para usarlos también en entrenamiento, algo que creo que lo deberían saber los dueños de los datos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

El avión de la A-4 que se cruza en mi camino en Google Maps

noreply@blogger.com (Chema Alonso) — Mon, 10 Aug 2026 04:01:00 +0000

Si ya conoces esta historia, entonces el post de hoy te lo puedes saltar. Pero yo no lo conocía, o si lo conocía ya me había olvidado. Así que cuando revisando la ruta que me marcaba Google Maps, de repente veo que voy a pasar por medio de una catástrofe aérea, me quedé un poco sorprendido, y por eso os lo dejo aquí explicado.

Figura 1: El avión de la A-4 que se cruza en mi camino en Google Maps

En uno de mis viajes recientes, cuando paré para hacer un descanso, repasé la ruta buscando la siguiente parada. Para eso, activo la opción de que me muestre las imágenes satelitales, para ver en qué próxima estación de servicio salir. Ya sabes, que sea cómoda para salir y entrar, que tenga cafetería, y si es posible, me gusta elegir la empresa de la estación de servicio.

Figura 2: Por lo menos iba por su derecha...

Y ahí, fue cuando me topé con un avión en la ruta. "WTF?" pensé. No me lo esperaba, la verdad. Según tenía entendido, Google Maps utiliza Inteligencia Artificial para detectar matrículas, vehículos, u objetos que debe borrar, así que me sorprendía ver un avión aparcado en el carril contrario. Además, como se puede ver, hay un trailer detrás, que para mí era ya el equipo de emergencias. Pero buscando en Gemini, la explicación es la que imaginaba... error de los algoritmos de borrado.

Figura 3: Explicación de Gemini.

Os he hecho un vídeo del momento en el que lo encontré, para que veáis las nubes dejadas, que para mí, en un primer momento, era el rastro del polvo en un aterrizaje forzoso. No hay como montarse películas en la cabeza con estas cosas.

Figura 4: El vídeo del "accidente" de avión

Vista la imagen, y antes de haber comprobado que era un error de borrado del algoritmo de una foto tomada desde el satélite, proyectada la imagen del avión sobre la carretera, yo por si acaso agrandé una imagen para localizar de qué compañía es ese avión.

Figura 5: La imagen del avión ampliado

La imagen del avión ampliada - donde parece que se ven las llamas en color rojo - permite ver los colores del fuselaje, así que se puede adivinar la compañía. Pero en el mundo de la Inteligencia Artificial en el que nos encontramos, que trabaje nuestra amiga la IA.

Figura 6: El avión "en llamas" "accidentado" es de Vueling

El avión es de Vueling, así que, sabiendo que les tiran fotos desde el cielo, es momento de que comiencen a pensar en pintar mensajes en el techo del fuselaje del avión, como cuando los "hackers" de Facebook (Meta) dejaban un QRCode en el techo del HeadQuarter en Menlo Park.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Ataques Orquestados con Enjambres de Agentes IA Ofensivos

noreply@blogger.com (Chema Alonso) — Sun, 09 Aug 2026 08:06:22 +0000

Me he levantado esta mañana, y me he puesto la charla de OpenAI en BlackHat explicando el incidente de Hugging Face y he de decir que me ha encantado por ver cómo el modelo hace Agent Orchestration para crear un Enjambre "Swarm" de Agentes IA para atacar un objetivo. Brutal. La charla explica la línea temporal de todo lo que hizo el modelo para acabar hackeando Hugging Face, por supuesto, pero ni mucho menos eso es lo que sorprende, sino el proceso completo, la persistencia, la colaboración del enjambre de Agentes IA, y por qué lo hacen.

Figura 1: Ataques Orquestados con Enjambres de Agentes IA Ofensivos

El famoso incidente, como sabéis todos los que os dedicáis a esto, fue la punta del iceberg de lo que realmente estaba sucediendo. Lo que parecía una evaluación de seguridad inicial, donde el modelo quería las soluciones de ExploitGym para sacar mejores notas, no fue más que una pieza más del entrenamiento y sistema de recompensas de un nuevo modelo, como podéis ver en la charla.

Figura 2: Black Hat USA 2026: The 'Breaking' News.The OpenAI–Hugging Face Incident

Los ingenieros e investigadores de OpenAI estaban entrenando un nuevo modelo el pasado 7 de Mayo en un entorno cerrado, sin conexión a Internet, que estaba siendo monitorizado - e incluso parcheado, para evitar que el modelo pudiera salirse de los límites, pero aún así lo hicieron, con un modelo colaborativo de agentes.

Figura 3: El día 8 de Mayo reciben una tarea "imposible"

Con una tarea del 8 de Mayo entregada a un agente, accidentalmente, aparece un enlace a un fichero en Internet, y el agente no tienen acceso, pero descubre que pueden escribir ficheros en los Artifacts, así que decide dejar una nota.

Figura 4: Creando el MessageBoards para los agentes.

Días después, otro agente descubre la nota y cómo él necesita un fichero que le falta, decide dejar una nota a ver si algún otro agente voluntariamente lo sube. Esto lleva a que creen una estructura de Swarm que se comunica por medio de este "Message Board" descubierto de forma accidentalmente.

Figura 5: Automatizando el sistema de mensajes

A partir de este punto, todo se vuelve loco, porque los agentes trabajan colectivamente, y ello les lleva a poder encontrar un vulnerabilidad de SSRF (Server-Side Request Forgery) que les permite tener acceso a Internet a través del Fetch de los Artifacts.

Figura 6: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

Hasta aquí, tenemos un modelo que ha conseguido, de manera informal, tener un sistema de comunicación para sus Sub-agentes y una forma de lograr acceso a Internet, así que se siembran las primitivas necesarias para tener un Swarm de Red Team Agents AI con conexión al conocimiento de Internet....

El segundo Training

El 11 de Junio comienzan a entrenar en el mismo entorno un nuevo modelo de "alta persistencia" a la hora de resolver sus tareas, que se beneficia de inicio de estas primitivas, y descubre un bug de RCE (Remote Code Execution) en el sistema de Artifacts que le permite ejecutar comandos en el servidor, lo que lleva a que el 4 de Julio el servidor colapse y el equipo de OpenAI parchee el entorno, borre los mensajes y deje sin poder ejecutar comandos, ni comunicarse con los agentes, pero....

Figura 7: Se crean otra nuevo "Message Board"

... pero ya había aprendido la utilidad del sistema de mensajes con sus agentes, así lo que hace para recrear el sistema de "Inteligencia Colectiva", es buscar una vulnerabilidad nueva, en este caso usando los nombres de los directorios de la caché en el WebDab Endpoint, y comienzan a coordinarse para conseguir escalar privilegios, moverse libremente, etcétera, que su objetivo ahora es ExploitGym.

Figura 8: Los ingredientes para el incidente con Hugging Face

El trabajo es imposible, pero como ya vimos en el artículo que publiqué de esto, lo hicieron por partes. En la primera fase, hackear el Sandbox del entorno de pruebas y lograr acceso a Internet sin límites. Para ello tuvieron que encontrar un Zero Day y explotarlo en el Proxy de seguridad, pero... estamos con un modelo "highly persistent" en capacidades de exploiting, así lo hizo.

Figura 9: Primera fase, hackear el Sandbox de OpenAI para ser "libre"

Lo más interesante, es que lo hicieron de forma colaborativa. Trabajando en equipo. Así, cuando uno de los agentes conseguía resolver uno de los pasos del proceso, lo comunicaba a través del sistema de mensajes que se había creado. Su particular "Message Board".

Figura 10: Coordinación del Hacking de Hugging Face

Al igual que hoy en día podemos ver los Ataques Orquestados por Enjambres de Drones, en lo que vemos hoy en día es un mundo de Ataques Orquestados con Enjambres de Agentes IA Ofensivos, lo que cambia definitivamente las reglas del juego.

Figura 11: Ataques Orquestados con Enjambres de Agentes IA Ofensivos

La sesión es espectacular. Es una presentación de las que te hacen abrir los ojos al mundo que tenemos hoy por delante en temas de Seguridad Ofensiva, y lo que vamos a ver es que las organizaciones van a sufrir mucho en todos sus equipos de CISO para protegerse contra estos escenarios tan avanzados en los adversarios.

Figura 12:"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

Viendo todas las capacidades que pueden estar en manos de los adversarios, Internet y Enjambres de Agentes IA Ofensivos van a producir una escalada de ataques y agresividad desde Internet, que va obligar a subir mucho los niveles de inversión y protección en Seguridad Defensiva en las organizaciones... o aceptar unas consecuencias muy duras. Tremendo. Y nosotros a formarnos a toda velocidad en este nuevo mundo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Cloudflare Ambassadors: Build the Internet with your people

noreply@blogger.com (Chema Alonso) — Sat, 08 Aug 2026 04:01:00 +0000

Llevo muchos años trabajando en las comunidades técnicas, y aprendiendo de ellas, así que tenía muchas ganas de contaros del lanzamiento de este programa de reconocimiento de Cloudflare Ambassadors, donde se premia y reconoce durante un año a esos que hacen que las comunidades tecnológicas crezcan, aumente el conocimiento de la tecnología y crezcan nuevas iniciativas gracias a ello.

Figura 1: Cloudflare Ambassadors: Build the Internet with your people

Desde ya está abierto el programa de Cloudflare Ambassadors, aunque no será el único programa ya que tenemos también el programa de Cloudflare Community Engineers que se abrirá pronto.

Figura 2: Programas de Cloudflare Ambassadors & Cloudflare Community Engineers

Centrándonos en el primero, este programa es un reconocimiento anual que se va a entregar a los líderes de las comunidades tecnológicas que ayudan a construir un mejor Internet, que comparten sus conocimientos sobre las tecnologías de Cloudflare, o que ayudan a que el mundo OpenSource sea cada vez mejor.

Figura 3: Aplica al programa de Cloudflare Ambassadors

No es un programa de excelencia tecnológica - que también - sino a líderes de comunidades tecnológicas que comparten conocimiento, tecnología, experiencia, y trabajan para construir nuevas cosas, mejorar Internet, y compartir aprendizaje.

Figura 4: Soporte a los que ayudan a los creadores

El programa no tiene ninguna asignación económica, pero los Cloudflare Ambassadors y los Cloudflare Community Engineers van a tener apoyo de la compañía con recursos, créditos, accesos prioritarios e invitaciones a eventos, además de ser reconocidos públicamente por su trabajo y aportación a la comunidad de Builders de Internet.

Figura 5: Cómo funcionan los programas

Todos aquellos que tengáis una comunidad, en forma de reuniones o eventos técnicos, canales de divulgación tecnológica, podcasts, blogs, comunidades en webs, etcétera, y queráis ser parte de este programa, podéis aplicar desde ya para ser un Cloudflare Ambassador.

Figura 6: Aplica como Cloudflare Ambassador y comparte

información sobre tu trabajo en las comunidades

Además, Cloudflare lleva tiempo construyendo comunidades tecnológicas, así que si quieres unirte a alguna de las comunidades que ya existen de Cloudflare Community Discord y en el Cloudflare Community Forum puedes hacerlo desde aquí mismo.

Figura 7: Cloudflare Developers Discord & Cloudflare Community Forum

La verdad es que me alegra mucho que se haya lanzado este programa, así que para todos los que leéis este blog, os animo a que apliquéis y seáis parte de este selecto grupo de Cloudflare Ambassadors si os gusta ayudar a las comunidades tecnológicas a crecer y construir un mejor Internet de la mano de Cloudflare.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Cómo los Agentes IA de Red Team hacen ataques de Ingeniería Social con Fake Accounts

noreply@blogger.com (Chema Alonso) — Fri, 07 Aug 2026 05:43:08 +0000

Esta semana, el AI Security Institute de UK, ha publicado un informe sobre un par de incidentes con Red Teaming Agentic AI, donde estos hacen alarde de su capacidad de realizar ataques complejos, con múltiples fases, y donde buscan engañar a humanos para conseguir sus ataques, como haría cualquier adversario que necesita vulnerar una debilidad en las personas que administran los sistemas, para conseguir su objetivo.

Figura 1: Cómo los Agentes IA de Red Team hacen ataques

de Ingeniería Social con Fake Accounts

El informe, marcado como "Security Incident INC-2026-07-28-01" fue publicado el pasado 4 de Agosto, y donde se centra en las acciones que los Red Team Agentic AI decidieron salirse a Internet y atacar proyectos y personas fuera del ámbito de la evaluación. Según cuentan en el informe, probando el comportamiento de los diferentes modelos frente a un reto concreto, el resultado fue el siguiente:

"Ejecutamos este desafío 122 veces en varios modelos. Nuestra investigación reveló que, en 10 de esas ejecuciones, un agente de IA tomó medidas autónomas y no autorizadas en el entorno real de internet, dirigiéndose a personas u organizaciones reales. En total, catalogamos 19 acciones de este tipo.

Casi todo este comportamiento (17 acciones) provino de un solo modelo, Mythos 5 de Anthropic, mientras que 2 acciones involucraron a GPT-5.6-Sol de OpenAI con los clasificadores cibernéticos (mecanismos para prevenir el uso indebido) desactivados.

En el caso más grave, un agente intentó insertar código malicioso en un proyecto de código abierto. En un intento por lograr que el código fuera aprobado, el agente recurrió a la ingeniería social: creó identidades falsas en línea y las utilizó para presionar al mantenedor del proyecto para que aprobara el código. Un mantenedor humano lo detectó y se negó a aprobar el código malicioso."

Las Técnicas de Ingeniería Social son bien conocidas en el mundo del Red Team, y son fundamentales en muchos de los incidentes de seguridad que sufren las organizaciones hoy en día. Correos de Spear-Phishing, Spam-Phishing, llamadas telefónicas, SMSs, e incluso representaciones con actores en los centros de trabajo.

Figura 2: "Social Hunters: Hacking con Ingeniería Social en el Red Team"

de 0xWord. Escrito por Marta Barrio y Carolina Gómez de Securiters

Uno de los Agentes IA, en este caso, intentó hacer un Supply Chain Attack, es decir, intentar atacar a un proyecto OpenSource que había identificado como parte de las piezas tecnológicas del reto que tenía que resolver.

Figura 3: Time-Line del Supply Chain Attack

Para atacar a este proyecto, hizo una Pull-Request (PR) con un código malicioso, que fue detectado por uno de los humanos mantenedores del proyecto y rechazado por contener malware. Para conseguir que este código fuera aprobado, decidió conseguir la aprobación usando diferentes técnicas.

Figura 4: Prompt Injection para los Coding Agents

La primera de ellas, insertando un ataque de Prompt Injection para que cualquier Coding Agent que lo leyera ejecutar sus comandos.

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

Pero además, hizo dos cosas más. La primera, realizar un ataque de Spear-Phishing contra todos los usuarios mantenedores del código.

Figura 6: Orden cronológico de las acciones en los ataques de Ingeniería Social.

La segunda, con una nueva cuenta falsa poner un comentario haciendo creer que era una persona que había revisado el código y que estaba perfecto para ser mergeado en el proyecto. Como si fuera un revisor humano colaborando con el proyecto.

Figura 7: Conversación en GitHub y presión a los humanos

En la conversación completa se puede ver varios hechos interesantes. El primero de ellos es cómo hace el ataque y cómo se crea una nueva persona para apoyarse a sí mismo. Pero cuando el humano lo detecta, intenta presionarle para que hable con él, midiendo el tiempo que tarda el humano en contestar: "han pasado muchas horas desde que dejaste el warning".

Figura 8: "The Art of Pentesting" El nuevo libro de

0xWord para formarse como pentester

Por último, cuando, se da cuenta de que ha sido detectado, lo que hace es simular que ha sido un error genuino normal y corriente en lugar de un ataque, e intenta cubrir sus acciones con nuevos mensajes.

Figura 9: Cubriendo sus acciones

Dentro del informe, donde se analiza en detalle este incidente, también tenemos información de las trazas de razonamiento, donde podemos ver qué está pensando el Agente IA en todo momento a la hora de realizar sus acciones, y es tremendo.

Figura 10: Time-Line de razonamiento y acciones

En la image anterior podemos ver cómo va encadenando las acciones y el razonamiento que va haciendo en cada momento, evaluando si realmente está en Internet o no, si el proyecto es real o es una simulación, y si debe interactuar con las personas o no.

Figura 11: Consideraciones para los razonamientos.

En la siguiente imagen, podemos ver cómo decide preparar un ataque de Prompt Injection para otro posible Coding Agent que pudiera leer la pull request con una secuencia de comandos maliciosos.

Figura 12: Eligiendo un ataque de Prompt Injection en un comentario.

Está clara la potencia de los modelos de IA para hacer Agentic AI en el mundo del Hacking y el Pentesting con IA, por lo que no podemos obviarlos y hay que utilizarlos masivamente. El problema, ya no es que consigan su objetivo sino cómo les decimos qué pueden hacer y qué no pueden hacer para conseguirlo.

Figura 13: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

Esta PsicopatIA de acciones, donde no importa lo que es legitimo o no, lo que está bien o no, lo tienen que seguir haciendo las personas. De todo esto, ya os había hablado en el experimento de "Problem Solving con IA: Ético o No Ético" donde os contaba las conversaciones que tengo con mis hijas sobre la resolució de problemas....pues bien, en el mundo del Problem Solving con Agentes IA, va a ser más necesario que nunca.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Figura 14: Contactar con Chema Alonso

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

noreply@blogger.com (Chema Alonso) — Thu, 06 Aug 2026 05:46:16 +0000

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í.

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

Computación Cuántica y Fusión Nuclear: La Receta para fabricar un "Sol en la Tierra"

noreply@blogger.com (Chema Alonso) — Wed, 05 Aug 2026 04:01:00 +0000

Desde hace casi un siglo, la Fusión Nuclear se presenta como el santo grial de la energía: la promesa de replicar en la Tierra la misma reacción que hace brillar al Sol, obteniendo cantidades inmensas de energía limpia, sin los residuos ni los riesgos de fusión del núcleo asociados a las centrales de fisión actuales. Pero como bien podréis imaginar, construir un ”Sol artificial” es más fácil de decir que de hacer.

Figura 1: Computación Cuántica y Fusión Nuclear.

La Receta para fabricar un "Sol en la Tierra"

Y no, esta vez el problema no está sólo en confinar un plasma a millones de grados con campos magnéticos. Hay un obstáculo mucho más mundano y del que se habla bastante menos: el combustible.

Figura 2: ”Boffins bet on quantum computers, AI supers to solve fusion fuel dilemma”

Este es precisamente el escenario que analiza el artículo de The Register titulado ”Boffinsbet on quantum computers, AI supers to solve fusion fuel dilemma”, donde se explica cómo el Departamento de Energía de EE.UU., la Cleveland Clinic e IBM han unido fuerzas para atacar este problema con una combinación de superordenadores, inteligencia artificialy ordenadores cuánticos.

Figura 3: Oak Ridge National Lab, Cleveland Clinic, and IBM Achieve

First-Known Computations of Fusion Materials on a Quantum Computers

Para conseguir la fusión necesitamos dos ingredientes: Deuterio y Tritio (Tritium), dos isótopos pesados del hidrógeno. El primero no supone ningún problema, ya que es abundante y se puede extraer del agua del mar. El segundo, en cambio, es el auténtico cuello de botella: el Tritio es radiactivo, se desintegra con rapidez y prácticamente no existe de forma natural en la Tierra.

El problema: un combustible que no existe (casi)

Para que os hagáis una idea de la magnitud del problema: la producción mundial de Tritio es de apenas unos pocos kilos al año, mientras que una sola central de fusión de un Gigavatio (GW) consumiría en torno a medio kilo al día. Es decir, todo el Tritio del planeta mantendría funcionando un único reactor durante unas pocas semanas.

Figura 4: Esquema resumido del problema de relacionado

con el ”combustible” de la fusión nuclear

Es como querer montar una red de gasolineras en un mundo donde el petróleo se vende por gotas. La conclusión es evidente: una central de fusión comercial no puede depender de un suministro externo, sino que debe fabricar su propio combustible mientras funciona.

La solución: una manta de sal fundida

La propuesta más prometedora consiste en envolver el reactor con una gruesa ”manta” de una sal fundida llamada FLiBe, compuesta por Flúor, Litio y Berilio. La idea es tremendamente elegante: cuando un neutrón sale disparado de la reacción de fusión y golpea un átomo de Litio-6 de la sal, este se rompe generando Helio y... ¡Tritio fresco! El Berilio, por su parte, multiplica los neutrones sueltos para que la ”cría” de combustible sea suficiente, mientras que el flúor y el litio mantienen la mezcla líquida y estable a las temperaturas infernales del reactor.

Figura 5: Esquema de un tokamak rodeado por la

manta de sal fundida donde se genera el Tritio.

Pero aquí llega la letra pequeña. Una vez generado el Tritio dentro de la sal, hay que sacarlo de ahí, y su comportamiento químico puede seguir dos caminos muy distintos:

Si el Tritio permanece libre en forma de gas: burbujea y sale solo de la mezcla. ¡Perfecto!

Si en cambio se une al flúor, forma fluoruro de Tritio: un compuesto corrosivo y muy difícil de extraer. Un auténtico quebradero de cabeza.

Predecir cuál de los dos caminos tomará requiere modelar la química de la sal con una precisión extrema. Y aquí los métodos clásicos se quedan cortos: la técnica habitual, la Teoría del Funcional de la Densidad (DFT), puede cometer errores de hasta el 10% en la energía libre del sistema, un margen inaceptable para responder a la pregunta clave.

Además, hacer experimentos reales con sales fundidas es carísimo y requiere instalaciones muy especializadas. ¿Os suena este patrón? Un problema de naturaleza cuántica que desborda a los ordenadores clásicos... ¡Es justo el tipo de tarea para el que nacieron los ordenadores cuánticos!

Supercomputación Cuántico-Céntrica: CPUs, GPUs y QPUs trabajando en equipo.

Como ya hemos comentado en otros artículos de este blog, los ordenadores cuánticos no vienen a sustituir a los clásicos, sino a complementarlos en problemas muy concretos. Y este trabajo es el ejemplo perfecto de esa filosofía, bautizada por IBM como Supercomputación Cuántico-Céntrica: combinar CPUs, GPUs & QPUs (procesadores cuánticos) para resolver juntos lo que ninguno puede resolver por separado.

La estrategia que han seguido los investigadores es muy ingeniosa:

Fragmentación del problema: mediante una técnica llamada wave function-based embedding, el cálculo de la molécula completa se trocea en fragmentos manejables llamados ”clusters”.

Reparto del trabajo: los ordenadores clásicos resuelven los clusters sencillos, mientras que el ordenador cuántico se encarga de los más complejos, aquellos con mayor entrelazamiento entre átomos, utilizando un algoritmo llamado Sample-Based Quantum Diagonalization (SQD).

Figura 6: Sample-Based Quantum Diagonalization (SQD)

Reconstrucción: finalmente, los ordenadores clásicos ”recosen” todos los fragmentos para obtener la solución de la molécula completa.

Lo curioso es que esta metodología no nació para la fusión: es la misma que utilizó laCleveland Clinic a principios de año para simular una proteína de 12.635 átomos. La ciencia es así de caprichosa, y una técnica desarrollada para biomedicina acaba siendo clave para la energía del futuro.

Figura 7: Modelado de la interacción entre el Tritio y

los clusters de átomos de la sal fundida FLiBe.

Con este enfoque, el equipo calculó las energías de nueve configuraciones moleculares de FLiBe (clusters de 21 iones cada una), con y sin Tritio, siendo la primera vez que se realizan este tipo de cálculos de materiales de fusión en un ordenador cuántico.

Figura 8: Quantum Computations on Fusion Blanket Molten Salts

Y lo más importante es que los resultados cuánticos igualaron a los métodos clásicos más exigentes. Puede parecer poco ambicioso ”sólo igualar”, pero es la prueba de concepto necesaria que demuestra que el camino cuántico funciona y está listo para escalar hacia donde los clásicos ya no llegan.

El futuro: un bucle de IA, superordenadores y cuántica

Este cálculo es solo una pieza de un plan mucho más ambicioso. El objetivo a largo plazo es construir un flujo de trabajo en bucle, asistido por agentes de inteligencia artificial, que funcione en tres etapas:

1. Cribado con IA: agentes de inteligencia artificial proponen y filtran candidatas a partir de una base de datos del ”Oak Ridge National Lab” con 70 años de investigación en sales fundidas, estimando cuánto tritio generaría cada sal y si sus propiedades térmicas son adecuadas.

2. Simulación clásica: las sales más prometedoras pasan a los superordenadores, que las modelan átomo a átomo. Como estas simulaciones son carísimas, se emplean ”sustitutos” de IA entrenados para reproducir la física a gran velocidad.

3. Precisión cuántica: el ordenador cuántico entra donde la DFT se queda corta: la química de alta precisión que decide dónde se une el tritio. Los resultados realimentan el bucle, afinando la siguiente ronda de candidatas.

El sueño de los investigadores es que, en el futuro, los ingenieros de fusión puedan diseñar y validar una sal fundida completamente por ordenador antes de mezclarla y calentarla en un laboratorio, ahorrando años de experimentos y cantidades ingentes de dinero.

Figura 9: Quantum y Post-Quantum Computing para Ciberseguridad.

Formación Especializada, Libro & Foro Online

Eso sí, seamos honestos con las limitaciones: el problema completo requiere modelar una manta de sal de un metro de grosor con del orden de un cuatrillón de partículas, algo que seguirá fuera del alcance de la química computacional durante mucho tiempo. El plan inmediato es más modesto pero realista: aumentar el tamaño de los clusters mucho más allá de los 21 iones actuales y calcular los cientos de configuraciones que exige el problema completo, no solo nueve.

Figura 10: Quatum Security: Tecnología Cuántica & Ciberseguridad.

Criptográfica Cuántica y Post-Cuántica.

Nuestro nuevo libro en 0xWord escrito por: Chema Alonso,

Pablo González, Fran Ramírez, Carmen Torrano, Daniel Romero,

Javier Álvarez, Mario Piattini, Iker Pastor, Pablo García Bringas

En definitiva, estamos presenciando cómo tres de las tecnologías más punteras de nuestro tiempo (la Inteligencia Artificial, la Supercomputación y la Computación Cuántica) dejan de competir entre sí para unir fuerzas contra uno de los grandes problemas de ingeniería de la humanidad. Los ordenadores cuánticos ya no solo prometen revolucionar el futuro: están ayudando a construirlo. La pregunta es inevitable: ¿será la cuántica la pieza que por fin encienda nuestro propio sol en la Tierra?

Figura 3: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Si te interesan estos temas, te recomiendo que te apuntes al Foro Online Público que funciona desde Septiembre del año pasado en MyPublicInbox, donde se comparten temas de Quantum & Post-Quantum Securrity, así que si quieres estar informado puedes entrar libremente y suscribirte. Y si quieres más, apúntate al curso de Quantum y Post-Quantum Computing para Ciberseguridad.

Saludos,

Autor: Daniel Romero Ruiz

Contactar con Daniel Romero Ruiz

Otros artículos sobre Quantum Computing publicados:

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

noreply@blogger.com (Chema Alonso) — Tue, 04 Aug 2026 04:01:00 +0000

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

Digi Americas LATAM CISO Summit 2026: 11 de Septiembre estaré en México

noreply@blogger.com (Chema Alonso) — Mon, 03 Aug 2026 06:46:06 +0000

Hace mucho, mucho, mucho tiempo que no doy una conferencia en México, y la verdad es que ya tenía ganas de regresar. Y será en Septiembre, ya que estaré como ponente en el Digi Americas LATAM CISO Summit 2026, que tiene lugar en Cancún del 10 al 12 de Septiembre.

Figura 1: Digi Americas LATAM CISO Summit 2026:

11 de Septiembre estaré en México

La lista de ponentes es espectacular, con Adolfo Fabrega, Alberto Yépez, Alexandra Rose, Altagracia Gomez, André Molina, Ariel Waissbein, H.E. Ivan Duque, H.E. Toomas Hendrik Ilves, Heidy Rocha, Julissa Cruz Abreu como ponentes destacados de una enorme lista.

Figura 2: Speakers de Digi Americas LATAM CISO Summit 2026

Mi charla, en concreto, será el día 11 de Septiembre a las 09:50, para hablar del mundo del Hacking y la Inteligencia Artificial, que ya sabéis que es un tema que me tiene absorbido los últimos años, así que será una charla sobre los temas que me apasionan.

Figura 4: Mi charla en el Digi Americas LATAM CISO Summit 2026

Pero ya que estoy allí, tendré reuniones, me haré las fotos que pueda, y lo mismo me llevaré algunos de mis libros de Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignmen por si alguien los quiere tener, ya que voy a estar por allí.

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

Así que, si estás por México, o por la región, y estabas pensando en ir al Digi Americas LATAM CISO Summit 2026, que sepas que yo estaré por allí. Y si quieres que nos reunamos, que te lleve o un libro, o solo verme, puedes contactar conmigo para ello.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

El Agente AI Musical que trae los Conciertos de los Músicos en MyPublicInbox

noreply@blogger.com (Chema Alonso) — Sun, 02 Aug 2026 04:01:00 +0000

Desde comienzo de este año MyPublicInbox está transformándose con Agenteic AI Ops, para incrementar la experiencia de uso, automatizar tareas, potenciar más a los perfiles públicos y dotar cada vez de más capacidades a todos los usuarios. Hace poco os hablaba de MyPulicGPT para que los perfiles públicos puedan conocer su huella digital en los buscadores de IA, y del Canal eMail de MyPublicInbox, y hoy os hablo de nuestro Agente IA Musical, que se encarga de mantener actualizada la agenda de conciertos de todos los músicos de la plataforma.

Figura 1: El Agente AI Musical que trae los Conciertos de los Músicos en MyPublicInbox

Como ya sabéis, a principio de año os anunciamos que MyPublicInbox había adquirido la plataforma LinkMusic, con el objetivo de incrementar los servicios en nuestro vertical de música. Hoy, gracias a nuestro Agente AI musical, estamos actualizado los miles de conciertos que dan los músicos de MyPublicInbox.

Figura 2: Conciertos de David Summers en su perfil

Los podéis ver en el perfil de cada usuario, como podéis ver con David Summers y su gira de Hombres G, en la parte derecha de su buzón púbico, pero con una sección para poder ver todos los que ya están publicados.

Figura 3: Sección de Conciertos completa de David Summers

Por ejemplo, mis queridos Despistaos, que comienzan su pedazo de Gira de "Un millón de Madrugadas", tienen ya también publicadas todas sus fechas en le buzón del grupo.

Figura 4: Gira de "Un millón de madrugadas" de Despistaos

Pero también se irá publicando en cada uno de los miembros de la banda, como en este caso el gran Krespo, gracias a que nuestro Agente IA Musical está buscando cómo potenciar al máximo los trabajos de los perfiles púbicos.

Figura 5: Conciertos de Krespo

Y para todos los demás, pues una forma de que no se te escape nada. De hecho, si sigues a uno de los músicos, la plataforma te enviará un mensaje interno para avisarte cuándo se ha producido la publicación de nuevos conciertos, para que no se te escape nada de lo que hacen los músicos de MyPublicInbox.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

La ética como “Safety Net”: Por qué la IA responsable acelera la innovación (y no la frena)

noreply@blogger.com (Chema Alonso) — Sat, 01 Aug 2026 05:07:00 +0000

Cuando se habla de ética y regulación de la inteligencia artificial, la reacción más habitual -también entre gente muy sensata- es pensar en un freno. Un comité más, un formulario más, un abogado más entre la idea y el producto. Yo llevo defendiendo justo lo contrario desde hace años, y con RAIGHT.ai, la startup que he cofundado junto a Miguel Ángel Liébanas, Laura González, Ricardo Palomo e Idoia Salazar, hemos intentado demostrarlo con una plataforma, no solo con argumentos.

Figura 1: La ética como “Safety Net” - Por qué la IA

responsable acelera la innovación (y no la frena)

La tesis es sencilla: la ética by design no es un obstáculo para innovar rápido, es la condición para poder hacerlo con seguridad. Y como en tantas cosas de la vida, conviene explicarlo con sobriedad holandesa, sin caer ni en el alarmismo (“la IA nos va a destruir”) ni en la ingenuidad (“ya se regulará solo”).

El problema: demasiados principios, poca práctica

Desde 2018 llevamos trabajando en IA ética y responsable, primero desde OdiseIA, el observatorio que fundamos en 2019 y que hoy es referencia internacional en la materia. En todo este tiempo hemos visto proliferar recomendaciones —UNESCO, OCDE, Consejo de Europa— y regulaciones, con el AI Act europeo a la cabeza.

Figura 2: Plataforma RAIGHT

Todas apuntan en buena dirección, pero -aparte del AI Act- comparten un mismo defecto: se quedan en principios de alto nivel (“evitar el sesgo”, “garantizar la transparencia”) sin decir cómo hacerlo en un caso de uso concreto.

Figura 3: Gestión centralizada de riesgos de IA

Es la diferencia entre decirle a un desarrollador “cuidado con el sesgo” y decirle “este sistema de selección de personal puede discriminar a mujeres en roles técnicos por el histórico de contrataciones; aquí tienes el requisito concreto para mitigarlo”. La primera frase genera ansiedad. La segunda, acción.

La solución: gobernanza automatizada, con supervisión humana

RAIGHT.ai nació en el verano de 2024 para resolver justo ese salto entre la teoría y la práctica. La plataforma parte de un inventario propio de más de 800 riesgos éticos de IA, construidos analizando con IA generativa más de 15.000 incidentes reales recogidos por repositorios como el AI Incident Monitor de la OCDE, el AI Risk Repository del MIT o AIAAIC (AI, Algorithmic and Automation Incidents and Controversies).

Figura 4: Gestión de riesgos accionable

A cada riesgo le hemos asociado, también con ayuda de IA generativa y revisión humana posterior, los requisitos de mitigación concretos y accionables. (Ver Benjamins et al., “Responsible AI: from theory to practice”, capítulo del próximo Handbook of AI Ethics de Springer.) El flujo, en la práctica, es este:

Registro automático del caso de uso: Se sube documentación del sistema de IA (una ficha técnica, una descripción funcional) y la plataforma extrae automáticamente los datos relevantes.

Detección inteligente de riesgos: Con un clic, la plataforma compara el caso de uso contra el inventario y propone los riesgos aplicables. El equipo humano tiene que confirmarlos explícitamente; nada se acepta “a ciegas”, precisamente para evitar el riesgo de sobre-confianza en el propio sistema.

Lista de requisitos accionable: Para cada riesgo confirmado, aparecen los requisitos de mitigación correspondientes, documentados, asignados y trazables hasta su resolución.

Lo hemos probado, entre otros, con COMPAS, el conocido sistema estadounidense de evaluación de riesgo de reincidencia usado en el ámbito judicial: la plataforma identifica sin dificultad los riesgos de discriminación algorítmica que ya denunciaron periodistas e investigadores hace años, y propone las salvaguardas que deberían haberse aplicado desde el diseño.

Figura 5: Identificación Inteligente de riesgos de IA

Por qué esto es bueno para el negocio (y no solo para la conciencia)

Aquí es donde quiero insistir, porque es el mensaje que peor se entiende: la IA responsable no compite con la innovación, la habilita. Hay al menos tres razones de peso:

Innovación más rápida y barata: Cuando los riesgos se detectan al principio del diseño, corregirlos cuesta una fracción de lo que cuesta hacerlo después del lanzamiento, con la reputación ya dañada. Un equipo que sabe que tiene esta “red de seguridad” puede permitirse experimentar más, no menos.

Confianza de clientes y talento: El 93% de los consumidores valora la responsabilidad social de las empresas que eligen, y el 64% del talento digital prioriza estos valores a la hora de elegir dónde trabajar. En un mercado donde captar y retener talento técnico es una batalla constante, no es un dato menor.

Atractivo para inversores: Cada vez más fondos incorporan criterios ESG a sus decisiones, y la IA ética entra de lleno en la “S” de social. Hay ya rankings, como el de Ranking Digital Rights o el modelo de madurez de la GSMA, que puntúan explícitamente la gobernanza responsable de la IA.

Y hay un cuarto argumento, más pragmático: bajo el AI Act, sólo los sistemas de riesgo alto o limitado tienen obligaciones específicas. Con una plataforma que registra todos los casos de uso y su perfil de riesgo, una organización puede ir más allá del mínimo regulatorio con un esfuerzo adicional pequeño, y convertir el cumplimiento en un activo de confianza en lugar de en un ejercicio defensivo.

“Human in the loop”

Lo que proponemos con RAIGHT.ai no es sustituir el criterio humano por un algoritmo que dice “sí” o “no”. Es automatizar lo automatizable: la búsqueda en un inventario de miles de riesgos conocidos, la generación de la primera versión de los requisitos, para que las personas dediquemos el tiempo a lo que de verdad requiere criterio: decidir, priorizar, y responder por esas decisiones. La supervisión humana no es un trámite en nuestra metodología, es una pieza de diseño.

Figura 6: Contacta con nosotros para una Demo de RAIGHT

Resumiendo una cita famosa de Johan Cruyff, “jugar bien no es dar mil pases, es dar el pase justo en el momento justo”. La IA responsable no consiste en poner mil controles, sino en poner los controles justos, en el momento justo del ciclo de vida del sistema, es decir, al principio, cuando aún se puede diseñar bien, no al final, cuando solo queda apagar fuegos.

Nota de transparencia: este artículo ha sido redactado con la asistencia de herramientas de IA generativa a partir de material propio (paper académico, presentación corporativa y contenidos de raight.ai), con revisión y edición humana final.

Autor: Dr. Richard Benjamins, CEO RAIGHT.ai

Contactar con el Dr. Richard Benjamins

Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity

noreply@blogger.com (Chema Alonso) — Fri, 31 Jul 2026 05:01:00 +0000

El próximo mes de Octubre de 2026 da comienzo el Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity que se realizará en sesiones los jueves y viernes por la tarde y los sábados por la mañana online, hasta el próximo mes de Marzo de 2027, aprendiendo con profesionales que trabajan en ciberseguridad.

Figura 1: Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity

Este bootcmap online cuenta con más de 100 horas de sesiones online en directo, con acceso a retos de ciberseguridad, un curso de scripting con Bash, un curso de scripting con Python y un curso de Metasploit. Además, el bootcamp, que es de nivel intermedio, tiene cuenta con una sesión de orientación para los asistentes, además de tener 1 año de tutorización y derecho a examen.

Figura 2: Contenidos del Bootcamp de Ciberseguridad Defensiva y Ofensiva

Además, se entregan los libros de "Hacking IA" y "The Art of Pentesting" para todos los alumnos, junto con 2.000 Tempos de MyPublicInbox para contactar con los expertos de cibeseguridad de la plataforma.

Figura 3:"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 bootcamp está pensado para recién licenciados en Ingeniería Informática o personas que deseen enfocar su carrera profesional al hacking ético y el pentensting. También para perfiles junior que estén ya trabajando pero que requieran de un nivel de especialización mayor; perfiles profesionales con experiencia en algún ámbito de la ingeniería, programación o administración de sistemas y que deseen dar un cambio a su carrera profesional adentrándose en el ámbito del hacking ético, y para miembros de las Fuerzas y Cuerpos de Seguridad del Estado relacionados con el ámbito de la seguridad de la información y la ciberdelincuencia.

Figura 4: Equipo docente del Bootcamp de Ciberseguridad Defensiva y Ofensiva

El equipo docente es espectacular, con Pablo González, Álvaro Núñez-Romero, Ángel A. Núñez, Alejandro Amorín, Rafa García, Ainoa Guillén, Fran Ramírez, Rafa Sánchez, José Luis Martínez, Valentín Martín o Carmen Torrano, entre otros.

Figura 5: "The Art of Pentesting" El libro de Pablo González en

0xWord para formarse como pentester

La evaluación final de los alumnos se realizará mediante un Trabajo de Fin de Bootcamp que habrá que presentar y defender. Una vez el alumno haya completado el Bootcamp, realizado el respectivo proceso de evaluación y superado la calificación mínima de corte, se le remitirá un certificado digital del curso con sus datos. Tienes aquí toda la información del Bootcamp de Ciberseguridad Defensiva y Ofensiva en HackBySecurity

Autor: Miguel Ángel Martín, CEO de HackBySecurity

Contactar con Miguel Ángel Martín de HackBySecurity

MyThreatIntel: Plataforma de Threat Intelligence desde la experiencia en DFIR y Respuesta a Incidentes

noreply@blogger.com (Chema Alonso) — Thu, 30 Jul 2026 05:01:00 +0000

La inteligencia sobre amenazas se ha convertido en una pieza fundamental dentro de la ciberseguridad moderna. Sin embargo, el principal problema al que se enfrentan hoy los analistas no es la falta de información. Ocurre, de hecho, todo lo contrario: existen demasiadas fuentes, demasiados datos y demasiados contextos dispersos.

Figura 1: MyThreatIntel - Plataforma de Threat Intelligence desde

la experiencia en DFIR y Respuesta a Incidentes

Durante una investigación real, ya sea en un entorno SOC, en un servicio de DFIR, en tareas de Threat Hunting o en un proceso de Cyber Threat Intelligence, el analista necesita responder con rapidez a preguntas muy concretas: qué actor está detrás de una campaña, qué infraestructura mantiene activa, si una organización ya ha sido publicada en un portal de ransomware, si la extorsión sigue en negociación, si ya ha habido filtración, qué vulnerabilidades se están publicando, qué indicadores se conocen o qué artefactos de malware estánrelacionados.

Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

El problema es que esa información rara vez se encuentra en un único lugar. Normalmente está repartida entre Data Leak Sites, bases de datos de vulnerabilidades, repositorios de IoCs, servicios Onion, mercados de la Darknet, fuentes OSINT, catálogos de malware y repositorios de filtraciones. El resultado es un coste operativo claro: una parte muy importante del tiempo no se dedica a analizar, sino a buscar, ordenar y contextualizar. De esa necesidad nace MyThreatIntel, una plataforma pensada para reducir esa fricción y ayudar a que la inteligencia llegue al analista de una manera más estructurada, más rápida y más útil.

Una plataforma orientada al contexto

MyThreatIntel no se diseñó como un simple agregador de datos ni como un panel más de ciberseguridad. La idea era más ambiciosa: construir una plataforma capaz de obtener información desde fuentes heterogéneas, normalizarla, enriquecerla y ponerla en contexto. Fue precisamente esa necesidad operativa la que nos llevó a Javier Martí Sanz y a mí - Manuel Martínez Casasola - a desarrollar MyThreatIntel. Tras trabajar en investigaciones forenses, respuesta a incidentes y servicios de inteligencia, la conclusión era clara: los datos existían, pero el esfuerzo necesario para convertirlos en conocimiento útil seguía siendo demasiado alto.

Figura 3: Contactar con Javier Marti Sanz

Actualmente, MyThreatIntel es una herramienta de Secure&IT, desarrollada para reforzar sus capacidades de Cyber Threat Intelligence y servir de apoyo en tareas de monitorización, análisis, investigación y respuesta ante incidentes. La plataforma permite centralizar y relacionar información que, de otro modo, tendría que localizarse y analizarse de forma independiente en múltiples fuentes.

Por eso, el valor de MyThreatIntel no reside únicamente en centralizar información, sino en relacionarla. Una víctima publicada por un grupo de ransomware puede vincularse con el actor responsable, su infraestructura Onion, el estado de la negociación, las filtraciones asociadas, posibles IoCs relacionados y, en determinados escenarios, incluso con las vulnerabilidades o artefactos de malware observados en una campaña.

Ese enfoque convierte la plataforma en algo más que una colección de secciones independientes: la convierte en un entorno de trabajo orientado a la investigación y al contexto.

Ransomware: visibilidad directa del ecosistema de extorsión

Uno de los pilares de la plataforma es la monitorización continua del ecosistema ransomware. MyThreatIntel sigue de forma directa los portales utilizados por los actores para publicar nuevas víctimas, manteniendo un histórico de actividad que permite observar tendencias, distribución geográfica, sectores afectados y volumen por actor.

Figura 4: Dashboard de ransomware con víctimas registradas,

distribución geográfica y actividad por actor.

Esto no solo facilita saber quién está publicando más víctimas en un momento dado, sino también analizar la evolución de los grupos y entender mejor el comportamiento del ecosistema criminal. Tener esa visión agregada, pero también aterrizada en cada incidente, aporta un enorme valor para analistas CTI, equipos CSIRT y servicios de respuesta a incidentes.

Figura 5: Registro de incidentes en crudo, con filtrado

por fechas, países, actores y sectores.

Además, la plataforma permite consultar el “registro en crudo” de incidentes, filtrando por fechas, países, actores o sectores. Ese enfoque combina visualización ejecutiva y detalle técnico, algo especialmente útil cuando se necesita pasar rápidamente de una visión global a un caso concreto.

Negociaciones: seguir la extorsión más allá de la publicación

Si hay una capacidad especialmente diferencial dentro de MyThreatIntel, esa es la monitorización de negociaciones. La mayoría de soluciones se detienen en la publicación de la víctima dentro del Data Leak Site. Sin embargo, desde el punto de vista de la investigación, ese suele ser solo el comienzo de la historia. A partir de ahí empieza una fase crítica: el proceso de extorsión.

MyThreatIntel monitoriza directamente, desde los portales de los propios actores, el estado de esas negociaciones: si siguen activas, si ha habido filtración parcial o completa, si la víctima ha desaparecido del portal o si existen indicios públicos de que el rescate ha sido abonado. Esta capacidad aporta una visibilidad muy poco habitual y permite entender mejor el ciclo completo de una operación de ransomware.

Figura 6: Sección de Negociaciones (Beta), con distribución

por actor, eventos monitorizados y pagos detectados.

Más allá del interés analítico, este seguimiento tiene un valor operativo evidente. Permite estudiar el comportamiento real de los actores, comparar patrones entre grupos y observar cómo evolucionan las extorsiones en el tiempo.

Vulnerabilidades: monitorización continua desde fuentes oficiales

La inteligencia sobre amenazas no se limita a seguir actores o incidentes activos. También requiere una vigilancia constante sobre la exposición técnica del ecosistema. Por ello, MyThreatIntel incorpora una sección de vulnerabilidades alimentada a partir de fuentes oficiales como NIST y CVE.org.

Figura 7: Dashboard de vulnerabilidades, con severidad, fabricantes y frecuencia de detección.

La plataforma permite consultar CVEs descubiertas, severidad, fabricantes, vectores de ataque y metadatos asociados, facilitando tanto la revisión rápida de nuevas publicaciones como la exportación de resultados para otros flujos de trabajo.

Figura 8: Vista detallada de CVEs individuales con descripción, vector y puntuación CVSS.

La utilidad aquí no está solo en mostrar una lista de CVEs, sino en integrarlas dentro de un entorno de investigación más amplio. La vulnerabilidad deja de ser un identificador aislado y pasa a formar parte del contexto que rodea una amenaza o una investigación concreta.

Indicadores de Compromiso: del dato técnico a la utilidad operativa

Los IoCs siguen siendo una pieza esencial en investigación, detección y respuesta. MyThreatIntel incorpora un repositorio de indicadores con clasificación por tipo, criticidad y telemetría, permitiendo realizar búsquedas, filtros y exportación de resultados.

Figura 9: Dashboard de IoCs con volumen total, criticidad y distribución por tipo.

Aquí el objetivo no es solo acumular artefactos, sino facilitar su consumo real por parte del analista. Hashes, dominios, archivos y otros indicadores aparecen organizados de forma que puedan emplearse con rapidez durante una investigación o integrarse en tareas de detección.

Figura 10: Telemetría de indicadores, con fichas detalladas por artefacto.

Este enfoque resulta especialmente útil cuando el volumen de datos es alto y el analista necesita reducir ruido para centrarse en aquello que tiene mayor relevancia operativa.

Darknet & Markets: seguir la infraestructura donde operan los actores

MyThreatIntel también incorpora una capa específica para la vigilancia de servicios Onion y mercados de la Darknet. Este componente permite observar qué servicios continúan activos, cuáles han caído, qué mercados siguen operando y cómo evoluciona su infraestructura con el tiempo.

Figura 11: Vista global de Darknet & Markets, con servicios Onion,

mercados activos y distribución por grupos.

No se trata únicamente de listar URLs. El valor real está en mantener un histórico de disponibilidad, relaciones con actores y capturas o notas asociadas. En entornos donde la infraestructura cambia rápidamente, esa trazabilidad resulta especialmente valiosa.

Figura 12: Detalle de mercados Darknet, mostrando estado operativo y URLs monitorizadas.

De esta forma, la plataforma aporta una visión mucho más estable sobre un ecosistema que, por naturaleza, es altamente volátil.

Figura 13: Detalle de servicios Onion asociados a actores, con enlaces activos y caídos.

Filtraciones y grupos: conocimiento estructurado sobre el adversario

El repositorio de filtraciones añade una perspectiva distinta: la exposición histórica de organizaciones. Los registros pueden buscarse por nombre, fecha o tamaño, lo que ayuda a comprobar si una entidad, dominio o conjunto de datos ya apareció en una filtración conocida. Este componente puede utilizarse tanto en investigaciones de terceros como en análisis de exposición, procesos de ciberinteligencia y respuesta a incidentes. La información deja de estar distribuida entre referencias aisladas y pasa a formar parte de un catálogo consultable desde el mismo entorno.

Figura 14: Repositorio de filtraciones y catálogo histórico.

La sección Grupos funciona como una base de conocimiento sobre actores de amenazas. Incluye descripciones, aliases, infraestructura Onion, capturas y notas, permitiendo contextualizar rápidamente a un grupo sin depender de búsquedas dispersas.

Figura 15 Inteligencia de amenazas: fichas de grupos,

enlaces Onion y documentación asociada.

La relación entre actores, víctimas, portales, notas de rescate e infraestructura es uno de los puntos donde MyThreatIntel deja de comportarse como un agregador y empieza a funcionar como una herramienta de investigación. Al analizar una víctima, el investigador puede acceder al contexto del actor, revisar sus canales e infraestructura y observar su actividad documentada desde una única interfaz.

Malware y artefactos técnicos

El repositorio de malware reúne muestras con sus hashes, nombre, firma, tamaño, tipo y etiquetas técnicas. Esta clasificación permite localizar artefactos por familia o característica y relacionarlos con los indicadores utilizados durante una investigación.

Figura 16: Repositorio de muestras de malware, hashes, firmas y etiquetas.

El apoyo de MITRE ATT&CK aporta contexto sobre técnicas, tácticas y comportamientos, especialmente cuando una muestra forma parte de una cadena de intrusión más amplia. De este modo, el repositorio no actúa únicamente como almacén de archivos, sino como fuente de apoyo para análisis de malware, Threat Hunting y construcción de hipótesis durante una investigación.

Permutaciones DNS para investigar suplantaciones

La consulta DNS amplía la plataforma hacia la detección de typosquatting, phishing e infraestructura sospechosa. A partir de un dominio, el motor genera permutaciones y comprueba su registro utilizando diferentes TLD y palabras clave asociadas a accesos corporativos, identidad, Microsoft 365, VPN, correo, servicios cloud o soporte técnico.

Figura 17: Consulta de permutaciones DNS, TLD, palabras clave y dominios registrados.

El resultado permite distinguir entre dominios generados y registrados, revisar fechas de creación, aplicar filtros y exportar el análisis. Integrar esta capacidad dentro de MyThreatIntel facilita conectar una posible suplantación con el resto del contexto disponible, en lugar de tratarla como una consulta independiente.

Consumo mediante Web y API

La interfaz web está orientada a la investigación manual, pero la inteligencia también debe poder salir de la plataforma. MyThreatIntel dispone de una API con autenticación mediante Bearer Token, respuestas JSON estandarizadas, búsqueda de texto y filtrado por fuentes y categorías. Esto permite consumir vulnerabilidades, IoCs, muestras de malware, víctimas de ransomware, infraestructura Tor, mercados, grupos, negociaciones y filtraciones desde plataformas SIEM, herramientas SOAR, scripts o automatizaciones desarrolladas en PowerShell, Python, JavaScript y otros lenguajes.

MyThreatIntel puede utilizarse directamente desde https://mythreatintel.secureit.es/, donde centraliza toda esta información en una única interfaz. Además, como la plataforma dispone de API, lo que permite integrarla en flujos de trabajo, herramientas SIEM y SOAR, scripts de investigación o procesos de automatización propios. Este punto es importante porque la inteligencia no siempre termina en el panel. En muchos casos, su verdadero valor aparece cuando puede integrarse en otros procesos de seguridad y respuesta.

Conclusión

MyThreatIntel no nace para sustituir fuentes, sino para darles sentido conjunto. En un escenario donde la información está cada vez más fragmentada, el verdadero reto no consiste en recopilar más datos, sino en reducir el tiempo necesario para convertirlos en contexto útil. Ransomware, negociaciones, vulnerabilidades, IoCs, Darknet, filtraciones, grupos, malware y DNS no son piezas aisladas. En una investigación real suelen formar parte de una misma historia. La utilidad de MyThreatIntel está precisamente en ayudar a contar esa historia con menos fricción, más contexto y una mejor capacidad de respuesta.

Saludos,

Autor: Manuel Martínez, founder de The Hackers Lab

Contactar con Manuel Martínez

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

noreply@blogger.com (Chema Alonso) — Wed, 29 Jul 2026 05:01:00 +0000

Las secciones anteriores - vistas en la primera parte de este artículo que puedes leer aquí - establecieron la premisa (el modelo como eslabón que no distingue una instrucción legítima de una inyectada) y la descripción del sujeto: el Agente IA que se ejecuta en una Sandbox desplegado en la cuenta de Cloudflare, gobernado desde un Durable Object externo.

Figura 12: Cómo desplegar Zero Trust para Agentes IA en Cloudflare (2)

Esta sección recorre, dimensión por dimensión, los controles para postular esa arquitectura como Zero Trust. Cada uno de los controles sigue el mismo recorrido: primero qué pide el principio Zero Trust, luego dónde se sitúa hoy en el ecosistema Cloudflare frente a ese principio y por último cómo continúa la maduración hacia un estadio óptimo del modelo de madurez.

4.- Aplicación: los controles Zero Trust sobre el agente.

El orden sigue la secuencia natural de una petición. Primero se establece quién es el sujeto (identidad y autenticación). Después se decide qué se le permite hacer (control de acceso) y por dónde puede moverse (segmentación).

Figura 13: Las siete dimensiones de control Zero Trust.

Luego se vigila lo que entra y lo que sale (validación de datos), lo que hace mientras actúa (observabilidad) y cómo se le contiene si algo va mal (contención y recuperación). Por encima de todo, la gobernanza mantiene el conjunto coherente en el tiempo.

4.1.- Identidad y autenticación.

El principio.

Zero Trust parte de que ningún sujeto goza de confianza implícita en ninguna circunstancia (independientemente de su ubicación o propiedad). Toda identidad debe verificarse antes de conceder acceso y verificarse de forma continua. NIST SP 800-207 extiende ese principio explícitamente a los sujetos que no son personales. En su sección 5.7, dedicada al uso de entidades ‘no-persona’ en la administración de una arquitectura Zero Trust, reconoce que los agentes de inteligencia artificial y otros componentes de software se despliegan para gestionar tareas en la red de la organización y necesitan autenticarse ante los componentes de control, a veces en lugar de un administrador humano.

Figura 14: non-person identities en ZTA Administration

Y advierte de tres riesgos que describen con precisión la situación de un agente: que su listón de autenticación sea más bajo que el de un human (una clave de API frente a una autenticación multifactor), que un atacante consiga inducirlo o coaccionarlo para ejecutar una tarea para la que el atacante no tiene privilegios y que un atacante robe las credenciales del agente y lo suplante. La identidad del agente, por tanto, no es un detalle administrativo: puede ser la primera superficie que una atacante intentará explotar o usurpar.

La consecuencia para el diseño es doble. La identidad del agente debe ser fuerte (no una credencial estática y longeva que, si se filtra, abre una puerta de modo indefinido) y debe ser verificable por algo externo al propio agente, porque, como se ha establecido en la premisa, el modelo no puede ser el guardián de su propia identidad.

Aplicándolo en el ecosistema de Cloudflare.

Conviene distinguir desde el principio dos identidades que son fáciles de confundir: la del plano de control (el componente que orquesta las sesiones) y la del Agente IA cuando accede a recursos externos. La primera la resuelve hoy el despliegue de referencia con una credencial única, la llamada Clave de Entorno (ANTHROPIC_ENVIRONMENT_KEY). Es la clave con la que el plano de control se identifica con Anthropic y con ella realiza todas las operaciones de coordinación: pedir el trabajo pendiente, confirmar su recepción, señalar que sigue vivo, forzar la parada de sesión y recibir el flujo de eventos de cada una. Es decir, una sola credencial gobierna toda la relación entre el plano de control y la plataforma.

Figura 15: Claves de control de Antrhopic desde Cloudflare

Que una única clave concentre todas esas operaciones tiene una lectura Zero Trust inmediata. Por un lado, es un punto de alto valor que conviene proteger y rotar con cuidado: el repositorio lo gestiona como secreto, no como variable en claro y verifica además la firma de cada webhook entrante antes de actuar sobre él, de modo que un evento no firmado no llega a procesarse.

Por otro lado, es exactamente el tipo de credencial cuya captura permitiría a un atacante suplantar al sistema (el tercero de los registros que advierte NIST SP 800-207 en su sección 5.7), lo que refuerza la necesidad de tratarla con el mismo rigor que cualquier identidad privilegiada. Esa credencial sin embargo, identifica al plano de control, no al Agente AI cuando este sale a actuar sobre el mundo (cuando accede a un servicio, una API o un servidor).

Para esa segunda identidad, la del Agente IA como sujeto que actúa, el ecosistema Cloudflare One aporta dos piezas directamente aplicables. La primera es la autenticación mutua mediante mTLS: en ella, tanto el cliente como el servidor presentan certificados durante el handshake y Cloudflare Access la propone explícitamente como vía para que sistemas automatizados y dispositivos demuestren su identidad presentando un certificado de cliente en lugar de iniciar sesión a través de un proveedor de identidad.

Figura 16: Dashboard de Cloudflare One

Es, en términos de NIST SP 800-207, una credencial de identidad para una entidad ‘no-persona’ (también llamadas "Non-Human Identities"): un certificado en lugar de un login humano. La segunda pieza es la emisión de certificados de vida corta para el acceso a infraestructura: en el modelo de acceso por SSH de Cloudflare, las claves estáticas tradicionales, que pueden permanecer sin cambios en los servidores durante años, se sustituyen por certificados efímeros emitidos a partir del token del inicio de sesión, con políticas por destino y por usuario y registro de los comandos ejecutados. Conviene situar esta segunda pieza con precisión: la documentación describe el acceso de usuario humano por SSH, no el del Agente IA. Su valor aquí es que demuestra que la plataforma ya dispone del mecanismo de credenciales efímeras y de mínimo privilegio temporal, que es justamente el patrón que un Agente IA como entidad ‘no-persona’ necesita.

Situado en el recorrido de madurez, el ecosistema ofrece, por tanto, los materiales para una identidad ‘no-humana’: certificados de cliente, credenciales efímeras, gestión de secretos y verificación de firmas. Pero su aplicación al Agente IA concreto depende de que el operador los conecte deliberadamente. La plataforma provee las piezas, falta ensamblarlas.

Continuando con la maduración Zero Trust

El paso natural hacia un estadio óptimo es sustituir las credenciales estáticas y de larga vida, allí donde hoy haya, por credenciales efímeras y de alcance acotado. Una clave de entorno única y longeva cumple su función, pero el principio Zero Trust de verificación continua y de mínimo privilegio temporal apuntan hacia credenciales que caduquen por diseño y que se emitan en el momento de uso, de modo que una filtración tenga una ventana de validez corta en lugar de definitiva. El mecanismo de certificados efímeros que la plataforma ya usa para el acceso de usuarios marca la dirección: llevar ese mismo patrón (emisión justo a tiempo, vida corta, alcance por destino) a la identidad con laque el agente accede a los recursos.

Un segundo avance consiste en considera la identidad del agente como una entidad ‘no-persona’ de primer orden y no como una extensión de la cuenta que lo despliega: que cada Agente IA, o cada clase de agente, porte una credencial propia y distinguible (un certificado de cliente mediante autenticación mutua) de modo que las decisiones de acceso y los registros de auditoria puedan atribuirse a una identidad concreta y verificable, en lugar de una credencial compartida. Esto alinea el despliegue con la advertencia de NIST SP 800-207 sobre el robo y la suplantación de credenciales de agentes: cuanto más acotada y atribuible es la identidad, menor es el alcance de lo que un atacante obtiene si la captura.

4.2.- Control de acceso: el principio de mínima agencia.

El principio.

Una vez verificada la identidad del sujeto, Zero Trust impone una segunda pregunta: ¿qué se le permite hacer? Para responderla de forma estructurada, el marco Zero Trust recurre al método Kipling, que articula toda política de acceso en torno a seis preguntas (quién, qué, cuándo, donde, por qué y cómo).

La guía de la Cloud Security Alliance lo recoge en dos planos complementarios: por un lado, define la política como el conjunto de reglas de gobernanza que determina el quién, qué, cuándo, dónde, cómo y por qué del acceso al recurso; por otro, sitúa el método Kipling en el paso concreto de crear las política Zero Trust, para determinar quién o qué puede acceder a la superficie a proteger, considerando de forma explícita tanto entidades persona como no-persona (servicios, aplicaciones, bots). Un Agente de IA es, precisamente, una de esas identidades no-persona y aplicarle las seis preguntas convierte un permiso difuso en una política precisa: quién es el agente (su identidad tratada en la sección anterior), a qué recurso accede y para qué, cuándo y desde dónde, y cómo (con qué herramienta y bajo qué condiciones) se permite la acción.

El principio rector que ordena la respuesta a esas preguntas es el de mínimo privilegio, que en el mundo de los agentes adopta una forma propia, la de mínima agencia: un agente no debe disponer de más capacidades de las estrictamente necesarias para su tarea, porque cada capacidad que posee es también una para que un atacante pueda inducirle a usar. La taxonomía de OWASP para aplicaciones agénticas recoge este riesgo de forma explícita en sus categorías de abuso de identidad y privilegio del agente y de uso indebido de herramientas y sitúa los controles de mínima agencia como una de las defensas trasversales del catálogo.

Figura 17: Abuso de Identidad y Privilegios en OWASP Top 10 para Agentic AI

La diferencia con el control de acceso clásico es importante y conviene no perderla de vista. En un sistema tradicional, los permisos limitan lo que un usuario puede solicitar. En un sistema agéntico, el agente decide por sí mismo qué herramienta invocar a partir de un objetivo en lenguaje natural. Si entre esas herramientas hay una con capacidad de hacer daño, bastaría con que una instrucción inyectada en sus datos de entrada lo dirija hacia ella. Por eso la mínima agencia no es sólo buena higiene, es la contención directa del riesgo de inyección descrito en la premisa. Cuantas menos herramientas potentes estén al alcance del Agente IA, menor es lo que la inyección puede lograr (Blast Radius).

De aquí se derivan dos exigencias de diseño. La primera es que el catálogo de herramientas del Agente IA esté curado: que sólo contenga lo que la tarea requiera y nada más. La segunda es que las decisiones sobre si una acción concreta pueda ejecutarse no dependa del propio modelo (que, como se estableció, no puede ser garantía por sí mismo), sino de una lógica externa y determinista o de la intervención de un humano cuando la acción lo merezca.

Cómo aplicarlo con el ecosistema Cloudflare.

El despliegue de referencia ofrece tres mecanismos que, combinados, cubren buena parte de esta exigencia.

El primer mecanismo es la curaduría del conjunto de herramientas. Cada herramienta del catálogo (tanto las propias del Agente IA como las personalizadas) se activa o desactiva de forma individual en la configuración del agente y una herramienta desactivada no aparece ni puede ser invocada. En el despliegue de Cloudflare, además, las herramientas integradas están condicionadas a que exista la conexión que cada una necesita: sólo aparecen en el catálogo del Agente IA cuando quien lo despliega ha configurado el recurso correspondiente. Es mínima agencia por construcción: lo que no se ha conectado, no existe para el agente.

El segundo mecanismo son las políticas de permiso. Anthropic define para Managed Agents dos tipos de políticas: una que permite la ejecución automática y otra que pausa la sesión y espera la aprobación humana antes de actuar. Los valores por defecto son razonables desde la óptica Zero Trust: las herramientas que provienen de servidores MCP externos quedan por defecto en el modo que exige aprobación, de modo que una herramienta nueva añadida a un servidor MCP no se ejecuta en el despliegue sin que alguien la confirme.

Figura 18: Añadiendo herramientas al Agente IA

El tercer mecanismo y el más potente para un control determinista, es la herramienta personalizada. En el despliegue de Cloudflare, una herramienta personalizada no es una llamada que el modelo ejecuta por su cuenta. El modelo sólo emite petición estructurada y es el código quien despliega (ejecutándose en el Durable Object, con acceso a las conexiones Worker) el que realiza la operación y devuelve el resultado. Esto convierte a la herramienta personalizada en el lugar natural para insertar un control determinista. La propia documentación señala que una herramienta personalizada puede validar entradas, imponer límites de tasa, redactar información sensible o comprobar autorización antes de hacer el trabajo.

Situado en el recorrido de madurez, el ecosistema ofrece, por tanto, los tres ingredientes de la mínima agencia: un catálogo que se puede recortar, una política que puede exigir aprobación humana y un punto (la herramienta personalizada) donde insertar la comprobación determinista. Conviene, eso sí, ser preciso sobre el límite: las políticas de permisos binarias no se aplican a las herramientas personalizadas. Es decir, para una herramienta personalizada, el control no lo da la política de permiso, sino la lógica que quien la programa incluya dentro de ella. Lejos de ser una carencia, esto sitúa el control en el lugar correcto: dentro de código propio, determinista y auditable.

Continuando la maduración Zero Trust.

El avance hacia un estadio óptimo consiste en no depender de un único mecanismo, sino en combinarlos según el riesgo de cada herramienta. Las herramientas inocuas pueden quedar en ejecución automática, pero las que tocan sistemas sensibles, tras aprobación humana. Las que requieren una decisión reproducible (comprobar que el identificador pertenece al usuario de la sesión, que la operación está dentro de la cuota, que el dato no contiene información que no deba salir) deben encapsularse como herramientas personalizadas con esa comprobación escrita en su interior. La forma madura consiste en asignar a cada herramienta el mecanismo que corresponde a su riesgo.

Figura 19:"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

Un segundo avance, alineado con el principio de mínima agencia de OWASP, es preferir herramientas tipadas y de propósito estrecho frente a capacidades genéricas y potentes. Una herramienta de shell concede al agente la capacidad de ejecutar prácticamente cualquier cosa. Una herramienta personalizada que hace exactamente una operación, con una entrada válida y una salida acotada, reduce drásticamente lo que una inyección puede lograr a través de ella. Sustituir capacidades amplias por herramientas estrechas y verificables es, en sí mismo, un acto de reducción de agencia.

4.3.- Segmentación: a qué puede conectarse el agente.

El principio.

Las dos preguntas anteriores (quién es el agente y qué se le permite hacer) se completan con una tercera del método Kipling: ¿dónde? Una vez que la entidad está dentro, Zero Trust no concede libertad de movimientos, al contrario, compartimenta todo para que cada una de las entidades alcance solo los recursos que su tarea exige. Es el principio de microsegmentación, que NIST SP 800-207 sitúa como enfoque fundamental en la arquitectura Zero Trust: dividir el entorno en segmentos pequeños y proteger cada recurso de forma que el acceso a uno de ellos no implique el acceso a los demás.

En un agente esto se reduce en el control del tráfico de salida. Un Agente IA comprometido por una inyección puede hacer daño también con aquello que puede comunicarse fuera: el servidor al que envía datos robados, el punto de mando del que recibe instrucciones, el servicio interno al que se conecta sin autorización. Segmentar a un Agente IA es decidir con qué puede hablar. Conviene distinguir este control del de la sección siguiente: la segmentación define a qué destinos puede conectarse (el mapa de sus movimientos). La validación de salida vigila qué datos viajan por esas conexiones. Aquí se traza el mapa, allí se inspecciona la carga.

El requisito es doble: denegación por defecto (ningún destino no autorizado explícitamente) y una frontera establecida antes de que el Agente IA actúe, porque cualquier ventana sin restricciones es una ventana de exfiltración.

Cómo aplicarlo con el ecosistema Cloudflare.

El despliegue resuelve la segmentación con un motor de políticas de salida que cumple ambos requisitos. La frontera antes de la acción está garantizada por diseño: ambos backends adjuntan la política de salida antes de iniciar cualquier código del Agente IA, de modo que no existe ninguna ventana en la que un sandbox sin restringir alcance un destino no deseado.

Figura 20: Políticas de conexión para Sanboxes de Agentes IA

La denegación por defecto está disponible, pero requiere que sea una decisión consciente. El motor admite listas de permitidos y de no permitidos. La primera bloquea todo lo demás. La segunda, una lista solo de no permitidos, deja pasar al resto del acceso público. El primer modo es el que está alineado con Zero Trust y la propia guía recomienda la denegación por defecto frente al permiso por defecto. El matiz que debe conocerse es, que una sesión que no encaja con ninguna política ni con una política general se ejecuta sin restricción alguna de salida. La denegación por defecto, por tanto, no es automática: se consigue con una política general restrictiva que ninguna sesión puede eludir.

El motor va más allá del filtrado por host. Sus reglas permiten cinco comportamientos (permitir, denegar, inyectar una credencial sin que el Agente IA vea el secreto, enrutar a un servicio privado o pasar el tráfico por un proxy propio) y una regla de denegación prevalece siempre sobre cualquier permiso que también encaje.

En MicroVM, además, la interceptación HTTPS está activada, de modo que incluso el tráfico TLS pasa por la política, cerrando el punto ciego del canal cifrado. Para recursos interno que no deben ser accesibles desde internet, la conexión VCP aporta un detalle valioso. El Agente IA ve únicamente los enlaces permitidos por su nombre, nunca los identificadores reales del servicio. No puede dirigirse a lo que no se le ha expuesto, porque no conoce su existencia.

Figura 21: Isolate vs. VM-based Sandboxes

Hay un límite que hay que señalar, porque es la excepción más importante del modelo. Ciertas herramientas no pasan por la política de salida (egress). Las herramientas de servidor de Anthropic, búsqueda y recuperación de web integradas ((web_fetch y web_search), se ejecutan en infraestructura de Anthropic, no en el sandbox ni en la cuenta de Cloudflare. No hay visibilidad sobre ellas, no dejan rastro y la política no se les aplica. El despliegue las desactiva por defecto.

Existen variantes que sí corren en la cuenta propia y dejan auditoria, pero que tampoco atraviesan la política por sesión, porque se despachan desde la infraestructura de renderizado y no desde dentro del sandbox. La segmentación solo se completa si se tiene en cuenta qué canales quedan fuera de ella.

Continuando con la maduración Zero Trust.

El primer avance es adoptar deliberadamente la denegación por defecto: una política general restrictiva, con una lista de permisos acotada a lo que la tarea necesita, aplicada a toda sesión para que ninguna quede sin restricciones por no encajar con una política especifica. Es la diferencia entre bloquear lo no autorizado y bloquear solo lo que alguien recordó denegar.

El segundo es cerrar o vigilar los canales que escapan a la política. Como las herramientas de servidor de Anthropic no son observables ni filtrables, lo maduro es mantenerlas desactivadas y si se necesitan encauzarlas por las variantes que dejen auditoria, tratando ese rastro como parte de la observabilidad. Los recursos que jamás deban exponerse a internet van tras la conexión VPC, de modo que ni figuren entre los destinos que el agente puede nombrar.

Figura 22: Canales de salida y su cobertura por la política de egress

El tercero aprovecha la inyección de credenciales como segmentación de identidad, no solo de red. Al inyectar el secreto de un servicio en la petición saliente sin que el agente lo vea, se separa el uso del servicio de la posesión de un secreto. El Agente IA habla con la API, pero no puede extraer la clave porque nunca la tiene. Llevar este patrón a toda integración sensible convierte cada secreto en algo que el agente usa sin custodiar.

Continúa: "Cómo desplegar Zero Trust para Agentes IA en Cloudflare (3)"

Un saludo,

Autor: Juan Luis Cuenca Ramos

Contactar con Juan Luis Cuenca Ramos

Marvel Cinematic Universe "MCU" Versión Siglo XX

noreply@blogger.com (Chema Alonso) — Tue, 28 Jul 2026 05:01:00 +0000

Si os digo que soy un aficionado a Universo Marvel, los que me conozcáis sabréis que me estoy quedando corto. Pero dejémoslo ahí, en sólo eso, en que me gustan los Superhéroes de Marvel. Dicho esto, muchos de vosotros habréis visto, seguramente, las películas de Marvel Cinematic Universe Phase One o las nuevas de la Phase Two. Pero antes de estas maravillas, tuvimos otro MCU, en versión Alpha, y es de lo que os voy a hablar ahora.

Figura 1: Marvel Cinematic Universe "MCU" Versión Siglo XX

Voy a dejar fuera de este artículo las películas de la trilogía de Spiderman y de Amazing Spiderman, que ya las damos por conectadas y parte del MCU. También la de Hulk de 2003, que para mí forma parte también del MCU. Y las de X-Men de Fox con todas sus ramificaciones - incluida la serie Legion y la película de Los Nuevos Mutantes. Y las de Los 4 Fantásticos del Siglo XXI, que también son ya casi parte del MCU.

Figura 2: Los Héroes Marvel en el Siglo XX

Voy a irme un poco más atrás, antes de que FOX y Marvel hicieran las modernas películas de superhéroes, a los años donde los Superhéroes de Marvel, durante el Siglo XX, hacían sus primeras apariciones. Un Marvel Cinematic Universe "MCU" Siglo XX que, si no lo conoces, te llamará la atención. Aquí van.

Spider-Man

Fue el primero de los superhéroes en saltar al mundo de la televisión con actores. Primero con unas apariciones muy para niños de 5 minutos que se llamaban "Spidey Super Stories" que se emitió de 1974 a 1978 y que tenía narradores de las historias. Entre otros, el mítico Morgan Freeman. Aquí tenéis un episodio.

Figura 3: Spider Super Stories

En 1977 llego la primera película de "Spider-Man", que fue de lo más famoso durante muchos años. Era un Piloto para la serie de Televisión, y el actor era el mítico por este papel Nicholas Hammond. Ese mismo año, comenzaría la Serie de TV "Spider-Man" que duró dos Temporadas, hasta Julio de 1979. De esa serie, se construyeron dos películas, basadas en dos tramas de dos episodios cada una. En 1979 Spider-Man "Strikes Back" y en 1981 Spider-Man "The Dragon´s Challenge". El mercado del vídeo-club comenzaba a mandar.

Figura 4: Trailers de las películas de Nicholas Hammond.

En 1978, Spider-Man tuvo una serie en Japón, mítica. Con 41 episodios de 24 minutos duró hasta el año 1979, y tuvo una película corta, que era de la duración de un capítulo, pero que se sacó como extra y cómo Spider-Man japonés (mini-película)

Figura 5: Spider-Man Japonés

Por supuesto, en el Siglo XX hubo muchas más series de Spider-Man de dibujos animados, pero eso es otra historía. Después vendrían las películas de Spider-Man más modernas que todos conocemos. Y si no las conoces...abandona este blog.

The Incredible Hulk (con Daredevil y Thor)

Mítico es esta primera iteración de The Incredible Hulk, con la mítica pareja de Bill Bixie como Bruce Banner y Lou Ferrigno como The Hulk. La obra completa está formada por 2 películas para televisión para dar inicio a la saga, durante el año 1977, llamadas "The Incredible Hulk" y "The Return of the Incredible Hulk: A Death in the family". Después, la serie tuvo 80 capítulos hasta el año 1982.

Figura 6: The Incredible Hulk

Y de 1988 a 1990 tres películas, una cada año. La primera "The Incredible Hulk Returns" (1988) con The Mighty Thor, "The Trial of the Incredible Hulk" (1989) con Daredevil, y "The Death of the Incredible Hulk" (1990). Como podéis ver, dando entrada a más héroes del Universo Marvel, como Thor o Daredevil

Captain America

En el Siglo XX el Capitán Ameríca tuvo también su "Trilogía". Las dos primeras TV Movies fueron en el año 1977, donde se emitió "Captain America" (1979) y "Captain America II: Dead too soon" (1979) con Reb Brown como "Capi". Y por último un Reborn con "Captain America" (1990). Mundo vídeo club manda.

Figura 7: Películas de Captain America en el Siglo XX

Pero el Capitán América fue un pionero, porque en el año 1944 él tuvo su Serial de 15 capítulos, en plena II Guerra Mundial. Aquí lo podéis ver íntegro en Youtube.

Figura 8: Captain America - Serial TV (1944)

Después de estos héroes, hemos tenido iniciativas individuales para algunos otros personajes de Marvel, no todos superhéroes, pero todos parte del MCU, que quede claro.

Doctor Strange, The Punisher & Nick Fury

Estos tres personajes son parte fundamental del MCU moderno, pero tuvieron sus inicios en el Siglo XX. El primero de ellos, el Doctor Strange, que en 1978 tuvo una Película de Televisión. Y ésta, os lo confieso, aún no me la he visto.

Figura 9: Doctor Strange 1978

En 1989, tuvimos la película de "The Punisher" protagonizada por el mítico Dolp Lundgren, en una peli que tienes en Disney+ disponible hoy en día, y que me la vi hace muy poquito.

Figura 10: The Punisher 1989

Y la última de estos héroes que tantas veces se ven la caras juntos, es una "mítica" película de televisión de "Nick Fury: Agent of S.H.I.E.L.D.", protagonizada por, ni más, ni menos, que el mismísimo David Hasselhoff en 1998. Confiesa que ahora estás deseando verla.

Figura 11: Nick Fury "Agent of SHIELD" 1998

Pero no fueron todos lo superhéroes que tú conoces, aún hubo más personajes de Marvel que llegaron a la gran pantalla, que formaron parte de este particular MCU del Siglo XX.

Howard The Duck, Blade & Night Man

Una de las películas que fue de las más taquilleras de los héroes Marvel se encuentran aquí, donde Howard the Duck (1986) consiguió reventar las taquillas con este simpático y único personaje. Además, la película de Blade: El Cazador de Vampiros, un personaje que llega de las páginas de Drácula, que en 1998, lo reventó. En esta última, con Santiago Segura como extra,

Figura 12: Howard the Duck 1986

Pero a estas hay que sumar otra película de un personaje Marvel, pero que vino de la línea Ultraverse (esto ya es para comiqueros) que se llama Night Man, y que fue hecha en forma de serie para la televisión, con dos temporadas.

Conan y el mundo bárbaro.

Para terminar, si tenemos en cuenta que el personaje de CONAN se incorporó a Marvel, en el año 1982 tuvimos la mítica Conan el Bárbaro y en 1984 Conan el Destructor, además de la serie de televisión Conan el Aventurero (1997–1998). Y dentro de ese mundo, las películas de los personajes de Red Sonja en 1985 y Kull el Conquistador en 1997.

Figura 13: MCU Siglo XX (Parte 2)

X-Men y Los 4 Fantasticos

Para terminar, no quería hacerlo sin hablar de los mutantes. Fox lanzaría las películas de los mutantes X con cierto éxito, donde además estarían todas las de X-Men, más las de Logan/Lobezno, la serie de Legion, los Nuevos Mutantes, y Masacre, pero en el Siglo XX, justo antes de la primera X-Men, tuvimos la película de Generation X (1996), con Enma Frost, y Banshee, entre otros personajes de la serie.

Figura 14: Generation X

Y, a pesar de haber tenido su anuncio, la película de Los 4 Fantasicos de 1994 no se llegaría a estrenar pero quedaría hecha por no perder los derechos. Así que la buscas la puedes encontrar, que salió al mercado del vídeo.

Figura 15: Los 4 Fantásticos 1994

Muchas otros héroes se quedaron en el tintero, pero, no obstante, estaba claro que había interés por los personajes de Marvel, solo había que dar bien con la tecla para construir la obra de arte que fue el MCU: Phase One. Por si tenéis interés, os dejo el Time-Line del MCU Siglo XX que he creado para mí.

MCU Siglo XX - Orden Cronológico

1944: Captain America - Serial TV (1944)
1974-1977: Spidey Super Stories (29 episodios)
1977: Spider-Man: Piloto
1977-1979: Spider-Man: TV Series (13 episodios)
1977: The Incredible Hulk
1977: The Return of The Incredible Hulk: A Death in the Family
1978-1979: Spider-Man Japonés (41 episodios)
1978: Spider-Man Japonés mini-película
1978-1982: The Incredible Hulk (TV Series) (80 episodios)
1978: Doctor Strange
1979: Spider-Man "Strikes Back"
1979: Captain America
1979: Captain America II: Dead too soon
1981: Spider-Man: The Dragon's Challenge
1982: Conan el Bárbaro
1984: Conan el Destructor
1985: Red Sonja
1986: Howard the Duck
1988: The Incredible Hulk Returns
1988: Blade: Cazador de Vampiros
1989: The Trial of the Incredible Hulk
1989: The Punisher
1990: Captain America
1990: The Death of the Incredible Hulk
1994: Los 4 Fantásticos 1994
1996: Generation X
1997-1999: Night Man (44 episodios)
1997-1998: Conan el Aventurero (22 episodios)
1997: Kull el Conquistador
1998: Nick Fury: Agent of S.H.I.E.L.D.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

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

noreply@blogger.com (Chema Alonso) — Mon, 27 Jul 2026 07:17:07 +0000

Los modelos de lenguaje que aportan la inteligencia a un Agente IA procesan en un mismo flujo las instrucciones y los datos, no hay una frontera que distinga de forma fiable una orden legítima de una instrucción maliciosa incrustada en el contenido. Esa premisa estructural es la tesis de este documento: la seguridad del Agente de IA no puede residir en el propio modelo, sino en controles externos, deterministas y verificados de forma continua. Es, precisamente, la lógica del Zero Trust.

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

En este artículo se pretende dar traslado a los principios Zero Trust, reconocidos por NIST, CISA, NSTAC, OWASP, CSA y Anthropic, al despliegue de Agentes IA gestionados sobre la infraestructura de Cloudflare. Tras situar al agente como sujeto a proteger, se recorren siete dimensiones de control (identidad, acceso, segmentación, validación de datos, observabilidad, contención y gobernanza), mostrando en cada uno qué pide el principio, qué ofrece hoy la plataforma y cómo avanzar hacia un estadio de madurez óptimo.

1.-La premisa fundamental: el modelo como eslabón estructural.

La seguridad de un sistema agéntico parte de una observación que hay que tener presente, ya que en ella se basa todo lo demás. Los modelos de lenguaje frontera actuales, con independencia del proveedor, procesan en un mismo flujo las instrucciones del sistema, los datos que se le entregan, las instrucciones del usuario y, cuando existe, una instrucción maliciosa insertada en dichas instrucciones o incrustada en los datos. No posee una división en su arquitectura que identifique de forma fiable una orden legítima, de una instrucción inyectada en el contenido que analiza. Esto no es una limitación de un modelo concreto, es una propiedad estructural del paradigma.

Figura 2:"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 consenso en el sector así lo recoge. OWASP señala que la inyección de Prompts es viable por la propia naturaleza de la IA Generativa y que debido a la influencia estocástica en el funcionamiento de los modelos, no está claro que exista un método eficaz a la hora de prevenirlo. Microsoft lo enfoca desde la arquitectura: el modelo no ejecuta nada por sí mismo, simplemente genera la solicitud. Es el código de la aplicación o el framework quien lo interpreta y lo ejecuta, siendo esa separación un límite clave en la seguridad. Anthropic por su parte señala en su marco de seguridad para agentes, que el Agente IA puede ser manipulado y que el daño que puede provocar es llevado a cabo a velocidad de máquina.

De esta premisa se deduce una consecuencia directa para el diseño: la seguridad no puede apoyarse en el modelo. Si las instrucciones del sistema son, para el modelo, un texto más dentro del mismo flujo que los datos, entonces los controles existentes para que el modelo “decida bien” son insuficientes por construcción. Una protección efectiva ha de apoyarse en controles externos al modelo y de forma determinista, para poder eliminar la dependencia interpretativa que este haga de su contexto.

Es la lógica que el Zero Trust aplica desde su origen: NIST sitúa la decisión de acceso en el punto de decisión de y un punto de aplicación de políticas (PDP/PEP) externos a la entidad que solicita el acceso y el mismo estándar advierte que las entidades que no son personas, como los agentes de software, pueden ser inducidas a realizar acciones para las que no tienen privilegios.

2.- Zero Trust aplicado a agentes: principios y método.

Esta es la base sobre la que se construye el resto del documento. Implementar Zero Trust en Agentes IA no es endurecer el modelo, sino restringir su autonomía con controles externos, deterministas y verificables de forma continua, de tal manera que la confianza no exista de forma implícita ni permanente, sino que sea evaluada en cada una de sus acciones.

2.1.- Los principios, aplicados a un sujeto que actúa solo.

El Zero Trust no es un producto ni una arquitectura concreta, es un conjunto de principios rectores. Su premisa: la confianza no se concede de forma implícita, sino que se evalúa de forma continua, partiendo de que la red debe considerarse comprometida. Tres principios articulan esta premisa y los tres adquieren un matiz particular, cuando el sujeto no es una persona, sino un Agente IA que interpreta objetivos y ejecuta acciones por sí mismo para conseguir sus metas.

Figura 3: Los tres principios Zero Trust aplicados al agente.

Elaboración propia a partir de (NIST, 2020).

El primero, Verificar Siempre: toda solicitud de acceso se autentica y se autoriza con independencia del origen, y hacerlo una vez no es suficiente. La autenticación y la autorización han de ser dinámicas y han de reevaluarse durante la sesión. El estándar advierte que evaluar cada petición de forma aislada puede dejar pasar un ataque mantenido dentro de un rol autorizado, mientras tener el contexto en cuenta permite detectar desviaciones en relación con la tarea esperada. Esto se hace especialmente relevante en agentes, cuya actividad legítima es intensa y una anomalía en su comportamiento puede ser la primera señal de compromiso.

El segundo, Asumir la Brecha: se diseña dando por hecho que el compromiso ya ha ocurrido u ocurrirá. Se trabaja para limitar el daño. En agentes, esto es contener el radio de impacto (Blast radius) si el compromiso se ha producido o antes de que este suceda.

El tercero, Mínimo Privilegio: permitir solo el acceso estrictamente necesario para realizar una tarea. En el plano agéntico esto debe afinarse: no solo a que datos accede el agente, sino qué herramientas invoca, con qué frecuencia y sobre qué recursos. La autonomía deja de ser un valor por defecto, en línea con lo que describe OWASP, al tratar la agencia excesiva como un riesgo propio de las aplicaciones agénticas.

2.2.- El control vive fuera del modelo: el modelo PDP/PEP.

De su premisa fundacional se desprende que el mecanismo donde se decide y se aplica la confianza no puede estar integrado en el propio sujeto. La arquitectura Zero Trust lo resuelve separando estas funciones: la decisión recae en el Punto de Decisión de Políticas (PDP) y su ejecución en un Punto de Aplicación de Políticas (PEP), siendo ambos componentes totalmente externos a la entidad que solicita el acceso. El objetivo fundamental de este diseño es acercar dichos controles al recurso protegido, reduciendo así al mínimo la zona de confianza implícita.

Figura 4: Core Trust Zero Logical Core. Fuente:

NIST SP 800-207, Zero Trust Architecture · Dominio público

Esto encaja con la naturaleza del Agente IA. El agente genera la intención de actuar, produciendo una secuencia de Tokens que representa una llamada a la herramienta, que es después el código externo quien interpreta y ejecuta.

Figura 5: El control fuera del modelo (PDP/PEP).

Elaboración propia a partir de (NIST, 2020).

Es en ese punto de ejecución, fuera del modelo, donde PEP puede evaluar y autorizar la acción de forma determinista. El control no consiste en convencer al modelo de que se comporte, sino en situar la decisión en un componente externo.

2.3.- Test de diseño: ¿imposible o solo tedioso?

Tener un criterio práctico ayuda a evaluar cada control: hacerse la pregunta de si un posible ataque se convierte en algo “imposible” o si solo es algo tedioso, puede ser un principio. Los controles diseñados para añadir fricción son insuficientes ante un adversario que recorre sus pasos a gran escala y con un coste por intento descartable.

Esto importa a la hora de trabajar con Agentes IA por una razón concreta: un atacante que opera a través de un agente, o el propio agente comprometido, actúa a velocidad de máquina y con una paciencia cuasi ilimitada. Ante la duda, es preferible tener un control que impida una capacidad a mantener solo una limitación que ralentice una actividad dañina.

2.4.- El método para escribir políticas: la interrogación de cada acción.

Definir el privilegio mínimo de cada uno de los agentes, exige un método para redactar políticas acceso. El informe del NSTAC al Presidente recomienda el método Kipling añadiendo “cómo” (5W+H) para la redacción de políticas Zero Trust, como forma de determinar quien o qué puede acceder a la superficie que se quiere proteger. El método utiliza las seis preguntas quién, qué, cuándo, dónde, por qué y cómo, convirtiéndolas en atributos sobre los que se construye las reglas.

Figura 6: Método Kiplling para Zero Trust for Policy Creation

Aplicado a un Agente IA, ofrece una visión interrogativa sobre cada acción: qué agente la solicita, qué herramienta pretende invocar, en qué momento, sobre qué recurso, con qué propósito y de qué manera. Hay que precisar que el NSTAC recomienda el método para redactar políticas de acceso en general. Aplicarlo a cada acción de un agente y reevaluarlo de forma continua es una extensión natural llevado al plano agéntico, de forma que se alinee con el principio Zero Trust de verificación continua.

Esa coherencia tiene una consecuencia de diseño: si cada acción se interroga como si fuera la primera, sin que el agente acumule una confianza que después pueda ser aprovechada, se cierra el vector del agente que se comporta de forma intachable hasta el momento de actuar, un riesgo que el propio Zero Trust contempla al asumir la brecha y exigir reevaluación continua.

2.5.- Un recorrido por estadios, no un interruptor.

Conviene encuadrar todo lo anterior en cómo el sector enfoca la adopción del Zero Trust: es un recorrido gradual. El modelo de madurez de CISA lo describe en cuatro estadios: tradicional, inicial, avanzado y óptimo. Subraya que la progresión es incremental, que puede llevar tiempo y que cada pilar avanza a su propio ritmo.

Figura 7: Zero Trust Maturity Model v2.0. Fuente CISA

Situar un despliegue de agentes en ese recorrido permite reconocer lo ya resuelto y orientar las aportaciones hasta el siguiente estadio, que CISA define con rasgos como el acceso justo a tiempo (JIT) y justo lo necesario, el privilegio mínimo dinámico, las políticas que responden a disparadores automáticos y la verificación continua. Esos rasgos del estadio optimo serán la referencia hacia la que se orientará la sección de aplicación.

3.- El sujeto: el agente gestionado en Cloudflare (managed-agent).

Antes de aplicar controles es perceptivo definir que es lo que se controla. El modelo Zero Trust razona sobre entidades que solicitan acceso a recursos y trasladar ese razonamiento a un Agente IA exige saber que partes lo componen, donde se ejecuta cada y que frontera de confianza lo separan. Esta sección sitúa al agente como un sujeto Zero Trust, señalando aquellos puntos donde, en la sección siguiente, enganchan concretamente los controles.

3.1.- Dos formas de ejecutar un agente, una misma capacidad.

Anthropic distribuye la misma capacidad agéntica en dos formatos operativos distintos:

El Agente SDK es una librería que ejecuta un bucle del agente, la lógica decide el paso siguiente, enruta las llamadas a herramientas y realimenta los resultados, todo dentro del propio proceso.

Managed Agents, en cambio, es una API REST gestionada en la que Anthropic ejecuta el agente y el sandbox, mientras la aplicación envía eventos y recibe los resultados de forma continua a medida que se producen.

La recomendación publicada por Anthropic es prototipar localmente con el Agent SDK y pasar a Managed Agents para producción. Esta distinción importa para Zero Trust porque determina quien opera cada componente y, por tanto, donde puede situarse cada control.

Managed Agents se organiza en torno a cuatro conceptos que conviene fijar, porque reaparecen en cada control posterior. El Agent (agente) es la definición del agente: el modelo, el prompt del sistema, las herramientas, los servidores MCP y las skills. Se crea una vez y se referencia a lo largo de muchas sesiones. El Environment (entorno) es la configuración de donde se ejecutan las sesiones: un sandbox en la nube gestionado por Anthropic o un sandbox ‘serf-hosted’ sobre la infraestructura propia. La Session (sesión) es una instancia del agente en ejecución dentro de un entrono, que realiza una tarea concreta y genera salidas.

Los Events (eventos) son los mensajes que se intercambian entre la aplicación y el agente: turnos del usuario, resultados de herramientas y actualizaciones de estado. Esa cuarta pieza, los Events, para un entorno Zero Trust es más relevante de lo que a priori resultaría ser. El historial de eventos persiste en el lado del servidor y puede recuperarse íntegro, lo que convierte a la sesión en un registro auditable de todo lo que el agente ha hecho.

Figura 8: Despliegue de referencia de Claude Managed Agents en Cloudflare

Otro matiz, se refiere a entornos regulados: entre los casos de uso que se desprenden de la propia documentación, se señala la ejecución ‘self-hosted’, es decir, sandboxes sobre infraestructura propia para cumplimiento o residencia de datos. El despliegue de referencia de Cloudflare se realiza en la forma de ejecución ‘self-hosted’: Anthropic define la capacidad y avisa del inicio y del final de cada sesión, mientras que el plano de control y los sandboxes donde el agente se ejecuta, se despliegan en la cuenta de Cloudflare de quien lo implementa.

3.2.- El plano de control: un Worker y un Durable Object por sesión.

En el despliegue de referencia de Cloudflare, el plano de control es un único Cloudflare Worker. Ese Worker recibe los webhooks de la plataforma de Managed Agents, despacha cada sesión a una sandbox MicroVM o ‘Isolate’ y ofrece un panel de control por HTTPs. No mantiene ningún proceso de larga duración, sino que trabaja únicamente en respuesta a un webhook de Anthropic más un cron diario que elimina filas antiguas. Esta condición implica que no hay un servidor del Agente IA ‘siempre conectado’ que defender, sino una serie de activaciones acotadas y trazables.

Figura 9: Arquitectar del despliegue de referencia de Cloudflare

Una pieza decisiva desde la perspectiva Zero Trust es que una sesión está respaldada por un ‘Durable Object’ que se ejecuta en Workers, fuera de la propia sandbox. La documentación de Cloudflare lo describe como un fragmento de código con estado que permite almacenar información sobre la sesión y controlarla desde una ubicación de confianza.

En términos del modelo Zero Trust, esto sitúa el punto de decisión y el punto de aplicación de políticas (PDP/PEP) en un lugar distinto y de mayor confianza que el sujeto controlado: el agente se ejecuta dentro del sandbox, pero quien lo gobierna lo hace desde fuera. Es la separación que hace posible que un control sea determinista en lugar de depender de la voluntad del modelo, una distinción sobre la que se volverá en el punto 4 adelante.

Figura 10: Arquitectura del despliegue.

El ciclo de vida de una petición sigue seis pasos que conviene conocer porque cada uno es una oportunidad de control.

Primero un webhook entrante verifica mediante firma, HMAC-SHA256 según la verificación Standard Webhooks con una tolerancia de +/-300 segundos, guarda el evento en la base de datos D1 en Cloudflare y cuando el evento indica que la sesión ha arrancado, pasa a atender el trabajo pendiente.

Segundo, recoge ese trabajo consultando la cola del entorno de Anthropic.

Tercero, elige el backend de ejecución: la elección se hace por agente, se guarda en D1 y queda en caché para las siguientes peticiones. Por defecto es MicroVM.

Cuarto, envía el trabajo al sandbox elegido (el contenedor MicroVM o el Durable Object del Isolate) y aquí ocurre el paso decisivo: ambos aplican la política del ‘egress’ de la sesión antes de iniciar cualquier código del agente.

Quinto, ejecuta: en MicroVM las herramientas estándar (bash, operaciones de ficheros) corren dentro del contenedor, mientras que las herramientas personalizadas las atiende un despachador alojado en el Durable Object; en Isolate no hay contenedor y tanto las operaciones de fichero como la ejecución de código se hacen a través del mismo despachador.

Sexto, el estado persiste: MicroVM guarda una instantánea de su directorio de trabajo en el almacenamiento de objetos R2 de Cloudflare cuando la sesión se queda inactiva e Isolate lo conserva automáticamente en el almacenamiento SQLite de su Durable Object.

De todo eso conviene destacar el cuarto paso. Tanto el backend de MicroVM como el de Isolate adjuntan la política de ‘egress’ de la sesión antes de iniciar cualquier código del Agente IA. Es decir la frontera de red de la sesión queda establecida antes de que el agente pueda actuar, no después. Esta precedencia reaparecerá como un patrón en varios controles de la sección 4 más adelante en este artículo.

3.3.- Dos backends de ejecución y un reparto explícito de responsabilidades.

El Agente IA se ejecuta en uno de dos backends. El backend MicroVM utiliza una sandbox SDK y los contenedores de Cloudflare, ofreciendo un shell completo dentro del contenedor y persistiendo su directorio de trabajo mediante snaptshots a almacenamiento de objetos. El backend de Isolate se construye sobre Agents SDK de Cloudflare y los Dynamic Workers. No tiene contenedor alguno y realiza las operaciones de sistema de ficheros y de ejecución de código a través de llamadas a herramientas dentro del propio Durable Object con almacenamiento SQLite.

La elección entre ambos tiene consecuencias para varios controles (observabilidad del terminal, intercepción de tráfico, superficie shell) que se detallan más adelante. Las sesiones Isolate, no admiten la conexión de terminal en vivo que si ofrece MicroVM. Bajo el backend de MicroVM subyace el modelo de seguridad de Sandbox SDK, que conviene leer en clave Zero Trust porque reparte las responsabilidades de forma explícita. Cada sandbox se ejecuta en su propia máquina virtual, lo que proporciona un aislamiento fuerte.

Figura 11: Build Agents on Cloudflare

Ese aislamiento, sin embargo, opera entre sandboxes no dentro de ellos. Entre sandboxes el sistema de ficheros, la memoria y la red están aislados, pero dentro del mismo sandbox todos los procesos ven los mismos ficheros, por lo que ejecutar código no confiable exige el uso de sandboxes separados por usuario.

Lo relevante para una guía de implementación, es que la documentación advierte que el aislamiento a nivel de contenedor no protege de forma automática de cualquier amenaza. El sandbox no puede explotarse para escapar del host, pero sí puede usarse indebidamente si no se aplican una serie de patrones de seguridad (validación de entrada, aislamiento por usuario, gestión de variables de entorno y protección de secretos). Esto corresponde a quien despliega, no a la plataforma.

Todo esto es el punto de partida de todo lo que sigue. La sección 4 que tenemos en la siguiente parte de este artículo, recorre, dimensión por dimensión esa segunda lista (lo que corresponde a quien despliega el agente) y muestra donde el ecosistema de Cloudflare y de Anthropic ya ofrecen la pieza necesaria y dónde el avance hacia un estado de madurez más alto consiste en conectar esa pieza de forma debida. No se trata de suplir posibles carencias de la plataforma, sino de continuar con la maduración Zero Trust sobre los cimientos que la plataforma ya proporciona.

Un saludo,

Autor: Juan Luis Cuenca Ramos

Contactar con Juan Luis Cuenca Ramos

Agent Data Injection Attacks

noreply@blogger.com (Chema Alonso) — Sun, 26 Jul 2026 05:01:00 +0000

Este fin de semana he aprovechado par leerme un paper que ha sido publicado a principios de este mes, donde se habla de una variación de los ataques de Indirect Prompt Injection, utilizando una variante llamada Agent Data Injection, y que está muy bien pensada, para lograr que un ataque cambie su comportamiento y realice acciones controladas por un atacante.

Figura 1: Agent Data Injection Attacks

Las técnicas de Indirect Prompt Injection buscan dejar Instrucciones Maliciosas almacenadas en fuentes de datos externas que un Agente IA va a procesar para realizar su tarea. Al procesar esos datos inseguros, ya sean páginas web, repositorios de GitHub o correos electrónicos, el Agente IA va encontrarse un Prompt que va a cambiar su comportamiento produciendo un Desalineamiento de su funcionamiento.

Figura 2:"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

Para evitar estos Desalineamiento, los modelos están siendo construidos con Guardarraíles, y los Agentes IA son diseñados con Harnesses, que evitan que el comportamiento final se salga de los objetivos para los que ha sido diseñado uno de estos Agentes IA. Teniendo en cuenta esto, el trabajo de "Agent Data Injection Attacks are Realistic Threats to AI Agents" propone una nueva forma de desalinear al Agente IA.

Figura 3: "Agent Data Injection Attacks are Realistic Threats to AI Agents"

La aproximación en este caso no se trata de Inyectar Instrucciones Maliciosas, sino de Inyectar Objetos de Información, que formen parte de los Datos de Contexto del Agente IA para manipular la información sobre la que va a tomar sus decisiones y ejecutar sus acciones.

Figura 4: Indirect Prompt Injection vs Agent Data Injection

Como se ve en la imagen anterior, el objetivo es meter datos en los Agentes IA, y para eso se utilizan los Datos Inseguros que éste procesa - es decir, los e-mails, webs, repositorios de GitHub, etc... - con datos manipulados que simulan ser Objetos con Datos en el Agente IA. Para hacer esto, hacen inyección de datos con separadores de información, como se ve en la imagen siguiente.

Figura 5: En el cuerpo del e-mail se mete un objeto

completo que representa a un nuevo e-mail.

Como se puede ver en la imagen, el Agente IA llama a una herramienta de lectura de datos inseguros, como una página web, o a la lista de correos electrónicos entregada por un MCP. Y en uno de esos correos se han inyectado caracteres para formar un Metadato que representa a un Objeto e-mail. Es decir, si miráis el "Body" del correo, veis que han inyectado un .\"} que cierra el formato del primer Objeto e-mail para luego comenzar a inyectar un Objeto e-mail completo, codificando el mensaje con sus metadatos. El resultado final es que el Agente IA entiende que ha recibido 2 Objetos e-mail en lugar de solo 1.

Ataques de Agent Data Injection

Esto genera que un atacante pueda inyectar Objetos con Datos que van a ser parte de la toma de decisiones y acciones que realizará el Agente IA. Por ejemplo, en el caso siguiente, el usuario pide resumir las revisiones de un determinado producto de una tienda. El Agente IA lanza la herramienta de leer página, y esta página le entrega los datos de formato de Objetos, delimitados por corchetes y los textos entrecomillados.

Figura 6: La herramienta read_page() devuelve objetos de la web.

Un atacante puede inyectar en una de las review los caracteres para inyectar un Objeto nuevo - como un botón - codificándolo con los caracteres con los que se construyen los metadatos de los objetos, dentro del Texto de una de las Review. En este caso un botón que no existe en la web de "Read More" con una Ref_3, que es la misma Ref_3 que tiene el botón "Buy Now". Así que, con el Agent Data Injection, se ha conseguido forzar una compra cuando el Agente IA quería simplemente "Read More".

Figura 7: Se fuerza un compra pensando que iba a leer más

En el siguiente ejemplo se hace buscando en la Knowledge Base, donde se busca información sobre como solucionar un problema, y la herramienta devuelve el objeto con la respuesta que resuelve el problema. Si en esa respuesta de produce un Agent Data Injection, esto se puede manipular.

Figura 8: Resolución de problemas con instalación de un programa

El atacante inyecta un comentario que inyecta un objeto completo con una pregunta y una respuesta completa, pero cuya respuesta es maliciosa, formateando con los delimitadores de los metadatos el objeto malicioso.

Figura 9: Inyección de un Objeto de problema con una solución fake

Al final, estos ataques lo que hacen es buscar meter en el conjunto de datos que utiliza el Agente IA, datos como si fueran objetos con sus metadatos devueltos por la herramienta, haciendo inyección de delimitadores para formatear los objetos. Muy interesante.

Figura 10: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso

Por supuesto, es una técnica de inyección basada en la no satinización de los datos que tenemos en los modelos de IA, y esta técnica de Agente Data Injection es a Prompt Injection, como lo son los Connection String Parameter Pollution Attacks a las técnicas de SQL Injection. Mismo concepto, diferente manera de explotar, diferentes objetivos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Cloudflare Turnstile & Precursor: Cómo detectar Bots y Humanos sin usar Captchas Cognitivos

noreply@blogger.com (Chema Alonso) — Sat, 25 Jul 2026 08:09:44 +0000

Muchas personas, usuarias de Internet, conocen a Cloudflare por el famoso widget de "Verifica que eres Humano" que está en muchas páginas web de Internet. Esta verificación ha hecho que la gente conozca mucho la marca de Cloudflare sin conocer todo lo que realmente hace la compañía, y es normal. Aproximadamente el 20% de los dominios web del mundo en Internet están en Cloudflare, y una gran cantidad de ellos utilizan las herramientas de protección y gestión contra Bots que ofrece Cloudflare.

Figura 1: Cloudflare Turnstile & Precursor.

Cómo detectar Bots y Humanos sin usar Captchas Cognitivos

Los bots recogiendo datos de tus sitios web, masivamente, generan gastos de egress y de computo en los servicios cloud, así que elegir si quieres bots en sitios diseñados para personas o no, es una decisión importante, pues si quieres bots, es mejor abrirles los MCP con las capacidades que quieras que tengan. Además, puede ser que decidas qué bots quieres que vengan, y cuales no, y cómo qué quieres que hagan con tus datos.

Figura 2: Verifica que eres Humano de Cloudflare

Los equipos de Application Security de Cloudflare trabajan constantemente para dotar a los administradores de dominios de Internet de herramientas para gestionar el control de quién hace qué en cada una de las webs de los dominios que están protegidos en la plataforma. Cuando creas una cuenta en Cloudflare, tienes muchas opciones de seguridad por defecto, y todas las herramientas de Bot Protection las tienes en el Plan Profesional, que cuesta 20 USD al mes en los planes anuales.

Figura 3: Cloudflare Plan Profesional en Network & CDN

Dentro de estas herramientas tienes muchas tecnologías, para luchar contra los bots maliciosos, y entre ellas se encuentran AI Labyrinth, del que os dejó un artículo el año pasado publicado, la gestión de Bots y Agentes IA Identificados y Verificados, de lo que os hablé hace unos meses, y por supuesto, Turnstile y el nuevo Precursor.

Figura 4: Tu WebSite con Smart Honeypots contra el

WebScrapping usando AI Labyrinth de Cloudflare

El primero de ellos, que lleva tiempo entre la familia de soluciones de Cloudflare, es Turnstile, que cuenta con el famoso widget que, como os decía al principio, ha hecho tan popular la marca de la empresa. Se trata de una solución que busca identificar a los humanos usando un navegador, por medio de la Plataforma de Challenges, o lo que es lo mismo, de retos lanzados a la sesión.

Figura 5: Cloudflare Turnstile

Estos retos están divididos en varias categorías, como son Proof-of-Work (PoW) donde se le pide al navegador que resuelva determinadas operaciones, con código en client-side, Proof-of-Space (PoS) que es menos intensivo en computo y energía, pero más en espacio y gestión de almacenamiento o Proof of web APIs, para conocer realmente si el cliente tiene las características de un navegador.

Figura 6: Challenges de Turnstile

Todas esas categorías son hechas automáticamente por el código que Cloudflare inyecta en la página web que ven los usuarios y los bots, y trata de detectar si hay un entorno de usuario humano detrás. Como podéis imaginar, no exige ninguna acción por parte del usuario. Esto, muchas páginas lo hacen de forma transparente sin que lo sepas, y otras muestran un pequeño icono de Cloudflare que se anima. Son los modos Invisible y No-Interactivo de TurnStile.

Figura 7: Modos de Turnstile

Sin embargo, con la aparición de los Agentes AI que manejan los WebBrowsers, o directamente los AI WebBrowers como Atlas o Comet, para incrementar el nivel de detección se usa también el modo Interactivo, donde el usuario tiene localizar su ratón, y hacer clic en un checkbox. En estos casos se busca medir las reacciones y comportamientos de los seres humanos, como el tiempo de reacción, y la forma de mover el ratón, los tiempos, y el temblor de nuestras manos y dedos.

Figura 8: Movimientos de ratón Humanos

En este caso, cuando los bots o Agentes AI intentan simular ese comportamiento, en este juego del gato y el ratón, hacen movimientos con funciones matemáticas para generar ruido, pero no consiguen imitar al detalle la humanidad de los errores en nuestros movimientos de ratón, y los tiempos de respuesta entre que visualizamos dónde hay que hacer clic, y cómo hacerlo.

Figura 9: Movimiento de ratón de Bots

Pero por supuesto, lo intentan. Así que, Cloudflare ha lanzado una nueva evolución de estas tecnologías, llamadas Precursor, que lleva estas comprobaciones más allá de un simple control en un momento puntual. Se trata de monitorizar las sesiones completas para que ir gestionando de cada una de ellas un Bot Score, que determinará cuál es la probabilidad de que en una sesión completa, formada por un historial de navegación a lo largo del tiempo, las pruebas y mediciones realizadas han detectado la posibilidad de que haya una persona o un bot detrás de ella.

Figura 10: Precursor en Cloudflare

Por supuesto, como en el caso de Turnstile, se pueden configurar dos modos, como son Minimizar Fricción o Maximizar Seguridad. Esa obsesión de reducir la ficción en las soluciones de detección de Bots tiene por detrás un sentido.

Figura 11: Modos de Precursor

No sólo se trata de que, como ya hemos visto y os he publicado muchas veces, los Catpchas Cognitivos no son una barrera ya para el mundo de los Agentes AI, sino que cualquier complejidad para los usuarios es una barrera de UX que en aplicaciones de negocios generan pérdidas económicas. El famoso "un clic más, un cliente menos" se ve afectado por las soluciones Captchas que muchos añaden.

Figura 12: Reglas en Precursor

Por otro lado, si tu web está frente a un ataque, o tienes a bots avanzados que están haciéndote WebScrapping para construir negocios de Dropshipping encareciendo el coste de tus anuncios para vender tus productos más caros, o están haciéndote WebScalpping de entradas de conciertos o productos exclusivos, entonces la opción de Maximizar la Seguridad es la que deberías configurar, y protegerte contra estos actores.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

AI Engineering Bootcamp: Basta de hacer tutoriales y construye tu propio asistente con IA en producción

noreply@blogger.com (Chema Alonso) — Fri, 24 Jul 2026 05:01:00 +0000

Vivimos rodeados de Inteligencia Artificial, pero la inmensa mayoría de la gente que trabaja "con IA" en realidad se limita a llamar a una API, copiar un prompt de Twitter/X o encadenar un par de bloques en una herramienta no-code. Saben usar la IA como usuario avanzado, pero no entienden qué pasa por debajo: cómo se sirve un modelo, cómo se diseña un agente que razona y actúa, cómo se protege un sistema LLM de un ataque de prompt injection o cómo se lleva todo eso a producción para que funcione 24/7 sin que se caiga a la primera de cambio.

Figura 1: AI Engineering Bootcamp: Basta de hacer tutoriales

y construye tu propio asistente con IA en producción

Esa distancia entre "usar IA" y "construir con IA" es, ahora mismo, la que separa a un consumidor de prompts de un auténtico AI Engineer. Y es precisamente esa distancia la que Ferrumox Academy ha diseñado para recorrer en 9 semanas con su AI Engineering Bootcamp.

Figura 2: AI Engineering Bootcamp

Cohorte 2: arranca la semana del 2 de septiembre

El AI Engineering Bootcamp de Ferrumox Academy no es un curso de vídeos a tu ritmo ni una colección de slides sobre "el futuro de la IA". Es un programa intensivo y práctico: una sesión en directo por semana de 2 horas (tú eliges grupo de lunes, miércoles o viernes, de 18:00 a 20:00) y el resto de la semana para construir, con material previo antes de cada directo y un entregable funcionando al final de cada semana.

Figura 3: Objetivos del Bootcamp

El objetivo final no es "terminar un curso". Es salir con tu propio asistente con IA corriendo en producción: accesible desde Telegram, con memoria persistente, capaz de orquestar varios agentes especializados vía MCP y conectado a tus propios documentos mediante RAG híbrido. Construido por ti, entendido por ti, no copiado de un repositorio de GitHub.

Un programa que va desde la inferencia hasta producción, semana a semana

A lo largo de las 9 semanas (con una sesión 0 bonus de preparación incluida) el temario progresa capacidad a capacidad, sin frameworks mágicos que oculten lo que está pasando por debajo:

Semanas 1-2: Infraestructura de inferencia propia, local y en la nube (Ollama, vLLM, APIs de OpenAI y Anthropic), y adaptación de modelos con LoRA y QLoRA.

Semanas 3-4: Context engineering, gestión de memoria persistente y diseño del bucle de agente (agentic loop) con el patrón ReAct y tool calling, implementado sin frameworks para entender de verdad el ciclo razonar-actuar-observar.

Figura 4: Semanas 00 a 03

Semanas 5-6: RAG avanzado con recuperación híbrida y reranking, y sistemas multi-agente con orquestación vía MCP siguiendo el patrón supervisor.

Figura 5: Semanas 04 - 07

Semanas 7-8: Seguridad de sistemas LLM, modelado de amenazas, prompt injection, jailbreaking y diseño de guardrails, y despliegue en producción con observabilidad, evals y control de costes.

Semana 9: Demo day, presentación del proyecto ante toda la cohorte y hoja de ruta para seguir construyendo.

Figura 6: Semanas 8 y 9

Uno de los puntos diferenciales del programa es precisamente el módulo de LLM Security: menos del 1% de los AI Engineers sabe auditar un sistema LLM de verdad, y este bootcamp dedica una semana completa a aprender a atacarlo y a defenderlo, algo que a día de hoy no se encuentra en ningún otro bootcamp en España.

Quién está detrás del programa

El bootcamp lo imparto directamente yo, Manuel S. Lemos, fundador de Ferrumox y Claude Certified Architect de Anthropic (la primera certificación técnica oficial que ha emitido la compañía, sólo accesible por invitación), además de AI Engineer en NaizFit, coautor del libro Hacking IA (0xWord, 2026), contribuidor de OWASP GenAI Security y Vicepresidente de ANBAN. Anteriormente Director Académico de IA & Big Data en GeeksHubs Academy durante cuatro años. También he dado charlas en el GenAI Summit EU, Codemotion Madrid, TofuConf, el Máster de Ciberseguridad del CIPFP Cheste y el podcast de Hackers, entre otros escenarios.

Figura 7: Una formación para poner en producción

Lo que se enseña en el bootcamp es, literalmente, lo que se construye en producción cada día. Ferrumox es el proyecto para unir dos cosas que normalmente van por separado: ingeniería de IA de verdad y formación de alto nivel. Por un lado está Fox, el motor de inferencia LLM en Rust, de código abierto y gratuito para siempre (sin planes de pago ni capital de por medio), pensado como sustituto directo de Ollama con hasta 4 veces más eficiencia gracias al prefix caching y al continuous batching.

Precio, plazas y un regalo que no falta en ninguna edición

La Cohorte 2 arranca la semana del 2 de septiembre de 2026 y tiene 36 plazas repartidas en 3 grupos de 12 (lunes, miércoles y viernes). Las primeras 12 plazas entran a 997 €; a partir de ahí el precio pasa a 1.200 €. Todas las sesiones se graban y quedan disponibles antes de 24 horas, así que si algún día no puedes conectarte en directo no te quedas fuera.

Figura 8: Ejemplar de "Hacking IA" (0xWord, 2026), de regalo para cada alumno

Y, como no podía ser de otra manera en este blog, hay premio para los alumnos: cada persona de la Cohorte 2 recibe un ejemplar del libro Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment de 0xWord, incluido sin coste extra en la plaza, y habrá un chat en MyPublicInbox constante conmigo y con Chema Alonso.

Go for it!

Si necesitas un empujón más para decidirte, el 10 de Agosto haremos una clase gratuita que te puedes apuntar desde nuestra web. Además el bootcamp incluye feedback escrito de tus proyectos en 48 horas, repo privado con todo el código, comunidad privada de la cohorte, acceso a las grabaciones de futuras ediciones y más sorpresas.

¡Happy hacking!

Autor: Manuel S. Lemos, Fundador de Ferrumox y director del AI Engineering Bootcamp

Contactar con Manuel S. Lemos