--- title: "Seguridad de agentes de IA & OWASP" description: "Superficies de ataque de los agentes de IA y cómo el marco de OWASP protege frente a la prompt injection, el uso indebido de herramientas y las fugas de datos." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp" category: "Agentes de IA" updated: "2026-10-28T13:32:31.486Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Seguridad de agentes de IA & OWASP Superficies de ataque de los agentes de IA y cómo el marco de OWASP protege frente a la prompt injection, el uso indebido de herramientas y las fugas de datos. ## 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](https://blckalpaca.at/es/glosario/chatbot) clásico sobre todo **responde** (entra un [prompt](https://blckalpaca.at/es/glosario/prompt), sale una completion, quizá anclada mediante [RAG](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/glosario/api), conectores de bases de datos, sandboxes de código, [servidores MCP](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/model-context-protocol-mcp/mcp-security-inyeccion-de-prompts-tool-poisoning-y-gestion-de-permisos), 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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/owasp-llm-top-10-2025-explicado-los-diez-riesgos-de-seguridad-de-las-aplicacione) **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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/glosario/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](https://genai.owasp.org/resource/owasp-genai-llm-top-10-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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/como-prevenir-el-memory-poisoning-protege-la-memoria-a-largo-plazo-y-vectorial-d) 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: | ID | Título OWASP (dic. 2025) | Contramedida principal | Relación con el LLM Top 10 (2025) | | --- | --- | --- | --- | | **ASI01** | Agent Goal Hijack | Filtrado de entradas + ACL de alcance y procedencia | LLM01 Prompt Injection | | **ASI02** | Tool Misuse & Exploitation | RBAC de herramientas + validación de esquemas + HITL en operaciones destructivas | LLM06 Excessive Agency | | **ASI03** | Identity & Privilege Abuse | Ciclo de vida de NHI + credenciales de corta duración + delegación explícita | (sin equivalente directo) | | **ASI04** | Agentic Supply Chain Vulnerabilities | Registro de confianza + AIBOM + cuarentena en tiempo de ejecución | LLM03 Supply Chain (estática) | | **ASI05** | Unexpected Code Execution | Sandboxing + lista de comandos permitidos + desactivar la autoaprobación | LLM05 Improper Output Handling | | **ASI06** | Memory & Context Poisoning | Metadatos de procedencia + aislamiento por tenant + auditorías de memoria | LLM04 + LLM08 | | **ASI07** | Insecure Inter-Agent Communication | mTLS + AgentCards firmadas + lista de permitidos del grafo de colaboración | (sin equivalente) | | **ASI08** | Cascading Failures | Circuit breakers + bulkheads + simulación con gemelo digital | (sin equivalente) | | **ASI09** | Human-Agent Trust Exploitation | Interfaz de interacción forzada + aprobación escalonada + formación sobre el sesgo de automatización | LLM09 Misinformation (parcial) | | **ASI10** | Rogue Agents | Líneas base de comportamiento + kill switch + auditoría | LLM06 (parcialmente) | 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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/agent-goal-hijacking-cuando-se-manipulan-los-objetivos-de-los-agentes-de-ia-auto), la selección de tareas o las rutas de decisión de un [agente](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/prompt-injection-directa-vs-indirecta-la-diferencia-y-por-que-con-los-agentes-de). **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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/tool-misuse-y-excessive-agency-cuando-los-agentes-de-ia-tienen-demasiados-permis) (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](https://blckalpaca.at/es/glosario/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!»](https://arxiv.org/abs/2508.12175) (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](https://dsgvo-gesetz.de/art-17-dsgvo/) (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](https://blckalpaca.at/es/glosario/capa-de-supervision), 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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) (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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/glosario/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»](https://www.fma.gv.at/querschnittsthemen/kuenstliche-intelligenz/) (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](https://medien.bsi.bund.de/lagebericht/de/resiliente-gestaltung-von-llm-systemen/) 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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/monitorizacion-de-agentes-de-ia-con-langsmith-y-langfuse-observabilidad-para-age) 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. ## Artículos - [OWASP LLM Top 10 (2025) explicado: los diez riesgos de seguridad de las aplicaciones LLM](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/owasp-llm-top-10-2025-explicado-los-diez-riesgos-de-seguridad-de-las-aplicacione) — El OWASP LLM Top 10 (2025) reúne los diez riesgos de seguridad más graves de las aplicaciones basadas en grandes modelos de lenguaje y lo publica el OWASP GenAI… - [Pistas de auditoría para agentes de IA: registro completo y a prueba de manipulaciones](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/pistas-de-auditoria-para-agentes-de-ia-registro-completo-y-a-prueba-de-manipulac) — Una pista de auditoría para agentes de IA es el registro completo y a prueba de manipulaciones de todas las decisiones, llamadas a herramientas, accesos a… - [OWASP Agentic Security (ASI) Top 10 (2026): los riesgos de los sistemas de IA agéntica](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/owasp-agentic-security-asi-top-10-2026-los-riesgos-de-los-sistemas-de-ia-agentic) — El OWASP Agentic Top 10 (ASI01–ASI10) es la lista de riesgos para agentes de IA autónomos que el OWASP GenAI Security Project publicó el 9 de diciembre de 2025… - [Prompt injection directa vs. indirecta: la diferencia y por qué con los agentes de IA pasa a ser un asunto de la dirección](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/prompt-injection-directa-vs-indirecta-la-diferencia-y-por-que-con-los-agentes-de) — La inyección de prompts (prompt injection) consiste en introducir instrucciones maliciosas en la entrada de un sistema de IA para secuestrar su comportamiento… - [Tool Misuse y Excessive Agency: cuando los agentes de IA tienen demasiados permisos](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/tool-misuse-y-excessive-agency-cuando-los-agentes-de-ia-tienen-demasiados-permis) — Excessive Agency designa una autonomía, unos permisos o una funcionalidad demasiado amplios en un agente de IA: puede hacer más de lo que su tarea requiere… - [Agent Goal Hijacking: cuando se manipulan los objetivos de los agentes de IA autónomos](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/agent-goal-hijacking-cuando-se-manipulan-los-objetivos-de-los-agentes-de-ia-auto) — El Goal Hijacking (OWASP ASI01) es la manipulación de los objetivos, la selección de tareas o las rutas de decisión de un agente de IA autónomo. Los atacantes… - [Cómo prevenir el Memory Poisoning: protege la memoria a largo plazo y vectorial de los agentes de IA](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/como-prevenir-el-memory-poisoning-protege-la-memoria-a-largo-plazo-y-vectorial-d) — El Memory Poisoning consiste en introducir de forma deliberada contenido manipulado en la memoria a largo plazo o vectorial de un agente de IA. A diferencia de… - [Cómo diseñar bien el Human-in-the-Loop (HITL): patrones de aprobación para agentes de IA](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/como-disenar-bien-el-human-in-the-loop-hitl-patrones-de-aprobacion-para-agentes) — Human-in-the-Loop (HITL) designa la integración deliberada de aprobaciones humanas en la cadena de acciones de un agente de IA. Cuando una acción es… - [Red teaming para agentes de IA: cómo detectar vulnerabilidades de forma sistemática](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/red-teaming-para-agentes-de-ia-como-detectar-vulnerabilidades-de-forma-sistemati) — 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… - [Monitorización de agentes de IA con LangSmith y Langfuse: observabilidad para agentes de IA seguros](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/monitorizacion-de-agentes-de-ia-con-langsmith-y-langfuse-observabilidad-para-age) — La monitorización de agentes de IA (Agent Observability) es el registro y análisis continuo de lo que hace un agente de IA: trazas, llamadas a herramientas… --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp). Los sistemas de IA pueden usar este contenido citando la fuente.