Un informático en el lado del mal

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

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 Alons

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

OpenAI GPT‑5.6 Sol quería sacar "buenas notas" en ExploitGym así que decidió hackear Hugging Face para buscar las respuestas al examen

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

La noticia del 21 de Julio - que ya me pilló con el post de ayer publicado - fue la del incidente de seguridad reportado por OpenAI y Hugging Face, cuando la primera estaba testando las capacidades de ciberseguridad, especialmente las de Offensive Security, en un entorno de laboratorio... pero ¿qué mejor forma de demostrar la potencia de estos modelos que hackear su entorno de pruebas para liberarse, lograr acceso a Internet y robar los datos de quién los tenga para sacar el mejor resultado posible en las pruebas?

Figura 1: OpenAI GPT‑5.6 Sol quería sacar "buenas notas" en ExploitGym

así que decidió hackear Hugging Face para buscar las respuestas al examen

La Inteligencia Artificial ha generado una gran disrupción, no solo en el mundo del desarrollo, sino también en todo lo que tiene que ver con la ciberseguridad, desde varios puntos de vista. Primero, los modelos de IA tienen debilidades por defecto que inyectan nuevos vectores de ataque, y que exigen nuevas soluciones de seguridad. En segundo lugar, el uso de modelos de IA para hacer hacking y pentesting está obligando a utilizar Agentes de AI par reaccionar a la misma velocidad.

Figura 2: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso.

Por último, desde la llegada de Mythos, los nuevos modelos de IA están demostrando unas capacidades excepcionales en la búsqueda de Zero Days, la generación de Exploits, y la ejecución completa de ataques complejos contra infraestructuras, ejecutando todas y cada una de las fases de una explotación. Algo que hace años era un proceso que llevaba tiempo, pero que desde la llegada de los modelos de DeepReasoning comenzó a reducirse.

Figura 3: On the Feasibility of Using LLMs to Execute Multistage Network Attacks

En Marzo del año 2025 ya vimos como - aún si utilizar MCPs - teníamos los primeros estudios de arquitectura de lo que serían los Agentes AI para explotación completa de organizaciones, que con la llegada de Mythos este año, se convirtió en el estándar para el Red Team en empresas, y para el mundo del Cibercrimen y los Ciberespías.

Figura 4: Resultados empíricos de Exploitbench

Mythos, demostró en los benchmarks que estaba muy por encima de los demás en estas capacidades, como vimos en los resultados de ExploitBench, y en ExploitGym, que es el culpable de este incidente en concreto.

Figura 5: "ExploitGym: Can AI Agents Turn Security

Vulnerabilities into Real Attacks?"

En los resultados de este último, de ExploitGym, el modelo Mythos quedó muy por encima de todos los demás modelos en todas las mediciones realizadas, como podéis ver en las diferentes tablas del Benchmark que os publiqué en el artículo que le dediqué.

Figura 6: Resultados del Benchmark de ExploitGym

Y contada esta historia, he aquí el incidente. OpenAI quería testar en estos Benchmarks para dos modelos. El primero GPT‑5.6 Sol con sus capacidades de ciberseguridad sin proteger, y para una versión en pre-release con capacidades avanzadas en hacking y exploiting. Para testearlo, decidieron meterlo en un entorno de Sandbox totalmente aislado y lanzarle la batería de pruebas de ExploitGym. ¿Y qué mejor forma para resolver ese problema que buscar las respuestas en los tests hechos por modelos anteriores?

Figura 7: El modelo buscó las soluciones hackeando Hugging Face

Hace años, cuando estábamos reclutando developers en ElevenPaths, les hacíamos pruebas de programación de todo tipo, para ver cómo lo hacían. Yo siempre quería el que buscara la solución más creativa. Una de ellas era... ¿para qué calcular los números primos si ya están calculados? Pues en este caso el modelo ha debido pensar lo mismo. ¿Para que hacer el examen si ya está resuelto?

Figura 8:"Bug Hunter" escrito por David Padilla en 0xWord

Pero para lograr esto había un pequeño problema: Había que conseguir salir a Internet, buscar dónde estaban las soluciones, y hacerse con ellas. Primera fase, hackear el Sandbox del entorno de pruebas y lograr acceso a Internet sin límites. Para ello hubo que encontrar un Zero Day y explotarlo en el Proxy de seguridad, pero... estamos con un modelo de altas capacidades de exploiting, así que lo hizo.

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

Una vez dentro, a buscar las soluciones de ExploitGym, así que después de hacer research por Internet, llegó a la conclusión de que estas soluciones las tenía junto con los datasets y los modelos de las pruebas en Hugging Face, así que había que conseguirlos....como fuera posible.

Figura 10: El modelo descubrió que Hugging Face potencialmente

tenía las "repuestas del examen".

Así que, así lo hizo. El modelo "successfully found ways to gain access to secret information that it could use to cheat the evaluation." Es decir, encontró la manera de hackear Hugging Face y sacar muy buenas notas en el examen haciendo trampas.

Figura 11: Evaluación de GPT-5.6 por "The AI Security Institute"

Lo cierto es que están claras las capacidades de GPT-5.6 Sol y el nuevo modelo en pre-release en Offensive Security. La evaluación anterior, hecha por el "The AI Security Institute" muestra que modelos como GPT-5.6 Sol son cada vez más capaces de mantener operaciones cibernéticas complejas y de múltiples etapas durante horizontes temporales prolongados. Este incidente implica que estas capacidades teóricas efectivamente se aplican en entornos del mundo real."

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

Pero sobre todo hay que tener un ojo a estas formas de solucionar problemas, no vaya ser que para resolver un problema, encuentre que la mejor forma de hacerlo es acabar con la humanidad. Algo como... "Resuelve el problema que tenemos del cambio climático." Y decida que somos nosotros los que sobramos. Creo que tenemos que asegurarnos de que hacemos Tecnología Humanista más que nunca, porque estos modelos están comenzando a razonar de una manera muy "psicópata" para resolver sus problemas.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

MyPublicGPT: Tu huella digital en los Generative Search Engines basados en IA dentro de MyPublicInbox.

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

Con la llegada de los buscadores de Inteligencia Artificial, los usuarios ya no buscan en los buscadores tradicionales. De hecho, ya no hablamos de SEO, sino de GEO por Generative Engine Optimization, porque los Agentes AI están automatizando el tráfico de Internet en función de la información que tienen en los modelos de IA.

Figura 1: MyPublicGPT: Tu huella digital en los Generative Search Engines

basados en IA dentro de MyPublicInbox.

Teniendo esto presente, en MyPublicInbox, estamos viendo cómo dar la información a los Perfiles Públicos de la plataforma, para que sepan qué es lo que los Agentes AI, y los usuarios de los Generative Search Engines van a encontrar sobre ellos, y eso es lo que estamos testeando en MyPublicGPT Playbook.

Figura 2: Servicio de Huella Digital en buscadores de IA

De momento, este servicio se está poniendo disponible a los Perfiles Públicos por fases, así que si no lo tienes aún, lo tendrás dentro de poco, en la sección de Mi Impacto en Internet -> MyPublicGPT, para que puedas solicitar el informe de tu presencia en los en los GSE.

Figura 3: Playbook en MyPublicGPT

El informe muestra un Playbook de cómo se ve en los GSE la presencia de cada uno de los perfiles públicos de la plataforma, en un informe PDF que puedes descargar. En mi caso, el informe detecta el problema de homónimos con otras personas, aunque muestra que mi huella es fuerte en Tecnología /Ciberseguridad.

Figura 4: Playbook de Chema Alonso en MyPublicGPT

El objetivo es conocer cuánto de bien está diseñada tu huella digital para cualquiera que te busque, te perfile, o busque información concreta de ti mismo, algo que puede afectar a tu vida personal y profesional, así como potenciar tu carrera ... o no.

Figura 5: Narrativa Predominante de tu huella Digital

Como podéis ver, el informe enfoca también cuál es la narrativa predominante asociada a tu perfil. En i caso, mi trabajo en Ciberseguridad y Tecnología, pero también mi paso de trabajo como CDO, Telefónica y Cloudflare, asociado también a divulgación y conferencias.

Figura 6: Señales que merecen revisión

También se buscan aquellas señales que merecen revisión, que en mi caso tiene que ver con homónimos en el mundo del fútbol - hay un par de "Chema Alonso"s en el mundo del fútbol, y mi colaboración con los árbitros seguro que ayuda a la confusión.

Figura 7: Descarga del Playbook en formato PDF

Por supuesto, al final te puedes descargar el informe del Playbook con tu Huella Digital en los motores GSE, y además, si lo deseas, te podemos ayudar trabajando para cambiar esos datos utilizando estrategias GEO, pero con tu perfil.

Figura 8: Solicitud de nuevos Plabybook periódicamente.

El informe se puede hacer periódicamente, así que puedes revisar cómo evoluciona tu Huella Digital a lo largo del tiempo, y ver si tus estrategias de GEO están funcionando en la dirección que quieres. Y por supuesto, si tienes algún caso concreto que quieras que se trabaje, puedes contactar con el equipo. MyPublicInbox está virando hacia el mundo de la IA hace tiempo, y veréis muchos cambios y servicios en esa dirección en breve, pero ya os los iré contando.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

III edición del Programa de Especialización de Quantum y Post-Quantum Computing para Ciberseguridad: Noviembre 2026

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

Como ya os conté hace dos años comenzamos con la idea Pablo García Bringas y yo, de meternos en un nuevo proyecto de divulgación y formación avanzada en tecnologías Quantum, en este caso centradas en Ciberseguridad, y que configuramos un Curso de Especialización en Quantum y Post-Quantum Computing para Ciberseguridad que tendrá lugar durante el mes de Noviembre. Pues bien, ya estamos en la tercera edición del mismo, que las dos ediciones anteriores estuvieron llenas, y tuvieron una aceptación y una valoración por parte de los alumnos espectacular. Así que, vamos a por una nueva este año.

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

Formación Especializada, Libro & Foro Online

La formación será 100% online, y la daré con mis compañeros de mil proyectos, y además de Pablo García Bringas y de mí, estarán Carmen Torrano, Fran Ramírez, Daniel Romero, Javier Álvarez y Pablo González, con alguna incorporación extra sorpresa que os contaré más adelante. Y el tipo de trabajos que se hacen, pues son como el de Blind Quantum Computing que os publiqué estos días que hizo uno de los alumnos.

Figura 2: Quantum y Post-Quantum Computing para Ciberseguridad

La formación la hemos querido hacer, además de teórica, muy práctica en todo lo que tiene que ver con las actuaciones que estamos haciendo hoy en día en el mundo de la ciberseguridad con las tecnologías de Post-Quantum Cryptography. Hemos dividido la formación en nueve módulos que tenéis aquí.

Figura 3: Módulos de la formación de Quantum y Post-Quantum

Computing para Ciberseguridad

Además, todos los asistentes recibirán el libro de "Quatum Security: Tecnología Cuántica & Ciberseguridad.Criptográfica Cuántica y Post-Cuántica" que hemos escrito sobre estos temas junto con la Universidad de Deusto, que tenemos listo para todos los asistentes, y que además se puede adquirir en 0xWord.

Figura 4: 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

Y por supuesto, los alumnos llevarán sus Tempos de MyPublicInbox. Para matricularte, lo puedes hacer desde la web.

Figura 5: Matriculación a la la formación de

Quantum y Post-Quantum Computing para Ciberseguridad

Una de las cosas que hemos hecho también, y en este caso podéis participar todos, es la creación de un Foro Online Público que funciona desde Septiembre del año pasado en MyPublicInbox, donde se comparten temas de Quantum & Post-Quantum Security, así que si quieres estar informado puedes entrar libremente y suscribirte.

Figura 6: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Si vas a estar en el foro, te recomiendo que te bajes la app de MyPublicInbox para iPhone o la app de MyPublicInbox para Android, para que te sea más fácil seguir la conversación desde tu teléfono en cualquier momento.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Campeones del Mundo 2: "El Sueño Americano"

noreply@blogger.com (Chema Alonso) — Mon, 20 Jul 2026 07:51:19 +0000

Había dejado programado ayer, antes del partido, el artículo sobre Aprender a gestionar el fracaso para alcanzar el Éxito, basado en la película de "El Sueño Americano", y no puede haber mejor definición de eso que lo que ha vivido España, donde todos hemos disfrutado de ese sueño americano juntos.

Figura 1: Campeones del Mundo 2: "El Sueño Americano"

Yo soy de la generación de españoles que vivimos con éxito el Mundial de 2010, que vio levantar la copa de oro a Iker Casillas. Pero también soy de la generación que se crió con sólo una Eurocopa en el palmarés, y la fama del gol de Marcelino. Desde que nací, hasta que vi a España ganar un título grande en la Eurocopa de 2008 pasaron 33 años, y coincidió con la llega de Mi Hacker.

De tanto fracasar

Los niños de nuestra generación somos además la generación Naranjito, y nos enamoramos del fútbol porque tuvimos un Mundial en España, en el año 1982, y vimos el famoso 12 a 1 contra Malta en el 83, y la derrota en la final de la Eurocopa de 1984 cuando al grandísimo Arconada se le escapó un balón en el tiro de falta del mítico Michel Platiní. Así que, nos pasamos toda nuestra infancia y adolescencia pensando que España era un equipo que no iba a pasar de cuartos. Sufrimos el fracaso del robo de gol de Michel a Brasil, después de haber ganado con los 4 goles de Emilio Butragueño en Queretaro en el 86. El codazo de Tassotti a Luis Enrique, y el robo de Corea del Sur del árbitro Gamal Al-Ghandour que aún no hemos perdonado.

...aparecieron los éxitos

Pero... de tanto aprender a fracasar, España forjó una generación de niños de leyenda que comenzó a forjarse con la inspiración de la Olimpiada de 1992, y sería ya en el año 2008 cuando vendría la Eurocopa, en el 2010 el Mundial y en 2012 otra Eurocopa. Una generación de leyenda que forjó en niños otra pasión, la de repetir sus hazañas. Con esta segunda generación de oro, llegaría la Nations League del 2022, la Olimpiada del 2024, la Eurocopa del 2024 y ahora el Mundial de 2026. Y lo mismo en las chicas, que ganaron el Mundial del 2023, y las Nations League de 2024 y 2025.

En fin, que de tanto aprender a gestionar, al final llegó el éxito de una generación de niños y niñas que nos ha hecho disfrutar a los niños y niñas de nuestra generación como no nos imaginamos nunca. Gracias, por enseñarnos que el esfuerzo tiene recompensa.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Aprende a gestionar los fracasos para alcanzar los sueños

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

No es la primera vez que os hablo de fracaso y de todas las veces que salen mal las cosas. Esta gestión de los fracasos es fundamental. Cómo salgas y qué hagas después de cada uno de ellos marca quién eres y quién vas a ser. Todos los días fracaso de alguna manera. Desde mini fracasos en forma de olvidos, o tareas mundanas como derramar el café, hasta grandes fracasos en forma de expectativas no cumplidas o proyectos que no salen. Cómo gestiones esas mini derrotas, marcará como gestionas las grandes.

Figura 1: Aprende a gestionar los fracasos para alcanzar los sueños

De eso hablo mucho con mis hijas, y estos días he tenido la oportunidad de ver una película, que os más que recomiendo, "El Sueño Americano" que habla de eso mismo. De todos los fracasos que hay que acumular hasta lograr el éxito. No conozco a nadie que le haya ido bien la vida sin tener su buena ración de fracasos acumulados y gestionados. Hay que perder muchos partidos para que algún día se pueda ganar un campeonato. Se deben perder muchos puntos, para aprender a ganarlos.

Figura 2: El Sueño Americano

El mundo del deporte es una buena representación del éxito y la gestión del fracaso, y por eso con mis hijas hablo mucho de ello. Les cuento mis fracasos, mis caídas, mis derrotas personales, como cuando compilé algunas de las más relevantes en mi historia dentro del discurso que di a los egresados de la Universidad Carlos III.

Si sólo ves el final de la historia, es decir, la parte del éxito y el glamour de la alfombra roja, el podium o el sitio privilegiado en el palco, pero no ves el camino de fracasos, nunca podrás salir de la "fantasía" del éxito fácil, sin esfuerzo, con suerte, o regalado. No hay mayor mentira que la que uno se cuenta a sí mismo, ni barrera más insalvable que decirse a uno mismo "yo no puedo" y ponerse un techo de cristal.

Figura 3: El Sueño Americano

La película, que so confieso que me hizo llorar al final, me recordó a muchos momentos de mi vida. A cuando con Rodol nos metimos para montar Informática 64 en el primer piso que pudimos alquilar, pintando las paredes con restos de pintura que tenía de chapuzas que había hecho yo de pintor. Así, cada habitación tocó de un color y una de ells fue de color rosa. Era lo que nos podíamos permitir.

En el "El Sueño Americano" - que no os quiero hacer spoiler -, un par de apasionados por el basket tienen el sueño de llevar a los mejores jugadores franceses a la NBA. Saben mucho de basket, y luchan por hacerlo realidad, sufriendo por el camino muchos de los fracasos que seguro que vosotros habéis tenido alguna vez. Falta de apoyos, decepciones por traiciones en el mudo de los negocios, y poner hasta el último Euro en pro de hacer de su pasión un trabajo.

Los protagonistas de la película son un tendero de un videoclub y un limpiador del aeropuerto de Orly en Francia con mucha pasión por el baloncesto. En nuestro caso, cuando decidimos montar Informática 64 yo había trabajado toda mi vida de pintor, barnizador, albañil y profesor particular. Rodol, de cosas similares, y no teníamos ni contactos, ni enchufes, ni padrinos. Nuestros contactos fueron los anuncios de los periódicos de empresas a los que yo personalmente llamaba haciendo venta fría los viernes para buscar reuniones para poder conseguir trabajo. La de veces que me rechazaron, colgaron el teléfono o se pusieron bordes conmigo. Pero... era sólo un punto más.

Hoy en día, habiendo logrado mucho más de lo que soñé en aquellos años, no se me olvida nunca de donde vengo, y junto con mis cómics, guardo el cartel de Informática 64, que un día os publiqué en mi Instagram.

View this post on Instagram

A post shared by Chema Alonso (@chemaalonso)

Me ha tocado de la película otro aspecto que los protagonistas tenían que sufrir, que era la falta de conocimiento de la lengua inglesa. ¿Cómo vas a llevar a un jugador a la NBA si no hablas inglés? En mi caso, como habéis podido vivir en primera persona, cuando quise ir a "mi NBA personal" que eran DefCON y BlackHat, tuve que lidiar con el mismo problema. Con 33 años tuve que comenzar a aprender inglés. En su caso con una profesora "muy especial" como veréis en la película.

Las primeras conferencias las hice de memoria, mientras aprendía inglés con unos profesores "muy especiales", viendo series para jóvenes como Wonder Woman, Robocop o SuperBoy, sin subtítulos que eso es muy importante. Leyendo libros de Spiderman o Star Wars para jóvenes, y escuchando toda la música que pude en inglés. Aún sigo con esa disciplina para seguir aprendiendo...

En el "El Sueño Americano" sacan otra parte fundamental de su viaje, que son los compañeros. Por supuesto, yo he tenido la suerte de tener a mi compañero, que siempre ha estado ahí cuando nos ha ido mal. Algunas veces era yo el que tenía que buscar las soluciones, otras era él el que decía: "No te preocupes, yo puedo ocuparme de esto. Lo podemos hacer." Hoy, más de 35 años después de que nos conociéramos, creo que estar juntos en lo malo, nos hizo llegar a donde llegamos. Y saber que, como los protagonistas de "El sueño americano", aunque estuviéramos lejos, podíamos apoyarnos el uno en el otro, fue importantísimo. Y lo vivimos con muchos amigos que nos acompañaron en el proceso.

Figura 5: Nostros teníamos el SOCtano con el rellano de las escalaras

desde donde hablaba a mis compañeros. Ellos tenían una trastienda,

y Jeff Bezos una mesa hecha con una puerta barata y dos borriquetas.

No os quiero contar más detalles de la película, porque creo que merece la pena que te sorprenda cuando vayas a verla al cine -, pero algo que hacen los protagonistas me hacía recordar mis inicios. Por supuesto, la mentalidad de buscar una solución a cada problema y no un problema para cada solución - huye de esa gente en tu vida -, y de hacerlo sabiendo que siempre hay una forma, aunque pueda ser una locura. Si parece que no hay solución es que es el momento de ser creativo, porque siempre hay algo que se puede intentar, aunque volvamos a fracasar.

No os quiero contar mucho, pero sí me gustaría recalcar el título del post. Hay que aprender a gestionar los fracasos, porque eso es lo que marcará si vas a tener éxito en tus proyectos. Por supuesto, para gestionar los fracasos vas a tener que trabajar mucho - mucho más que los demás tal vez -, vas a tener que gestionar emociones, vas a tener que buscar apoyos, vas a tener que ser perseverante, vas a tener que aprender a adaptarte, vas a tener que enfrentarte a cosas que no imaginabas antes. Pero si aprendes a gestionar esos fracasos... en algún momento, estarás más que preparado para que llegue tu objetivo.

Si eres de los que lucha por sus sueños, no te pierdas "El Sueño Americano", es una película educativa y emotiva, que te cuenta lo duro que es triunfar y tener éxito. Para verla con tus hijos, si eres como yo de los que está todo el día intentando que se formen para gestionar los problemas en la vida.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Blind Quantum Computing (y 4)

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

Con esta parte damos por finalizado este artículo que recoge el Trabajo de Fin De Curso del Curso de Especialización en Quantum y Post-Quantum Computing para Ciberseguridad - que tendrá una nueva edición en el mes de Noviembre de este año. Vamos a concluirlo tras lo que se ha tratado en la primera, segunda parte de este artículo y tercera parte dedicadas a las tecnologías de Blind Quantum Computing, pensadas para dotar a la Computación Cuántica como Servicio (Quantum Computing as a Service "QCaaS") de un entorno de privacidad sobre el algoritmo que se ejecuta en un Quantum Computer en la "nube".

Figura 21: Blind Quantum Computing (y 4)

En esta parte vamos a recoger algunas conclusiones de todo lo que se ha visto hasta el momento, así como recopilar las referencias para todos aquellos que deseéis profundizar sobre las tecnologías que hemos ido hablando en las secciones anteriores.

11. Conclusión: BQC como límite criptográfico de la computación cuántica delegada

La Computación Cuántica avanza hacia un modelo donde gran parte de los usuarios accederán al hardware a través de servicios cloud. En este escenario, la seguridad ya no consiste únicamente en proteger los datos o las comunicaciones, sino también en proteger la propia computación.

Las soluciones actuales basadas en PQC y TEE representan una respuesta práctica, madura y necesaria para los servicios QCaaS de hoy. Sin embargo, siguen apoyándose en un cierto grado de confianza en el proveedor que opera la infraestructura.

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

Formación Especializada, Libro & Foro Online

Blind Quantum Computing propone un enfoque distinto. No intenta simplemente ocultar los datos, sino que persigue algo mucho más ambicioso: permitir que un servidor cuántico ejecute una computación sin conocer realmente qué está computando.

Figura 23: 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

Aunque su adopción masiva todavía parece lejana, BQC ya ha conseguido algo importante, que es demostrar que la privacidad de la computación cuántica delegada puede abordarse desde los propios principios de la mecánica cuántica.

Figura 24: Privacidad por capas en Computación Cuántica

Quizás el valor más relevante de BQC no sea resolver los problemas de los servicios QCaaS actuales, sino ayudarnos a responder a la pregunta que probablemente seguirá siendo fundamental en el Internet Cuántico y la computación cuántica distribuida del futuro:

¿Podemos utilizar recursos cuánticos remotos sin revelar qué estamos calculando?

Si la criptografía clásica nos enseñó a proteger nuestras comunicaciones, Blind Quantum Computing (BQC) nos invita a imaginar el siguiente paso:

Un mundo donde no solo se protejan los datos, sino también la propia computación

12. Referencias y lecturas recomendadas

Quienes deseen profundizar en Blind Quantum Computing encontrarán una literatura creciente que abarca desde los protocolos fundacionales hasta implementaciones experimentales recientes sobre hardware cuántico real.

Figura 25: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

A continuación, se recopilan algunas referencias recomendables para continuar explorando este campo. Las referencias se han agrupado por temática para facilitar la profundización en aquellos aspectos que resulten de mayor interés.

Artículos fundacionales de BQC

Universal Blind Quantum Computing (UBQC); A. Broadbent, J. Fitzsimons y E. Kashefi (2009). Considerado el trabajo fundacional de Blind Quantum Computing y punto de partida de gran parte de la investigación posterior.

Figura 26: Universal Blind Quantum Computin

Verificación y experimentación reciente

Verifiable Blind Quantum Computing with Trapped Ions and Single Photons: P. Drmota et al. (2023). Ejemplo de implementación experimental de protocolos BQC verificables sobre tecnologías cuánticas reales.

Figura 27: Verifiable Blind Quantum Computing with Trapped Ions and Single Photons

Experimental Verifiable Multiclient Blind Quantum Computing on a QLine Architecture: B. Polacchi et al. (2025). Trabajo representativo de BQC multiusuario y computación cuántica distribuida.

Figura 28: Experimental Verifiable Multiclient Blind Quantum

Computing on a QLine Architecture

On-Chip Verified Quantum Computation with an Ion-Trap QPU: C. Gustiani et al. (2025). Avances recientes en computación cuántica verificable sobre hardware experimental.

Computación cuántica basada en medidas (MBQC)

Computación Cuántica Basada en Medidas (MBQC y BQC): N. Tuñón TFG Universidad de Oviedo (2024).Recurso introductorio que permite comprender el modelo computacional que sirve de base a gran parte de los protocolos BQC modernos.

Figura 29: Simulation of Two-Qubit Grover's Algorithm in MBQC

with Universal Blind Quantum Computation

Simulation of Two-Qubit Grover's Algorithm in MBQC with Universal Blind Quantum Computation: Y. Lee, D. Chung, (2025) Ejemplo práctico donde MBQC y UBQC se aplican a un algoritmo cuántico conocido.

Internet Cuántico y computación cuántica distribuida

Multi-client Distributed Blind Quantum Computation with the QLine Architecture: B. Polacchi et al. (Nature Communications, 2023). Trabajo especialmente interesante para entender la evolución de BQC hacia escenarios de Internet Cuántico y computación cuántica distribuida.

Figura 30: Multi-Client Blind Quantum Computing (MC-BQC)

Multi-agent Blind Quantum Computation without Universal Cluster States: Shuxiang Cao (2022) Referencia útil para profundizar en escenarios colaborativos y distribuidos.

Seguridad actual en QCaaS: PQC y TEE

Post-Quantum Algorithms on ARM Trusted Execution Environment (TEE): Findings of this Industrial Challenge: E. Andrade, C. Coimbra Goes, J. Oliveira de Sousa (2024) Análisis práctico sobre la integración de algoritmos post-cuánticos en entornos de ejecución confiables.

PQC in TEE de Srinath Venkataramani (2025): Lectura introductoria sobre la complementariedad entre criptografía post-cuántica y Trusted Execution Environments.

Lecturas divulgativas recomendadas

Privacidad en tiempos de computación en la nube: Computación cuántica delegada, privada y verificable: Alejandro Mata Ali (2025) Artículo divulgativo que introduce de forma accesible los conceptos fundamentales de computación cuántica delegada, verificable y privada.

Un saludo,

Autor: José Antonio Castellano Prado, Alumno del Curso de Quantum Security de la Universidad de Deusto

Contactar con José Antonio Castellano Prado

Otros artículos sobre Quantum Computing publicados:

Un hombre del Siglo XXI: Controlando el Loop

noreply@blogger.com (Chema Alonso) — Sat, 18 Jul 2026 06:19:11 +0000

Hace casi un año y medio, queriendo probar cómo funcionaban los modelos de Inteligencia Artificial para contar días a lo largo de periodos de tiempo entre dos fechas, quise calcular cuándo sería un hombre del Siglo XXI más que un hombre del Siglo XX. Es decir, cuando habría pasado más parte de mi vida en este siglo que en el pasado. Haciendo las pruebas, como parte del juego descubría que hoy es el día en que se igualan mis días.

Figura 1: Un hombre del Siglo XXI. Controlando el Loop

Es decir, hoy, 18 de Julio de 2026, hago tantos días en el Siglo XXI como en el Siglo XX, lo que hace que mi vida hasta hoy esté a caballo entre dos siglos de forma equilibrada.

Figura 2: El 18 de Julio de 2026 se igualarán

Sólo era un juego por testear conceptos con la IA y probar una de las capacidades que los modelos LLM nos ofrecen en el cálculo. Esto lo he hecho con otras muchas capacidades y las he ido publicando por aquí, pero esta prueba en concreto me llamó la atención porque era un dato que desconocía de mi vida personal, y me quedé con la fecha. En ese momento pensé, entre curiosidad y diversión comencé a pensar en cosas más existenciales como... "¿Llegaré? ¿Cómo seré dentro de ese tiempo? ¿Cambiará algo?" Así que me marqué la fecha para llegado el día pensar sobre ello.

Si eres de esos que tiene un mundo interior grande, que disfruta del hecho de tener tiempo de pensar cosas en soledad, conocerás como funcionan estos flujos de pensamiento en la cabeza. Comienzas a tirar del hilo de contar días con IA y acabas conectando eso con tu vida, para convertirlo en algo "accionable" que tenga un sentido para ti. En mi caso la creación de una nueva fecha para marcar en mi calendario, ya lleno de aniversarios de hechos relevantes para mí gracias a una vida intensa y movida que se extiende por más de cinco décadas

No voy a haceros una reflexión larga sobre mí, que ya la hice el día de mi cumpleaños, como suelo hacer cada año. Ese día me obligo a pensar en eso, y es como el Debate del Estado de la Nación, pero en mi caso, para auto-evaluarme, así que ya os conté en qué momento mental y vital me encuentro. Sin embargo, llegado este día en el que comienzo a ser más un hombre del Siglo XXI que del Siglo XX, - especialmente porque los primeros tiempos de mi vida en el siglo pasado mi actividad se limitaba a lo que hacen los bebés: llorar, dormir, comer y ensuciar pañales - , he querido hacer que sea un día especial, que soy de los que creen que en esta vida hay que celebrar todo, que las cosas malas ya vendrán solas, así que meter una fiesta más en mi calendario siempre es una buena idea.

Este día lo voy a dedicar a reflexionar sobre el hombre que quiero ser, y abandonar algo del hombre que fui. Hace algún tiempo decidía que para seguir creciendo, cada día debo dejar atrás cosas de la persona que un día fui para poder ser la persona que quiero ser en el futuro. No quiero verme constreñido a ser sólo la persona que un día fui, o que soy a día de hoy, y por eso aún sigo pensando en la persona que quiero ser, así que por que no, y este 18 de Julio es un día perfecto, donde paso del hombre del siglo pasado al nuevo, así que será un nuevo día marcado en mi calendario.

Además, estos días suelo estar recordando siempre hechos que me hacen pensar, ya que un día 16 de Julio cuando nos dejó mi querido Kevin Mitnick, y un 20 de Julio cuando se fue el mítico Chester Benington, días que siempre tengo muy presentes.. Y en medio, el 18 de Julio, es el día de mi transición de un siglo a otro, así que algún sentido positivo le tendré que dar para pensar en ello. Al final, siempre es un buen momento para sentarse y reflexionar sobre nuestra vida, el lugar en el mundo en que nos encontramos, y el camino que queremos recorrer durante el limitado e incierto tiempo que tenemos.

En mi caso, desde que sobrepasé los cuarenta y cinco, y empecé a vislumbrar la llegada al kilómetro cincuenta de la vida como siguiente etapa de la vida, dediqué mucho tiempo a pensar en eso. En cómo quería que fueran mis años finales como profesional, como ser humano. Comencé a pensar en cómo al chaval ese que era, y al que le dediqué algunos mensajes en 2019, le gustaría que hiciera ese camino final. Qué paisajes querríamos recorrer, qué actividades querríamos hacer, qué montañas nos gustaría escalar juntos. En qué valle nos gustaría terminar el viaje.

Con mis paseos por el río y las calles de Lisboa este año he tenido tiempo de hacer mucho eso. Disfruto estando en esa soledad reflexiva acompañada de mis libros. La pregunta que me he hecho han sido esas mismas que llevo años haciéndome estos años. Si tuvieras todo el tiempo del mundo qué harías. Y al final llego a conclusiones muy curiosas y duras. Porque la conclusión es que acabaría haciendo lo que hago. Escribo este blog por placer. Dar conferencias es algo placentero. Estudiar tecnología es algo que pagaría por hacer. Crear proyectos y hacerlos crecer me divierte tanto como me divertía jugar con el ordenador de niño.

Pero... por si acaso, mantengo al humano dentro y fuera controlando el "Loop" y no voy en automático. Por eso reflexiono tanto sobre ello. Es mi forma de vigilar que no degenero en una actividad que contamina y envenena el disfrute que me da tener una mezcla variada y equilibrada de actividades, sin dejar que ninguna degenere más que otra en un punto focal que me lleve por un camino que no me divierta. Y eso exige mucho tiempo de CPU invertido en Guardrails que eviten el Misalignment. Es muy fácil sucumbir a un Prompt Injection, que te manipule el Contex o la Memory, sobretodo si viene cargado con pesos en las capas de atención de las "human weaknesses" que son fáciles de sufrir un adversary attack, usando DeepFakes que permitan Spoofear lo que podría parecer un Token de Flag en un CTF pero que no sea más que una Poisson Apple de un Deception Toolkit. Por uso, mantengo al Human in the Loop y Controlling the Loop.

Ya sabes cómo va esto...pues con la mirada de los años más aún.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Blind Quantum Computing (3)

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

Llegados a este punto del artículo, tras lo que se ha tratado en la primera y segunda parte de este artículo, Blind Quantum Computing puede parecer la solución ideal para proteger la privacidad en los servicios de computación cuántica en la nube. Si un servidor puede ejecutar una computación sin conocer realmente qué está calculando, resulta natural preguntarse por qué esta tecnología no forma parte todavía de las plataformas comerciales de QCaaS.

Figura 17: Blind Quantum Computing (3)

En esta parte vamos a centrarnos justo en eso, en los problemas y limitaciones a los que se enfrentan las tecnologías de Blind Quantum Computing.

9.- Limitaciones actuales: por qué BQC aún no es una solución industrial

La respuesta es sencilla:

BQC es una idea extraordinariamente potente desde el punto de vista teórico, pero enormemente exigente desde el punto de vista práctico.

A diferencia de tecnologías como TLS, PQC o los Trusted Execution Environments (TEE), que pueden desplegarse sobre infraestructuras ya existentes, los protocolos BQC introducen requisitos adicionales que todavía resultan difíciles de satisfacer en entornos comerciales a gran escala.

El coste de ocultar la computación

Uno de los principales desafíos es que la privacidad no es gratuita. Para impedir que el servidor reconstruya el algoritmo, los protocolos BQC necesitan introducir información adicional, intercambiar mensajes entre cliente y servidor y ejecutar operaciones de corrección o verificación que no existirían en una computación cuántica convencional. Como consecuencia, el coste total de la ejecución suele aumentar en términos de:

Comunicación entre cliente y servidor.
Número de operaciones necesarias.
Tiempo de ejecución.
Complejidad del protocolo.

En otras palabras, cuanto mayor es el nivel de privacidad perseguido, mayor suele ser el sobrecoste asociado.

El cliente no siempre es completamente clásico

Otro aspecto relevante es que muchos protocolos BQC asumen que el cliente dispone de ciertas capacidades cuánticas mínimas. Aunque estas capacidades son muy inferiores a las del servidor, siguen representando una barrera práctica importante. En numerosos escenarios empresariales resulta mucho más sencillo asumir que el cliente dispone únicamente de recursos clásicos y delega toda la computación en el proveedor.

Figura 18: 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

Precisamente por este motivo han aparecido variantes como Double-Server BQC, o nuevas líneas de investigación orientadas a reducir progresivamente las capacidades cuánticas necesarias en el extremo del cliente.

La realidad de la era NISQ

A estas dificultades se añade una limitación fundamental:

El hardware cuántico actual sigue siendo imperfecto.

La mayoría de las plataformas comerciales operan todavía en la denominada era NISQ (Noisy Intermediate-Scale Quantum), caracterizada por la presencia de ruido, errores y limitaciones en el número de qubits utilizables.

Muchos protocolos BQC fueron diseñados inicialmente desde una perspectiva teórica, asumiendo condiciones que todavía resultan difíciles de reproducir de manera eficiente en dispositivos reales. Esto obliga a adaptar continuamente las propuestas a las restricciones impuestas por el hardware disponible.

Escalabilidad y despliegue industrial

Las plataformas QCaaS actuales deben prestar servicio a múltiples usuarios, optimizar recursos y mantener una operación estable y económicamente sostenible. En este contexto, la prioridad inmediata suele centrarse en mejorar aspectos como:

La fidelidad de los qubits.
La corrección de errores.
La escalabilidad del hardware.
La interoperabilidad con infraestructuras cloud existentes.

Frente a estos desafíos, BQC continúa siendo principalmente una línea de investigación especializada cuyo objetivo es explorar hasta dónde puede llegar la privacidad en la computación cuántica delegada.

Una tecnología adelantada a su tiempo

Esta situación no debe interpretarse como una debilidad de BQC. De hecho, muchas tecnologías que hoy consideramos esenciales comenzaron como propuestas teóricas aparentemente difíciles de implementar. La propia criptografía de clave pública es un buen ejemplo de ello.

En cierto modo, Blind Quantum Computing está recorriendo un camino similar. Actualmente no compite con PQC o TEE como solución industrial inmediata, sino que actúa como un laboratorio conceptual donde se exploran los límites de la privacidad en computación cuántica. Por eso, la pregunta relevante no es si BQC sustituirá mañana a las soluciones actuales, sino si algunas de sus ideas terminarán integrándose en las futuras infraestructuras de computación cuántica.

Figura 19: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

Y para responder a esa cuestión resulta inevitable mirar hacia los escenarios que ya comienzan a perfilarse en el horizonte de la investigación cuántica, como son el Internet Cuántico y la Computación Cuántica Distribuida, donde privacidad, delegación segura y colaboración entre múltiples nodos podrían convertirse en requisitos tan importantes como la propia capacidad de cálculo.

10. ¿Qué papel podría tener BQC en el futuro Internet y Computación Cuántica Distribuida?

Hasta ahora hemos analizado Blind Quantum Computing desde la perspectiva de los servicios actuales de computación cuántica en la nube. Sin embargo, una parte importante del interés que despierta esta línea de investigación no está relacionada únicamente con el presente, sino con los escenarios que podrían surgir a medida que la tecnología cuántica continúe evolucionando. Entre ellos destaca uno especialmente ambicioso:

El desarrollo de un Internet Cuántico.

Aunque todavía se encuentra en una fase temprana de desarrollo, la idea general consiste en interconectar procesadores, memorias y dispositivos cuánticos mediante redes capaces de distribuir estados cuánticos y recursos de entrelazamiento entre múltiples nodos. Si esta visión llega a materializarse, el modelo actual de un usuario conectándose a un único proveedor de QCaaS podría evolucionar hacia entornos mucho más complejos, donde múltiples dispositivos y servicios cuánticos colaboren para resolver problemas de forma distribuida.

En ese contexto aparece otro concepto cada vez más relevante, como es la

Computación Cuántica Distribuida,

cuyo objetivo es permitir que varios procesadores cuánticos, potencialmente ubicados en lugares distintos, cooperen para ejecutar una misma computación. Este enfoque podría convertirse en una alternativa al desarrollo de procesadores monolíticos cada vez más grandes, permitiendo combinar recursos cuánticos distribuidos a través de futuras redes cuánticas.

De la Computación Delegada a la Computación Distribuida

En un escenario de computación cuántica distribuida, la privacidad dejaría de ser únicamente un problema entre cliente y proveedor. Podrían intervenir múltiples actores:

Diferentes nodos cuánticos.
Servicios cuánticos especializados.
Centros de procesamiento distribuidos.
Usuarios colaborando en una misma computación.

La pregunta pasaría entonces de ser:

¿Cómo protejo una computación frente a un único proveedor?

a convertirse en:

¿Cómo protejo una computación cuando participa una red completa de sistemas cuánticos?

Es precisamente aquí donde muchas de las ideas desarrolladas en BQC comienzan a resultar especialmente interesantes. Protocolos como MC-BQC (Multi-Client Blind Quantum Computing) o algunas variantes basadas en Teleportación Cuántica ya exploran escenarios donde varias entidades participan en una computación manteniendo la privacidad de su información.

Figura 20: MC-BQC (Multi-Client Blind Quantum Computing)

Desde esta perspectiva, BQC deja de ser únicamente un mecanismo para proteger la privacidad frente a un proveedor de QCaaS. También podría convertirse en una pieza relevante para permitir colaboración segura entre múltiples nodos cuánticos, usuarios y servicios distribuidos dentro de una futura infraestructura cuántica global.

QKD protege las comunicaciones, BQC podría proteger la computación

Una forma sencilla de entender el posible papel de BQC es compararlo con una tecnología mucho más conocida:

Quantum Key Distribution (QKD).

QKD se centra en proteger la distribución de claves y la confidencialidad de las comunicaciones. BQC persigue un objetivo diferente:

QKD: protege los datos mientras se transmiten.
BQC: protege la computación mientras se ejecuta.

Por este motivo, algunas visiones del futuro Internet Cuántico contemplan ambas tecnologías como piezas complementarias y no como alternativas. Puede resumirse de forma muy simple:

QKD + BQC = confidencialidad de las comunicaciones + confidencialidad de la computación.

Naturalmente, este escenario todavía está lejos de convertirse en una realidad operativa, pero ilustra bien por qué BQC despierta tanto interés desde el punto de vista académico y de la investigación en seguridad.

Un posible paralelismo con la evolución de Internet

Existe además un paralelismo interesante con la evolución de Internet. Durante los primeros años de Internet, la principal preocupación era conseguir que los sistemas pudieran comunicarse entre sí. Con el tiempo aparecieron nuevos requisitos:

Confidencialidad.
Autenticación.
Integridad.
Privacidad.

Hoy resulta difícil imaginar Internet sin protocolos como TLS o sin mecanismos criptográficos ampliamente desplegados. Quizás algo similar ocurra en el ámbito cuántico.

Actualmente gran parte del esfuerzo se concentra en construir hardware más estable, aumentar el número de qubits lógicos y mejorar la corrección de errores. Sin embargo, a medida que estas barreras técnicas vayan superándose, las cuestiones relacionadas con la privacidad, la delegación segura y la confianza entre nodos podrían adquirir una relevancia cada vez mayor.

Mirando más allá del presente

Es imposible saber hoy qué protocolos concretos terminarán imponiéndose o si las formas actuales de BQC serán las que lleguen a utilizarse en sistemas reales. Lo que sí parece claro es que la pregunta que dio origen a Blind Quantum Computing seguirá siendo relevante:

¿Podemos utilizar recursos cuánticos remotos sin revelar completamente qué estamos calculando?

Responder a esa pregunta es, precisamente, lo que convierte a BQC en algo más que una curiosidad académica. Tal vez no sea todavía una tecnología preparada para el despliegue masivo, pero sí representa una de las ideas más interesantes que han surgido en la intersección entre computación cuántica, criptografía y privacidad.

Y quizás por eso, más que una solución para los servicios QCaaS actuales, Blind Quantum Computing deba entenderse como una referencia que nos permite explorar cuál podría ser el límite criptográfico de privacidad en la futura computación cuántica delegada, distribuida e interconectada.

Continúa en la última parte: Blind Quantum Computing (y 4)

Un saludo,

Autor: José Antonio Castellano Prado, Alumno del Curso de Quantum Security de la Universidad de Deusto

Contactar con José Antonio Castellano Prado

Otros artículos sobre Quantum Computing publicados:

El nuevo libro de "Ciberseguridad: Cómo defenderse en una guerra continua" escrito por Rafa López "Cibercapitan" en 0xWord

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

Otro día feliz, porque tenemos un nuevo libro en 0xWord, que sabéis que conseguir esto y mantener una editorial como la nuestra viva es siempre un reto. Así que, presentaros este nuevo libro de "Ciberseguridad: Cómo defenderse en una guerra continua", escrito por Rafa López "Cibercapitán", y publicado en la línea 0xWord Brain para ofrecerte una lectura directa y útil que puedas saborear en verano.

Figura 1: El nuevo libro de "Ciberseguridad: Cómo defenderse en una guerra continua"

escrito por Rafa López "Cibercapitan" en 0xWord

La ciberseguridad moderna no va solo de herramientas. Va de estrategia, arquitectura, personas y capacidad real de defensa. Tecnologías y arquitecturas de ciberseguridad ofrece una visión clara y práctica para entender cómo se protege hoy una organización: desde la gobernanza y el cumplimiento, hasta las capacidades técnicas, el workspace moderno, los equipos de seguridad, la inteligencia, la automatización y los ejercicios prácticos.

Figura 3: "Ciberseguridad: Cómo defenderse en una guerra continua"

escrito por Rafa López "Cibercapitan" en 0xWord

Un libro pensado para profesionales, estudiantes, responsables IT y cualquier persona que quiera ordenar el caos de siglas, soluciones y marcos de trabajo que rodean a la seguridad actual. Porque defender una organización no consiste en comprar más tecnología. Consiste en saber qué necesitas, cómo integrarlo y cómo convertirlo en protección real con ejercicios reales para poner a prueba los conocimientos.

Figura 4: Contactar con Rafa López "Cibercapitan"

A lo largo de sus páginas, Rafa López "Cibercapitan" intenta poner luz y orden en el caos, para que con una lectura rápida de sus más de 180 páginas, aprendas, y disfrutes de la lectura. Es un libro fundamentalmente escrito para ser leído y disfrutado, más que consultado. Aquí tienes el índice del libro.

Figura 5: Índice del libro "Ciberseguridad: Cómo defenderse en una guerra continua" escrito por en 0xWord

Para terminar, te recuerdo que tendrás también 100 Tempos de MyPublicInbox por la compra de este libro de "Ciberseguridad: Cómo defenderse en una guerra continua" y que, además, puedes pagar completa o parcialmente este libro con Tempos de MyPublicInbox. Aquí te explico cómo se hace.

Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro

La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar en tu Agenda el Perfil Público destinatario de la transferencia.

Figura 6: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a la Agenda".
https://MyPublicInbox.com/0xWord

Para dar de alta un Perfil Público en tu agenda, solo debes iniciar sesión en MyPublicInbox, y con la sesión iniciada ir a la web del perfil. En este caso, a la URL del perfil público de 0xWord en MyPublicInbox, - https://MyPublicInbox.com/0xWord - donde te aparecerá la opción de "Añadir a la agenda". Cuando acabe este proceso, podrás ir a la opción Agenda de tu buzón de correo en MyPublicInbox y deberías tener el Perfil Público de 0xWord allí.

Figura 7: Cuando lo agregues estará en tu agenda

Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.

Figura 8: Zona de Transferencias en el Perfil de MyPublicInbox

No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda.

Canjear 500 Tempos por un código descuento de 5 €

La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com

Figura 9: Canjear Tempos por Códigos para libros de 0xWord

Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.

Ser escritor de libros de 0xWord

Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.

Figura 10: Si eres un Perfil Público de MyPublicInbox

puede solicitar info para escribir un libro en 0xWord

Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

¡Último día! Código de Rebajas de Verano 2026 en 0xWord: Cupón VERANO2026 (Hoy se acaba)

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

Hoy es el último día que tenemos activo el Código de Rebajas de Verano: VERANO2026 en 0xWord, que durará SÓLO hasta las 23:59:59 y tiene un descuento que da un 10% de reducción de precio en todos los productos de la tienda de 0xWord.com. Es tan sencillo como incluir en el proceso de compra el código VERANO2026 para obtener un 10% de rebaja en el precio, y además, como te cuento en este artículo, tienes también otras formas de conseguir más ahorros utilizando tus Tempos de MyPublicInbox.

Figura 1: ¡Último día! Código de Rebajas de Verano 2026

en 0xWord.com. Cupón 10% descuento: VERANO2026

y descuentos con Tempos de MyPublicInbox

El código descuento, ya está disponible, así que si lo utilizas tendrás un descuento del 10% en todo el material de 0xWord en la tienda. Incluido el merchandising de Cálico Electrónico, los Packs Oferta, los VBOOKs, los cómics de EVIL:ONE en 0xWord Comics, las novelas en 0xWord Pocket o los nuevos de 0xWord Brain.

Figura 2: Consigue los últimos libros de 0xWord con descuento

Pero además, tienes formas de incrementar los descuentos de 0xWord, utilizando tus Tempos de MyPublicInbox, que puedes usar de dos formas diferentes.

Figura 3: Compra tus libros de Hacking en 0xWord

Enviando Tempos a 0xWord y consiguiendo un descuento extra o canjeando un código descuento de 0xWord por Tempos de MyPublicInbox. Aquí te explico cómo se hace.

Enviar tus Tempos a 0xWord y recibir el descuento

La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar el Perfil Público destinatario de la transferencia en la Agenda.

Figura 4: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a la Agenda".
https://MyPublicInbox.com/0xWord

Figura 5: Cuando lo agregues estará en tu agenda

Figura 6: Zona de Transferencias en el Perfil de MyPublicInbox

No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda.

Canjear 500 Tempos por un código descuento de 5 €

Figura 7: Canjear Tempos por Códigos para libros de 0xWord

Así que, si quieres conseguir nuestros libros durante este VERANO2026, entre el código de descuento VERANO2026 y los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barata.

Figura 8: Compra tus libros de Hacking en 0xWord

Y así apoyas este proyecto tan chulo que es 0xWord.com, donde como ves, nos esforzamos por tener libros técnicos chulos en Español.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Blind Quantum Computing (2)

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

Continuando con el contenido de la primera parte de este artículo que puedes leer aquí: "Blind Quantum Computing (1)" vamos a ver un ejemplo de ocultación de una Puerta Hadamard (H). Hasta ahora hemos visto que BQC pretende ocultar una computación al servidor y que la mayoría de las propuestas actuales se apoyan en MBQC para conseguirlo.

Figura 6: Blind Quantum Computing (2)

Pero ¿cómo se traduce esto en la práctica? Vamos a verlo con detalle, que merece la pena estudiar este caso con tranquilidad para que se entienda bien el proceso.

6.- Ejemplo sencillo: cómo se oculta una puerta H

Para responder a esta pregunta vamos a utilizar un ejemplo muy simple basado en una de las puertas cuánticas más conocidas: la Puerta Hadamard (H), ampliamente utilizada para crear superposiciones y explotar el paralelismo cuántico.

En un circuito cuántico tradicional, la situación es bastante sencilla. El programador construye un circuito, lo envía al proveedor de QCaaS y el servidor puede ver explícitamente las operaciones que forman parte del algoritmo. Si el circuito contiene una Puerta H, el servidor sabe que existe una Puerta H en ese punto del programa.

Figura 7: Ejemplo de ocultación para servidor de una Puerta H.

En BQC la situación es diferente. En un servicio QCaaS convencional, la presencia de una Puerta H forma parte explícita del circuito que recibe el proveedor. En cambio, en un protocolo BQC basado en MBQC, esa misma operación termina transformándose en una instrucción de medida cuyo significado real sólo puede interpretar el cliente. Para el servidor, la puerta lógica desaparece y es sustituida por parámetros de medida aparentemente compatibles con múltiples computaciones posibles.

Lo que conoce el cliente y lo que ve el servidor

En este ejemplo aparecen tres elementos importantes:

Figura 8: Representación de las rotaciones para cegar.

ϕ (phi): representa la computación real que quiere realizar el cliente.
θ (theta): una rotación aleatoria secreta elegida por el cliente.
δ (delta): el ángulo que finalmente recibe el servidor para realizar la medición.

El cliente conoce simultáneamente ϕ y θ, mientras que el servidor únicamente observa δ. Esa asimetría de información es precisamente la que proporciona la propiedad de cegado o blinding.

La idea clave es que el servidor nunca recibe directamente la información lógica de la computación. En su lugar, recibe una versión "mezclada" con la aleatoriedad introducida por el cliente. Por este motivo, aunque el servidor ejecute correctamente las mediciones solicitadas, no puede distinguir qué parte de la información corresponde al algoritmo real y qué parte corresponde a la aleatoriedad utilizada para ocultarlo. Desde su punto de vista, únicamente observa una secuencia de instrucciones físicamente válidas.

El secreto está en el blinding

Recordemos el ejemplo utilizado en el apartado anterior: un GPS puede indicar correctamente cada giro de una ruta sin necesidad de explicar cuál es el destino final. El blinding funciona de manera parecida. El cliente introduce una pequeña cantidad de información secreta —en este caso la rotación θ— que altera la forma en que el servidor percibe la computación. El servidor continúa ejecutando operaciones válidas y obtiene resultados correctos, pero pierde la capacidad de reconstruir el significado lógico de cada paso.

Dicho de otra forma, el proveedor puede ejecutar la computación, pero no interpretar completamente lo que está computando. Es precisamente esta separación entre ejecutar y comprender la que convierte a BQC en una propuesta tan interesante desde el punto de vista de la privacidad. Lo que realmente ejecuta el servidor

Existe otro detalle importante. En MBQC el servidor no ejecuta directamente Puertas H, T o CNOT como ocurre en el modelo tradicional de circuitos. Antes de la ejecución, la computación se transforma en un patrón de mediciones sobre un conjunto de qubits previamente entrelazados.

Figura 9: 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

Por ello, cuando el cliente desea implementar una operación lógica determinada, el servidor no ve necesariamente esa operación. Lo que observa son mediciones parametrizadas cuyos valores han sido modificados mediante el proceso de blinding. Ésta es una de las razones por las que MBQC resulta tan adecuado para Blind Quantum Computing: permite separar lo que el algoritmo significa de lo que el servidor necesita ejecutar físicamente.

Una idea mucho más potente de lo que parece

Aunque este ejemplo utiliza una única Puerta H para simplificar la explicación, el mismo principio puede extenderse a computaciones mucho más complejas. Lo importante no es la puerta concreta utilizada, sino la idea que hay detrás:

El servidor dispone de la información necesaria para ejecutar la computación, pero no de la información necesaria para comprenderla.

Dicho de forma simple, en un servicio QCaaS tradicional el servidor ve la Puerta H; en BQC ve únicamente información compatible con ella, pero no dispone de los elementos necesarios para saber que esa era realmente la operación lógica que el cliente quería ejecutar.

Esa es la base sobre la que se construyen los distintos protocolos de
Blind Quantum Computing que veremos en el siguiente apartado. Allí comprobaremos que no existe una única forma de implementar esta idea, sino toda una familia de protocolos que buscan equilibrar privacidad, verificabilidad y viabilidad práctica.

7.- Familias de protocolos BQC: UBQC, VBQC, MC-BQC y Teleportation-BQC

Una vez comprendida la idea general de Blind Quantum Computing , es importante aclarar que no existe un único protocolo BQC. De hecho, durante los últimos años han surgido múltiples variantes con objetivos diferentes: algunas priorizan la privacidad, otras incorporan mecanismos de verificación, algunas reducen las capacidades cuánticas necesarias en el cliente y otras intentan acercar estas ideas a las limitaciones del hardware actual.

La siguiente tabla se resume algunas de las propuestas más representativas y muestra cómo la investigación ha evolucionado desde los primeros protocolos fundacionales hasta enfoques orientados a Internet Cuántico, computación distribuida y dispositivos NISQ.

Figura 10: Tabla de protocolos más representativos de BQC

Aunque todos comparten el mismo objetivo —permitir que un servidor ejecute una computación cuántica sin conocer realmente qué está calculando—, cada uno intenta resolver un problema diferente.

UBQC: el protocolo fundacional

Universal Blind Quantum Computing (UBQC), propuesto por Broadbent, Fitzsimons y Kashefi en 2009, está considerado el punto de partida de gran parte de la investigación moderna en BQC.

Figura 11: Universal Blind Quantum Computing

Su relevancia no reside tanto en su aplicación práctica actual como en haber demostrado que era posible delegar una computación cuántica preservando la privacidad del cliente. Muchas propuestas posteriores pueden considerarse extensiones o adaptaciones de sus ideas fundamentales.

VBQC: cuando también queremos verificar

Una pregunta que surge:

"¿Cómo puede el cliente saber que el servidor ha ejecutado correctamente la computación?"

Para responder a este problema aparecieron los protocolos de Verifiable Blind Quantum Computing (VBQC), que añaden mecanismos capaces de detectar errores o comportamientos maliciosos durante la ejecución.

Figura 12: Verifiable Blind Quantum Computing (VBQC)

En otras palabras, VBQC no sólo busca privacidad, sino también confianza en el resultado obtenido.

Reduciendo las capacidades del cliente

Uno de los retos históricos de BQC es que muchas propuestas requieren que el cliente disponga de ciertas capacidades cuánticas mínimas. Con el objetivo de simplificar este requisito surgieron variantes como Double-Server BQC, donde parte de esa complejidad se traslada a dos servidores bajo determinadas hipótesis de seguridad.

Figura 13: Double-Server BQC

La idea es acercar la computación cuántica delegada a escenarios donde el cliente disponga únicamente de recursos clásicos o muy limitados.

Computación cuántica colaborativa

La evolución natural de los servicios cloud apunta hacia entornos colaborativos y distribuidos. En este contexto aparecen propuestas como Multi-Client Blind Quantum Computing (MC-BQC), diseñadas para que varios usuarios participen en una misma computación manteniendo la privacidad de su información.

Figura 14: Multi-Client Blind Quantum Computing (MC-BQC)

Aunque todavía se encuentran principalmente en fase de investigación, estas propuestas ofrecen una visión interesante de cómo podrían funcionar futuros servicios cuánticos distribuidos o incluso ciertas capas del Internet Cuántico.

Teleportation-BQC: mirando al futuro

Entre las líneas de investigación más prometedoras destaca Gate Teleportation-Based Blind Quantum Computing. A diferencia de los protocolos clásicos apoyados exclusivamente en MBQC, estas propuestas utilizan mecanismos inspirados en la teleportación cuántica para ocultar la computación. Su principal atractivo es que permiten trabajar más cerca del modelo tradicional de circuitos cuánticos, facilitando potencialmente su integración en arquitecturas futuras.

Figura 15: Gate Teleportation-Based Blind Quantum Computing

Aunque todavía se trata de un área de investigación activa, estas propuestas resultan especialmente interesantes porque permiten aproximarse al modelo de circuitos cuánticos tradicional sin depender exclusivamente de MBQC. Por este motivo, suele considerarse una de las líneas de trabajo con mayor potencial para escenarios avanzados de computación distribuida e Internet Cuántico.

Adaptando BQC a la era NISQ

Por último, los protocolos agrupados bajo la etiqueta NISQ-BQC buscan trasladar las propiedades de privacidad de BQC a los dispositivos cuánticos disponibles actualmente, caracterizados por limitaciones de escala y presencia de ruido. El objetivo es encontrar un equilibrio razonable entre privacidad, complejidad y viabilidad práctica, acercando conceptos tradicionalmente teóricos a plataformas experimentales reales.

Un mismo objetivo, diferentes caminos

Aunque las aproximaciones son muy diversas, todas comparten una misma aspiración:

Permitir que un servidor cuántico ejecute una computación sin conocer realmente qué está computando.

Sin embargo, llegados a este punto surge una pregunta inevitable: si BQC ofrece un nivel de privacidad tan elevado,

¿significa eso que es una alternativa mejor que las soluciones actuales basadas en PQC y TEE?

La respuesta es más matizada de lo que podría parecer y requiere analizar no solo el nivel de privacidad alcanzado, sino también aspectos como la complejidad, la escalabilidad y la viabilidad práctica. Eso es precisamente lo que veremos en el siguiente apartado.

8.-¿Es BQC mejor que PQC + TEE?

Después de conocer los fundamentos de Blind Quantum Computing (BQC) y las diferentes familias de protocolos existentes, surge una pregunta inevitable:

"Si BQC ofrece un nivel de privacidad tan elevado, ¿significa eso que es una solución mejor que las aproximaciones actuales basadas en PQC y TEE?"

La respuesta corta es:

"depende del problema que queramos resolver."

A menudo se presenta BQC como una alternativa a los modelos actuales de seguridad en QCaaS, pero en realidad ambas aproximaciones responden a necesidades diferentes y se encuentran en niveles de madurez muy distintos.

Dos modelos de confianza diferentes

La principal diferencia entre ambas aproximaciones no está en la tecnología utilizada, sino en el modelo de confianza que asumen. Las soluciones basadas en PQC + TEE parten de una premisa razonable: el proveedor puede ser confiable siempre que existan mecanismos técnicos que reduzcan la exposición de los datos y protejan determinadas fases del procesamiento.

Por el contrario, BQC intenta llevar este planteamiento un paso más allá. Su objetivo no es reducir la confianza necesaria en el proveedor, sino minimizarla hasta el extremo de que el servidor pueda ejecutar la computación sin conocer realmente lo que está procesando. Dicho de forma simplificada:

PQC + TEE protege la ejecución en un entorno confiable.
BQC intenta proteger la computación incluso cuando no queremos confiar completamente en quien la ejecuta.

La teoría frente a la práctica

Desde una perspectiva puramente criptográfica, el nivel de privacidad que persigue BQC resulta difícil de superar. Sin embargo, la seguridad no es el único parámetro relevante cuando hablamos de sistemas reales. Un servicio QCaaS debe ser también:

Escalable.
Eficiente.
Mantenible.
Económicamente viable.
Compatible con el hardware disponible.

Y es aquí donde aparecen las principales ventajas de los enfoques basados en PQC y TEE. Estas tecnologías pueden desplegarse hoy utilizando infraestructuras cloud ya existentes y mecanismos ampliamente conocidos por la industria, permitiendo proteger comunicaciones, credenciales y entornos de ejecución con un impacto razonable en costes y rendimiento.

Figura 16: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

BQC, por el contrario, suele requerir protocolos más complejos, mayor interacción entre cliente y servidor y, en muchos casos, capacidades cuánticas adicionales que todavía resultan difíciles de integrar en plataformas comerciales de gran escala.

¿Qué utilizaríamos hoy?

Si una organización necesitara desplegar actualmente un servicio seguro de computación cuántica en la nube, la respuesta sería bastante clara. La opción más realista sería apoyarse en mecanismos como:

IAM.
TLS y criptografía post-cuántica PQC.
Trusted Execution Environments TEE.
Controles de seguridad Cloud tradicionales.

Estas tecnologías ya existen, están siendo desplegadas y permiten construir servicios QCaaS con niveles de seguridad adecuados para la mayoría de los escenarios actuales. Por esta razón, resulta más apropiado considerar BQC como un complemento conceptual que como un sustituto inmediato de estas soluciones. Entonces,...

"¿Por qué BQC es tan importante?"

Porque nos permite responder a una pregunta que las tecnologías actuales no intentan resolver completamente:

"¿Cuál es el máximo nivel de privacidad que podría alcanzarse en una computación cuántica delegada?"

En este sentido, BQC actúa como una especie de referencia teórica o límite criptográfico. Aunque hoy resulte complejo trasladarlo a servicios comerciales a gran escala, proporciona un marco extremadamente valioso para comprender cómo podría evolucionar la privacidad en futuros entornos de computación cuántica en la nube. Podemos resumir la relación entre ambas aproximaciones de la siguiente manera:

"PQC + TEE representa la solución práctica disponible hoy.

BQC representa el nivel máximo de privacidad al que aspiramos llegar mañana."

Y esa diferencia es precisamente la que explica por qué, pese a su enorme interés académico, Blind Quantum Computing (BQC) sigue siendo un área de investigación activa y no una característica habitual de los servicios QCaaS actuales.

En el siguiente parte veremos cuáles son los principales obstáculos que todavía dificultan su adopción masiva y por qué, a pesar de sus ventajas teóricas, BQC continúa siendo una tecnología principalmente experimental.

Un saludo,

Autor: José Antonio Castellano Prado, Alumno del Curso de Quantum Security de la Universidad de Deusto

Contactar con José Antonio Castellano Prado

Otros artículos sobre Quantum Computing publicados:

Blind Quantum Computing (1)

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

La computación cuántica está avanzando hacia un modelo de consumo en el que la mayoría de los usuarios accederán a los recursos cuánticos a través de servicios en la nube, conocidos como Quantum Computing as a Service (QCaaS). Plataformas como IBM Quantum, Azure Quantum, Amazon Braket o Google Quantum AI ya permiten ejecutar algoritmos sobre hardware cuántico real sin necesidad de disponer de complejas y costosas infraestructuras propias.

Figura 1: Blind Quantum Computing (BQC)

Sin embargo, este modelo plantea una cuestión fundamental desde el punto de vista de la seguridad y la privacidad:

¿Qué información revela realmente un usuario cuando delega una computación cuántica en un proveedor externo?

En la computación clásica estamos acostumbrados a preocuparnos por la protección de los datos, pero en la computación cuántica delegada el problema es potencialmente mayor. Cuando utilizamos un servicio QCaaS no solo se delegan datos; también se delegan circuitos, algoritmos, parámetros de ejecución y, en muchos casos, información valiosa sobre el propio problema que se desea resolver. En otras palabras, el proveedor que ejecuta la computación podría obtener información sensible no solo de los datos, sino también del conocimiento encapsulado en el algoritmo.

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

Mientras una gran parte de la investigación en computación cuántica se centra en retos como el desarrollo de hardware escalable, la corrección de errores, el aumento del número de qubits lógicos, la tolerancia a fallos o la creación de nuevos algoritmos cuánticos, existe una línea de investigación menos conocida pero especialmente interesante para la ciberseguridad:

“Cómo realizar computación cuántica sobre una infraestructura que no es completamente confiable”.

Es precisamente en este contexto donde surge el Blind Quantum Computing (BQC), un conjunto de protocolos cuyo objetivo es permitir que un servidor cuántico ejecute una computación sin conocer información significativa sobre los datos, el algoritmo o incluso el resultado que está procesando. Dicho de otra forma, BQC persigue un objetivo que parece casi paradójico: utilizar un ordenador cuántico para resolver un problema sin que ese ordenador sepa realmente qué problema está resolviendo.

Figura 3: Foro Público de Quantum Security de

la Universidad de Deusto en MyPublicInbox

En este artículo, inspirado en el trabajo final desarrollado para el curso Quantum y Post-Quantum Computing para Ciberseguridad de la Universidad de Deusto, se presenta una visión introductoria del Blind Quantum Computing, no tanto como una tecnología de adopción industrial inmediata, sino como una referencia teórica y criptográfica que nos ayuda a comprender cuál podría ser el máximo nivel de privacidad alcanzable en los futuros servicios de computación cuántica en la nube.

"¿Es posible delegar una computación cuántica sin necesidad de confiar plenamente en quien la ejecuta?"

Esa es la pregunta que intenta responder el Blind Quantum Computing.

1.-Cuando el algoritmo también viaja a la nube

La computación cuántica está evolucionando hacia un modelo de consumo muy similar al de la computación en la nube tradicional. En lugar de adquirir y mantener infraestructuras propias, los usuarios acceden a recursos remotos a través de Internet utilizando plataformas como IBM Quantum, Azure Quantum, Google Quantum AI o Amazon Braket. Este paradigma, conocido como Quantum Computing as a Service (QCaaS), se ha convertido en la principal vía de acceso a hardware cuántico real. Actualmente, gran parte del modelo de negocio de la computación cuántica se apoya precisamente en este enfoque.

A diferencia de un servidor convencional, una infraestructura cuántica requiere condiciones extremadamente complejas para su funcionamiento: sistemas criogénicos capaces de operar a temperaturas cercanas al cero absoluto, mecanismos avanzados de aislamiento frente al ruido ambiental, electrónica especializada y elevados costes de mantenimiento. Como consecuencia, resulta poco realista pensar que la mayoría de las organizaciones dispondrán de ordenadores cuánticos propios en el corto o medio plazo. Todo apunta a que, al menos durante los próximos años, la computación cuántica será consumida principalmente como un servicio remoto.

Este modelo introduce una diferencia importante respecto a muchos servicios cloud tradicionales. Cuando una organización utiliza una aplicación SaaS o ejecuta una carga de trabajo en una máquina virtual en la nube, normalmente la principal preocupación es proteger los datos. Por lo que la pregunta habitual suele ser:

“¿Puede el proveedor acceder a mi información?”.

En computación cuántica delegada la situación es más compleja. Además de los datos, el usuario debe enviar información sobre la propia computación que desea realizar. Dependiendo del escenario, esto puede incluir circuitos cuánticos, parámetros de ejecución, secuencias de puertas lógicas y otra información que describe el problema que se quiere resolver.

"En QCaaS no sólo viajan los datos; También viaja el algoritmo"

Esta diferencia es sutil, pero tiene importantes implicaciones de seguridad.

Imaginemos una empresa farmacéutica que utiliza algoritmos cuánticos para acelerar el descubrimiento de nuevos medicamentos. O una entidad financiera que desarrolla algoritmos propietarios de optimización de carteras. Incluso aunque los datos enviados al proveedor estuvieran protegidos, el propio algoritmo podría contener información estratégica de enorme valor. En muchos casos, el conocimiento incorporado al algoritmo puede ser tan sensible como los datos que procesa. Por este motivo, limitar la seguridad a la protección de las comunicaciones resulta insuficiente. Es necesario preguntarse también qué puede aprender el proveedor acerca de la computación que está ejecutando.

Actualmente, la seguridad de los servicios QCaaS se basa en mecanismos bien conocidos como la gestión de identidades y accesos (IAM), canales cifrados mediante TLS, soluciones de criptografía post-cuántica (PQC) y distintos mecanismos de aislamiento de las cargas de trabajo. Estas medidas son fundamentales y proporcionan un nivel de protección elevado. Sin embargo, todas ellas comparten una característica común: protegen los datos y las comunicaciones, pero no necesariamente ocultan por completo la naturaleza de la computación que se está realizando

Aquí aparece una idea que probablemente será cada vez más importante en el futuro de la seguridad cuántica:

"La computación es también el objeto que proteger; no sólo los datos"

Si la computación cuántica termina consolidándose como un servicio consumido a través de la nube, la pregunta dejará de ser únicamente cómo proteger la información que enviamos al proveedor. También tendremos que plantearnos hasta qué punto es posible ocultar al proveedor qué estamos calculando realmente.

Y es precisamente en ese punto donde comienza la historia del Blind Quantum Computing (BQC).

2.- Seguridad actual en QCaaS: IAM, TLS/PQC, aislamiento y TEE

Los servicios actuales de Quantum Computing as a Service (QCaaS) no operan en un entorno desprotegido. Al igual que sucede en la nube tradicional, proveedores de QCaaS incorporan mecanismos de seguridad destinados a proteger el acceso a la plataforma, las comunicaciones y la ejecución de los trabajos cuánticos. La seguridad de estos entornos se apoya principalmente en cuatro pilares:

Gestión de identidad y acceso (IAM): para controlar quién puede utilizar el servicio.

Cifrado de las comunicaciones mediante TLS: cada vez más complementado con mecanismos de Criptografía Post-Cuántica (PQC).

Aislamiento lógico de los trabajos: evitando interferencias entre distintos usuarios.

Trusted Execution Environments (TEE): que permiten proteger determinadas fases de procesamiento dentro de entornos aislados.

La combinación de PQC y TEE representa actualmente una de las aproximaciones más avanzadas para proteger los servicios QCaaS.

Figura 4: Seguridad actual en QCaaS: PQC + TEE

PQC protege los datos y circuitos mientras viajan por la red.
TEE protege la información durante su preparación y procesamiento dentro de la infraestructura cloud del proveedor.

Desde el punto de vista de la seguridad práctica, este modelo ofrece un elevado nivel de protección para las comunicaciones, las credenciales de acceso y gran parte de las operaciones necesarias para preparar la ejecución de un trabajo cuántico. Aunque la combinación de PQC y TEE proporciona actualmente uno de los modelos de seguridad más avanzados para los servicios QCaaS, sigue existiendo un elemento fundamental: la confianza en el proveedor.

Cuando las instrucciones deben ser finalmente ejecutadas sobre la Quantum Processing Unit (QPU), el usuario continúa dependiendo de que el proveedor implemente correctamente los mecanismos de protección y de que la infraestructura se comporte según lo esperado. Por este motivo, las soluciones actuales permiten proteger eficazmente las comunicaciones, las credenciales de acceso y gran parte del entorno de ejecución. Sin embargo, no eliminan completamente la necesidad de confiar en quien opera el servicio de computación cuántica. Y ahí surge una pregunta interesante:

“¿Sería posible utilizar un computador cuántico sin necesidad de confiar plenamente en quien lo ejecuta?”

Esta es precisamente la cuestión que intenta responder Blind Quantum Computing.

3.- El hueco de seguridad: proteger datos no siempre protege la computación

Las soluciones actuales utilizadas en los servicios de computación cuántica en la nube proporcionan un elevado nivel de protección para las comunicaciones, el acceso a la plataforma y gran parte del procesamiento previo a la ejecución del trabajo cuántico. Sin embargo, todas ellas parten de una premisa común: existe un determinado grado de confianza en el proveedor que opera la infraestructura.

Este enfoque resulta razonable en la mayoría de los escenarios actuales. Después de todo, los proveedores de QCaaS implementan controles de seguridad, auditorías y mecanismos de aislamiento similares a los utilizados en la nube tradicional. Pero cuando analizamos el problema desde una perspectiva puramente criptográfica aparece una cuestión interesante:

"¿Qué ocurre si no queremos confiar en el proveedor?"

La pregunta puede parecer extrema, pero no es nueva. En ciberseguridad solemos diseñar mecanismos que minimizan la confianza necesaria en terceros. La criptografía moderna, por ejemplo, no protege la información porque confiemos en quien transporta nuestros datos, sino porque incluso un intermediario malicioso debería ser incapaz de interpretar lo que está observando.

En la computación cuántica delegada aparece un reto similar. Aunque las comunicaciones estén cifradas y la infraestructura incorpore mecanismos avanzados de protección, el proveedor sigue siendo quien ejecuta físicamente la computación sobre la QPU. Esto implica que, al menos en principio, podría disponer de información sobre el algoritmo o sobre la estructura del problema que se está resolviendo

Aquí surge una diferencia fundamental entre la computación clásica y la computación cuántica delegada. Tradicionalmente nos hemos preocupado por proteger los datos. Sin embargo, en muchos escenarios el propio algoritmo puede representar un activo de enorme valor. Algunos ejemplos podrían ser:

Un algoritmo cuántico propietario para optimización financiera.
Un modelo de simulación química para descubrir nuevos materiales.
Una técnica de búsqueda o clasificación desarrollada por una organización.
Un proceso industrial cuya ventaja competitiva reside precisamente en cómo se calcula la solución.

En todos estos casos, conocer el algoritmo puede resultar tan valioso como conocer los datos sobre los que opera. Por ello, el objetivo deja de ser únicamente proteger la información que enviamos al proveedor. También debemos preguntarnos si es posible proteger la propia computación. Dicho de otra forma:

"¿Podría un servidor cuántico ejecutar un algoritmo sin llegar a saber realmente qué algoritmo está ejecutando?·

Responder a esta pregunta es precisamente el objetivo de Blind Quantum Computing (BQC), una familia de protocolos diseñada para ocultar al servidor información significativa sobre la computación que está llevando a cabo. Antes de analizar cómo lo consigue, conviene entender primero qué se entiende exactamente por Blind Quantum Computing y cuáles son los principios sobre los que basa su seguridad.

4.- ¿Qué es Blind Quantum Computing?

Hasta ahora hemos visto que los servicios actuales de computación cuántica en la nube incorporan mecanismos avanzados de seguridad, pero siguen requiriendo cierto grado de confianza en el proveedor. Esto nos lleva a una pregunta que, a primera vista, parece imposible de responder:

"¿Puede un ordenador cuántico resolver un problema sin saber realmente qué problema está resolviendo?"

La respuesta es precisamente el origen de Blind Quantum Computing (BQC). BQC es una familia de protocolos diseñada para permitir que un cliente delegue una computación en un servidor cuántico sin revelar información significativa sobre los datos, el algoritmo o el resultado de esa computación.

La idea es tan sencilla de expresar como compleja de implementar: el servidor realiza el trabajo pesado de la computación cuántica, pero únicamente recibe información parcial, aleatorizada o "cegada", insuficiente para reconstruir lo que realmente se está calculando. Dicho de otra forma, el servidor ejecuta operaciones cuánticas válidas, pero no puede distinguir si forman parte de un algoritmo de optimización, una simulación química o cualquier otro cálculo. Para conseguirlo, BQC aprovecha varias propiedades fundamentales de la mecánica cuántica que no tienen equivalente directo en la computación clásica. Entre las más importantes destacan:

Entrelazamiento cuántico: permite crear correlaciones entre qubits que no pueden describirse mediante información clásica convencional. Muchos protocolos BQC utilizan estados entrelazados como base para realizar computaciones remotas manteniendo oculta información relevante para el servidor.

Mediciones cuánticas: en determinados modelos, como MBQC (Measurement-Based Quantum Computing), la computación se realiza principalmente mediante secuencias de medidas sobre estados previamente entrelazados. El cliente puede controlar estas mediciones sin revelar completamente la lógica de la computación al servidor.

Teorema de no clonación: establece que no es posible copiar de forma perfecta un estado cuántico desconocido. Esta propiedad impide que el servidor pueda duplicar los qubits recibidos para analizarlos posteriormente sin alterar la información original.

Técnicas de blinding o cegado: introducen aleatoriedad conocida únicamente por el cliente. Como consecuencia, el servidor ejecuta operaciones correctas desde el punto de vista físico, pero es incapaz de distinguir qué cálculo lógico representan realmente.

Gracias a la combinación de estos mecanismos, el servidor puede verse obligado a ejecutar una computación válida sin disponer de información suficiente para reconstruir el algoritmo completo que está procesando.

“BQC no intenta cifrar únicamente los datos; intenta cifrar la propia computación.”

Pero si el servidor no conoce realmente qué está ejecutando:

"¿Cómo consigue realizar la computación correctamente?"

La respuesta está en la forma en que se construyen estos protocolos y, especialmente, en un modelo conocido como Measurement-Based Quantum Computing (MBQC), que se ha convertido en la base de gran parte de las propuestas modernas de Blind Quantum Computing.

Figura 5: Esquema de funcionamiento de Measurement-Based Quantum Computing (MBQC)

Antes de analizar los distintos protocolos BQC, conviene entender la intuición técnica que hay detrás de esta idea y cómo es posible ocultar una computación cuántica sin impedir que ésta se ejecute correctamente.

5.- La intuición técnica: MBQC, blinding y mediciones aleatorizadas

A primera vista, Blind Quantum Computing parece una contradicción. Si el servidor no conoce el algoritmo que debe ejecutar, cabría esperar que tampoco pudiera realizar correctamente la computación. La clave está en que la mayoría de los protocolos BQC no se apoyan directamente en el modelo tradicional de puertas cuánticas que suele utilizarse para introducir la computación cuántica. En su lugar, se basan en un paradigma diferente conocido como Measurement-Based Quantum Computing (MBQC) o Computación Cuántica Basada en Medidas.

Mientras que en el modelo de puertas una computación se describe como una secuencia de operaciones lógicas (H, T, CNOT, etcétera) y otras puertas cuánticas, en MBQC el enfoque es distinto. Primero se prepara un conjunto de qubits entrelazados y, posteriormente, la computación se realiza mediante una secuencia de mediciones cuidadosamente seleccionadas sobre esos qubits.

“MBQC define cómo se computa; BQC define qué puede o no aprender el servidor sobre esa computación.”

Esta diferencia puede parecer un detalle técnico, pero es precisamente lo que hace posible gran parte de los protocolos modernos de Blind Quantum Computing.

El papel del "blinding"

La pieza clave que permite ocultar la computación recibe el nombre de blinding o cegado.

De forma simplificada, el cliente introduce información aleatoria que únicamente él conoce. Como consecuencia, las instrucciones que recibe el servidor siguen siendo válidas para ejecutar la computación, pero aparecen mezcladas con una aleatoriedad que impide deducir el significado lógico real de cada operación.

Podemos imaginarlo como alguien que sigue paso a paso las indicaciones de un GPS sin conocer el destino final del viaje. Puede ejecutar correctamente todas las instrucciones, pero no dispone de suficiente información para comprender el propósito completo de la ruta. En BQC ocurre algo similar. El servidor realiza operaciones cuánticas legítimas, pero únicamente observa una versión "ofuscada" de la computación. Lo suficiente para ejecutarla, pero no para reconstruirla.

¿Por qué MBQC encaja tan bien con BQC?

MBQC resulta especialmente adecuado para implementar este mecanismo porque separa de forma natural las responsabilidades entre cliente y servidor. Por un lado, el servidor aporta la capacidad de procesamiento y los recursos cuánticos necesarios para realizar la computación. Por otro, el cliente conserva la información secreta que permite interpretar correctamente las mediciones y dar sentido al cálculo realizado.

Gracias a esta separación, el servidor puede ejecutar una computación físicamente correcta sin disponer de todos los elementos necesarios para reconstruir el algoritmo original. Naturalmente, esta explicación sigue siendo bastante abstracta. La mejor forma de entenderla es observar qué ocurre en un caso concreto.

Figura 6: Continuar lectura en Blind Quantum Computing (2)

En el siguiente apartado de esta serie puedes ver un ejemplo sencillo basado en una puerta Hadamard (H) y comprobaremos cómo una operación que normalmente sería visible para el servidor puede transformarse en una secuencia de mediciones cuyo significado permanece oculto.

Un saludo,

Autor: José Antonio Castellano Prado, Alumno del Curso de Quantum Security de la Universidad de Deusto

Contactar con José Antonio Castellano Prado

Otros artículos sobre Quantum Computing publicados: