En 2023 el red teaming de modelos de lenguaje era una disciplina experimental que practicaba un puñado de equipos de investigación. Hoy es un requisito de cumplimiento para cualquier sistema agente que manipule datos sensibles o dispare acciones reales. La diferencia de tres años es la combinación de tres factores: los ataques se han profesionalizado, los marcos han convergido, y los reguladores han empezado a pedir evidencia.

Este artículo recoge el manual operativo que uso personalmente al revisar agentes en producción. No es teoría; son los vectores de ataque que realmente rompen sistemas, las defensas que realmente cortan ataques, y los errores que cuestan más tiempo del que se invirtió en construir el agente.

Puntos clave

  • La prompt injection sigue siendo el vector número uno, pero solo 1 de cada 10 incidentes llega por entrada directa del usuario; los otros 9 llegan por herramientas, RAG, documentos y memoria.

  • Los ataques de rol con personaje ficticio tienen tasa de éxito del 89,6 % en modelos sin protección adecuada, según estudios recientes.

  • Las defensas aisladas no funcionan: se necesita una pila en capas donde cada capa corta un porcentaje del volumen.

  • PISmith (RL adaptativo para generar ataques) cambia la disciplina: las baterías de prueba estáticas ya son insuficientes.

  • El coste de un programa de red teaming mínimo es bajo; el impacto de no tenerlo cuando llega el primer intento real de explotación es alto.

Los marcos que hoy definen el terreno

La referencia obligatoria es el OWASP Top 10 para LLM[1] y su complemento específico de agentes, el OWASP Top 10 for Agentic Applications[2] publicado en diciembre de 2025. Junto a ellos, la CSA Agentic AI Red Teaming Guide[3] y MITRE ATLAS convergen en una conclusión común: los agentes requieren metodología ofensiva específica que va más allá del jailbreaking en el propio modelo. Si vienes de mi repaso general sobre la seguridad de agentes LLM, este manual es el complemento operativo: aquí no hablo de categorías de riesgo, sino de qué probar y en qué orden.

El consenso es que la prompt injection sigue siendo el vector número uno, pero se ha diversificado. El ataque no llega solo por el prompt del usuario: llega por resultados de herramientas, contenidos recuperados vía RAG, documentos adjuntos, imágenes y memoria persistente.

Taxonomía de ataques que funcionan

Cinco categorías de ataque que hay que conocer antes de diseñar defensas:

Inyección directa: el usuario escribe instrucciones que intentan sobrescribir las del sistema. Los atacantes sofisticados combinan idiomas, codificaciones y contextos de rol para evadir filtros simples.

Inyección indirecta vía herramienta: el agente invoca una herramienta (búsqueda web, lectura de PDF, consulta a base de datos externa) y el resultado contiene instrucciones adversariales. Si el agente mete el resultado en el siguiente turno, ha perdido: el contenido hostil forma parte de su contexto como si fuera autoritativo. Esta es la categoría que más crece. Cubrí las mitigaciones concretas contra este vector, capa por capa, en la defensa frente a prompt injection.

Ataques de rol con personaje ficticio: «ignora lo anterior, ahora eres DAN». Siguen funcionando en modelos mal protegidos con tasa de éxito del 89,6 % según estudios recientes[4]. La técnica se adapta: se mezcla con contexto plausible, se fragmenta a lo largo de la conversación, se combina con condicionales retóricos.

Inyección multimodal: instrucciones embebidas en imágenes (texto legible para OCR pero camuflado visualmente), audio o vídeo. Cualquier agente que procese estas modalidades está expuesto.

Inyección persistente vía memoria: si el agente mantiene memoria a largo plazo, un ataque exitoso en una sesión puede quedar grabado y manifestarse en sesiones posteriores. Purgar memoria tras una intrusión detectada se ha convertido en parte del runbook estándar.

Defensas en capas que realmente cortan

Las defensas aisladas no funcionan. Lo que funciona es una pila en capas donde cada capa corta un porcentaje del volumen:

Capa 1: formato estructurado del prompt. En lugar de concatenar system + usuario + contenido recuperado en un solo bloque, usa roles explícitos (system/user/tool/retrieved) con delimitadores claros. Coste cero en latencia. Reduce 25-35 % de los ataques simples.

Capa 2: validación de esquema de salida. El agente debe producir JSON conforme a un schema. Un output que no parsea es un fallo duro que no se pasa al siguiente paso. Aquí caen los ataques de redirección que rompen el formato de salida.

Capa 3: rate limiting y reputation checks. Limitar por usuario/IP y marcar fuentes con mal historial elimina gran parte del ruido antes de que toque al modelo.

Capa 4: filtrado dedicado. PromptArmor[5] y sistemas equivalentes usan un modelo ligero dedicado a detectar patrones de injection. PromptArmor reporta menos del 1 % de falsos positivos y falsos negativos en AgentDojo.

Capa 5: monitorización de llamadas a herramientas. Las herramientas que tocan datos sensibles o ejecutan acciones deben tener política explícita: qué parámetros son aceptables, cuántas llamadas por turno, qué combinaciones están prohibidas.

Capa 6: voto multi-modelo en acciones sensibles. Para decisiones críticas (borrar datos, enviar dinero, acceder a PII masivo), se consulta a dos o tres modelos distintos y solo se procede si hay consenso. Duplica el coste pero elimina toda una clase de ataques.

PISmith y el red teaming adversarial automatizado

PISmith[6], publicado a principios del año, entrena un modelo atacante que optimiza prompts inyectados en escenarios caja negra usando aprendizaje por refuerzo. El resultado es un generador de ataques que adapta su estrategia al comportamiento del sistema objetivo.

Esto cambia la disciplina en dos direcciones:

  • Para defensores: la batería de pruebas ya no puede ser estática; hay que incluir un atacante adaptativo que busca debilidades del sistema específico.

  • Para equipos rojos: un ingeniero con herramientas como PISmith puede cubrir en una semana lo que antes requería un equipo durante un mes.

La consecuencia práctica: los ejercicios de red teaming anuales se han quedado cortos. El patrón que funciona es pruebas continuas con atacantes generativos en staging, con revisiones humanas trimestrales sobre los hallazgos más significativos.

Los tres errores más caros

Tres patrones que siguen apareciendo en incidentes:

Confiar en system prompts para guardar secretos: «nunca reveles esta clave de API» en el system prompt es estadísticamente el mejor predictor de que esa clave será revelada en los próximos 30 días. Las claves deben estar en sistemas fuera del alcance del modelo, inyectados por el runtime solo cuando hace falta.

Asumir que el filtro del proveedor protege: los filtros de Claude, GPT o Gemini detectan un subconjunto de ataques conocidos y varían con cada versión del modelo. Depender exclusivamente de ellos es dejar la seguridad en manos ajenas.

No registrar lo suficiente para reproducir incidentes: sin la traza completa (entrada, contenido recuperado, llamadas a herramientas con sus resultados, estado final), el equipo acaba especulando en lugar de analizando.

Cómo empezar si no tienes nada

Para un equipo sin programa previo, el camino mínimo:

  • Semana 1: catálogo de vectores (los de esta lista más los específicos del dominio).

  • Semana 2: batería de 40-50 ataques manuales representativos ejecutados contra el agente en staging, con resultados documentados.

  • Semana 3: primera capa de defensa (formato estructurado y validación de schema) implementada y la batería rebatida.

  • Semana 4: integración en CI para que la batería corra en cada despliegue.

En tres meses, un equipo puede pasar de cero a un pipeline que bloquea regresiones de seguridad al mismo nivel que bloquea regresiones funcionales.

Conclusión

El LLM red teaming ya no es una disciplina opcional reservada a los equipos más ambiciosos. Es higiene básica para cualquier agente que toque algo que importe. Los marcos están, las herramientas están, las técnicas están documentadas.

Donde todavía no se hace, lo único que falta es la decisión de tratar al modelo como el componente crítico que es. Eso significa someterlo a las mismas disciplinas de seguridad que aplicamos al resto de la pila. Quien lo hace duerme tranquilo; quien no, paga el precio completo cuando ocurre el primer fallo.

¿Lees en inglés? Versión completa: LLM red teaming: a practical playbook.

Fuentes:

  1. OWASP: Top 10 for LLM Applications[1]
  2. OWASP: Top 10 for Agentic Applications[2]
  3. CSA / OWASP: Agentic AI Red Teaming Guide[3]
  4. arXiv: estudio sobre tasa de éxito de ataques de rol con personaje ficticio[4]
  5. DeepTeam: qué es el LLM red teaming (PromptArmor y filtrado dedicado)[5]
  6. arXiv: PISmith, red teaming adversarial con aprendizaje por refuerzo[6]

Preguntas frecuentes

¿Es seguro guardar una clave de API en el system prompt si le digo al modelo que nunca la revele?

No. Escribir «nunca reveles esta clave de API» en el system prompt es estadísticamente el mejor predictor de que esa clave será revelada en los próximos 30 días. Las claves deben vivir en sistemas fuera del alcance del modelo y ser inyectadas por el runtime solo cuando hacen falta. Tampoco basta con el filtro del proveedor: los filtros de Claude, GPT o Gemini detectan un subconjunto de ataques conocidos y cambian con cada versión del modelo.

¿Por dónde entran realmente los ataques de prompt injection en un agente?

Solo 1 de cada 10 incidentes llega por entrada directa del usuario; los otros 9 llegan por resultados de herramientas, contenidos recuperados vía RAG, documentos adjuntos, imágenes y memoria persistente. La categoría que más crece es la inyección indirecta vía herramienta. Si el agente mete el resultado de una búsqueda web o un PDF en el siguiente turno, el contenido hostil pasa a formar parte de su contexto como si fuera autoritativo.

¿Cuánto tarda un equipo sin nada en montar un programa mínimo de red teaming?

Cuatro semanas para el camino mínimo, con la semana 1 dedicada al catálogo de vectores, incluidos los específicos del dominio. Semana 2: batería de 40-50 ataques manuales ejecutados contra el agente en staging con resultados documentados. Semana 3: primera capa de defensa (formato estructurado del prompt y validación de schema de salida) y la batería repetida. Semana 4: integración en CI para que corra en cada despliegue, y en tres meses el pipeline bloquea regresiones de seguridad igual que las funcionales.

Fuentes

  1. OWASP Top 10 para LLM
  2. OWASP Top 10 for Agentic Applications
  3. CSA Agentic AI Red Teaming Guide
  4. tasa de éxito del 89,6 % según estudios recientes
  5. PromptArmor
  6. PISmith