Mostrando entradas con la etiqueta Blue Team. Mostrar todas las entradas
Mostrando entradas con la etiqueta Blue Team. Mostrar todas las entradas

lunes, diciembre 15, 2025

Cómo desplegar Inteligencia Artificial con seguridad en una empresa

El uso de LLMs, de modelos avanzados de DeepReasoning, la construcción de Agentes IA para hacer tareas en tu empresa, la construcción de servicios digitales basados en IA que dan servicios a empleados y clientes, la habilitación de herramientas de IA para los empleados, o simplemente la nueva generación de atacantes armados con modelos de IA para la explotación que obligan a una nueva generación de expertos de ciberseguridad que use la IA para defenderse, ha abierto un ecosistema exponencial de puntos de riesgo que hay que evaluar, y no es nada sencillo.

Dejadme que vayamos por partes, a ver si soy capaz de transmitiros el puzzle que todos los que trabajamos en ciberseguridad con Inteligencia Artificial llevamos en la cabeza, y que veáis la cantidad de controles que deben ser añadidos para que se pueda tener un servicio de IA desplegado con seguridad. 

Si tienes dudas de los riesgos, no dejes de verte esta charla que te ayudará a entenderlo, y si quieres aprender más aún, te recomiendo que te compres el libro de "Hacking & Pentesting con Inteligencia Artificial" que te va a encantar.
Vamos por partes en alto nivel, y ya iré desgranando cada una de estas partes en muchos más artículos, que tenemos un año 2026 por delante completo para llenar de posts, pero partamos de este gráfico que usamos en Cloudflare que recoge un poco la complejidad del ecosistema. 

Tenemos clientes, empleados, aplicaciones construidas con modelos de IA y servicios SaaS remotos que son utilizados por tus empleados y APIS conectados. Y todos ellos pueden convertirse en maliciosos y ser un atacante, así que sobre este ecosistema primero hay que tener Visibilidad, para luego poder añadir Controles de Uso, Protección de Datos, Mitigación de ataques y amenazas, y hacerlo en todos los puntos de interacción, que como vamos a ver son muchos distintos y necesitamos diferentes herramientas.

Mis empleados usan herramientas/Servicios/productos de IA en SaaS

Este es el primero de los casos de uso. Sencillo. Tus usuarios quieren utilizar algo como ChatGPT, Gemini o Perplexity en la empresa para pedirle cosas, pero no están conectados a tu arquitectura de datos. No hay RAG, ni nada parecido. Solo empleados enviando Prompts a servicios SaaS. Aquí el riesgo es que datos confidenciales de la empresa pasen a formar parte de los datos de entrenamiento de los servicios SaaS, así que hay que controlar vía legal, y vía técnica, que esto no pase.
Para ello, puedes buscar servicios empresariales que garanticen que los datos de tus empleados no van a ser utilizados para entrenar los modelos, y que están en instancias aisladas que los protegen. Pero ... ¿es suficiente? No, esto te garantiza que los datos que están yendo a los servicios autorizados por la empresa no van a ser utilizados para entrenamiento, pero hay que controlar qué otros servicios utilizan tus empleados, para bloquearlos o monitorizarlos. Incluso siendo un servicio autorizado, deberías controlar qué están enviando allí.
Para eso, debes desplegar en la empresa un solución de WAF hacia dentro, y de CASB hacia fuera, y sobre ellas asegurarte que tienes visibilidad de a dónde se están conectando, qué están enviando, y tener políticas de bloqueo para evitar la fuga de datos, así que necesitas añadir reglas de DLP (Data Loss Prevention) en esas conexiones. 

Mis empleados conectan modelos y agentes de IA a sus datos privados

Estamos en las arquitecturas RAG para usuarios, donde los agentes pueden acceder a sus datos personales para hacer tareas, ya sea un Copilot personal, o un agente de ChatGPT con conexión a su Cloud Drive, o un Gemini conectado a su calendario y su correo personal o profesional. En este caso, tenemos todos los problemas de de ataques a empleados con técnicas de Indirect Pompt Injection de los que tanto hemos hablado, así que hay que utilizar filtros de seguridad para detectar todos los ataques que vayan en los datos de entrada. Que hemos visto muchos. Aquí te dejo para que leas.
Esto quiere decir que las herramientas de e-Mail seguro, de detección de ataques de phishing, de Navegación Segura, tienen que estar monitorizando los puntos de entrada de datos para detectar los ataques de Prompt Injection que puedan estar en webs, correos electrónicos o ficheros adjuntos. Por supuesto, controlar el despliegue y proliferación de AI-Web Browsers como Atlas o Comet, que puede ser un foco de problemas dentro de la organización.

Mis aplicaciones se conectan a modelos LLM para hacer cosas con mis datos

En este caso es una aplicación de la empresa que se conecta a un modelo LLM, donde podemos tener muchos problemas que no nos gustan. Por eso necesitamos construir Guardarraíles para controlar, el consumo, la fuga de datos con peticiones que vayan de la aplicación al modelo usando reglas DLP, los ataques de Prompt Maliciosos, detectar posibles ataques de Prompt Injection o Jailbreak, y luego filtrar las respuestas del LLM antes de hacer acciones con ellas o enviarlas a clientes o empleados, para que no haya respuestas con sesgos, alucinaciones, peligrosas, o con fugas de datos.
Para ello es necesario construir un AI Gateway entre la aplicación y el modelo LLM para controlar los datos que van en el Prompt y los resultados que están llegando. Pero también para controlar a alto nivel, si se ha producido un desalineamiento entre el "intent" inicial y las acciones que se están realizando en este momento. Puede que el Prompt fuera normal "Resume este documento", pero el Prompt Injection estuviera en el Doc y desalineara al modelo para hacer cosas malas.
Así que, debes tener un control exhaustivo entre tu aplicación y el modelo LLM que da poder al backend de tus servicios, porque puede ser un punto peligroso y de riesgo en tu arquitectura.

Mi aplicación está abierta a Internet (Vía Web o vía API)

Llegamos al punto divertido. Estamos en Internet, y publicamos una aplicación web, una aplicación, o una API. Sea el caso que sea, primero necesitamos tener visibilidad de quién se está conectando. Y no es trivial. Antes los "bots" eran siempre automatismos malos - excepto en las APIs -, pero ahora pueden ser Agentes AI, así que hay que discernir bien qué hacer. Primero, debes tener un WAF que te visibilidad de las Non-Human Identities en forma de Bots que se están conectando a tu web o aplicación. 
Estas NHI generan costes de cloud en transferencia de datos, y en computo, así que elegir quiénes quieres que se nutran de tus datos o servicios es un primer punto de decisión para saber si quieres bloquearlos, dejarles pasar o exigirles un pago con un servicio Pay-Per-Crawl. Para que os hagáis una idea, hoy en día hay identificados 497 diferentes Verified Bots, donde se mira la petición y la dirección IP de origen que están utilizando para hacer "crawling" de Internet, e incluso detectar cuando alguno hace algo de "cloacking". 

En segundo lugar, tienes que tener WAF y un API Gateway con reglas para detectar los ataques automatizados, y los endpoints peligrosos, como hemos hecho siempre, pero una vez que estamos hablando de Aplicaciones y APIs que tienen en el backend conexiones a LLMs - ya sea locales en la empresa o remotos, conectados vía un AI Gateway -, necesitas crear Guardarrailes para detectar, una vez más, y un Firewall for AI para detectar los ataques de Pompts Maliciosos, Prompt Injection, Jailbreak, las fugas de datos con reglas DLP, alucinaciones, Bias, datos erróneos sensibles o los problemas de desalineamiento entre la petición y la respuesta, además de la política corporativa de la empresa.

Figura 11: Firewall for AI

Además, si quiero hacer todos estos análisis personalizados y con alto rendimiento, probablemente tenga que hacerlos en el Edge utilizando modelos de IA entrenados para detectar estos ataques, o configurados por ti de manera especial para que protejan todo lo que está entrando y saliendo de tus aplicaciones, así que necesitaras Workers con modelos de IA para inferencia. 

Tengo un MCP para los modelos de AI

Vamos al siguiente nivel, donde ahora lo que tenemos es un MCP Server abierto para que modelos o Agentes AI se conecten a las capacidades que ofrecen tus aplicaciones. Una autopista para los Agentic AI que abre tus capacidades. 
Pero... ¿es ese Agente AI peligroso? Pues lo mismo, necesitas Guardarrrailes para todo lo que se está comunicando en ambas direcciones, con reglas y protecciones diferentes en cada uno de los canales.
Si has llegado hasta aquí, verás que cada uno de estos puntos es un hilo de configuración completo con una suite de herramientas, puntos de análisis de seguridad, y sobre todo con cambios diarios - cada hora -, sobre los riesgos y las protecciones, porque las amenazas están activas las 24 horas del día, y como he dicho muchas veces, nos faltan muchas medidas de seguridad en los modelos que hemos construido.

Threat AI-Intelligence

Por supuesto, en este mundo se necesita un servicio de WAF con Threat AI-Intelligence que vaya detectando las amenazas globales y dándote configuraciones automáticas de reglas de protección contra los nuevos ataques de AI (Prompt Injection, Jailbreak, etc...), así como las nuevas NHI detectadas, las nuevas botnets de atacantes, etcétera. Esto lo hace automáticamente Cloudflare en sus servicios, pero ademas existe Cloudforce ONE si quieres solo la inteligencia.

Figura 14: Cloudforce ONE

Con la llegada de las AI-Enterprises, este tipo de riesgos con AI pueden hacer mucho, mucho, mucho daño hoy en día y en el futuro, porque el que un atacante pueda controlar un LLM interno puede darle mucho, mucho, mucho poder.

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

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)  

Figura 15: Contactar con Chema Alonso

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

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

domingo, noviembre 16, 2025

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: , , , , , , , , , , , , , ,

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: Entradas (Atom)

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares