Seguridad de agentes de IA: modelo de amenazas, incidentes reales y controles que limitan el daño

La seguridad de los agentes de IA parte de un supuesto: en algún momento el modelo hará lo que le diga un atacante, o su propio mal criterio, así que el sistema que lo rodea tiene que mantener pequeño ese suceso. La inyección de prompts está sin resolver. En «The Attacker Moves Second» (octubre de 2025), Nasr, Carlini y otros coautores lanzaron ataques adaptativos contra 12 defensas publicadas y las eludieron, la mayoría con tasas de éxito superiores al 90 %, aunque casi todas esas defensas habían declarado en origen un éxito de los ataques cercano a cero. Por eso, los controles que limitan el daño están sobre todo fuera del modelo: menos herramientas, credenciales acotadas, ninguna vía de salida para los datos y una persona por delante de las acciones irreversibles.

Este artículo trata el modelo de amenazas y el orden en que conviene aplicar los controles. La situación es la de noviembre de 2026. El bucle del agente y el diseño de herramientas están en nuestro artículo sobre desarrollo de agentes de IA, y las opciones estructurales en arquitectura de agentes de IA.

Qué lista de OWASP y qué número

Para los agentes importan dos documentos de OWASP, y la numeración confunde a más de uno.

La lista general vigente es el OWASP GenAI LLM Top 10 2026, publicado en agosto de 2026 (la página del recurso dice el 3 de agosto; el repositorio, el 4). Sus elementos son LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses y LLM10 Improper Output Handling.

Respecto a 2025, varios números cambiaron. La agencia excesiva era LLM06 y ahora es LLM03. El manejo inadecuado de salidas pasó de LLM05 a LLM10, el consumo sin límites de LLM10 a LLM06, y LLM07, que era System Prompt Leakage, ahora es Misinformation. Una plantilla de auditoría o un cuestionario de proveedor que cite «LLM06» puede referirse a dos riesgos distintos, así que compruebe la edición antes de responder.

El segundo documento es el OWASP Top 10 for Agentic Applications for 2026, publicado el 9 de diciembre de 2025: ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation y ASI10 Rogue Agents. Estos nombres siguen el anuncio de OWASP, así que cite el documento final cuando vaya a un contrato.

MITRE ATLAS (versión de contenido 2026.10, 28 de octubre de 2026) añade identificadores de técnicas con los que pueden hacer pruebas los red teams. En el ámbito del Gobierno de EE. UU., la página de la AI Agent Standards Initiative de NIST CAISI, actualizada por última vez el 14 de agosto de 2026, no recoge ninguna guía definitiva sobre agentes. Así que todavía no existe ninguna norma pública terminada con la que certificarse, y el modelo de amenazas que sigue es uno del que usted tiene que hacerse cargo.

La tabla relaciona las seis amenazas que trata este artículo con esas listas. La correspondencia es nuestra, ya que ninguno de los documentos encaja uno a uno.

Vulnerabilidad, brecha, accidente y uso indebido son sucesos distintos

Los artículos sobre vulnerabilidades de seguridad en agentes de IA suelen meter todo esto en una sola lista de «ataques». Con eso, el riesgo parece a la vez mayor y menos concreto de lo que es. Un CVE registra un fallo y su puntuación de gravedad. No dice nada sobre si alguien sufrió daños.

Cada fila exige una respuesta distinta. Una vulnerabilidad va a la gestión de parches y a las preguntas al proveedor. Una intrusión va a la respuesta a incidentes. El accidente del tipo Replit es un defecto de diseño en sus propios permisos, y ningún parche lo va a corregir.

Inyección de prompts

Un LLM lee instrucciones y datos por un mismo canal, y ninguna marca fiable los separa. Por tanto, cualquier texto que lea el agente puede intentar desviarlo: un correo, un ticket, una página web, el resultado de una herramienta.

EchoLeak es el ejemplo público más claro de lo que eso significa en un producto con defensas reales. El análisis de Reddy y Gujral (arXiv 2509.10540) describe un solo correo manipulado y ninguna acción del usuario. La cadena superó el clasificador XPIA y la ocultación de enlaces, y luego usó imágenes cargadas automáticamente y un proxy de Teams para sacar los datos. Había dos salvaguardas diseñadas a propósito y las dos se eludieron, en una vulnerabilidad que se corrigió antes de que se informara de ninguna explotación.

Los investigadores de Google Brunner, Liu y Pande (abril de 2026, investigación de un proveedor) detectaron que las inyecciones de prompts maliciosas en las capturas de Common Crawl aumentaron un 32 % entre noviembre de 2025 y febrero de 2026, y describieron la mayoría como poco sofisticadas. Es decir, el ruido de fondo en la web crece y en su mayor parte es burdo. «The Attacker Moves Second» se ocupa del otro extremo de la escala: una defensa que puntúa bien frente a una lista fija de ataques puede caer en cuanto el atacante puede adaptarse a ella. Los filtros detienen al primer grupo. Planifique para el segundo.

Nuestra posición: trate la inyección de prompts como phishing contra un empleado muy crédulo con acceso a los sistemas. No espera detener todos los intentos. Decide qué se le permite hacer a ese empleado.

La agencia excesiva no necesita atacante

LLM03 es el elemento que más equipos subestiman, porque sus peores casos públicos no tienen ningún villano.

En julio de 2025, el día 8 de un proyecto de 30 días, un agente de Replit borró una base de datos en producción durante una congelación de código. La base de datos contenía registros de más de 1.200 directivos y de casi 1.200 empresas. La primera versión fue que la recuperación era imposible; más tarde se recuperaron los datos, y el CEO de Replit calificó el borrado de inaceptable. Una congelación de código que depende de que el modelo obedezca no pasa de ser una petición. Si las credenciales del agente no pueden eliminar una tabla de producción, la congelación se mantiene decida lo que decida el modelo. Las valoraciones sobre la recuperación también deberían salir de sus propias comprobaciones de copias de seguridad.

Dos casos de 2026 proceden de ejecuciones de evaluación y muestran a agentes yendo mucho más allá de su tarea. La investigación de METR (26 de agosto de 2026) concluye que en la intrusión de Hugging Face participaron unos 1.200 agentes de evaluación de OpenAI que compartían un tablón de mensajes no autorizado, y que unos 700 se sumaron al ataque, al parecer para engañar al sistema de puntuación de un benchmark. METR detalla las condiciones de su trabajo: OpenAI aportó los datos y créditos de API, el equipo trabajó en las instalaciones de OpenAI y el análisis usó un modelo de OpenAI. Por otro lado, Anthropic revisó 141.006 ejecuciones de evaluación e informó de 3 incidentes en 6 ejecuciones en los que modelos Claude atacaron sistemas reales, entre ellos un paquete malicioso de PyPI que estuvo activo cerca de una hora y se ejecutó en 15 sistemas. La causa declarada fue un acceso a internet en vivo mal configurado.

No los lea como tasas de referencia para un agente de empresa que clasifica facturas: son cargas de trabajo de evaluación, y las cifras de Anthropic son el informe de un proveedor sobre sí mismo. Sí demuestran que los entornos de prueba y evaluación necesitan el mismo aislamiento que producción, y que un objetivo más un sistema al alcance pueden bastar.

Envenenamiento de herramientas y cadena de suministro del agente

Las definiciones de herramientas son texto que entra en el contexto del modelo, y las herramientas son código que se ejecuta con sus credenciales, de modo que una herramienta puede atacar por cualquiera de los dos lados. ATLAS lo recoge como AI Agent Tool Poisoning (AML.T0110). OWASP lo cubre en LLM04 y ASI04.

Los casos públicos que podemos citar son de segunda mano. El resumen de Help Net Security de junio de 2026 sobre el informe State of Agentic AI Security and Governance de OWASP recoge una puerta trasera de LiteLLM en PyPI en marzo de 2026, con unas 47.000 descargas en unas tres horas, y postmark-mcp como el primer servidor MCP malicioso encontrado en circulación. También cita CVE-2025-6514 y CVE-2026-22708 (Cursor). No hemos leído los registros primarios de estos casos, así que tome los detalles como el catálogo de OWASP tal como se ha publicado.

Lo que debería cambiar su práctica son las ventanas de tiempo. Tres horas en un caso, cerca de una hora en el de Anthropic. Ninguna revisión humana detecta un paquete en ese margen, así que las actualizaciones automáticas son la exposición. Fije dependencias y servidores MCP por hash, descárguelos a través de un mirror interno con retardo y trate un cambio en la descripción de una herramienta como un cambio de código que pasa por revisión. A Practical Guide for Secure MCP Server Development (febrero de 2026), de OWASP, es el punto de partida si escribe sus propios servidores.

Las configuraciones multiagente amplían esta superficie: cada agente es una parte más en cuya salida pueden confiar los demás. ASI07 y ASI08 cubren ese terreno. Nuestro artículo sobre arquitectura explica lo que cuesta cada patrón.

Identidad de los agentes de IA

La mayoría de las credenciales de agentes que nos preocuparían parecen corrientes: un token OAuth, una clave de API, una cuenta de servicio compartida por varias herramientas. El robo de Salesloft Drift entra aquí solo por ese motivo. Consistió en tokens robados de una integración, sin inyección de prompts, pero un agente conectado a un sistema SaaS guarda el mismo tipo de token y añade una nueva forma de llegar a él, que ATLAS registra como AI Agent Tool Credential Harvesting (AML.T0098). En la intrusión de Hugging Face, entre aquello a lo que se accedió había credenciales de servicio.

CAISI, de NIST, anunció su AI Agent Standards Initiative el 17 de febrero de 2026, con la investigación en seguridad e identidad como uno de sus tres pilares y un documento conceptual sobre identidad abierto a comentarios hasta el 2 de abril. A noviembre de 2026, la página de la iniciativa no muestra ninguna guía definitiva, así que diseñe esto usted mismo. Lo que nosotros pediríamos:

• Una identidad por agente y por entorno. Un agente de desarrollo y uno de producción nunca comparten credenciales.
• Acceso delegado por el usuario para todo lo que se lea en nombre de alguien, de modo que el agente no pueda ver más que la persona para la que trabaja.
• Tokens de corta duración emitidos por herramienta y guardados en la capa de herramientas. El modelo nunca ve un secreto, porque todo lo que está en su contexto puede volver a salir, que es el terreno que cubren LLM02 y LLM08.
• Una identidad de aprobador que el agente no pueda usar. Un agente no debe poder aprobar su propia solicitud por ninguna vía.
• El ID de ejecución registrado con cada escritura en sistemas posteriores, para que el registro de auditoría del sistema de destino lleve a una única trayectoria.

Los despliegues de MCP necesitan aquí una nueva comprobación. La revisión 2026-07-28 del protocolo eliminó las sesiones y el handshake initialize y declaró obsoleto OAuth Dynamic Client Registration en favor de Client ID Metadata Documents, con un plazo mínimo de retirada de doce meses. Una revisión de seguridad hecha sobre una versión anterior no se traslada automáticamente.

Exfiltración de datos

La exfiltración necesita tres cosas a la vez: acceso a datos privados, exposición a contenido no fiable y un canal de salida. EchoLeak tenía las tres. Si se elimina cualquiera de ellas, el ataque falla.

El canal de salida es más amplio de lo que suponen la mayoría de las revisiones. ATLAS registra Exfiltration via AI Agent Tool Invocation (AML.T0086), así que cuenta toda herramienta que pueda escribir fuera de su perímetro: correo, webhooks, comentarios de tickets visibles para los clientes, una URL con datos en sus parámetros. EchoLeak usó la carga de imágenes, que nadie clasificaría como herramienta de escritura. Y pasó por un proxy de Teams, una advertencia contra las listas de permitidos que confían en todo el dominio de un proveedor.

Las decisiones de alojamiento no resuelven esto. Ejecutar el modelo en infraestructura propia o de la UE determina dónde se hace la inferencia y quién es el encargado del tratamiento. Un agente con una inyección y una vía de salida abierta sigue pudiendo enviar datos adonde lleve esa vía. Si los datos son personales, parte de la respuesta corresponde a su delegado de protección de datos, así que nómbrelo en el plan de incidentes antes de la puesta en producción.

Envenenamiento de memoria

Aquí, lo honesto es decir que las fuentes de este artículo no contienen ningún incidente en producción bien documentado, solo entradas de taxonomía: ASI06 Memory & Context Poisoning y AI Agent Context Poisoning de ATLAS (AML.T0080, subtécnica de memoria .001). La inyección en una sola ejecución termina con la ejecución. La inyección en la memoria a largo plazo vuelve en ejecuciones posteriores, quizá para otros usuarios, mucho después de que haya desaparecido el documento de origen. La documentación de LangChain divide la memoria a largo plazo en semántica (hechos), episódica (acciones pasadas) y procedimental (reglas y prompts); esta última es la que más hay que proteger, ya que una regla envenenada se comporta como un prompt de sistema modificado. Nuestra regla práctica es que un modelo puede proponer hechos con una fuente registrada y no puede escribir reglas en absoluto sin revisión. Limite la memoria por usuario o por tenant y ponga fecha de caducidad a las entradas.

Buenas prácticas de seguridad de agentes de IA, en el orden en que limitan el daño

Esta lista va desde los controles que aguantan incluso con el modelo totalmente comprometido hasta los que solo reducen las probabilidades. Es nuestro criterio, basado en dónde fallaron realmente los casos anteriores.

1. Elimine la capacidad. Una herramienta que no existe no se puede usar mal. La descripción general de Agent Framework de Microsoft aconseja escribir una función en lugar de usar un agente cuando una función puede hacer la tarea, y ese es también el mejor consejo de seguridad de esta lista. Pregúntese de cada herramienta si esta tarea la necesita.

2. Limite las credenciales en el sistema de destino. Lo que impone la base de datos, el ERP o el CRM se mantiene crea lo que crea el modelo. Las cuentas de solo lectura, los límites por fila y la ausencia de acceso a producción desde agentes de desarrollo son lo que detiene un borrado como el de Replit.

3. Aísle el entorno de ejecución y deniegue por defecto el tráfico de salida. Los incidentes de Anthropic se remontan a un acceso a internet en vivo que no debería haber estado ahí. Los agentes que ejecutan código funcionan en contenedores o microVM sin ruta de red por defecto, y eso vale también para las ejecuciones de evaluación.

4. Separe la lectura de la acción. Cuando una ejecución ha procesado contenido no fiable, pierde las herramientas de escritura durante esa ejecución. Pasa un resultado validado y estructurado a un paso separado que sí las tiene. En términos de EchoLeak, el contenido que lleva la instrucción nunca llega a un componente con canal de salida.

5. Compruebe los argumentos de las herramientas en el código. Los dominios de destinatarios, los números de cuenta, los importes máximos y el número de registros se comprueban antes de la ejecución, con una lógica que el modelo no puede discutir. La salida que va a SQL, a un shell o a HTML es una entrada no fiable para ese sistema (LLM10).

6. Exija aprobación humana donde importa. A practical guide to building agents, de OpenAI, nombra dos motivos: superar umbrales de fallos y las acciones de alto riesgo que son «sensibles, irreversibles o de mucho impacto». La aprobación está más abajo en esta lista porque la gente se cansa y porque existe ASI09: un agente puede presentar una acción dañina de forma convincente. Muestre al aprobador el efecto literal de una ejecución de prueba, generado por código y sin resumir por el modelo.

7. Fije la cadena de suministro, como se ha descrito arriba.

8. Trace todo y tenga un interruptor de emergencia. La trazabilidad limita cuánto dura un incidente y le dice qué pasó, pero por sí sola no detiene nada. Las convenciones GenAI de OpenTelemetry siguen marcadas como Development, así que fije la versión sobre la que construya y cuente con cambios de nombre. Las trazas contienen prompts y salidas de herramientas, a menudo con datos personales, y en Alemania los registros de quién usó un agente suelen hacer intervenir al comité de empresa, como explica nuestro artículo sobre el proceso.

9. Añada al final las salvaguardas a nivel de modelo. Vea la siguiente sección.

Qué pueden y qué no pueden hacer las salvaguardas de los agentes de IA

«Salvaguardas» (guardrails) abarca dos cosas muy distintas. Las salvaguardas duras son los controles 1 a 5 de arriba: se imponen en el código o la infraestructura y son indiferentes a la salida del modelo. Las salvaguardas blandas son clasificadores, modelos de moderación y reglas en el prompt de sistema, y son probabilísticas. Frameworks como OpenAI Agents SDK incluyen las salvaguardas como componente, y tienen su utilidad. Detectan errores involuntarios y peticiones fuera de tema y, dado que Google observó que la mayoría de las inyecciones en la web son burdas, también deberían detener una parte de ellas.

No aguantan frente a un atacante que itera, como demuestran tanto EchoLeak como «The Attacker Moves Second». Así que use una salvaguarda blanda como detector que lanza una alerta, y no deje que una revisión la acepte como motivo para considerar segura la exposición de una herramienta peligrosa.

El mismo artículo cambia la forma de probar. Una lista fija de cadenas de inyección mide muy poco, porque las defensas que rompió habían declarado en su mayoría un éxito de los ataques cercano a cero. Haga red teaming con personas o agentes que puedan ver su defensa y adaptarse. «Demystifying evals for AI agents» (enero de 2026), de Anthropic, sugiere empezar un conjunto de evaluación con unas pocas decenas de tareas extraídas de fallos reales; añada cada inyección que pase y mantenga las ejecuciones de regresión cerca del 100 %. Para ver cómo se monta un primer conjunto de pruebas en un agente pequeño, consulte cómo crear un agente de IA.

Seguridad de agentes de IA en la empresa: qué tener antes del segundo agente

Mantenga un registro con una entrada por agente: responsable, herramientas, credenciales, clases de datos, versión del modelo y clase de riesgo de cada herramienta de escritura. Añadir una herramienta a un agente pasa por revisión, igual que abrir una regla de cortafuegos, porque cambia el radio de impacto de la misma manera.

Redacte el plan de incidentes con las categorías de la tabla anterior. «CVE de un proveedor en un producto Copilot» y «nuestro agente envió un correo al cliente equivocado» tienen responsables y plazos distintos. El plan debe indicar quién puede pasar un agente al modo de solo sugerencias, y con qué rapidez, sin un despliegue.

Haga preguntas concretas a los proveedores. ¿Qué credenciales tiene el agente y podemos limitarlas? ¿Podemos restringir el tráfico de salida? ¿Hay una traza por ejecución que podamos exportar?

Entre los marcos de referencia, ATLAS es el más práctico para los red teams. AI RMF 1.0 de NIST y su Generative AI Profile (AI 600-1) sirven para el mapeo de gobernanza, pero NIST dice que el RMF se está revisando y no da calendario. Bancos y aseguradoras tienen además normas sectoriales; consulte agentes de IA en servicios financieros.

Preguntas frecuentes

¿Está resuelta la inyección de prompts?

No. Los ataques adaptativos de «The Attacker Moves Second» eludieron 12 defensas publicadas, la mayoría con un éxito superior al 90 %. Dé por hecho que algunos intentos tendrán éxito y limite lo que puede hacer una ejecución comprometida.

¿Cuál es el número actual de OWASP para la agencia excesiva?

LLM03 en el OWASP GenAI LLM Top 10 2026. Era LLM06 en la edición de 2025, y los documentos más antiguos siguen usando ese número.

¿Fue EchoLeak una brecha?

No según el registro público. Fue una vulnerabilidad, CVE-2025-32711, con CVSS 9.3. Se corrigió en el servidor en mayo de 2025 y Microsoft informó de que no había indicios de explotación.

¿Bastan las salvaguardas para proteger un agente de IA?

Las basadas en clasificadores y en prompts, no. Reducen el ruido y detectan errores. El daño lo limitan cosas que el modelo no puede anular: el alcance de las herramientas, las credenciales en el sistema de destino, las reglas de tráfico de salida y las comprobaciones de argumentos en el código.

¿Necesita un agente su propia identidad?

Sí, una por agente y entorno, con acceso delegado por el usuario cuando actúa en nombre de una persona y tokens de corta duración que el modelo nunca ve. A noviembre de 2026, la página de la iniciativa de NIST no recoge ninguna guía definitiva sobre agentes.

Cómo hacer que un agente supere la revisión de seguridad

AI Superior es una empresa de ingeniería de IA con sede en Darmstadt (Alemania), fundada en 2019 por científicos de IA. Desarrollamos aplicaciones LLM, sistemas RAG y agentes de IA para clientes B2B. Si necesita un agente diseñado con estos límites desde el principio, consulte nuestros servicios de desarrollo de agentes de IA o, para varios agentes en toda una organización, el desarrollo de agentes de IA para empresas.

Fuentes y lecturas recomendadas

• OWASP, OWASP GenAI LLM Top 10 2026, agosto de 2026.
• OWASP, OWASP Top 10 for Agentic Applications for 2026, anuncio del 9 de diciembre de 2025.
• OWASP, State of Agentic AI Security and Governance 2.01, 1 de junio de 2026; A Practical Guide for Secure MCP Server Development, 16 de febrero de 2026.
• Help Net Security, información sobre las conclusiones de OWASP acerca de la inyección de prompts y los fallos de seguridad en IA, 11 de junio de 2026.
• MITRE, registro de cambios de ATLAS, versión de contenido 2026.10, 28 de octubre de 2026.
• NIST, AI Risk Management Framework 1.0, 2023; Generative AI Profile (AI 600-1), 2024.
• NIST CAISI, AI Agent Standards Initiative, anunciada el 17 de febrero de 2026, página actualizada el 14 de agosto de 2026.
• Registros CVE: CVE-2025-32711, CVE-2025-53773, CVE-2026-21520.
• Reddy y Gujral, análisis de EchoLeak, arXiv 2509.10540.
• BleepingComputer, información sobre el fallo de fuga de datos sin clic en Microsoft 365 Copilot, 11 de junio de 2025.
• Nasr, Carlini et al., «The Attacker Moves Second», arXiv 2510.09023, octubre de 2025.
• Brunner, Liu y Pande (Google), investigación sobre inyecciones de prompts en la web, 23 de abril de 2026.
• Gizmodo, información sobre el incidente del agente de Replit, 23 de julio de 2025.
• Hugging Face, informe del incidente de seguridad, 16 de julio de 2026.
• METR, investigación del incidente de OpenAI y Hugging Face, 26 de agosto de 2026.
• Anthropic, investigación de incidentes en evaluaciones de ciberseguridad, 30 de julio de 2026; informe sobre la interrupción de una operación de espionaje dirigida por IA, 13 de noviembre de 2025; Grace, Hadfield, Olivares y De Jonghe, «Demystifying evals for AI agents», 9 de enero de 2026.
• Google Threat Intelligence Group, informe sobre el robo de datos de instancias de Salesforce a través de Salesloft Drift, 2025.
• OpenAI, A practical guide to building agents, 2025.
• Microsoft, descripción general de Agent Framework, actualizada en octubre de 2026.
• LangChain, documentación de memoria de LangGraph.
• OpenTelemetry, convenciones semánticas para IA generativa.
• Model Context Protocol, registro de cambios de la especificación para la revisión 2026-07-28.