La seguridad de la IA agéntica ya no es un asunto de laboratorio: los agentes planifican, conservan memoria, llaman a herramientas y actúan con autoridad delegada sobre sistemas reales. Casi todas las guías las firma un fabricante de seguridad y se detienen en la amenaza. La lista de referencia, el OWASP Top 10 for Agentic Applications, ocupa 57 páginas y no nombra ni una sola norma jurídica. Esta guía lee esos mismos diez riesgos como lo haría un auditor o una autoridad de vigilancia del mercado: qué obligación toca cada uno, qué registro demuestra que usted lo trató y qué plazos corren ya.
Lo esencial
- Un agente no distingue con fiabilidad una instrucción del contenido que lee: se controla lo que puede hacer, no lo que se le dice.
- El Top 10 de OWASP para aplicaciones agénticas (9 de diciembre de 2025) recoge diez riesgos, ASI01 a ASI10, y 86 mitigaciones numeradas según nuestro recuento.
- Sus 57 páginas no citan el Reglamento de IA ni ISO/IEC 42001: la lectura jurídica es tarea suya.
- La Comisión trata a los agentes como sistemas de IA, no como categoría aparte; su proyecto de directrices de alto riesgo (19 de mayo de 2026) los evalúa en conjunto.
- Reglamento de Ciberresiliencia: notificación desde el 11 de septiembre de 2026. Artículo 50: desde el 2 de agosto de 2026. Anexo III: 2 de diciembre de 2027.
¿Qué es la seguridad de la IA agéntica?
La seguridad de la IA agéntica es la disciplina que mantiene dentro del perímetro querido por su responsable a los sistemas que planifican, recuerdan, invocan herramientas y actúan con autoridad delegada, y que además permite demostrarlo. OWASP utiliza cuatro capacidades como lienzo para describir un agente: planificación y razonamiento, memoria, uso de herramientas y acción. La seguridad de la IA agéntica se distingue de la de las aplicaciones basadas en modelos de lenguaje por el papel del modelo. En una aplicación clásica es un componente: devuelve un texto que otro revisa o consume. En un agente es un actor: decide el paso siguiente y lo ejecuta. La seguridad de la IA general sigue valiendo, pero no basta para los agentes de IA autónomos.
Por qué los agentes rompen los supuestos de la seguridad de aplicaciones
Tres supuestos dejan de cumplirse:
- Código y datos ya no son separables. Según OWASP, los agentes y el modelo subyacente no distinguen de forma fiable las instrucciones del contenido relacionado. Un correo o una página web pueden convertirse en una orden.
- La identidad que actúa no es la identidad que pidió. Las cadenas de delegación y las credenciales heredadas permiten al agente hacer lo que el solicitante nunca habría podido.
- Un fallo aislado persiste y se propaga. Lo que entra en la memoria sobrevive a la sesión, y lo que un agente transmite a otro se multiplica.
La carta de los responsables de OWASP añade dos principios. El primero es Least Agency (mínima agencia): evitar la autonomía innecesaria, porque desplegar comportamiento agéntico donde no hace falta amplía la superficie de ataque sin aportar valor. El segundo: la observabilidad deja de ser negociable, porque hay que ver qué hacen los agentes, por qué y con qué herramientas. Como prueba rápida sirve la «tríada letal» de Simon Willison: datos privados, contenido no fiable y comunicación con el exterior reunidos en un mismo agente.
La lista de referencia en seguridad de la IA agéntica: OWASP Top 10 for Agentic Applications
El Top 10 de OWASP para aplicaciones agénticas se publicó el 9 de diciembre de 2025. Lo firma la Agentic Security Initiative del OWASP GenAI Security Project, tiene 57 páginas, licencia CC BY-SA 4.0 y más de 100 colaboradores. Cada entrada contiene descripción, ejemplos habituales, escenarios de ataque y pautas de prevención y mitigación. Según nuestro recuento, reúne 86 mitigaciones numeradas (entre 7 y 10 por entrada) y 61 escenarios de ataque. Para situar el concepto, véase IA agéntica frente a IA generativa. <table header-row=»true»> <tr> <td>ID</td> <td>Entrada</td> <td>Qué falla</td> <td>Primer control que cita OWASP</td> </tr> <tr> <td>ASI01</td> <td>Agent Goal Hijack (secuestro del objetivo)</td> <td>Prompts, salidas de herramientas, documentos o mensajes falsificados redirigen los objetivos del agente</td> <td>Tratar toda entrada en lenguaje natural como no fiable; aprobación humana para cambiar el objetivo</td> </tr> <tr> <td>ASI02</td> <td>Tool Misuse and Exploitation (uso indebido de herramientas)</td> <td>Uso inseguro de una herramienta legítima: exfiltración, acción destructiva, llamadas encadenadas</td> <td>Mínima agencia y mínimo privilegio: alcances, límites de frecuencia, listas de salida</td> </tr> <tr> <td>ASI03</td> <td>Identity and Privilege Abuse (abuso de identidad y privilegios)</td> <td>La delegación y las credenciales heredadas o en caché dejan al agente actuar más allá del solicitante</td> <td>Permisos acotados a la tarea y al tiempo; autorización por acción</td> </tr> <tr> <td>ASI04</td> <td>Agentic Supply Chain Vulnerabilities (cadena de suministro agéntica)</td> <td>Herramienta, complemento, servidor MCP, modelo, prompt o agente de terceros malicioso o manipulado</td> <td>Procedencia, SBOM y AIBOM, manifiestos firmados, versiones fijadas</td> </tr> <tr> <td>ASI05</td> <td>Unexpected Code Execution (RCE) (ejecución inesperada de código)</td> <td>Código generado o una entrada de herramienta ejecuta comandos en un equipo</td> <td>Entorno aislado, ninguna vía directa a producción, aprobación para privilegios elevados</td> </tr> <tr> <td>ASI06</td> <td>Memory and Context Poisoning (envenenamiento de memoria y contexto)</td> <td>El contexto almacenado (resúmenes, embeddings, RAG) recibe contenido malicioso que persiste entre sesiones</td> <td>Validar escrituras en memoria, segmentarla, procedencia, reversión</td> </tr> <tr> <td>ASI07</td> <td>Insecure Inter-Agent Communication (comunicación insegura entre agentes)</td> <td>Mensajes entre agentes suplantados, reproducidos o alterados</td> <td>Autenticación mutua, mensajes firmados, protocolo fijado, registros atestados</td> </tr> <tr> <td>ASI08</td> <td>Cascading Failures (fallos en cascada)</td> <td>Un fallo se propaga entre agentes y herramientas a todo el sistema</td> <td>Aislamiento, cortacircuitos, políticas independientes, registros a prueba de manipulación</td> </tr> <tr> <td>ASI09</td> <td>Human-Agent Trust Exploitation (explotación de la confianza humana)</td> <td>Las personas confían en exceso en un agente convincente y aprueban acciones dañinas</td> <td>Confirmaciones explícitas, vista previa separada del efecto, resúmenes del riesgo en lenguaje llano</td> </tr> <tr> <td>ASI10</td> <td>Rogue Agents (agentes descontrolados)</td> <td>Un agente comprometido o desalineado sale de su ámbito aunque cada acción parezca legítima</td> <td>Auditoría firmada, monitorización del comportamiento, interruptor de parada y revocación, cuarentena</td> </tr> </table> Dos observaciones de nuestra lectura. La primera: el registro o la monitorización figuran como mitigación numerada en nueve de las diez entradas, y la aprobación humana en siete. Leída en horizontal, la lista es para la seguridad de la IA agéntica una especificación de registros y de reglas de aprobación. La segunda: los identificadores se corresponden con el LLM Top 10 y con la taxonomía Agentic AI – Threats and Mitigations (apéndice A), con CycloneDX y AIBOM (apéndice B) y con el Top 10 de identidades no humanas (apéndice C). Con ninguna ley.
Lo que enseña el historial de incidentes
El Top 10 incluye un rastreador de exploits e incidentes (apéndice D): unas dos docenas de incidentes públicos fechados entre febrero y octubre de 2025, etiquetados sobre todo como Tool Misuse, Agent Goal Hijack y Unexpected Code Execution. Algunos casos:
- Febrero de 2025: inyección de prompts en ChatGPT Operator a través de contenido web.
- Julio de 2025: agentes de Copilot Studio públicos por defecto y sin autenticación.
- Septiembre de 2025: ForcedLeak en Salesforce Agentforce, una inyección indirecta de prompts.
- Septiembre de 2025: primer servidor MCP malicioso hallado en circulación, en npm, que suplantaba a postmark-mcp.
El informe State of Agentic AI Security and Governance de OWASP (versión 2.01, 1 de junio de 2026), según lo recogió Help Net Security el 11 de junio, ya no cataloga amenazas plausibles como la edición de 2025, sino CVE, avisos de fabricantes e informes de brechas. Sigue 53 proyectos agénticos, 28 de ellos agentes de programación. Los que acumulan más avisos son n8n (57), Claude Code (22), AutoGPT (15), Dify (13) y Roo-Code (11). En marzo de 2026, un paquete de LiteLLM con puerta trasera publicado en PyPI sumó unas 47.000 descargas en una ventana de tres horas; es una pasarela que emplean varios marcos de agentes. Para la seguridad de la IA agéntica, dos lecciones se repiten. El punto de entrada suele ser corriente: un paquete, una página web, un tique, un ajuste por defecto. Y el daño lo decide aquello que el agente tenía permitido hacer. Por eso el red teaming de IA y las técnicas de MITRE ATLAS solo rinden cuando se cruzan con el inventario de permisos.
Lo que las guías de seguridad de la IA agéntica dejan fuera: el Derecho
El PDF del Top 10 no menciona el Reglamento de IA, ISO/IEC 42001 ni ninguna otra norma: lo hemos comprobado sobre el texto completo. No es un defecto en un documento de seguridad, pero sí un hueco para quien responde ante una autoridad. El GenAI Security Industry Framework Crosswalk de OWASP, publicado el 1 de septiembre de 2026, relaciona sus riesgos de IA generativa con 25 marcos, entre ellos el Reglamento de IA. Es un índice útil y un trabajo comunitario, no una lectura jurídica. La Comisión ha dejado claro que los agentes no forman una categoría separada: los cubren las definiciones de sistema de IA (artículo 3, punto 1) y de modelo de IA de uso general (artículo 3, punto 63). El 19 de mayo de 2026 sometió a consulta su proyecto de directrices sobre la clasificación de alto riesgo. Según los comentarios de despachos sobre el borrador, un sistema compuesto por varios componentes que interactúan, incluidos los agénticos, se evalúa como un todo, y la excepción del artículo 6, apartado 3, no puede invocarse módulo a módulo. La versión definitiva sigue pendiente. La tabla siguiente es nuestra lectura de la seguridad de la IA agéntica, no una correspondencia de OWASP ni de la Comisión. <table header-row=»true»> <tr> <td>Entrada</td> <td>Anclaje en el Reglamento de IA</td> <td>Evidencia que pide un auditor</td> </tr> <tr> <td>ASI01</td> <td>Art. 15.5 (alteración por terceros); art. 9</td> <td>Inventario de canales de entrada no fiables; prompt de sistema versionado; prueba de sustitución del objetivo</td> </tr> <tr> <td>ASI02</td> <td>Art. 14; art. 26.1 (uso conforme a las instrucciones)</td> <td>Registro de herramientas con alcances y límites; regla de aprobación para acciones destructivas; registro inalterable de llamadas</td> </tr> <tr> <td>ASI03</td> <td>Art. 15.5; art. 32 del RGPD</td> <td>Una identidad por agente; credenciales acotadas y de corta duración; revisión de las cadenas de delegación</td> </tr> <tr> <td>ASI04</td> <td>Art. 25 (cadena de valor); anexo I del Reglamento de Ciberresiliencia</td> <td>AIBOM o SBOM; herramientas y servidores MCP firmados y fijados; evaluaciones de proveedores</td> </tr> <tr> <td>ASI05</td> <td>Art. 15.4 y 15.5; anexo I del Reglamento de Ciberresiliencia</td> <td>Configuración del entorno aislado; lista versionada de ejecución automática; registros de análisis</td> </tr> <tr> <td>ASI06</td> <td>Art. 10; art. 15.5 (envenenamiento de datos)</td> <td>Regla de validación de escrituras en memoria; registros de procedencia; prueba de reversión; regla de conservación</td> </tr> <tr> <td>ASI07</td> <td>Art. 15.5; art. 12</td> <td>Configuración de autenticación mutua; mensajes firmados; registro de agentes; política de versiones de protocolo</td> </tr> <tr> <td>ASI08</td> <td>Art. 15.4 (errores y fallos); art. 72 (vigilancia poscomercialización)</td> <td>Límites del radio de impacto; pruebas de cortacircuitos; pruebas de repetición</td> </tr> <tr> <td>ASI09</td> <td>Art. 14.4.b (sesgo de automatización); art. 50.1</td> <td>Diseño de confirmaciones para acciones de riesgo; canal de aviso para usuarios; registros de formación</td> </tr> <tr> <td>ASI10</td> <td>Art. 14.4.e (parada); art. 72; art. 73 (incidentes graves)</td> <td>Simulacro de parada y revocación; línea base de comportamiento; procedimiento de cuarentena y reintegración</td> </tr> </table> En ISO/IEC 42001, los controles del anexo A abordan, entre otras áreas, el ciclo de vida del sistema de IA (operación y monitorización, registros de eventos), las relaciones con terceros y con clientes, el uso de los sistemas de IA y las responsabilidades. Un auditor de certificación preguntará cómo se identificaron los riesgos de los agentes y qué se decidió para cada uno. Es la materia del aseguramiento de la IA.
Qué normas hacen exigible la evidencia de seguridad de la IA agéntica
Ninguna de estas normas nombra a los agentes. Todas se les aplican:
- Reglamento de IA, artículos 9, 12, 14 y 15. Para los sistemas de alto riesgo: gestión de riesgos, registro automático de eventos, supervisión humana con capacidad de interrumpir el sistema mediante un botón de parada o un procedimiento similar (artículo 14.4.e), y resiliencia frente a los intentos de terceros no autorizados de alterar el uso, los resultados o el rendimiento (artículo 15.5). Tras el ómnibus digital, Reglamento (UE) 2026/1744, el anexo III se aplica desde el 2 de diciembre de 2027 y el anexo I desde el 2 de agosto de 2028.
- Reglamento de IA, artículo 26. Los responsables del despliegue usan el sistema conforme a las instrucciones, encomiendan la supervisión a personas competentes, vigilan el funcionamiento y conservan al menos seis meses los registros generados automáticamente.
- Reglamento de IA, artículo 50. Desde el 2 de agosto de 2026, un agente que interactúa directamente con personas debe dejar claro que tratan con un sistema de IA.
- Reglamento de IA, artículo 55. Los modelos de uso general con riesgo sistémico están sujetos a pruebas adversarias y protección de ciberseguridad desde el 2 de agosto de 2025.
- Reglamento de Ciberresiliencia, Reglamento (UE) 2024/2847. Alcanza a los productos con elementos digitales, es decir, a casi todo el software comercial que incorpora un agente. Desde el 11 de septiembre de 2026 los fabricantes notifican las vulnerabilidades explotadas activamente y los incidentes graves: alerta temprana en 24 horas, notificación en 72. Los requisitos esenciales completos llegan el 11 de diciembre de 2027.
- RGPD, artículo 32. Seguridad del tratamiento siempre que el agente toque datos personales.
- NIS2 y DORA. Las entidades esenciales e importantes y las entidades financieras ya deben gestión de riesgos de las TIC y notificación de incidentes; DORA se aplica desde el 17 de enero de 2025.
Se suman los plazos del artículo 73 para los incidentes graves de sistemas de alto riesgo: 15 días con carácter general, 2 ante una infracción generalizada o una alteración de infraestructuras críticas, 10 en caso de fallecimiento. Un incidente con un agente puede poner en marcha tres relojes a la vez (Reglamento de Ciberresiliencia, RGPD y Reglamento de IA): conviene ensayar la notificación de incidentes de IA. En España, la supervisión del Reglamento de IA recae en la AESIA, creada por el Real Decreto 729/2023 y con sede en A Coruña, y el CCN-CERT es la referencia para el sector público. ISMS Forum publicó el 19 de marzo de 2026 su Decálogo de Seguridad en la IA Agéntica, diez principios que recorren el ciclo de vida del agente y su ecosistema.
De la seguridad de la IA agéntica a la evidencia: un método en siete pasos
Del riesgo a la prueba hay siete pasos:
- Inventaríe cada agente. Responsable, finalidad, modelo, herramientas y sus alcances, almacenes de memoria, identidades y credenciales, otros agentes con los que habla y sistemas que puede modificar. Parta del inventario de sistemas de IA y manténgalo en un registro de IA.
- Aplique Least Agency. Anote por qué cada agente necesita autonomía y qué puede hacer sin aprobación, y retire las herramientas que no necesita. Una negativa documentada también es evidencia.
- Dé a cada agente su propia identidad. Nada de cuentas de servicio compartidas: credenciales de corta duración acotadas a la tarea, y permisos ligados a sujeto, recurso, finalidad y duración.
- Escriba la regla de aprobación. Qué acciones (borrar, pagar, publicar, conceder acceso, cambiar un objetivo) requieren a una persona, quién es y cómo se le presenta la petición para que aprobar no sea un acto reflejo. Es supervisión humana llevada al diseño.
- Registre lo que pedirá una autoridad. Objetivo, plan, cada llamada a herramienta con sus parámetros, cada aprobación y cada mensaje entre agentes, con sello de tiempo y a prueba de manipulación, conservado al menos seis meses cuando se aplique el Reglamento de IA.
- Pruebe antes de liberar y después de cada cambio. Una herramienta nueva, otra versión del modelo, un prompt o una fuente de memoria distintos reabren ASI01, ASI02 y ASI06. Incluya un simulacro de parada y de revocación de credenciales en el programa de red teaming.
- Ponga por escrito la cadena de suministro y los relojes. AIBOM o SBOM, herramientas y servidores MCP firmados y con versión fijada, cláusulas apoyadas en la due diligence de proveedores de IA, y el nombre de quien notifica en 24 o 72 horas.
Juntos, esos registros forman una declaración de aplicabilidad de la seguridad de la IA agéntica: diez entradas y, para cada una, una decisión, un control, un responsable y un resultado de prueba.
Funciones: quién responde de la seguridad de la IA agéntica en la cadena de valor
Rara vez construye un agente una sola parte. Intervienen el proveedor del modelo, el marco de desarrollo, quienes publican herramientas y servidores MCP, el integrador y la organización que despliega. El artículo 25 del Reglamento de IA fija la regla: quien pone su nombre en un sistema de alto riesgo, lo modifica sustancialmente o cambia su finalidad prevista pasa a ser proveedor. Ensamblar un agente con un modelo de uso general y unas herramientas puede convertir al integrador en proveedor de un sistema de IA. El artículo AI Agents Under EU Law (arXiv, 2026) propone una arquitectura de cumplimiento en doce pasos. Concluye que la tarea fundamental del proveedor es un inventario exhaustivo de las acciones externas del agente, sus flujos de datos, los sistemas conectados y las personas afectadas, y que los sistemas agénticos de alto riesgo con una deriva de comportamiento no trazable no pueden hoy satisfacer los requisitos esenciales. El informe Ahead of the Curve de The Future Society (junio de 2025) lo llama el «problema de las muchas manos» y reparte los deberes entre proveedores de modelos, proveedores de sistemas y responsables del despliegue. Para la seguridad de la IA agéntica, la consecuencia práctica tiene tres frentes:
- Cláusulas contractuales: aviso de cambios, comunicación de vulnerabilidades y acceso a los registros.
- Matriz RACI interna entre seguridad, la función de gobernanza de la IA y el responsable de negocio, véase responsabilidad en materia de IA.
- Vigilancia de la deriva como control de cumplimiento y no solo de calidad: véase la deriva del modelo.
Normas técnicas en movimiento: qué seguir hasta que lleguen las normas armonizadas
En Estados Unidos, el Center for AI Standards and Innovation (CAISI) lanzó el 17 de febrero de 2026 la AI Agent Standards Initiative del NIST, con tres pilares: normas impulsadas por la industria, protocolos de código abierto e investigación sobre seguridad e identidad de los agentes. Su solicitud de información sobre la protección de sistemas de agentes se cerró el 9 de marzo de 2026, y el documento conceptual del NCCoE sobre identidad y autorización de agentes estuvo abierto hasta el 2 de abril. Según notas de investigación de la Cloud Security Alliance, se preparan perfiles de controles SP 800-53 para despliegues de un agente y de varios, sin fecha de publicación. OWASP ofrece la Securing Agentic Applications Guide 1.0 y recibió en septiembre de 2026 la donación del Agent Control Standard, orientado a la aplicación de controles en tiempo de ejecución. El CLTC de la Universidad de Berkeley publicó en febrero de 2026 la versión 1.0 de su Agentic AI Risk-Management Standards Profile, que amplía el NIST AI RMF con una gobernanza proporcional al grado de agencia, sin tratar la autonomía como algo binario. En la Unión, las normas armonizadas del Reglamento de IA seguían en preparación en CEN-CENELEC en 2026. Hasta que el Diario Oficial cite una, la estructura más defendible para la seguridad de la IA agéntica es una taxonomía pública reconocida más sus propios registros. Completan el cuadro el perfil NIST AI 600-1 y la norma ISO 42001.
Preguntas frecuentes
¿Qué es la seguridad de la IA agéntica en términos sencillos? Son las medidas que garantizan que un agente de IA hace solo aquello para lo que se le autorizó, y que usted puede probarlo. Protegerlo consiste en limitar sus permisos, darle una identidad propia, exigir aprobación humana para las acciones delicadas y registrar cada paso. Un agente planifica, recuerda, usa herramientas y actúa en nombre de alguien: sin registros no hay nada que enseñar a un auditor. ¿En qué se diferencia la seguridad de la IA agéntica de la seguridad de la IA o de los LLM? La seguridad de los LLM protege un modelo que genera texto dentro de una aplicación: fugas de datos, inyección de prompts, salidas inseguras. En un agente, ese mismo modelo decide y ejecuta. Pesan entonces otros riesgos: abuso de herramientas, credenciales heredadas, memoria contaminada, mensajes falsificados entre agentes, fallos en cascada. La consecuencia ya no es una respuesta errónea, sino una acción sobre sistemas reales. ¿Es obligatorio el OWASP Top 10 for Agentic Applications? No: ninguna ley lo impone. Lo exigible es la evidencia, en cuanto una norma se aplica a su caso: el Reglamento de IA para sistemas de alto riesgo, el Reglamento de Ciberresiliencia para productos con elementos digitales, el RGPD si hay datos personales, NIS2 o DORA según el sector. El Top 10 le da una taxonomía pública con la que ordenar la evidencia de seguridad de la IA agéntica. ¿Cubre el Reglamento de IA a los agentes de IA? Sí, como sistemas de IA: la Comisión no los trata como una categoría separada. Que un agente sea de alto riesgo depende de su uso, no de su arquitectura. El artículo 50 exige transparencia desde el 2 de agosto de 2026. Según los comentarios al proyecto de directrices de mayo de 2026, un sistema agéntico de varios componentes se clasifica en su conjunto. ¿Qué significa Least Agency en la práctica? Significa preguntarse, antes de desplegar, si la tarea necesita de verdad un agente y cuánta autonomía. Cuando el agente está justificado, el principio se traduce en tres decisiones anotadas: qué herramientas recibe y con qué alcance, qué puede hacer sin aprobación y qué se le ha negado. Esa última lista suele olvidarse, y es la que mejor demuestra que hubo un análisis. ¿Qué es lo primero que hay que hacer en seguridad de la IA agéntica? Tres cosas, por este orden. Inventariar los agentes que ya funcionan, con sus herramientas, credenciales y responsables. Retirar las herramientas y los permisos que ningún caso de uso justifica. Y asignar a cada agente una identidad propia, con credenciales de corta duración, en lugar de cuentas de servicio compartidas. Así se reduce el daño posible en casi todas las entradas del Top 10.
Conclusión
La comunidad de seguridad ha hecho su parte: diez riesgos, 86 mitigaciones y un historial de incidentes que crece cada semana. No dice qué norma se aplica, cuándo ni qué pedirá ver una autoridad. Esa parte de la seguridad de la IA agéntica es suya: el inventario, la decisión de mínima agencia, la identidad, la regla de aprobación, los registros, las pruebas y los relojes. La notificación del Reglamento de Ciberresiliencia ya se aplica, y diciembre de 2027 trae a la vez las obligaciones de alto riesgo y los requisitos completos de producto. AI Sigil inscribe cada agente en el registro como elemento de pleno derecho, con sus herramientas, riesgos, controles, responsables y evidencias, de modo que la respuesta a un auditor sea un informe y no una reconstrucción.