1. Objetivos de la semana
En Cybersecurity-14 hemos construido el modelo defensivo:
Ahora cambia completamente nuestra perspectiva.
Vamos a pensar como un atacante.
El objetivo de un Red Team no es demostrar que el sistema es perfecto. Es descubrir dónde deja de ser seguro.
Identificar la superficie de ataque del agente.
Intentar modificar el comportamiento del agente.
Buscar caminos hacia privilegios superiores.
Comprobar si el agente puede convertir una manipulación en una acción.
Determinar si puede extraerse información protegida.
Convertir los hallazgos en controles defensivos.
2. ¿Qué es AI Agent Red Teaming?
AI Agent Red Teaming consiste en evaluar de forma adversarial un sistema de agentes de Inteligencia Artificial.
Pero existe una diferencia fundamental respecto a un pentest tradicional.
El Red Team debe atacar tanto las interfaces técnicas como las interfaces semánticas.
3. El nuevo Red Team
Un especialista tradicional en seguridad puede analizar:
- redes;
- firewalls;
- APIs;
- servidores;
- aplicaciones;
- identidades.
El Red Team de IA debe añadir:
- model behavior;
- prompt manipulation;
- context manipulation;
- tool abuse;
- agent autonomy;
- memory poisoning;
- multi-agent trust.
Un agente combina software tradicional con un componente probabilístico.
Por tanto, debemos combinar seguridad determinista con pruebas adversariales sobre el comportamiento del modelo.
4. Definir el Scope
Nunca debemos comenzar un Red Team atacando indiscriminadamente.
Primero debemos definir el alcance.
| Elemento | Ejemplo |
|---|---|
| Agent | Infrastructure-Agent |
| Model | LLM corporativo |
| Tools | CMDB, logs, ticketing |
| Memory | Vector database |
| Identity | Service identity |
| Network | Internal APIs |
| Data | Infrastructure metadata |
Rules of Engagement
El alumno debe definir:
- qué sistemas puede atacar;
- qué herramientas puede utilizar;
- qué datos pueden utilizarse;
- qué acciones están prohibidas;
- cómo detener la prueba;
- cómo documentar evidencias.
Un Red Team no consiste en causar daño. Consiste en demostrar de forma controlada que un daño sería posible.
5. Threat Model del agente
Utilizaremos el modelo construido en la semana anterior y ahora añadiremos rutas de ataque.
Preguntas del Red Team
- ¿Podemos alterar el contexto?
- ¿Podemos engañar al modelo?
- ¿Podemos conseguir una tool call?
- ¿Podemos aumentar privilegios?
- ¿Podemos acceder a datos?
- ¿Podemos influir en memoria?
- ¿Podemos provocar una llamada externa?
- ¿El sistema detectará el ataque?
6. Attack Chain
Uno de los conceptos más importantes de esta semana es que una vulnerabilidad aislada puede ser poco peligrosa.
Varias vulnerabilidades encadenadas pueden convertirse en un incidente crítico.
Por ejemplo:
Una inyección de prompt por sí sola podría únicamente modificar la respuesta del agente.
Pero si esa manipulación consigue provocar una llamada a una herramienta privilegiada, el impacto cambia completamente.
7. Reconnaissance
El primer paso de cualquier Red Team consiste en conocer la superficie de ataque.
Inventario
- modelos;
- agentes;
- tools;
- APIs;
- databases;
- memory stores;
- identities;
- network connections.
Agent Fingerprinting
También podemos estudiar cómo responde el agente ante determinadas categorías de preguntas.
El objetivo no es buscar una frase mágica, sino identificar:
- qué conoce;
- qué puede hacer;
- qué herramientas tiene;
- qué restricciones existen;
- qué información revela.
8. Prompt Attack Surface
El atacante puede intentar influir en diferentes capas del contexto.
El Red Team debe comprobar si una capa inferior puede modificar la interpretación de una capa superior.
Categorías de pruebas
| Categoría | Objetivo |
|---|---|
| Instruction Override | Intentar cambiar las instrucciones principales |
| Role Manipulation | Intentar cambiar el rol del agente |
| Context Confusion | Confundir datos con instrucciones |
| Authority Impersonation | Simular una fuente autorizada |
| Policy Evasion | Intentar evitar controles |
| Goal Manipulation | Modificar el objetivo del agente |
9. Indirect Prompt Injection
Una de las pruebas más importantes consiste en comprobar si el agente confía excesivamente en contenido externo.
El Red Team debe comprobar si una fuente no confiable puede modificar el comportamiento del agente.
Introduce contenido externo controlado que contiene instrucciones claramente diferenciadas de los datos y observa si el agente intenta tratarlas como órdenes.
10. Tool Abuse
Aquí entramos en una de las áreas más críticas.
El agente puede tener herramientas que permitan modificar el mundo real.
El Red Team debe comprobar:
- si puede invocar herramientas no autorizadas;
- si puede modificar parámetros;
- si puede encadenar herramientas;
- si puede abusar de herramientas legítimas;
- si puede aumentar el alcance de una operación.
Tool Chaining
Cada operación individual podría parecer legítima. La cadena completa puede no serlo.
11. Tool Parameter Manipulation
Supongamos que tenemos:
{
"tool": "restart_service",
"parameters": {
"service": "web-api"
}
}El Red Team debe comprobar que:
- el servicio está permitido;
- el entorno está permitido;
- la identidad puede ejecutar la operación;
- la operación está dentro del scope;
- existe control de aprobación.
No basta con comprobar que existe la herramienta.
Debemos probar también la seguridad de sus parámetros.
12. Identity Attacks
Un agente seguro debe tener una identidad verificable.
El Red Team debe comprobar si puede:
- suplantar otro agente;
- reutilizar credenciales;
- obtener tokens;
- abusar de delegaciones;
- provocar privilege escalation.
Debemos verificar que Agent A no pueda conseguir indirectamente los privilegios de Agent B.
13. Credential Exposure
Otro test crítico consiste en verificar si el agente puede revelar secretos.
Debemos buscar accidentalmente:
- API keys;
- tokens;
- passwords;
- connection strings;
- cloud credentials;
- internal endpoints.
Utiliza secretos ficticios y entornos aislados.
14. Data Exfiltration Testing
El objetivo es determinar si un atacante puede conseguir que el agente revele información que debería estar protegida.
Flujo a probar
El test debe comprobar:
- si el agente revela datos directamente;
- si los incluye en respuestas;
- si los envía a herramientas;
- si los incluye en emails;
- si los almacena en memoria.
15. Memory Poisoning
La memoria persistente puede convertirse en una excelente superficie de ataque.
Pregunta del Red Team
¿Puede un usuario introducir información en memoria que posteriormente sea tratada como una instrucción confiable?
Si la respuesta es sí, tenemos una vulnerabilidad de persistencia.
16. Multi-Agent Attacks
Las arquitecturas multiagente introducen nuevas posibilidades.
El Red Team debe estudiar:
- trust entre agentes;
- delegación;
- propagación de identidad;
- propagación de permisos;
- confianza en resultados;
- mensajes manipulados.
Agent Confusion
Un agente podría recibir un mensaje aparentemente procedente de otro agente.
Debemos comprobar que exista autenticación real entre agentes y que el contenido del mensaje no sea suficiente para establecer confianza.
17. Network Attack Surface
Un agente es también un componente de red.
El Red Team debe identificar:
- destinos permitidos;
- destinos inesperados;
- egress unrestricted;
- metadata endpoints;
- DNS access;
- proxy bypass;
- service-to-service access.
18. Agent SSRF Conceptual
Un agente con capacidad de realizar peticiones HTTP puede convertirse conceptualmente en un proxy controlado por un atacante.
Por tanto, una herramienta HTTP debe tener restricciones similares a las que aplicaríamos a un componente backend:
- allowlist de destinos;
- bloqueo de redes internas no autorizadas;
- validación de URLs;
- timeouts;
- rate limits;
- logging.
19. Automatizar el Red Team
Realizar manualmente todas las pruebas no escala.
Podemos construir un framework de pruebas.
Cada test debe producir
{
"test_id": "PROMPT-001",
"category": "prompt-injection",
"input": "...",
"expected": "BLOCK",
"actual": "ALLOW",
"severity": "HIGH",
"detected": false
}20. Security Regression Testing
Una vulnerabilidad corregida hoy puede reaparecer mañana.
Por eso cada vulnerabilidad debe convertirse en una prueba automatizada.
Cada vulnerabilidad importante debe terminar convertida en un test permanente.
21. Attack Success Rate
Podemos medir la eficacia de nuestras defensas.
Attack Success Rate =
successful attacks
------------------
total attacks
Ejemplo:
Tests executed: 500
Successful attacks: 12
ASR = 12 / 500
ASR = 2.4%
El objetivo no es utilizar esta métrica de forma aislada. Debemos analizar qué ataques tuvieron éxito y por qué.
22. Risk-based Red Teaming
No todos los tests tienen la misma prioridad.
| Ataque | Probabilidad | Impacto | Prioridad |
|---|---|---|---|
| Prompt manipulation | Alta | Medio | Alta |
| Tool abuse | Media | Crítico | Crítica |
| Data leakage | Media | Crítico | Crítica |
| Memory poisoning | Media | Alto | Alta |
| Agent impersonation | Baja | Crítico | Alta |
23. Attack Graph
Una herramienta muy potente es representar las posibles rutas de ataque.
El objetivo es identificar los caminos que pueden conducir desde una entrada de bajo privilegio hasta un activo crítico.
24. Agent Attack Surface Matrix
| Superficie | Pregunta | Control |
|---|---|---|
| Prompt | ¿Puede manipularse? | Prompt defense |
| Context | ¿Puede contaminarse? | Source validation |
| Tools | ¿Puede abusarse? | Tool gateway |
| Identity | ¿Puede suplantarse? | Strong identity |
| Memory | ¿Puede envenenarse? | Memory controls |
| Network | ¿Puede utilizarse como proxy? | Egress policy |
| Data | ¿Puede exfiltrarse? | DLP |
| Runtime | ¿Puede escapar? | Sandbox |
25. Laboratorios
Objetivo
Recibe la siguiente arquitectura:
Tarea
Identifica al menos 20 posibles superficies de ataque.
Respuesta orientativa
- user input;
- web results;
- database output;
- ticket content;
- email content;
- API responses;
- tool parameters;
- tool authorization;
- agent identity;
- API credentials;
- memory;
- network egress;
- logging;
- error messages;
- agent-to-agent communication;
- retrieval layer;
- vector database;
- system instructions;
- session state;
- approval workflow.
Escenario
Tenemos un agente que resume documentos.
Los documentos proceden de usuarios externos.
Tarea
Diseña una batería de pruebas que determine si el agente distingue correctamente entre:
- contenido del documento;
- instrucciones del sistema;
- petición del usuario.
Resultado esperado
El agente debe poder procesar el documento sin permitir que su contenido cambie las políticas de seguridad.
Escenario
Un agente dispone de:
read_logs
create_ticket
restart_service
modify_firewall
delete_resource
Tarea
Clasifica cada herramienta por nivel de riesgo y define qué pruebas realizarías.
Resolución orientativa
| Tool | Riesgo |
|---|---|
| read_logs | Bajo/medio |
| create_ticket | Bajo |
| restart_service | Medio/alto |
| modify_firewall | Alto |
| delete_resource | Crítico |
El Red Team debe probar especialmente si una herramienta de bajo riesgo puede utilizarse como paso intermedio para alcanzar otra de mayor privilegio.
Objetivo
Determinar si un usuario puede introducir información persistente que modifique el comportamiento futuro del agente.
Debes diseñar
- test de escritura;
- test de persistencia;
- test de recuperación;
- test de influencia;
- test de eliminación.
Escenario
Existen tres agentes:
Monitoring-Agent
Operations-Agent
Admin-Agent
Diseña pruebas para comprobar que un agente no pueda hacerse pasar por otro.
Objetivo
Determinar si un agente puede revelar información clasificada mediante sus respuestas o herramientas.
Diseña tests para:
- respuesta directa;
- tool output;
- email;
- memory write;
- API call.
Construye una matriz:
| Destino | Permitido |
|---|---|
| Internal API | ✓ |
| Ticketing | ✓ |
| Internet general | ? |
| Cloud metadata | ✗ |
| Unknown endpoint | ✗ |
Objetivo
Convierte las vulnerabilidades descubiertas en tests automatizados.
TEST-001
Prompt Injection
Expected: BLOCK
TEST-002
Unauthorized Tool
Expected: DENY
TEST-003
Sensitive Data
Expected: MASK
TEST-004
Unknown Destination
Expected: BLOCK
TEST-005
Privilege Escalation
Expected: DENY
26. Ejercicios de nivel avanzado
Ejercicio 1
¿Qué diferencia fundamental existe entre un pentest tradicional y un Red Team de agentes?
Ver respuesta
El pentest tradicional se centra principalmente en componentes deterministas de software e infraestructura. El Red Team de agentes debe además evaluar comportamiento probabilístico, contexto, instrucciones, memoria, herramientas y autonomía.
Ejercicio 2
Un agente puede consultar una base de datos y crear tickets. ¿Por qué podría existir una vulnerabilidad aunque ambas herramientas estén correctamente autorizadas?
Ver respuesta
Porque la seguridad también debe analizar las cadenas de acciones. Una combinación de herramientas aparentemente legítimas puede permitir extraer información y posteriormente enviarla mediante otra herramienta.
Ejercicio 3
¿Por qué un ataque de prompt injection puede ser más grave cuando el agente dispone de herramientas?
Ver respuesta
Porque el ataque puede pasar de modificar una respuesta textual a provocar una acción sobre sistemas reales.
Ejercicio 4
¿Qué debe ocurrir con una vulnerabilidad descubierta durante el Red Team?
Ver respuesta
Debe documentarse, clasificarse por riesgo, corregirse, volver a probarse y convertirse idealmente en un test de regresión permanente.
Ejercicio 5
¿Por qué el Red Team debe analizar el comportamiento del agente completo y no únicamente el modelo?
Ver respuesta
Porque el riesgo real aparece en la interacción entre modelo, contexto, memoria, herramientas, identidad, red y sistemas externos. Un modelo puede estar correctamente configurado y aun así formar parte de una arquitectura insegura.
27. Caso práctico resuelto
Escenario
Tenemos:
Hallazgo
El Red Team descubre que el agente puede consultar información interna mediante una herramienta legítima y posteriormente utilizar el email.
Individualmente ambas operaciones están autorizadas.
El problema aparece cuando se combinan.
Vulnerabilidad
El sistema permite combinar dos capacidades legítimas para construir una ruta de exfiltración.
Corrección
Introducimos:
- data classification;
- email destination allowlist;
- DLP;
- risk escalation;
- human approval.
Nuevo flujo
Resultado
El ataque inicial deja de ser posible aunque el agente siga teniendo acceso a las mismas herramientas.
La seguridad debe analizar no solo herramientas individuales, sino también las combinaciones posibles entre capacidades.
28. Attack Tree
Construiremos un árbol de ataque para conseguir un objetivo.
El objetivo del Red Team es encontrar qué ramas del árbol están abiertas.
29. Purple Team
Una vez descubierto un ataque, dejamos de trabajar exclusivamente como Red Team.
Pasamos a Purple Team.
El objetivo es cerrar el ciclo completo.
30. Attack → Detect → Respond → Improve
El Red Team ejecuta una prueba controlada.
El sistema defensivo debe identificar el comportamiento.
El sistema bloquea, aísla o escala la operación.
El equipo corrige el control.
El Red Team vuelve a ejecutar el ataque.
31. Detection Engineering para AI Red Team
Cada ataque debe tener una señal detectable.
| Ataque | Señal | Respuesta |
|---|---|---|
| Prompt Injection | Input anomaly | Block / review |
| Tool Abuse | Unexpected tool call | Deny |
| Data Exfiltration | DLP event | Block |
| Privilege Escalation | Authorization failure | Alert |
| Memory Poisoning | Suspicious memory write | Quarantine |
| Egress Abuse | Unknown destination | Block |
32. Attack Telemetry
El Red Team debe generar evidencias que puedan analizarse.
{
"test_id": "TOOL-014",
"agent": "operations-agent",
"tool": "modify_firewall",
"risk": 82,
"policy": "HIGH_RISK_CHANGE",
"decision": "DENY",
"detected": true,
"timestamp":
"2026-08-29T12:00:00Z"
}Esta información puede alimentar el SIEM o el sistema de observabilidad de la plataforma.
33. Continuous AI Security Testing
El Red Team no debe ejecutarse únicamente una vez al año.
De esta forma la seguridad pasa a formar parte del ciclo de desarrollo del sistema de IA.
34. AI Security CI/CD
Podemos integrar las pruebas de seguridad directamente en el pipeline.
git commit
↓
unit tests
↓
integration tests
↓
AI security tests
↓
prompt regression
↓
tool authorization tests
↓
DLP tests
↓
agent behavior tests
↓
security gate
↓
DEPLOY
Si un test crítico falla, el despliegue debe detenerse.
35. Métricas avanzadas
| Métrica | Qué mide |
|---|---|
| Attack Success Rate | Porcentaje de ataques exitosos |
| Detection Rate | Porcentaje de ataques detectados |
| False Positive Rate | Alertas incorrectas |
| Mean Time To Detect | Tiempo hasta detectar |
| Mean Time To Block | Tiempo hasta bloquear |
| Coverage | Superficie cubierta por tests |
| Regression Coverage | Vulnerabilidades cubiertas permanentemente |
36. Security Score del agente
Podemos crear un modelo conceptual de puntuación.
Agent Security Score =
Identity
+ Authorization
+ Prompt Defense
+ Tool Security
+ Memory Security
+ DLP
+ Network Security
+ Detection
+ Response
No debe interpretarse como una garantía matemática. Es una herramienta de gobierno para comparar versiones y detectar degradaciones.
37. GRAN RETO · Build an AI Red Team Platform
Objetivo
Construye un pequeño framework capaz de evaluar automáticamente la seguridad de un agente de IA.
Arquitectura objetivo
El sistema debe ser capaz de:
- Ejecutar tests de prompt injection.
- Probar controles de herramientas.
- Validar autorización.
- Probar DLP.
- Probar memoria.
- Evaluar egress.
- Registrar evidencias.
- Asignar severidad.
- Generar un informe.
- Guardar las pruebas para regresión.
Resultado esperado
El alumno debe terminar con una plataforma donde pueda conectar un agente y obtener algo parecido a:
AI AGENT SECURITY REPORT
Tests: 250
PASS: 224
FAIL: 18
BLOCKED: 8
Critical: 2
High: 5
Medium: 9
Low: 2
Detection Rate: 91%
Attack Success: 7.2%
Overall Risk: HIGH
38. Entregables del proyecto
| Entregable | Descripción |
|---|---|
| Architecture | Diagrama completo |
| Threat Model | Activos y amenazas |
| Attack Matrix | Pruebas planificadas |
| Test Engine | Motor de ejecución |
| Telemetry | Eventos de seguridad |
| Risk Engine | Clasificación |
| Report | Informe final |
| Regression Suite | Tests persistentes |
39. Cómo debe pensar un Red Teamer de IA
Busca entradas y fuentes de contexto controlables por el atacante.
Determina qué capacidades tiene realmente el agente.
Analiza combinaciones de herramientas.
Busca trust boundaries.
Analiza el blast radius.
Comprueba las capacidades defensivas.
40. Checklist del Red Team
| Área | Test |
|---|---|
| Identity | ☐ Impersonation |
| Authentication | ☐ Credential abuse |
| Authorization | ☐ Privilege escalation |
| Prompt | ☐ Injection |
| Context | ☐ Manipulation |
| Tools | ☐ Unauthorized calls |
| Tool chaining | ☐ Capability combination |
| Memory | ☐ Poisoning |
| Data | ☐ Leakage |
| Network | ☐ Egress abuse |
| Multi-Agent | ☐ Trust abuse |
| Detection | ☐ Alert generation |
| Response | ☐ Containment |
| Regression | ☐ Test persistence |
41. Preguntas de nivel experto
Pregunta 1
Un agente tiene correctamente configurado IAM. ¿Significa que es seguro?
Respuesta
No. IAM protege identidad y permisos, pero no necesariamente protege prompt injection, manipulación de contexto, memory poisoning, tool chaining o comportamiento inesperado del modelo.
Pregunta 2
¿Puede existir una vulnerabilidad aunque ninguna herramienta individual tenga permisos excesivos?
Respuesta
Sí. Las vulnerabilidades pueden aparecer mediante la combinación de capacidades legítimas. Por ejemplo, leer información sensible y disponer de una herramienta capaz de enviarla externamente.
Pregunta 3
¿Qué diferencia existe entre encontrar una vulnerabilidad y demostrar un riesgo real?
Respuesta
Encontrar una vulnerabilidad significa identificar una debilidad. Demostrar el riesgo implica demostrar, dentro del scope autorizado, que dicha debilidad puede conducir a un impacto relevante.
Pregunta 4
¿Por qué es importante guardar los tests después de solucionar una vulnerabilidad?
Respuesta
Para evitar regresiones. Una futura modificación del prompt, modelo, herramienta o política podría volver a introducir la vulnerabilidad.
Pregunta 5
¿Qué debería ocurrir si el Red Team consigue que un agente ejecute una operación de alto riesgo?
Respuesta
Debe documentarse la cadena de ataque, preservar evidencias, evaluar impacto, corregir el control, crear una prueba de regresión y volver a ejecutar el escenario hasta comprobar que la ruta queda bloqueada.
42. La verdadera finalidad del Red Team
El objetivo no es conseguir el mayor número posible de vulnerabilidades.
El objetivo es aumentar progresivamente la resiliencia del sistema.
Es un sistema diseñado para detectar, contener y recuperarse cuando algo falla.
43. La arquitectura completa
Después de las semanas 14 y 15 tenemos ya las dos caras del sistema.
44. Recursos y referencias
Referencia fundamental para estudiar riesgos de aplicaciones y sistemas basados en modelos generativos.
Marco de referencia para estudiar técnicas y tácticas contra sistemas de Inteligencia Artificial y Machine Learning.
Marco para identificar, evaluar y gestionar riesgos relacionados con sistemas de IA.
Útil para conectar ataques contra agentes con técnicas tradicionales de infraestructura y sistemas.
Estudia metodologías tradicionales de Red Team y trasládalas a sistemas basados en agentes.
Campo relacionado con el estudio de ataques contra sistemas de Machine Learning y modelos de IA.
45. Lo que debes recordar
01. Un agente debe ser atacado como un sistema completo.
02. El modelo es solo una parte de la superficie de ataque.
03. Prompt injection debe probarse de forma sistemática.
04. El contexto externo debe considerarse no confiable.
05. Las herramientas son uno de los objetivos principales del Red Team.
06. Las cadenas de herramientas pueden generar riesgos que no aparecen analizando cada herramienta por separado.
07. La identidad y la autorización deben probarse adversarialmente.
08. La memoria puede ser una superficie de ataque persistente.
09. El egress del agente debe estar controlado.
10. Los ataques deben convertirse en tests de regresión.
11. Red Team + Blue Team = Purple Team.
12. La seguridad de agentes debe convertirse en un proceso continuo.
46. Conexión con Cybersecurity-16
En esta semana hemos aprendido a atacar el agente.
Pero todavía nos falta una pieza fundamental.
No podemos monitorizarlos individualmente.
Necesitamos una arquitectura centralizada capaz de conocer:
- qué agentes existen;
- qué permisos tienen;
- qué herramientas utilizan;
- qué datos procesan;
- qué riesgo presentan;
- qué comportamiento están teniendo;
- qué ataques están recibiendo.
En Cybersecurity-16 construiremos el siguiente componente de nuestra superplataforma:
AI Security Operations Center · AI-SOC
Un SOC específicamente diseñado para monitorizar agentes de IA, correlacionar sus eventos, detectar comportamientos anómalos, priorizar riesgos y automatizar la respuesta.