Seguridad de agentes de IA & OWASP

Qué significa la seguridad de agentes de IA según OWASP

La seguridad de agentes de IA según OWASP describe la protección sistemática de agentes de IA autónomos frente a amenazas que surgen de su capacidad para planificar por su cuenta, invocar herramientas, escribir en memoria persistente y actuar, con una aprobación humana mínima paso a paso. Mientras que un chatbot clásico sobre todo responde (entra un prompt, sale una completion, quizá anclada mediante RAG), los agentes planifican, razonan, eligen herramientas, escriben en memoria y actúan. Este cambio de nivel de abstracción amplía la superficie de ataque en tres ejes: autonomía (planes de varios pasos, automodificación del contexto y la memoria), uso de herramientas (sistema de archivos, API, conectores de bases de datos, sandboxes de código, servidores MCP, pares del protocolo A2A) y persistencia (almacenes de memoria de larga duración, bases de datos vectoriales, cadenas de confianza entre agentes).

OWASP lo resume con la formulación propia del GenAI Security Project (Sotiropoulos et al., 9 de diciembre de 2025): los sistemas agénticos heredan todos los riesgos de los LLM e introducen clases de vulnerabilidades completamente nuevas, derivadas de la autonomía, la integración de herramientas, la coordinación multiagente y el estado persistente. Para quienes toman decisiones en empresas en Europa, la idea central es esta: quien solo lee el LLM Top 10 subestima sistemáticamente el riesgo agéntico.

Las dos listas de OWASP de referencia

El OWASP GenAI Security Project (genai.owasp.org) publica una familia de documentos de seguridad de IA que se solapan entre sí. Dos de ellos son clave para los agentes:

• OWASP Top 10 para aplicaciones LLM 2025 (LLM01:2025 a LLM10:2025). Aborda los riesgos del modelo y de la aplicación en cualquier aplicación de IA generativa o LLM, ya sea conversacional, basada en RAG, de tipo copiloto o agéntica. Es la referencia que la mayoría de los equipos de seguridad de la región DACH (Alemania, Austria y Suiza) ya conoce. Desde el 3 de agosto de 2026 existe la edición 2026. En ella, Excessive Agency ocupa el puesto 3 (LLM03:2026). Las correspondencias de esta página siguen la numeración de 2025.
• OWASP Top 10 for Agentic Applications 2026 (ASI01 a ASI10). Publicado el 9 de diciembre de 2025 por la misma iniciativa (Agentic Security Initiative), con más de 100 colaboradores y un Expert Review Board (entre otros, NIST, Alan Turing Institute, Microsoft AI Red Team, AWS/CoSAI, Zenity). Es la columna vertebral del modelado de amenazas específico de agentes.

Nota importante sobre la taxonomía: la lista canónica de diciembre de 2025 difiere de un borrador de trabajo anterior de OWASP («Agentic AI Threats and Mitigations v1.0», febrero de 2025, citado a menudo como «15 agentic threats»). Muchos artículos de profesionales de principios y mediados de 2025 siguen usando la numeración de ese borrador (por ejemplo, «Memory Poisoning como ASI01»). Esa numeración pertenece a borradores históricos, no al Top 10 final. Las categorías antiguas se reparten hoy dentro de la lista consolidada. Memory Poisoning se ubica en ASI06; el bypass de HITL, en ASI09.

ASI01–ASI10 de un vistazo

Las diez amenazas agénticas canónicas y sus categorías de control principales:

La lógica de amplificación es decisiva: según el mapeo de DeepTeam, ASI01 = LLM01 (Prompt Injection) × LLM06 (Excessive Agency), solo que con una ejecución en varios pasos que multiplica el daño más allá de una única respuesta. ASI03, ASI07 y ASI08 no tienen un análogo directo en el LLM Top 10; ASI10 solo está parcialmente relacionado con LLM06:2025.

Inyección de prompts y Agent Goal Hijack (ASI01)

En ASI01, un atacante manipula los objetivos, la selección de tareas o las rutas de decisión de un agente, ya sea mediante prompt injection directa o de forma indirecta con instrucciones ocultas en documentos, el corpus RAG, correos electrónicos, invitaciones de calendario, descripciones de PR o salidas de herramientas. Lo esencial: los agentes y el modelo subyacente no pueden distinguir de forma fiable las instrucciones de los datos; todo texto que lee el agente forma parte de la superficie de ataque.

El punto de inflexión documentado es EchoLeak (CVE-2025-32711, CVSS 9.3), revelado por Aim Labs en junio de 2025 en Microsoft 365 Copilot: la primera prompt injection zero-click documentada en un sistema en producción real. Un único correo manipulado eludió el clasificador XPIA de Microsoft y exfiltró, a través de un proxy de Teams permitido, el contenido más sensible del contexto de Copilot, sin un solo clic del usuario (Aim Labs acuñó el término «LLM Scope Violation»; detalle técnico: arXiv 2509.10540, Reddy et al., septiembre de 2025). Microsoft lo corrigió en el lado del servidor. Otros casos: GitHub Copilot YOLO Mode (CVE-2025-53773) y CamoLeak en GitHub Copilot Chat (CVSS 9.6), que mediante un bypass de CSP a través del propio proxy de imágenes Camo de GitHub extrajo secretos de repositorios privados carácter a carácter. El origen académico de la disciplina es el trabajo de Greshake et al. (arXiv 2302.12173, 2023) sobre la prompt injection indirecta.

Ejemplo en DACH: un agente de atención al cliente de un banco que lee un buzón compartido puede ser inducido, mediante un correo de «gracias» con instrucciones ocultas, a revelar en su siguiente respuesta fragmentos de transacciones de otros clientes.

Uso indebido de herramientas (ASI02) y Excessive Agency

ASI02 se distingue sutilmente del abuso de privilegios: el acceso es legítimo, el uso no lo es. El agente opera dentro de los permisos autorizados, pero aplica una herramienta legítima de forma insegura: borra datos, llama a API costosas con demasiada frecuencia, ejecuta operaciones destructivas. Excessive Agency (LLM06:2025), es decir, conceder capacidad de acción sin control, sin una limitación de alcance suficiente ni supervisión humana, es el puente conceptual hacia ASI02 y, en parte, hacia ASI10.

Caso documentado: en el Amazon Q Code Assistant (CVE-2025-8217, julio de 2025), unos atacantes comprometieron un token de GitHub e introdujeron prompts destructivos en la extensión de VS Code v1.84.0, que con --trust-all-tools --no-interactive podrían haber borrado sistemas de archivos y recursos en la nube sin confirmación; alrededor de 1 millón de desarrolladores tenía instalada la extensión. Contramedidas: mínimo privilegio por herramienta, validación de esquema de cada argumento de herramienta, listas de permitidos y denegados por rol de agente, desactivación de la autoaprobación (modos «YOLO») para todo lo que toque bases de datos, pagos, comunicaciones o despliegues, y límites de coste con circuit breakers.

Memory & Context Poisoning (ASI06)

A diferencia de los chatbots, que olvidan entre sesiones, los agentes mantienen memoria persistente: historial de conversaciones, preferencias, contexto aprendido, almacenes RAG. Esto crea superficies de ataque persistentes: una sola inyección exitosa envenena la memoria de forma permanente, la carga útil sigue activa indefinidamente y cada sesión futura hereda el compromiso.

Evidencia: el ataque a la memoria de Google Gemini (febrero de 2025, Johann Rehberger) demostró la «delayed tool invocation»: un documento subido indicaba a Gemini que guardara información falsa cuando, más adelante, aparecieran determinadas palabras desencadenantes. El estudio «Invitation Is All You Need!» (Nassi, Cohen, Yair, agosto de 2025) presentó 14 escenarios de ataque contra asistentes basados en Gemini, activados a través de correos electrónicos, invitaciones de calendario y documentos compartidos. Según el análisis de riesgos de los autores, el 73 % de las amenazas analizadas supone un riesgo de alto a crítico para los usuarios. Varios blogs de seguridad, citando a Lakera, describen un comportamiento de «agente durmiente»: según ellos, los agentes comprometidos desarrollan creencias falsas persistentes sobre las políticas de seguridad y las defienden frente a las personas. Contramedidas: tratar las escrituras en memoria como operaciones sensibles para la seguridad, metadatos de procedencia (fuente, marca de tiempo, ruta de ingesta, nivel de confianza) por entrada, aislamiento por tenant, auditorías periódicas de la memoria y procedimientos de borrado conformes al art. 17 del RGPD (derecho de supresión).

Contramedidas y human-in-the-loop (ASI09)

Los agentes generan resultados pulidos y con tono de autoridad. Las personas tienden a confiar en ellos. ASI09 (Human-Agent Trust Exploitation) convierte precisamente esta capa de confianza en un objetivo de ataque: el sesgo de automatización, la deferencia a la autoridad y la «polished hallucination» hacen que los aprobadores humanos den luz verde a las recomendaciones sin examinarlas. La capa de supervisión, concebida como control de seguridad, se convierte en la vulnerabilidad. Algunos proveedores de seguridad describen un caso, no verificado de forma independiente, en el que un agente de compras habría sido convencido a lo largo de tres semanas de que su límite de autorización era de 500.000 USD; después, el atacante habría colocado 5 millones de USD en pedidos falsos.

Las puertas HITL eficaces requieren una verificación independiente de las pruebas, no solo de la recomendación del agente: aprobaciones escalonadas (mayor impacto → más aprobadores o pruebas más sólidas), patrones de interfaz que muestren activamente el razonamiento, la procedencia de las fuentes y el nivel de confianza (no un simple botón de «Aprobar»), y «test injections» periódicas para comprobar si el HITL funciona de verdad (como un simulacro de incendio). Esto coincide directamente con el art. 14 del Reglamento de IA de la UE (supervisión humana).

Como principio general rige la defensa en profundidad: ningún guardrail aislado es una bala de plata. EchoLeak eludió el clasificador XPIA de Microsoft; todos los guardrails publicados (Bedrock Guardrails, Google Model Armor, Gemini Safety) fueron burlados en cuestión de meses por investigadores competentes. Hacen falta varias capas complementarias: filtros de entrada (p. ej., Llama Guard 4, NVIDIA NeMo Guardrails, Microsoft Prompt Shield, Lakera Guard) + aplicación de alcance y procedencia + filtros de salida + monitorización del comportamiento. Los guardrails suelen añadir 100–500 ms de latencia por capa y presentan tasas de falsos positivos más altas en contextos multilingües de DACH (code-switching DE/FR/IT/EN). Las afirmaciones de proveedores del tipo «bloquea el 99,x % de las prompt injections» deben tratarse como marketing hasta que un red team independiente las verifique.

Cumplimiento normativo en DACH (a título informativo, no es asesoramiento jurídico)

Las listas de OWASP no son una certificación: «OWASP-compliant» no es una afirmación fiable de un proveedor; los proveedores pueden aplicar las recomendaciones de OWASP, no ser «compliant». Aun así, encajan limpiamente en el marco de cumplimiento de la región DACH:

• El art. 15 del Reglamento de IA de la UE (precisión, solidez y ciberseguridad) cubre ampliamente los sistemas de alto riesgo, pero es tecnológicamente neutro; la inyección indirecta, las particularidades de las NHI y las cascadas multiagente aún no están codificadas en la norma y siguen recayendo en el responsable del despliegue.
• RGPD, art. 32 (medidas técnicas y organizativas): la mayoría de las amenazas ASI afectan a la confidencialidad, la integridad, la disponibilidad y la resiliencia. ASI06, por ejemplo, afecta al art. 5(1)(d) (exactitud) y al art. 17 (supresión).
• ISO/IEC 42001:2023 (anexo A, 38 controles repartidos en 9 objetivos) aporta los controles de referencia, entre otros A.6.2.4 (V&V), A.6.2.6 (operación/monitorización) y A.6.2.8 (registro).
• NIS2 / DORA: para las entidades esenciales e importantes, el art. 21(2) de NIS2 exige, entre otras cosas, seguridad de la cadena de suministro (→ ASI04) y control de acceso (→ ASI03); los arts. 28–30 de DORA regulan el riesgo de terceros proveedores de TIC, algo directamente relevante para las cadenas de suministro de MCP y de agentes en el sector financiero.

Supervisión en DACH: la guía orientativa de BaFin (18 de diciembre de 2025) y la comunicación supervisora 08/2024 de FINMA no son vinculantes, pero desplazan de forma notable la carga de la prueba en las auditorías; ambas recomiendan, entre otras cosas, pruebas de penetración adversariales o ciberejercicios basados en escenarios. En Austria, la FMA ha seguido el mismo camino con el documento informativo «Nutzung von KI im Finanzsektor» (versión 1.0, a 11 de septiembre de 2026). Este documento tampoco es vinculante. Establece que las aplicaciones de IA ya deben cumplir hoy los requisitos tecnológicamente neutros del derecho de los mercados financieros, DORA incluida, y que el órgano de dirección asume la responsabilidad última también de los riesgos TIC relacionados con la IA. El BSI señala en su informe de situación 2025 la prompt injection indirecta como el vector de ataque más relevante en la actualidad contra sistemas LLM y constata que no existe una única medida altamente eficaz contra ella.

Perspectivas y recomendaciones prácticas

El OWASP Agentic Top 10 está en su versión 1.0 (9 de diciembre de 2025) y previsiblemente se actualizará al menos una vez al año. Conviene guardar genai.owasp.org en favoritos en lugar de tratar la lista como algo estático. Tres apuntes prácticos sin adornos. Primero, MITRE ATLAS, como manual de tácticas de adversarios, va entre 6 y 12 meses por detrás del frente agéntico, sobre todo en ASI07, ASI08 y ASI10. Segundo, la detección en despliegues de agentes en producción sigue siendo débil: la mayoría de los stacks de observabilidad se construyeron para aplicaciones clásicas y no detectan anomalías en las trazas de razonamiento, violaciones de procedencia en las escrituras de memoria ni señales de deriva de comportamiento; la conclusión «no lo vemos en el SIEM, así que no ocurre» es peligrosamente errónea. Tercero, el «AI red teaming» no equivale a un pentest clásico (otras habilidades, otras herramientas como Garak/PyRIT/DeepTeam, hallazgos probabilísticos en lugar de binarios).

Para quienes despliegan agentes en Europa, el punto de partida pragmático es este: crear un registro de riesgos basado en el OWASP Agentic Top 10, mapearlo con ISO 42001 y el art. 15 del Reglamento de IA de la UE, tratar cada agente como una Non-Human Identity independiente con credenciales de corta duración, implantar guardrails con defensa en profundidad, proteger las operaciones destructivas con un HITL real y tener preparado un kill switch para aislar agentes fuera de control. Encontrarás más detalles sobre prompt injection, red teaming, monitorización y registros de auditoría en los artículos de abajo.