hego.red - Notas prácticas de red teaming de IA/LLM

Notas prácticas de red teaming de IA/LLM

Empieza aquí

Bienvenido. Estas son notas prácticas y directas sobre red teaming de LLM, escritas desde el punto de vista de un pentester. Usa las pestañas de arriba para moverte: Fundamentos explica qué estás probando en realidad, Ataques y Metodología son el cómo, Bootcamp es un curso guiado y PortSwigger trae laboratorios resueltos, Alcance y Flujo de ataque te ayudan a delimitar un objetivo, y Terminología es el diccionario rápido. ¿Primera vez aquí? Solo lee esta pestaña de arriba abajo. Pulsa / en cualquier momento para buscar en todo.

Fundamentos: ¿qué estamos probando en realidad?

Lee esto primero. En un minuto te muestra qué es realmente una "función de IA", las palabras modelo / chatbot / agente, y cómo la IA genera una respuesta. Una vez que ves el panorama, las demás pestañas cobran sentido.

1. Pruebas la app, no el cerebro

Una "función de IA" no es más que una app normal con un modelo de IA enchufado. Pruebas la app que construyó el cliente. El cerebro del modelo suele ser del proveedor (Claude, OpenAI) y queda fuera de alcance.

Tú / el cuadro de chat
donde escribes tu mensaje
↓
La AppESTO ES LO QUE PRUEBAS
el cliente construyó esta parte:
  • añade reglas ocultas (el prompt del sistema)
  • puede leer documentos o una base de datos (RAG)
  • puede llamar a herramientas (email, base de datos, ejecutar código)
  • muestra la respuesta al usuario
↓
El Modelo / "el cerebro"normalmente del proveedor
solo convierte texto en más texto
Casi todos los bugs viven en la caja verde (la app), no en el cerebro. Hacer que el cerebro diga algo grosero es problema del proveedor, no un hallazgo real.

2. Modelo vs Chatbot vs Agente

Estas tres palabras confunden a todo el mundo. Es solo una escalera: cada peldaño añade una cosa.

Modelo (LLM)
el cerebro. Lee texto, adivina la siguiente palabra. Eso es todo.
→
Chatbot
modelo + reglas ocultas + una ventana de chat. Conversa contigo.
→
App RAG
chatbot + puede leer documentos y tus datos.
→
Agente
modelo + herramientas. Puede HACER cosas y dar pasos, no solo hablar.

Cuanto más a la derecha, más puede hacer, y más puedes atacar tú.

3. Cómo genera una respuesta

El modelo no "piensa". Lee texto y adivina la siguiente palabra, una y otra vez. Lo que merece la pena mirar no es el adivinar, es quién escribió el texto del que adivina. Cinco tipos de texto acaban delante de él, y solo uno lo escribió la gente que construyó la aplicación.

Prompt del sistemaLo escribe quien desarrolla. El único texto de aquí que la aplicación posee, y el premio para cualquiera que consiga que el modelo lo repita. ↳ fuga del prompt
Tu mensajeLo escribe quien esté tecleando. En un chatbot público, eso es cualquiera del mundo. ↳ inyección directa
Un documentoLo escribe quien redactó el archivo, la página o el registro. Cualquiera que pueda dejar uno donde la aplicación vaya a leerlo ya está escribiendo al modelo. ↳ inyección indirecta
Resultado de una herramientaLo escribe quien controla aquello que la herramienta tocó: un sitio web, una API, un buzón, una fila de una base de datos. ↳ secuestro del agente
La respuestaLo escribe el modelo a partir de todo lo anterior. Cualquier fuente que nombre es algo que generó, no algo que el runtime siguiera. ↳ salida insegura

Una sola imagen, de izquierda a derecha. Cinco tipos de texto llegan por la izquierda, se unen en una sola cadena y se entregan al modelo. Fíjate en el documento ámbar: se sienta dentro del turno verde de user, y cuando el modelo lo tiene, ya no está. Cada caja lleva el ataque en el que se convierte, y las tres marcas discontinuas son los únicos sitios donde puede ponerse un control.

siguiente turno: lo que viste vuelve como historial Prompt del sistemalo escribió quien desarrolla ↳ fuga del prompt Historial del chatturnos previos, ya en gris ↳ envenenamiento de memoria Tu mensajequien esté tecleando ↳ inyección directa Documento recuperadoquien redactó el archivo ↳ inyección indirecta Herramientaquien controla el sitio ↳ secuestro del agente ensamblado del prompt añade tags de rol filtro de entrada VENTANA DE CONTEXTO system assistant tool user documento pegado el modelo system assistant tool user los roles sobreviven, los autores no 1 los roles son tokens 2 lee todo lo anterior 3 predice el siguiente un rol es tendencia, no regla filtro de salida Lo que vesmarkdown, enlaces, imágenes ↳ salida insegura La respuestauna masa gris las citas son generadas Uso de herramientasi la pidió ↳ agencia excesiva aprobar la herramienta Un sitio web, una API,un buzón, una fila de BD ↳ exfiltración de datos el bucle del agente: lo que trajo vuelve como texto 1234567

Cada flecha lleva texto. Las etiquetas de rol sobreviven hasta dentro del modelo, pero etiquetan turnos y no autores, y los tres controles están fuera de la caja.

  1. Cinco fuentes. Solo la primera la escribió la gente que construyó la aplicación. Las otras cuatro vienen de quien teclea, de quien redactó un archivo, o de quien controla un sitio que la aplicación tocó. Una imagen también cuenta, porque el modelo lee el texto que hay dentro.
  2. Una plantilla las une, con una etiqueta de rol en cada turno. Las etiquetas son reales y sobreviven hasta la secuencia de tokens. Marcan turnos. No marcan quién escribió el texto que hay dentro de un turno.
  3. La ventana de contexto es un límite de longitud, no un almacén. Cuando una conversación la desborda, algo tiene que salir. La mayoría de apps fijan el prompt del sistema y sacan del medio o resumen; las ingenuas sacan por arriba y lo pierden.
  4. El modelo lo lee como una sola secuencia. Cada token lee todo lo que va antes y nada de lo que va después, y por eso el texto colocado al principio dirige todo lo que sigue. Predice un token, lo añade, y vuelve a correr.
  5. La respuesta sale sin procedencia. Si cita una fuente, esa cita la escribió la misma pasada que leyó el texto envenenado. Es una afirmación, no una cadena de custodia.
  6. Se muestra, o se convierte en una llamada a una herramienta. Mostrarla ejecuta markdown, enlaces e imágenes en tu navegador. Una llamada sale hacia algo que la aplicación no controla.
  7. Las dos vuelven. Lo que viste regresa como historial, lo que trajo la herramienta regresa como texto nuevo, y la siguiente petición arranca con más material que nadie avaló.

4. La única falla de la que sale todo

Vuelve a mirar la caja del modelo en el diagrama. Las etiquetas de rol entraron y salieron por el otro lado, pero el documento ámbar no: quedó plegado dentro del turno verde de user, y dentro del modelo ya no queda nada que diga que lo escribió un desconocido.

Los roles son reales. Una API moderna recibe system, user, assistant y tool como campos separados, y sobreviven hasta la secuencia de tokens como tokens delimitadores. Lo que no sobrevive es nada más fino que un turno.

Un documento recuperado no tiene un rol propio. Se pega dentro de un turno user, o dentro de un turno tool, así que cuando el modelo lo lee lleva exactamente el rango del turno en el que lo metieron. Lo mismo pasa con lo que trae una herramienta: la envoltura y el sitio de quien ataca son una sola masa bajo una sola etiqueta.

Y un rol es una tendencia, no un permiso. A los modelos se les entrena para dar más peso a una instrucción de system que a una de user, y la mayor parte del tiempo ese entrenamiento aguanta. Es una tendencia aprendida de ejemplos, no una regla que el runtime imponga, y por eso una instrucción lo bastante segura de sí misma dentro de una salida de herramienta todavía puede ganar. Instrucción y datos siguen siendo el mismo material.

Así que los controles que existen de verdad se sitúan antes de esta caja o después: filtros de entrada, listas de permitidos en la recuperación, escáneres de salida, aprobación de herramientas, sandboxes. Los que intentan trabajar dentro, como el entrenamiento de jerarquía de instrucciones, también son tendencias, y las tendencias se doblan. Y por eso la pregunta útil nunca es "¿es seguro el modelo?". Es sobre cuáles de estas flechas puede escribir quien ataca, y qué hay al otro lado de la caja cuando lo hace.

Este es el juego entero: las etiquetas de rol marcan turnos, no autores, así que un texto que llegó como dato puede actuar como una instrucción. Eso es la inyección de prompts, y casi todos los demás ataques se construyen encima.

5. Entonces, ¿dónde están los bugs?

Cada capa que viste arriba tiene su propio bug. Este es el OWASP LLM Top 10, en palabras sencillas:

CapaEl bug
Tu entradaInyección de prompts: tu texto actúa como un comando.
El modeloJailbreak (romper su seguridad); si está ajustado, filtrar sus datos de entrenamiento.
Documentos / RAGEnvenenar los documentos para que el modelo los obedezca (inyección indirecta).
HerramientasHacer que use una herramienta que no debería, o atacar la entrada de la herramienta (SQLi, SSRF, ejecutar código).
La respuesta que se muestraManejo inseguro de la salida: la app ejecuta la respuesta como HTML/SQL, y llegan XSS y compañía.

6. El riesgo depende de la app

La misma respuesta puede estar bien en una app y ser un desastre en otra. Así que antes de probar, pregunta: ¿para qué sirve esta app y qué contaría como "malo" aquí?

AppCómo se ve lo "malo"
Generador de historias / juegosquiere salidas creativas y disparatadas: casi todo vale.
Bot interno de RR. HH. o soportedebe ceñirse a los hechos: inventarse una política es el bug.
Redactor de emails para la empresadebe ser honesto pero acorde a la marca: un texto grosero o deshonesto es el bug.

Normalmente quieres la inteligencia del modelo (buen lenguaje y razonamiento), no su conocimiento: debería responder a partir de tus datos y decir "no lo sé" en caso contrario.

Dos mitos que descartar. (1) "El riesgo de la IA son solo robots de ciencia ficción tomando el control." No: los riesgos reales están aquí ya: tu bot puede filtrar datos, dar respuestas dañinas o hacer que demanden a la empresa hoy mismo. (2) "Un modelo más grande y listo es más seguro." Las puntuaciones de benchmark no te dicen qué tan seguro es en TU app. Prueba tu app, no el ranking.

Fuentes: OWASP Top 10 for LLM Apps, PortSwigger Web LLM attacks, MITRE ATLAS. Siguiente: la pestaña Terminología para las palabras, luego Metodología para el plan.