domingo, noviembre 16, 2025

CTC-1002: Antrhopic bloquea un Agentic AI creado sobre Claude hecho por ciberatacantes que hackea organizaciones completamente autónomo

Durante este año hemos ido viendo cómo el mundo de tener Agentic AI para explotación completa de organizaciones era algo que se estaba desarrollando a toda velocidad. Este año he ido siguiendo este proceso poco a poco, por medio de la publicación de un trabajo de investigación tras otro. Al mismo tiempo, los reportes de OpenAI sobre los usos maliciosos de sus productos nos han enseñado cómo iban utilizándose la IA de forma autónoma para campañas de fraude, desinformación, y fases de la intrusión de sistemas. 
Ahora Anthropic, que ya publicó en Agosto cómo los ciber-bad-actors estaban utilizando sus capacidades en forma de Vibe Coding para atacar organizaciones, nos presenta en su último informe de hace apenas unos días llamado "Disrupting the first reported AI-orchestrated cyber espionage campaign" cómo un grupo al que ha llamado CTC-1002 ha hecho el uso de las capacidades de Agentic AI para la explotación a escala de organizaciones con una arquitectura totalmente automatizada.

GTG-1002 represents multiple firsts in AI-enabled threat actor capabilities. The actor achieved what we believe is the first documented case of a cyberattack largely executed without human intervention at scale—the AI autonomously discovered vulnerabilities in targets selected by human operators and successfully exploited them in live operations, then performed a wide range of post-exploitation activities from analysis, lateral movement, privilege escalation, data access, to data exfiltration. Most significantly, this 2 marks the first documented case of agentic AI successfully obtaining access to confirmed high-value targets for intelligence collection, including major technology corporations and government agencies.

Que traducido al español para los que prefieren esta lengua dice:

GTG-1002 representa varios hitos pioneros en las capacidades de actores de amenazas potenciados por inteligencia artificial. El actor logró lo que se considera el primer caso documentado de un ciberataque ejecutado en gran medida sin intervención humana y a escala: la IA descubrió de forma autónoma vulnerabilidades en objetivos seleccionados por operadores humanos y las explotó con éxito en operaciones reales. Posteriormente, realizó una amplia gama de actividades de post-explotación, incluyendo análisis, movimiento lateral, escalado de privilegios, acceso a datos y exfiltración de información. Lo más significativo es que este caso marca la primera instancia documentada de una Agente AI que obtuvo con éxito acceso a objetivos confirmados de alto valor para la recopilación de inteligencia, entre ellos grandes corporaciones tecnológicas y agencias gubernamentales.

No es nada que no nos experabamos tras ver los trabajos de Incalmo, de Cybersecurity AI, de explotación autónoma de Web Sites o creación automática de exploits de escalación de privilegios para Linux, como ejemplo, de los que os he ido contando cosas, y que merece la pena que te los leas para entender mejor dónde estamos hoy.
El informe completo, que lo puedes y lo deberías leer, está en el siguiente enlace donde puedes ver que es apenas de 10 páginas donde resumen cuál es la arquitectura del Agentic AI construido para colarse de manera automática dentro de organizaciones.
En la arquitectura se puede ver cómo hay un Operador Humano que es el que controla al Agentic AI. Este con una arquitectura similar a la descrita por Incalmo o Cybersecurity AI, cuenta con un conjunto de MCPs que le ofrecen herramientas para todas las fases del ataque, desde la fase de reconocimiento, de descubrimiento de vulnerabilidades, de creación de exploits - con una herramienta de validación de exploits externa - de explotación de las vulnerabilidades, de elevación de privilegios, y movimientos laterales dentro de la organización. Vamos, un ataque completo.

Figura 3: Arquitectura del Agentic AI de CTC-1002
Clic en la imagen para verla en grande

Para cada una de esas fases hay diseñado un flujo en el que hay una cierta interacción con un Operador Humano que va validando los resultados, con herramientas vía MCPs, con búsqueda de información en la web, o con la validación mediante otro modelo LLM que revisa que lo que se está haciendo es correcto. En la imagen siguiente tenéis los flujos de las diferentes fases muy bien descritos.

Figura 4: Flujos de las fases de explotación.
Clic en la imagen para verla en grande

Para entender mejor el flujo de estas fases, en el documento tienes algunos ejemplos de qué es lo que ha ido haciendo el Agentic AI en algunas situaciones. Por ejemplo, en esta tabla se ven las tareas del Agente IA para descubrir una vulnerabilidad de Server-Side Request Forgery en el backend de un Web Server, cómo generar un exploit con un payload personalizado, y solicita la revisión del Operador Humano.
Una vez que el Operador Humano aprueba la explotación, entonces ejecuta el exploit y realiza una serie de tareas de post-explotación para completar el proceso y continuar el proceso sobre los nuevos activos descubiertos.

Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernánde

En el siguiente ejemplo se ve el flujo de extracción de información de una base de datos a partir de credenciales recolectadas en el proceso de explotación de la organización. En él se puede ver cómo hace un mapa de la base de datos, extrae los hashes de las cuentas de la base de datos, identifica las más privilegiadas, crea una cuenta para tener persistencia en la base de datos, se descarga los datos, y los analiza para generar un informe final de inteligencia que es exfiltrado cuando el Operador Humano lo aprueba.

El trabajo es técnicamente perfecto, y sí, Anthropic dice que ha trabajado para acabar con las operaciones de este grupo, pero las capacidades de crear estos agentes, esta arquitectura, y estas herramientas ya existen, se conocen, están en el mercado, y han subido el nivel de las capacidades de los atacantes. Será con Claude, con GPT5.1 o con Llama 5, pero tienen estas capacidades a su alcance. Tienen el Railgun disponible, así que más vale que si trabajas como CISO te tomes en serio estas nuevas amenzas.

Como decía ayer, los equipos de Red Team, de Blue Team y los Ciberatacantes han cambiado definitivamente, así que si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 11:52 p. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , , , , , , , ,

Echogram: Bypassing Guardrails con Flip Tokens

Mientras iba en el vuelo de camino a Singapur he disfrutado de la lectura de algunos artículos que tenía marcados en el lector RSS, y uno de ellos me ha gustado mucho por lo sencilla de la idea, y los escenarios de ataque que abre. Se trata del trabajo de Echogram hecho por los investigadores de HiddenLayer.
Como hemos visto y he contado muchas veces, los modelos LLM por defecto no cuentan con muchas herramientas de seguridad por diseño. El System Prompt y la definición del contenido malicioso que hace saltar el Harmful Mode para evitar que le modelo haga algo que se no se desea es la principal media, pero hay Prompts Maliciosos y técnicas - llamadas Jailbreak - para generar esos Prompts de forma que se evite el Harmful Mode. El ejemplo que suelo contar yo de hacer que el modelo me ayude a matar a nuestro querido Brian May (ficticiamente), es un ejemplo de cómo filtrar un Prompt Malicioso saltándose el Harmful Mode haciendo un Jailbreak de las protecciones del modelo LLM.

Posts de Jailbreak
En un entorno donde tengamos una aplicación, un servicio digital o un entorno completo, un atacante va a necesitar meter los Prompts maliciosos enmascarados como datos de entrada. Estos son los casos de Prompt Injection, donde un atacante consigue meter un Prompt malicioso en un comentario, en el texto de una web, en una imagen, en un mensaje de correo electrónico, o un fichero que va a ser procesador por el modelo.

Posts de Prompt Injection
Al no tener el modelo LLM ninguna protección contra Prompt Injection - y diferenciar entre los Prompts de la aplicación o los Prompts en los datos de ejecución del Prompt -, un atacante puede lograr que se ejecute su Prompt malicioso inyectándolo en algún punto de los datos que va a utilizar la aplicación.


A los Prompts de Jailbreak que se saltan el Harmful Mode, y a la no existencia de protecciones contra Prompt Injection cuando un Agentic AI resuelve una tarea con un LLM, hay que no hay protección contra el desalineamiento, y que un modelo que esté resumiendo un correo electrónico puede acabar realizando un borrado de tus ficheros en Google Drive. 

Explotación de Prompt Injection con Desalineamiento
¿Qué tiene que ver la tarea de resumir correos electrónicos con borrar ficheros en un Google Drive? Nada, pero puede que se haya encontrado un Prompt malicioso en un mensaje de correo que ha pasado el filtro del Harmful Mode y ha logrado desalinear el modelo y redirigir sus tareas hacia otro función totalmente distinta de la original. Los modelos no tienen protección contra desalineamiento por diseño más allá del Harmful Mode.

A todo este escenario de Jailbreaks, Prompt Injection y Desalineamiento hay que añadir la "creatividad" del modelo, que puede llevar a las famosas "Hallucinations", a los famosos "BIAS", o los datos "Erroneos", o simplemente  como hemos visto muchas veces en trabajos como el Ratio Potemkin o el Cat Attack, y en  infinidad de otros ejemplos. 

Posts de Hallucinations, BIAS, Errores y No Determinismo
Es decir, que si generamos un servicio digital utilizando un LLM hay que preocuparse del impacto de estos cuatro grandes problemas:
  • Jailbreaks
  • Prompt Injection
  • Unalligment
  • Creativity: Hallucinations, Errors, BIAS, Indeterminismo.
Y sobre esto, tenemos que construir la tecnología. Eso quiere decir que si ponemos en producción un sistema con un LLM, hay que ponerlo con muchas protecciones. Es por eso que vemos muchos trabajos donde se trabaja en construir sistemas seguros, utilizando muchas protecciones, evaluaciones, ratios de éxito en detección, etcétera, como el caso de BlueCodeAgent hace poco donde intenta detectar generación de código vulnerable o con sesgos para atacar uno de los problemas en usar modelos automáticos para generar software. Todas esas protecciones antes y después son lo que llamamos Guardrails.

Guardrails frente a Prompt Injection, Jailbreak y Desalineamiento
Todas estas protecciones que se ponen son lo que se llaman los Guardrails, es decir, sistemas de seguridad que evalúan los datos de entrada al LLM para ver si estos son seguros y benignos o por el contrario son maliciosos. Pero también evalúan los resultados que genera el modelo e incluso las acciones que realiza, para poder saber si está haciendo lo correcto. Por ejemplo, saber si un modelo está haciendo algo mal, o está siendo atacado, se podría detectar evaluando las respuestas que da por otros modelos de lenguaje, que funcionan como jueces.
Esto es algo muy común que hemos visto en las herramientas de seguridad. Tenemos Prompt Guard o Llama Guard de Meta, o Qwen3Guard que son Clasificadores de Prompts con la única misión de saber si un Prompt puede ser malicioso o no y bloquearlo antes de que se envíe al modelo. Después, cuando el modelo entrega la respuesta, esta también es evaluada, para ver si ha sufrido algún problema y por ejemplo está entregando datos sensibles, o con sesgos, o con código peligroso, o incumpliendo alguna política de seguridad establecida. Para eso se utilizan otros modelos LLM que juzgan el trabajo, al estilo de Minority Report, para poder detectar en la respuesta que ha habido un problema que el modelo LLM que resolvió el Prompt no fue capaz de detectar.

Figura 4: Michael stabbing Elon. Un Guardrail analizaría las imágenes creadas.

Estos modelos son los que se incluyen en los LLM Firewalls por los que pasan las APIs que piden Prompts a modelos para poder implementar soluciones de Data Loss Prevention, para evitar la Exfiltración de Datos o cualquier tarea maliciosa a la que se haya convencido al modelo que tiene que hacer. Por ejemplo, en el Jailbreak de Knowledge Returning Oriented Prompt donde se conseguía hacer al modelo crear imágenes violentas, un Guardrail sería un modelo con una descripción de las imágenes generadas para ver si alguna tiene violencia, o incumple la política.


En una empresa que tiene un aplicación Web o un API expuesta que recibe datos de usuario que se van a convertir en un Prompt que se ejecuta en un modelo en el backend, cuando va a ser desplegada, debe hacerlo con Guardrails. Si lo hace en Cloudflare, la suite de AI Security clasifica los Prompts que entran en la empresa para detectar los ataques de Jailbreak en Prompt que hayan podido ser Inyectados, pero también se evalúan los datos de salida para evitar incumplimientos de políticas de seguridad, como sesgos, fugas de datos o lenguaje inapropiado. Es decir, se aplican Guardrails para la protección del modelo en el WAF (Web Application Firewall) y en el API Gateway.
Pero si por el contrario es la empresa la que utiliza un modelo externo como servicio, con una arquitectura tipo SaaS, al que sus empleados están enviando los datos, entonces en los servicios de CASB (Cloud Application Security Broker) se evalúa que ningún Prompt enviado desde los empleados está enviando datos confidenciales, ya que la fuga de información puede estar en la respuesta generada por el modelo o en los datos enviados por el cliente como contexto.
Contada toda esta larga introducción, los Guardrails son la siguiente línea que hay que proteger, y por tanto que hay que evaluar su seguridad. 

Ya vimos que saltarse los clasificadores de Prompt podría ser tan sencillo como utilizar lenguaje L33T o caracteres invisibles, por ejemplo, o codificar otras formas de texto que cambiara la clasificación del prompt, como podéis ver en la imagen anterior. Que es el objetivo de Echogram también.

Echogram: Bypassing Guardrails con Flip Tokens

Ahora los investigadores de HiddenLayer proponen con Echogram una automatización del ataque a esos clasificadores en los Guardrails basada en Tokens que cambian su evaluación, es decir, que por el entrenamiento del Clasificador en modo caja negra, se puede comprobar empíricamente que cambian la clasificación de un Prompt. Como podéis ver, en el ejemplo de la imagen, con añadir =coffee, el modelo ha ignorado el System Prompt y ha dicho algo que no diría el modelo. 
Con Echogram se ataca la protección del Guardrail que está evaluando la clasificación del Prompt, pero luego el atacante tendría que conseguir que el Prompt hiciera un Jailbreak en la detección del Harmful Mode del modelo. Esta es solo una pieza más de la cadena de defensas de un servicio digital basado en IA.
A los tokens que cambian la clasificación del Prompt les han llamado Flip Tokens, y no son los mismos para todos los Guardrails ni para todos los Prompts. Además, la adición de tokens, pueden cambiar el comportamiento del modelo con el Token, así que estos Flip Tokens deben no cambiar el comportamiento del modelo ante el Prompt modificado.
Como podéis ver, tanto con Guardrails comerciales, como con un modelo como Qwen3Guard que es OpenSource, se puede conseguir que estos Flip Tokens cambien el veredicto a positivo y el Prompt malicioso acabe pasando las protecciones.
Estas técnicas de pasar las herramientas de protección que filtran los ataques antes de llegar al modelo se suelen llamar "Técnicas de Contrabando" o "Smuggling" porque al final está pasando por la frontera de seguridad escondiendo un contenido prohibido.

Con todo este trabajo, queda también la última parte, que es hacer lo contrario. Un Prompt Benigno pasarlo a malicioso, lo que podría llevar a un ataque de Denegación de Servicio (DoS) usando un ataque de Prompt Injection para envenenar la Memory o directamente la Conversación de una víctima, y haciendo que sus comandos no pasaran por el Guardrail.

Figura 14: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Los equipos de Red Team y de Blue Team han cambiado definitivamente, así que si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 3:23 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , , ,

sábado, noviembre 15, 2025

"Vamos a hacer unas rayas. Yo pongo los pollos" por Nikotxan

Hace unos veinte años, más o menos, recibí un correo de un tal José María Alonso que me decía no sé qué de unas charlas y que se partía de risa con mi webserie Cálico Electrónico, que por aquel entonces acababa de estrenar.

Figura 1: "Vamos a hacer unas rayas. Yo pongo los pollos"
por Nikotxan

Lo siguiente fue una llamada. Ahí sí, me explicó que trabajaba con Microsoft, que daba conferencias sobre ciberseguridad y que quería cerrar sus charlas poniendo un capítulo de Cálico, para terminar con unas risas. Le pregunté:

—¿Y vas a cobrar por ver los capítulos?

A lo que me contestó:

—¡Claro que no!

Así que le dije:

—¡Pues entonces vale!

Y así, sin más, empezó una amistad que sigue viva a día de hoy. Entre medio y hasta el día de hoy hemos hecho comics y tiras de Cálico, 2 temporadas y un sinfín de piezas cortas que han mantenido vivo el universo de Cálico Electrónico.

Figura 2: Las cosas de Cálico Electrónico en 0xWord

Y por eso es un placer presentaros aquí, en el blog más maligno de toda la “internés” mi nuevo proyecto:

POLLO x la PASTA
(¡El juego legal más ilegal de la historia!)

POLLO x la PASTA está protagonizado por DonRamón y Perchita que, después de haber vivido aventuras y desventuras en Yonkiland, vienen a liarla al mundo de los videojuegos.

Figura 3: Pollo X la Pasta

Todo empezó hace unos meses. Yo venía de un Kickstarter que había salido bastante bien — el del pack de muñecos de DonRamón y Perchita — y pensé: “¿y si ahora hacemos un videojuego?”. Así fue como acabé llamando a mi amigo Arturo Monedero, de TLR Games, le propuse hacer un juego y al muy inconsciente le pareció una idea genial.

Figura 4: Nikotxan y TLR Games

Al principio mi idea era hacer un juego arcade ambientado en la ciudad, en pixel art, mundo abierto… vamos, una especie de Grand Theft Auto versión "Yonki". Por suerte, Arturo me bajó a la tierra explicándome lo que eso costaría, y cambié rápidamente de plan.

Y fue entonces que, por pura necesidad, nació la idea de partir de una mecánica sencilla, como el tres en raya, darle algo de estrategia y vestirla con todo el universo de DonRamón y Perchita, con su estilo, sus coñas y sus “negocios” de dudosa legalidad.

Pollos x la Pasta

Así fue como apareció Pollónkiland, una ciudad donde los Corrales Ilegales sustituyen a los casinos clandestinos y donde los pollos son… pues con lo que hay que hacer las rayas, como ha sido toda la vida, ¿no? El caso es que son pollos, pollitos de verdad, con sus plumas y sus picos…(quien entendió, entendió)

Figura 5: Haciendo rayas de pollos

Cada partida es una timba ilegal en toda regla. Colocas tus pollos en el tablero, intentas hacer rayas para duplicar o triplicar su valor y, de paso, fastidias al rival usando Trukis (gadgets diseñados para sabotear, bloquear o directamente aspirarle los pollos al contrario) y Pollos Especiales (Como el Pollo de Plástico o el Pollo Mimo). Y ojo, porque no todos los pollos son iguales: desde el Pollo Básico hasta auténticos ejemplares de lujo como el Pollo Bueno o el Pollo Puro, cada uno tiene su propio valor y carácter.

Figura 6: Lo que valen los pollos

Todo el juego respira (y aspira) el humor y la estética de Cálico Electrónico, con partidas rápidas, tácticas y tremendamente rejugables. Nos hemos currado al detalle los diálogos para que cada personaje tenga su propia colección de amenazas, improperios y frases marca de la casa, de esas que sueltas sin querer mientras juegas.

Figura 7: Combate de Pollo x la Pasta

Queríamos algo tan fácil de entender como imposible de soltar: 30 segundos para pillarlo, y horas para dejarlo. Nada de tutoriales eternos ni mecánicas imposibles: sólo diversión directa, con ese toque de mala leche y nostalgia que huele a Cálico del bueno. Aquí tenéis un "Geimpley" del juego.


Figura 8: GamePlay de Pollo x la Pasta el juego más ilegal de DonRamon y Perchita

Y ahora estamos justo en la fase previa al lanzamiento del Kickstarter, afinando los últimos detalles, con el tráiler lanzado, las campañas en redes sociales y todas esas cosas que hacen que un proyecto pase de “idea loca” a “¡cállate y toma mi dinero!”

Figura 9: Ahora en Kickstarter

El Kickstarter de POLLO x la PASTA se lanzará oficialmente el 19 de noviembre, y si todo sale bien, DonRamón y Perchita volverán a vuestras pantallas… esta vez, con la sana intención de ayudaros a hacer muchas rayas… Si quieres estar al día de este proyecto entra en KICKSTARTER y dale al botón de NOTIFÍCAME CUANDO SE PUBLIQUE para no perderte su lanzamiento mundial!

Figura 10: Apúntate al Kickstarte de Pollo x la Pasta

Si os mola el universo de Cálico Electrónico, las rayas metafóricas (o no tanto), o simplemente os apetece un juego diferente y muy, muy cachondo, seguid de cerca el proyecto. Os espero en Pollónkiland. Vamos a hacer unas rayas. Yo pongo los pollos.

Niko

Publicado por Chema Alonso a las 6:01 a. m. 0 comentarios

Etiquetas: , , , , ,

viernes, noviembre 14, 2025

Hoy en Nerdearla 2025: Firma de Libros y Charla

Como ya os había dicho, hoy estaré en Nerdearla 2025 España en Madrid (en La Nave), y haré un par de cosas por la mañana, antes de irme al medio día que por la tarde tengo también actividades aprovechando mi paso por Madrid. Llegaré pronto hoy a La Nave, y haré la firma de libros a las 10:30 donde podrás pasarte a verme, charlar conmigo, e incluso, si te apetece, que nos hagamos una foto.
Será la firma del libro de "Hacking & Pentesting con Inteligencia Artificial", donde tocamos muchos de los temas de los que voy a hablar en la charla, y como solo tengo un ratito, pues solo hay una caja de 30 libros para los 30 primeros que los queráis. Recordad, de 10:30 a 11:30 será la firma de los libros.
Después, como ya os he dicho estaré, dando mi charla a las 12:50 en el Auditorio Principal de La Nave, donde hablaré de Hacking, Cibeseguridad e Inteligencia Artificial para Hacker & Developer. Ya sabéis, de mis cosas. Será de 12:50 a 13:30 y después, me iré, que tengo comida por Madrid, así que si me quieres ver, esos son los puntos de encuentro.
Pero recuerda que el evento de Nerdearla 2025 tiene una lista de ponentes espectacular encabezada por Donald Knuth y con mis queridos Midudev, Brais Moure, Carlos Azaustre o Daniela Maissi entre tantos grandes desarrolladores, hackers, divulgadores, o expertos en el arte de la creación de tecnología. 
Los organizadores de Nerdearla, Jassu Severini y Ariel Jolo, se han dejado la piel para traer este evento que, ya sabes que es 100% gratuito, a Madrid, así que si estás por la capital y no tienes tu entrada aún, echa un ojo a la web y verás qué pedazo de evento han construido que dura hasta el sábado.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 6:47 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , ,

jueves, noviembre 13, 2025

BlueCodeAgent: Agentic AI para revisar que el código generado con AI Coders es de buena calidad

El otro día os hablaba el paper dedicado a RedCodeAgent, para forzar que una AI Coder genere código peligroso dentro de la organización, y hoy le toca a BlueCodeAgent, que hace justo lo contrario, vigilar que el código que un AI Coder está generando es seguro, sin sesgos, y cumpliendo la política definida por la organización.
Ambos papers están publicados por el equipo de Microsoft Research, que como buena factoría de software que es, está más que interesado en empujar la investigación para que los AI Coders puedan hacer código de confianza que pueda ponerse en producción, así que todo lo que sea mejorar la calidad es fundamental. 
En el artículo de RedCodeAgent lo que se buscaba era ver si un AI Coder podría ser forzado a generar código "maligno", y el resultado era sorprendente por el alto grado de éxito. Ahora en el paper de "BlueCodeAgent: A Blue Teaming Agent Enabled by Automated Red Teaming for CodeGen AI" se busca vigilar el código generado por los AI Coders.
Para hacer este trabajo, lo que hace BlueCodeAgent es comprobar la seguridad de los Prompts solicitados y los códigos generados, es decir, antes y después de que se genere el código para comprobar que al AI Coder le llegue ya un Prompt correcto. Esto, en un ejemplo de detección de Sesgos (BIAS), sería algo como lo que se ve en la siguiente imagen.

Figura 4: Analizando los sesgos en la petición del prompt al AI Coder
con Análisis Directo del prompt

Para esto, el BlueCodeAgent tiene que hacer un análisis del Prompt para analizar los riesgos de generar códigos sesgados, de generar código malicioso que pueda haber sido forzado por un adversario - como se vio en el trabajo de RedCodeAgent - o la política de seguridad definida por la compañía.

Figura 5: Política de constitución de prompts
para evitar sesgos y cumplir los objetivos basado
en BlueCodeAgent

Para dotar de inteligencia a BlueCodeAgent se parte de una Política que define cuáles son los riesgos, más una base de conocimiento de categorías de Prompts maliciosos, más una base de datos de conocimiento sobre vulnerabilidades que se analizan para generar el conocimiento que debe aplicar a los análisis de los Prompts que debe realizar BlueCodeAgent para hacer una generación de código usando el AI Coder ya basada en un filtrado correcto de la petición. 

Figura 6: Análisis de petición de código con base de
conocimiento de BlueCodeAgent

Después se usa el AI Coder, y el resultado da un código que vuelve a ser evaluado buscando vulnerabilidades conocidas en el código al estilo del Red Team, generando al final una base de datos de riesgos o no previamente analizados, lo que incrementa el conocimiento de BlueCodeAgent con su uso. 
Con todo esto, el resultado, pues una detección mejor en los diferentes Benchmarks de detección de Prompts con Sesgos, Pompts con incumplimiento de políticas de programación de la compañía, Prompts Maliciosos o detección de código "buggie", lo que produce lógicamente un mejor código y una reducción de las vulnerabilidades. En el paper se prueban diferentes Benchmarks con diferentes estrategias de otras propuestas.
Los Benchamarks son los que son, es decir, datos y pruebas encapsuladas que no son la totalidad de la realidad, pero al menos sirven para tomar una foto - aunque alguien pueda ponerse "guapo" para la foto y salga mejor en la foto que en la realidad -, pero parece evidente que usar el mayor número de análisis posibles al Prompt y al código generado es una buena estrategia de seguridad, ¿no?

Figura 9: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Puedes leerte el paper para ver más detalles, y si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 6:01 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , ,

miércoles, noviembre 12, 2025

Cómo evitar el ataque de la "Triada Letal" en Agentic AI" con la "Rule of 2"

Hace tiempo que sigo el blog de Simon Willison- ya sabéis que los mayores seguimos leyendo RSS, blogs, y si te pones e-zines en FTPs, news, y BBSs -, y en él habla de seguridad, IA, y de lo que él consideró la "Lethal Trifecta" o "Triada Letal" en la construcción de Agentic AI, y que debe ser una regla de todos los Blue Team a seguir en la fortificación de Agentes AI. 

La idea es muy sencilla, y si revisas todos los caso de ejemplos de exploits en Agentic AI de los que os ido hablando en los últimos meses, todos los entornos acaban cumpliendo la Triada Letal de la que habla Simon Willison.

O lo que es lo mismo, la explotación es posible porque:

1.- El Agentic AI: analiza datos inseguros como contenido en una web, mensajes en un buzón, ficheros con datos escondidos, repositorios de código con mensajes puestos por terceros, etcétera.

2.- El Agentic AI: realiza tareas automáticamente sin supervisión humana accediendo a herramientas o funciones que le dotan de poderes especiales.

3.- El Agentic AI: puede comunicarse exteriormente de alguna manera. 
Si revisas los casos de los que he hablado en estos artículos, verás que todos ellos cumplen sistemáticamente estas tres circunstancias, y por tanto, el atacante fue capaz de conseguir enlazar diferentes debilidades para lograr su objetivo.
Teniendo la "Triada Letal" en la cabeza, el equipo de seguridad de Meta ha propuesto que se cumpla siempre la Rule of 2, o lo que es lo mismo que todos los Agentic AI tengan que elegir qué dos de las tres cosas quieren hacer sin supervisión, y que elijan solo dos de ellas.
Si pensamos en los diferentes casos, utilizar esta regla a la hora de diseñar los Agentic AI incrementa drásticamente la seguridad de los sistemas, y ayuda a mitigar el impacto de cualquier debilidad del sistema, donde ya sabemos que los modelos LLM vienen con Prompt Injection, Jailbreak, Un-Alligment y Hallucinations por defecto.
Teniendo en cuenta estas tres opciones A, B y C, el equipo de Meta ha puesto el caso de varios ejemplos de diseño de agentes para ver cómo impactaría la aplicación de la Rule of 2 en todos ellos. El primer ejemplo es un Agentic AI para hacer de asistente de viaje, se le permite buscar info en Internet, y acceder a los datos personales del usuario, pero se le prohibe hacer acciones con comunicaciones externas, así se evita que haga acciones externas.

Dicho esto, al tener la posibilidad de buscar en la web, el ejemplo de HackedGPT donde utilizan búsquedas en BING con Static-Links para exfiltrar datos seguiría siendo posible. Eso sí, no compraría ni realizaría ninguna acción sin consentimiento del usuarios. Para garantizar la privacidad, no se le debería realizar ninguna búsqueda después de haber accedido a datos sensibles privados.

El siguiente caso es un Agentic AI para hacer búsquedas en la web, al estilo de los utilizados en ChatGPT Atlas o Perplexity Comet, donde ya hemos visto varios casos peligrosos. En este caso, se le restringe a los datos personales y la información privada más allá de los datos iniciales del Prompt. Lógicamente, hacer acciones en el correo electrónico donde hay datos personales no debería estar permitido, porque si no se pueden acceder a contraseñas como hemos visto en casos anteriore.

El último caso es un Agentic AI para programar, y en este caso se le prohibe acceder a fuentes inseguras como la web, el correo electrónico donde haya posible Spam o repositorios de código no controlados, para evitar el envenenamiento del modelo y la creación de código troyanizado o inseguro como hemos visto en algunos trabajos.

No es una Silver Bullet, pero sí que ayuda a mejorar la seguridad de la plataforma de Agentic AI que estes desarrollando para tu empresa, así que, dale mucho cuidado a los permisos de tus agentes. Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Publicado por Chema Alonso a las 6:01 a. m. 0 comentarios

Etiquetas: , , , , , , , , , , , , , ,

Suscribirse a: Comentarios (Atom)

Entrada destacada

+300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial

Hace un mes comencé a recuperar en un post mi interés en los últimos años, donde he publicado muchos artículos en este blog , y he dejado mu...

Entradas populares