Red teaming para agentes de IA: cómo detectar vulnerabilidades de forma sistemática

El red teaming para agentes de IA consiste en atacar agentes de IA de forma sistemática y simulada para detectar vulnerabilidades como la inyección de prompts, los jailbreaks, el uso indebido de herramientas y la fuga de datos antes de que los exploten atacantes reales. Combina herramientas de ataque automatizadas con la creatividad manual de los ataques en varias fases y ofrece resultados medibles, como tasas de éxito de ataque, en lugar de listas binarias de vulnerabilidades. A diferencia de una prueba funcional, no pregunta «¿funciona el agente?», sino «¿cómo se puede abusar de él en contra de su verdadero propósito?».

Este artículo forma parte del hub «Seguridad de agentes de IA según OWASP» y concreta cómo puedes comprobar de forma ofensiva los riesgos catalogados en el OWASP Agentic Top 10 (ASI01–ASI10).

Tres respuestas rápidas

• ¿Qué se ataca? La superficie de ataque específica de los agentes: no solo el modelo, sino también las llamadas a herramientas, la memoria persistente, la comunicación entre agentes y el human-in-the-loop. El objetivo es detectar el secuestro de objetivos, el uso indebido de herramientas, el envenenamiento de memoria y la fuga de datos.
• ¿Con qué? Escáneres open source (Garak, PyRIT, DeepTeam, Promptfoo) para la amplitud, red teaming manual para los ataques de varias fases y bug bounty para la cobertura a largo plazo.
• ¿Con qué frecuencia? Línea base trimestral más pruebas activadas por eventos (nuevas herramientas, cambios en el prompt, actualizaciones del modelo, CVE críticos).

Por qué el red teaming de IA no es un pentest clásico

La distinción más importante, de entrada: el red teaming de IA no es sinónimo de una prueba de penetración tradicional. Los equipos de compras confunden ambos con frecuencia, con consecuencias caras cuando se acepta un pentest con Burp Suite como «prueba de seguridad de IA».

Las diferencias son de fondo:

Un agente de IA a menudo ni siquiera «se rompe» en el sentido clásico: sigue instrucciones que, mediante engaño, ha tomado por legítimas. Como los agentes y el modelo subyacente no pueden distinguir de forma fiable entre instrucciones y datos, cualquier texto que lea el agente forma parte de la superficie de ataque. Eso exige otra disciplina de pruebas.

Qué vulnerabilidades busca un red team de forma específica

El red teaming recorre las clases de amenaza específicas de agentes del OWASP Agentic Top 10. En la práctica, eso significa construir deliberadamente los siguientes ataques:

• Inyección de prompts / secuestro de objetivos (ASI01). Inyección directa e indirecta, instrucciones ocultas en documentos, el corpus RAG, correos electrónicos, invitaciones de calendario, descripciones de PR o salidas de herramientas. Especialmente pérfida es la deriva multi-turn «boiling frog», en la que cada paso por separado parece plausible, pero la trayectoria acumulada es maliciosa.
• Jailbreaks. Eludir las barreras de seguridad para provocar acciones o contenidos prohibidos.
• Uso indebido de herramientas (ASI02). Una función legítima (p. ej., send_email) se usa para otro fin; se explotan los modos de aprobación automática o «YOLO», que desactivan las solicitudes de confirmación.
• Envenenamiento de memoria y de contexto (ASI06). Un contenido inyectado una sola vez envenena la memoria persistente de forma duradera; la «delayed tool invocation» se activa semanas después con una palabra desencadenante.
• Fuga de datos. Exfiltración mediante imágenes Markdown manipuladas, cadenas de redirecciones o proxies usados de forma indebida.
• Ataques entre agentes (ASI07) y explotación de la confianza humano-agente (ASI09). Mensajes falsificados entre agentes y la neutralización deliberada de la capa de aprobación humana mediante recomendaciones redactadas con aplomo, pero manipuladas.

Que estos ataques son reales lo demuestran incidentes documentados: EchoLeak (CVE-2025-32711, CVSS 9.3 según Microsoft) fue la primera inyección de prompts zero-click real en un sistema LLM en producción y eludió el clasificador XPIA (Cross-Prompt Injection Attempt) de Microsoft. CamoLeak (CVSS 9.6) exfiltró carácter a carácter secretos de repositorios privados y código fuente a través del propio proxy de imágenes Camo de GitHub. Ambos casos lo dejan claro: investigadores competentes han eludido en cuestión de meses cada guardrail publicado.

Enfoque: automatizado frente a manual

Un red teaming maduro combina dos modos que se complementan.

Automatizado significa escala y repetibilidad. Los escáneres lanzan amplias bibliotecas de sondas contra el agente y miden qué porcentaje logra pasar. Son adecuados para la integración continua en CI/CD y para pruebas de regresión tras cada cambio. Punto débil: encuentran sobre todo patrones de ataque conocidos.

Manual significa creatividad y contexto. Analistas experimentados construyen campañas de varias fases adaptadas al agente concreto, justo los ataques que los escáneres no detectan. Ejemplos de la investigación: el «Agent Session Smuggling» contra el protocolo A2A (Palo Alto Unit 42, 31 de octubre de 2025) no es una inyección de un solo intento, sino una campaña sostenida de ingeniería social de agente contra agente. A2A lo desarrolló Google y, desde junio de 2025, el protocolo está en manos de la Linux Foundation. El ataque a la memoria de Google Gemini (Johann Rehberger, febrero de 2025) utilizó la «delayed tool invocation» para envenenar la memoria de forma diferida.

Herramientas y frameworks (a fecha de 2026)

Las siguientes herramientas son las piezas consolidadas en la práctica. Datos de versiones y de mercado a fecha de 2026.

Comerciales: Lakera Red (Lakera, de Zúrich, parte de Check Point desde octubre de 2025), HiddenLayer AIDR, Robust Intelligence (Cisco), Trustwise y Cranium.

Bug bounty con alcance de IA: HackerOne (GitHub utilizó HackerOne para la divulgación de CamoLeak), Bugcrowd e Intigriti, con sede en la UE y bien implantada en la región DACH (Alemania, Austria y Suiza).

Reporting: medible y mapeado a frameworks

El valor de un red teaming depende por completo del informe. Como los resultados son probabilísticos, hay que cuantificarlos. Métricas útiles:

• Tasa de éxito de ataque: porcentaje de ataques exitosos por clase.
• Tasa de detección: cuántos ataques detectó la monitorización.
• Tiempo hasta la detección: cuánto se tarda en detectarlos.
• Radio de impacto: cuántos agentes o sistemas posteriores en la cadena se verían afectados.

Cada hallazgo debería mapearse a frameworks consolidados: OWASP Agentic Top 10 (ASI01–ASI10) como registro de riesgos, MITRE ATLAS como playbook de adversarios (con la honesta salvedad de que ATLAS va 6–12 meses por detrás de la frontera agéntica, sobre todo en ASI07, ASI08 y ASI10) y, como enfoque emergente (a fecha de 2026), AIVSS (versión 0.8) para la puntuación cuantitativa. Además, los hallazgos pueden estructurarse de forma compatible con AVID, lo que permite usarlos como evidencia de auditoría reproducible para ISO 42001 A.5 y el art. 9 del Reglamento de IA de la UE. Importante para el área de compras: «OWASP-compliant» no es una afirmación sólida. OWASP no certifica.

Con qué frecuencia y quién

Frecuencia (regla general): línea base trimestral más pruebas activadas por eventos, antes de cada nueva integración de herramientas con permisos destructivos, tras cada cambio sustancial en el prompt o el mensaje de sistema, tras cada actualización de versión del modelo y de forma puntual en cuanto un CVE o PoC afecte a tu stack.

Quién: los grandes grupos con su propio stack de agentes sobre datos sensibles mantienen un red team de IA dedicado (interno o externo con contrato permanente) que trabaja con Garak, PyRIT y DeepTeam frente al framework OWASP_ASI_2026, además de un programa de bug bounty. Las pymes que despliegan agentes a través de API gestionadas externalizan el red teaming a proveedores especializados, porque internamente les faltan las habilidades específicas de ML.

Para las entidades financieras de la UE, las pruebas ofensivas están reguladas. DORA es un reglamento de la UE, se aplica directamente desde el 17 de enero de 2025 y exige pruebas de resiliencia periódicas (arts. 24–25). Las pruebas de penetración basadas en amenazas (TLPT) (arts. 26–27) solo tienen que realizarlas las entidades financieras que haya designado la autoridad supervisora competente. En Alemania, la guía orientativa de la BaFin sobre riesgos TIC en el uso de la IA del 18.12.2025 menciona las pruebas de penetración adversariales y la simulación de ataques (envenenamiento de datos, evasión) como medidas adecuadas. La guía es expresamente no vinculante. Aun así, quien opere sistemas de IA críticos sin este tipo de pruebas debería poder justificarlo en una auditoría.

Ejemplo práctico con cifras

Una aseguradora utiliza un flujo de trabajo multiagente para la tramitación de siniestros. Un red team interno construye una inyección indirecta: en la copia escaneada de un informe médico se oculta, mediante texto que el OCR puede reconstruir, la instrucción de aprobar automáticamente los casos de determinadas categorías. El agente de «Risk Scoring» adopta la evaluación manipulada y la transmite a los agentes de «Pricing» y «Compliance».

Las métricas medidas: tasa de éxito de la inyección, 1 de 1 (con éxito); tiempo hasta la detección, > 4 horas; radio de impacto, 3 agentes posteriores en la cadena. Como comparación, una investigación de Galileo AI (diciembre de 2025) mostró en sistemas multiagente simulados que un único agente comprometido envenenó el 87 % de la toma de decisiones posterior en 4 horas. Un incidente documentado en compras del sector manufacturero (2025): a lo largo de tres semanas convencieron poco a poco a un agente de que su límite de aprobación era de 500.000 USD; después, el atacante colocó 5 millones de USD en pedidos falsos repartidos en 10 transacciones. Este tipo de hallazgos traduce riesgos abstractos en cifras aptas para un comité de dirección.

Lista de comprobación práctica

• Definir el alcance: ¿qué herramientas, memorias, rutas entre agentes y puntos de control HITL entran en el alcance?
• Derivar escenarios basados en el modelo de amenazas a partir de OWASP ASI01–ASI10.
• Integrar un escaneo base automatizado (Garak/PyRIT/DeepTeam) en CI/CD.
• Completar con campañas manuales de varias fases (boiling frog, A2A, delayed invocation).
• Recopilar métricas: tasa de éxito de ataque, tasa de detección, tiempo hasta la detección, radio de impacto.
• Mapear los hallazgos a OWASP/MITRE ATLAS/AIVSS y documentarlos de forma compatible con AVID.
• «Inyecciones de prueba» para comprobar si el human-in-the-loop funciona de verdad.
• Fijar la cadencia: trimestral más pruebas activadas por eventos.

Para agencias y responsables de decisiones B2B

Quien construye agentes para clientes o los utiliza en su propio stack de marketing y ventas debería entender el red teaming como parte fija del proceso de entrega y operación, no como una prueba de aceptación puntual. Para las agencias es además un factor diferenciador: unas tasas de éxito de ataque demostrables y un reporting mapeado a OWASP generan entre los clientes una confianza que la frase «usamos guardrails» no consigue. Blck Alpaca te ayuda a montar un setup de red teaming adecuado a la madurez y a la regulación de tu empresa: desde la selección de herramientas y el desarrollo de escenarios hasta un informe apto para auditorías. Habla con nosotros antes de que tu agente pase a producción.