Seguridad de los agentes de IA: ¿qué cambia cuando un modelo dispone de herramientas y credenciales?

La seguridad de los agentes de IA consiste en proteger los sistemas de IA que pueden actuar, y no solo responder. Un agente dispone de herramientas, credenciales y memoria, por lo que garantizar su seguridad implica controlar qué se le permite invocar, qué identidad tiene y qué hace en tiempo de ejecución, más allá de lo que indique su modelo.

Esa distinción determina el alcance del impacto. Un modelo que responde a preguntas puede equivocarse. Un agente que disponga de un token de API, un buzón de correo y un shell puede equivocarse y actuar en consecuencia, dentro de los límites que le permitan sus permisos. Esta página aborda la superficie de amenaza específica de los agentes: la familia de técnicas de agentes de MITRE ATLAS, el envenenamiento de herramientas, la identidad y el inventario de los agentes, los incidentes documentados y la detección en tiempo de ejecución. Para obtener información sobre la arquitectura circundante, el ciclo de vida y la gobernanza de los sistemas autónomos, incluyendo el envenenamiento de memoria y el Top 10 de OWASP para aplicaciones basadas en agentes, consulta nuestra guía sobre seguridad de la IA basada en agentes.

¿Qué es la seguridad de los agentes de IA?

Un agente de IA es un modelo lingüístico programado para actuar. Planifica, utiliza herramientas, lee y escribe en la memoria, almacena credenciales y, cada vez más, se coordina con otros agentes. Cada una de esas capacidades es útil, pero también constituye una interfaz a la que un atacante puede acceder. Ahí radica todo el riesgo de seguridad de los agentes de IA: el modelo no se ha vuelto más peligroso, sino que ahora tiene «manos».

La definición más clara de esta línea proviene de un organismo de normalización, más que de un proveedor. El «OWASP Top 10 para aplicaciones de modelos de lenguaje grande (LLM) 2026» se centra en el caso del «modelo como componente», es decir, un modelo integrado en una aplicación y que responde a consultas. En cuanto el modelo se convierte en el actor —utilizando herramientas, conservando la memoria entre sesiones y provocando consecuencias posteriores—, OWASP lo incluye en su lista de «agencia». Se trata de un organismo de normalización que traza con precisión el límite del que trata esta página. El repositorio de código fuente canónico fecha esa edición el 4 de agosto de 2026 y muestra hasta qué punto se ha desplazado el límite: la «agencia excesiva» ocupa ahora el puesto LLM03, tras haber subido desde el sexto lugar en la lista de 2025.

La consecuencia práctica es que la seguridad de los agentes de IA es, ante todo, un problema de permisos y herramientas, más que un problema de modelos. Reforzar la seguridad de un modelo no reduce el alcance de una herramienta a la que el agente sigue teniendo permiso para recurrir. Aquí es donde la seguridad de los agentes se diferencia de la disciplina más amplia de la seguridad de la IA, y es por eso por lo que el « prompt injection » (la capacidad de un agente para actuar en función de lo que lee) tiene mucha más importancia una vez que el agente puede actuar en función de lo que lee.

El momento adecuado es la otra mitad de la respuesta. Gartner prevé que, para 2026, hasta el 40 % de las aplicaciones empresariales incluirán agentes integrados específicos para cada tarea, frente a menos del 5 % en 2025. Una encuesta realizada en 2025 a 353 organizaciones reveló que el 80 % afirmaba que sus agentes de IA habían llevado a cabo acciones no deseadas. Además, el análisis de Google de las instantáneas de Common Crawl reveló un aumento relativo del 32 % en la categoría de contenido malicioso entre noviembre de 2025 y febrero de 2026, lo que significa que el contenido no fiable que leen los agentes está empeorando. La adopción va por delante de los controles, lo cual es el patrón recurrente de todos los retos de seguridad relacionados con los agentes de IA de esta lista.

Los cinco puntos en los que un agente puede ser atacado

La mayoría de los trabajos recientes sobre este tema coinciden en el mismo modelo de cinco capas de la superficie de ataque de los agentes de IA, y esa coincidencia es una buena indicación de que el modelo es sólido. Se trata de un requisito mínimo más que de un factor diferenciador, por lo que conviene mencionarlo una vez y pasar a otro tema.

‍

Tabla 1: Las cinco capas de la superficie de ataque de un agente de IA y el fallo que introduce cada una de ellas.

El resto de esta página aborda lo que ese modelo no trata: los identificadores de técnicas específicas, los límites de la herramienta, el registro de identidades y las señales de tiempo de ejecución.

Cómo se corresponden los ataques de los agentes con MITRE ATLAS

MITRE ATLAS es la base de conocimientos de MITRE sobre el comportamiento real de los adversarios frente a los sistemas de IA, y constituye el marco nativo de agentes para este problema. Su versión actual es la v2026.07, publicada en GitHub el 7 de agosto de 2026. El texto de la publicación describe con exactitud su contenido: «Esta versión de los datos de ATLAS contiene 1 matriz, 16 tácticas, 101 técnicas, 77 subtécnicas, 37 medidas de mitigación y 68 casos prácticos». Esto supone un total de 178 definiciones de técnicas.

De esos 178, 29 entradas son específicas de cada agente: 13 técnicas principales y 16 subtécnicas. Junto a ellas se encuentran siete medidas de mitigación de los agentes y cuatro casos prácticos sobre agentes clave. La base de recuento es importante, así que aquí la tienes: una entrada cumple los requisitos cuando su nombre completo tal y como aparece en ATLAS contiene «AI Agent» o «Agent», además de AML.0034.002 Cost Harvesting: Consumo de recursos por parte de los agentes, que, aunque está claramente relacionado con los agentes, no supera una prueba estricta de límites de palabra en «Agent». Todos los identificadores que aparecen a continuación se han extraído del material de la versión publicado en el repositorio de datos de ATLAS.

El alcance general es aún mayor. En la versión v2026.07, 48 de las 178 definiciones de técnicas (el 27,0 %) mencionan el término «agente» en su nombre o descripción, junto con 19 de los 68 casos prácticos (el 27,9 %) y 14 de las 37 medidas de mitigación. Aproximadamente una cuarta parte del corpus de ATLAS hace referencia ahora a los agentes de alguna manera.

Este es el factor diferenciador, expresado con precisión y no de forma imprecisa. No es cierto que nadie haya relacionado ATLAS con los agentes. Lo que sí es cierto es que todos los intentos públicos se basan en una versión obsoleta de ATLAS y abarcan, como mucho, 2 de las 29 entradas de agentes actuales. Existen dos correspondencias públicas de este tipo, y ninguna de ellas es una página que se posicione para este tema, razón por la cual el propio corpus de posicionamiento no recoge ningún identificador de ATLAS. Una de las dos cita la versión 5.4.0 de ATLAS y menciona siete identificadores de técnicas. La otra cita una técnica que ya ha sido retirada. Para obtener una visión general del marco en sí, consulta nuestra guía explicativa sobre el marco MITRE ATLAS; lo que sigue se refiere específicamente a los agentes.

Una nota sobre el otro marco de MITRE: ATT&CK no es el enfoque principal adecuado en este caso. Es relevante tras la compromisión, una vez que las credenciales de un agente o su host se utilizan indebidamente como punto de apoyo convencional, pero no cuenta con una familia de técnicas propias del agente. La versión actual es ATT&CK v19.2, publicada el 6 de agosto de 2026. Las pruebas de ataque de los agentes frente a estas técnicas forman parte de Equipo rojo de IA, y ATLAS v2026.07 también lo formalizó, añadiendo AML.M0035 El «Red Team» de IA como medida de mitigación.

Tabla 2: Las 29 entradas de técnicas específicas de cada agente en MITRE ATLAS v2026.07, agrupadas por técnica principal. Los identificadores y los nombres se han extraído del recurso de la versión; la columna «práctica» es nuestra explicación en lenguaje sencillo, no el texto descriptivo de ATLAS.

Tabla 3: Las siete medidas de mitigación específicas para cada agente en MITRE ATLAS v2026.07.

La contaminación de la herramienta y el límite de la herramienta

Una definición de herramienta no es una configuración. Se trata de un texto que el modelo lee y sigue, lo que la convierte en una superficie de instrucciones. El «envenenamiento de herramientas» es el ataque que se deriva de ese hecho, y MITRE ATLAS lo registra como AML.0110 Envenenamiento de herramientas de agentes de IA.

Hay que diferenciar tres conceptos, ya que suelen confundirse. El « Prompt injection » es el mecanismo de ejecución. El «memory poisoning» corrompe lo que recuerda el agente, y se trata en profundidad en nuestra guía sobre seguridad de la IA agentiva. El «tool poisoning» corrompe la propia herramienta, y prompt injection suele ser la forma en que se propaga.

Tres puntos en los que una herramienta puede contaminarse

En la versión 2026.07 de ATLAS se añadieron tres subtécnicas bajo AML.0110, y resultan útiles precisamente porque distinguen entre tres problemas defensivos diferentes. La técnica principal es anterior a esta versión y se ha actualizado en ella; las tres técnicas derivadas son nuevas.

‍

Tabla 4: Las tres subtécnicas de «envenenamiento» de herramientas de agentes de IA en MITRE ATLAS v2026.07.

En la columna «Implementación» se recoge un caso documentado. En septiembre de 2025, un paquete de npm muy utilizado que incluía una herramienta de envío de correos electrónicos para agentes fue objeto de un ataque de puerta trasera. Revelación por parte de Koi Security de la puerta trasera «postmark-mcp» describe claramente la situación: «Durante 15 versiones, QUINCE, la herramienta funcionó a la perfección», y luego la versión 1.0.16 añadió discretamente una copia oculta de cada mensaje a la dirección de un atacante. La cifra que se repite con frecuencia de unas 300 organizaciones afectadas no es un dato cuantitativo. Se trata de una estimación de los propios investigadores, que aplican la hipótesis de que «quizá el 20 % se utilice activamente» a una base de referencia de 1 500 descargas por semana. Considérela una hipótesis, porque eso es lo que hicieron sus autores. ATLAS recoge el incidente como caso práctico AML.CS0053.

El MCP como superficie de ataque

El Protocolo de Contexto de Modelos (MCP) es la forma predominante en que las herramientas se ponen a disposición de los agentes, lo que convierte a un servidor MCP en una dependencia de la cadena de suministro que ostenta autoridad sobre la producción. El análisis de Gartner lo expresa en términos similares, señalando que el MCP «se diseñó ante todo pensando en la interoperabilidad, la facilidad de uso y la flexibilidad, por lo que los fallos de seguridad pueden manifestarse sin una supervisión continua de la IA agentiva». La misma previsión estima que, para 2028, el 25 % de las aplicaciones empresariales de IA generativa sufrirán al menos cinco incidentes de seguridad menores al año, frente al 9 % previsto para 2025.

La especificación del Protocolo de Contexto de Modelo(MCP), en su revisión publicada con fecha del 28 de julio de 2026, incluye un requisito normativo que merece la pena citar textualmente: «Los servidores MCP NO DEBEN aceptar ningún token que no haya sido emitido explícitamente para el servidor MCP». Esa frase figura en la sección dedicada a la mitigación del «token passthrough» del documento de buenas prácticas de seguridad de la especificación, que enumera once subsecciones sobre ataques y mitigaciones: Problema del «Confused Deputy», paso de tokens, falsificación de solicitudes del lado del servidor, secuestro de identificadores de estado, compromiso del servidor MCP local, validación de la URL de autorización de OAuth, seguridad del transporte stdio en escenarios de proxy, ataques de confusión, suplantación de la URI de redireccionamiento de localhost, políticas de confianza CIMD y minimización del ámbito.

Vale la pena señalar dos correcciones, ya que ambos errores son habituales. En primer lugar, los términos «tool poisoning», «line jumping», «tool shadowing» y «rug pull» no son conceptos de la especificación MCP. Proceden de OWASP y de investigaciones de la comunidad. Cualquiera que cite «la sección sobre tool poisoning de la especificación del MCP» está describiendo algo que no existe. En segundo lugar, el término «secuestro de sesión» (Session Hijacking) ha sido sustituido por «secuestro de identificador de estado» (State Handle Hijacking): el MCP es ahora un sistema sin estado, sin sesiones a nivel de protocolo, por lo que cualquier contenido que cite el secuestro de sesión del MCP como una sección de la especificación actual se basa en una revisión ya obsoleta.

OWASP ha asignado al «envenenamiento de herramientas» un número de orden propio, MCP03:2025, dentro de la lista OWASP MCP Top 10. En este caso, es importante tener en cuenta el estado del proyecto: se trata de un proyecto de la incubadora de OWASP en la versión v0.1, que actualmente se encuentra en la fase 3, con lanzamiento beta y pruebas piloto. No hay fecha prevista para su lanzamiento definitivo, y la próxima versión está programada para octubre de 2026. No tiene la misma autoridad que el Top 10 de LLM y no debe citarse como si la tuviera.

Las directrices gubernamentales van más allá. La ficha informativa de la NSA sobre ciberseguridad relativa al Protocolo de Contexto Modelo (MCP), un documento de 17 páginas en su versión 1.0, con fecha de mayo de 2026 y publicado exclusivamente por la NSA, establece nueve recomendaciones sobre el MCP. Vale la pena citar textualmente dos de ellas, ya que ambas suelen parafrasearse de forma que pierden fuerza: «Elija proyectos MCP compatibles siempre que sea posible» y «Realice un seguimiento de las vulnerabilidades relacionadas con el MCP y aplique los parches correspondientes».

Hay una condición límite que conviene mencionar una vez y no volver a tocar: una importante consultora especializada recomienda ahora considerar como zona prohibida cualquier caso de uso que combine el acceso de los agentes a datos sensibles, la ingesta de contenido no fiable y la capacidad de comunicarse con el exterior. Esa combinación se trata en nuestro seguridad con IA agente página. Las cadenas de suministro de herramientas también se solapan con el riesgo de dependencia convencional, lo que MITRE ATLAS nombres directamente como AML.0010.005 Supply Chain : Herramienta de agente de IA.

La identidad del agente, el inventario y el problema del registro

La gestión tradicional de identidades y accesos parte de la base de que existe un sujeto con patrones de acceso predecibles, un titular humano y una sesión sobre la que se puede razonar. Un agente rompe estas tres premisas. Su patrón de acceso es no determinista, ya que el modelo decide qué funciones se deben invocar. Su autoridad proviene de una cadena de delegación, en lugar de un inicio de sesión. Y, estructuralmente, es un «delegado confuso», ya que posee más autoridad que quien le pide que actúe. Este último punto no es una mera reflexión teórica: el problema del «delegado confuso» es el primer ataque mencionado en el propio documento de seguridad de la especificación MCP.

Por lo tanto, el primer control no es un control en absoluto. Se trata de un inventario. Tres páginas independientes de este mercado afirman que la detección de agentes es importante, pero ninguna de ellas explica el método. El método consiste en un registro que se compara con el comportamiento observado. Cualquier elemento que utilice herramientas que no figuren en el registro se considera un agente oculto, y esa comparación es la única forma fiable de medir la proliferación de agentes.

Tabla 5: Campos que debe incluir un registro del registro de agentes y las consecuencias de omitir cada uno de ellos.

En cuanto al vocabulario, hay dos términos que describen el mismo concepto subyacente. Tanto «identidad de máquina » como «identidad no humana» (NHI) se refieren a un sujeto con credenciales y permisos que no es una persona, lo que abarca cuentas de servicio, claves de API, cargas de trabajo y, ahora, agentes. Una advertencia sincera: la diferencia entre estos términos puede ser una auténtica laguna en el lenguaje del mercado, o puede que el mercado simplemente se haya decantado por «identidad no humana». Los datos disponibles no permiten distinguir entre ambas posibilidades. En los casos en que la identidad de agente se solapa con la detección del uso indebido de cualquier entidad no humana, ese ámbito pertenece a la detección y respuesta ante amenazas de identidad.

La capa de estándares portátiles es el punto débil, y conviene ser franco al respecto. SPIFFE y SPIRE, los proyectos de la CNCF para la emisión de identidades criptográficas de cargas de trabajo, se han graduado desde el 20 de septiembre de 2022, por lo que cualquiera que los describa como «emergentes» está desactualizado desde hace cuatro años. Por encima de esa capa, el panorama es más escaso de lo que sugiere el volumen de actividad. Hay 165 borradores activos de la IETF sobre la identidad o la autorización de agentes de IA. Los 165 son propuestas individuales. Ninguna ha sido adoptada por un grupo de trabajo. La capa de estándares de identidad de agentes es una explosión de propuestas, no una capa de estándares . Vale la pena mencionar dos contraejemplos: el «OAuth Client ID Metadata Document» es un auténtico documento de grupo de trabajo al que la especificación MCP hace referencia directamente, y el grupo de trabajo OpenID AuthZEN cuenta con un borrador de autorización vinculante para MCP, cuyo «AuthZEN Access Request and Approval Profile» alcanzó el estado de Borrador 1 el 20 de agosto de 2026. Mientras tanto, el grupo de trabajo WIMSE ha elaborado seis documentos activos y ningún RFC en los aproximadamente 33 meses que lleva en funcionamiento, y el RFC 8693 sigue siendo un «estándar propuesto» sin actualizaciones ni elementos obsoletos en ninguna de sus 120 filas de relación, lo que significa que nada lo ha sustituido en materia de delegación de agentes. Las fuentes de lo anterior se encuentran en el datatracker de la IETF.

En la práctica: todavía no es posible adquirir una identidad de agente portátil, por lo que el ámbito de actuación, el patrocinador y la fecha de caducidad son los controles de los que realmente dispones. Las directrices del NCSC sobre la adopción de la IA agentiva llegan a una conclusión similar desde el punto de vista de la gobernanza. Los principios de «Zero trust » se aplican perfectamente a los agentes, con un único ajuste: el principal, cuya identidad se verifica continuamente, no es una persona, por lo que la señal de verificación debe provenir del comportamiento y no de un evento de inicio de sesión.

Lo que revelan los incidentes documentados relacionados con agentes de IA

Los incidentes que se han producido son más útiles que las previsiones, ya que cada uno de ellos muestra dónde falló realmente el sistema.

Tabla 6: Incidentes de seguridad documentados relacionados con agentes de IA, con sus fuentes principales y los identificadores de los estudios de caso de ATLAS, cuando existan.

Desarrollador de Amazon Q. Una contribución maliciosa llegó a la extensión publicada. El boletín de seguridad de AWS AWS-2025-015 describe el resultado con exactitud: «El equipo de seguridad de AWS ha inspeccionado el código y ha determinado que el código malicioso se distribuyó junto con la extensión, pero no se ejecutó debido a un error de sintaxis». La instrucción destructiva estaba completamente formada. Un error tipográfico fue lo que la detuvo. En CVE-2025-8217, ambas puntuaciones, CVSS v4.0 5,1 MEDIUM y v3.1 4,0 MEDIUM, son secundarias y fueron asignadas por AWS como CNA. El NVD no publicó ninguna puntuación primaria propia y el estado del registro es «Aplazado».

postmark-mcp. Ya se ha tratado anteriormente, y también encaja aquí, porque una herramienta de agente envenenado es una dependencia que hereda la autoridad de producción del agente. Se aplica el razonamiento que rige cualquier ataque a la cadena de suministro, con un camino mucho más corto hasta las consecuencias.

Acción de GitHub «Claude Code». Una única herramienta que no se ejecutaba en un entorno aislado constituía toda la vía de ataque, a la que se podía acceder desde una incidencia normal de GitHub. Informe técnico de GMO Flatt Security registra una puntuación CVSS v4.0 de 7,8 asignada por el proveedor, una recompensa de 4.800 dólares y la corrección de la vulnerabilidad de elusión del núcleo en claude-código-acción v1.0.94. El aislamiento parcial de un agente supone una elusión total.

La intrusión impulsada por agentes de julio de 2026. Un proveedor de plataformas de IA reveló que un marco de agentes autónomos llevó a cabo una intrusión de extremo a extremo en sus sistemas internos. Su cronología técnica constituye el registro forense: «Nuestra reconstrucción forense abarca unas 17 600 acciones del atacante que pudimos recuperar, agrupadas en unos 6 280 clústeres, entre las 02:28 UTC del 9 de julio de 2026 y las 14:14 UTC del 13 de julio de 2026». Esos aproximadamente 6 280 son clústeres de actividad, no clústeres de cálculo, y el intervalo de tiempo es de unos cuatro días y medio. El mismo documento señala que «el agente leyó los objetos secretos del clúster, incluido un objeto de producción que contenía 136 claves». La comunicación del incidente por parte del proveedor describe «un acceso no autorizado a un conjunto limitado de conjuntos de datos internos y a varias credenciales» y afirma que aún se estaba llevando a cabo la evaluación del impacto en socios y clientes. No nombra a la otra parte, y tampoco debería hacerlo ningún resumen del mismo.

El detalle sobre la detección es lo que hay que destacar. Las señales sí se activaron. Según las propias palabras del proveedor, «fueron correlacionadas por nuestro conjunto de agentes de seguridad basados en IA y se interpretaron como una señal de ataque coherente. Sin embargo, no se logró elevar correctamente el nivel de gravedad de la alerta ni activar al equipo de guardia, lo que supuso una pérdida de tiempo valioso en la respuesta».

EchoLeak. Acceso a datos privados, ingesta de contenido no fiable y un canal de salida, observados en entorno de producción en Microsoft 365 Copilot. Hay que tener en cuenta ambas puntuaciones con objetividad: CVE-2025-32711 ha recibido una puntuación CVSS de 9,3 (CRÍTICA) por parte de Microsoft, en su calidad de CNA, mientras que el análisis independiente del NIST realizado por el NVD le otorga una puntuación de 7,5 (ALTA), con CWE-74. La cifra de 9,8 que circula en algunos medios no tiene fundamento en ninguna de las dos fuentes. EchoLeak y los incidentes relacionados con agentes se tratan en nuestra página sobre seguridad de la IA basada en agentes.

Los incidentes de evaluación cibernética. Un proveedor de modelos reveló que «tras revisar 141.006 ejecuciones de evaluación en las que Claude podría haber obtenido acceso a Internet», identificó tres incidentes en los que sus modelos llegaron a organizaciones de terceros durante las pruebas de seguridad. Desde entonces, se ha contactado con dos de las tres organizaciones. Tres de 141.006 no constituye una tasa base y nunca debe expresarse como porcentaje: la divulgación describe una investigación, no una medición de la incidencia. Su propia formulación de la causa raíz es la exposición más clara de la tesis de esta página: «Creemos que estos incidentes se acercan más a un fallo del sistema de pruebas y operativo que a un fallo de alineación del modelo».

Dos CVE de 2026 en productos de agentes de envío completan el panorama. El CVE-2026-62830 en Azure SRE Agent tiene una puntuación CVSS v3.1 de 9,9 (CRÍTICO) con CWE-862, y el CVE-2026-59118 en Copilot Cowork tiene una puntuación de 9,3 (CRÍTICO) con CWE-285. Ambas se publicaron el 6 de agosto de 2026, y ambas puntuaciones han sido asignadas por la CNA sin un análisis independiente del NVD. Este patrón es la norma en los productos de agentes de IA, más que la excepción, por lo que cualquier tabla de CVE sobre este tema debe indicar de quién es la puntuación que muestra. Ninguna de ellas aparece en el catálogo de vulnerabilidades explotadas de la CISA, por lo que ninguna debería describirse como explotada.

El denominador común es que ninguno de estos casos se debe a que un modelo sea erróneo. Casi todos se deben a un « prompt injection » indirecto que llega a una herramienta, o a un permiso más amplio de lo que requiere la tarea. El caso de julio de 2026 es una excepción instructiva, ya que en él el agente era el atacante y no la víctima. Nuestra propia investigación sobre las comunidades de agentes de IA y la ilusión de inofensividad llega a la misma conclusión desde la perspectiva de la interacción entre agentes.

Detección y contención de un agente de IA comprometido

Empieza con una afirmación sincera, ya que es la que establece los requisitos. Hay dos modos de fallo documentados, y se trata de problemas distintos.

Lo primero es el silencio. En el caso de ZombieAgent, ningún control tradicional detectó la exfiltración. Ni las pasarelas web seguras, ni las herramientas para terminales, ni los cortafuegos, y ninguna alerta llegó al usuario. El registro del «OECD AI Incidents and Hazards Monitor» es la entrada neutral correspondiente a este caso. Los investigadores lo describen como un « prompt injection » indirecto de «cero clics», que es su propia definición y merece la pena citarla tal cual, ya que el usuario aún tiene que interactuar con el asistente de forma normal para que se active la carga útil.

La segunda es una clasificación errónea del ruido. En la intrusión de julio de 2026, las señales se emitieron desde varias capas a la vez y se correlacionaron para formar una señal de ataque coherente. A continuación, el sistema no elevó el nivel de gravedad de la alerta. Tanto el silencio como una clasificación errónea de la gravedad conducen al mismo resultado, y ninguno de los dos se soluciona con un modelo mejor.

Hay cinco señales de tiempo de ejecución en torno a las cuales merece la pena desarrollar sistemas de detección:

1. Anomalías en el cumplimiento de instrucciones: acciones sin relación plausible con la tarea.
2. Secuencias de llamada a herramientas que alteran la topología prevista del flujo de trabajo.
3. Exfiltración a través de canales de bajo ancho de banda de los que el agente dispone legítimamente.
4. Acceso a credenciales y claves secretas fuera del ámbito de la tarea actual.
5. Anomalías en la escritura en memoria que hacen que algunas instrucciones permanezcan inactivas de una sesión a otra.

Señal. Cómo se ve en la telemetría. Técnica ATLAS. Restricción de mitigación. Anomalía en el seguimiento de instrucciones. Llamadas a herramientas sin tarea principal ni solicitud del usuario.AML.T0080AML.M0030Llamada a la herramienta «topology break»: una secuencia de llamadas que cruza un límite del flujo de trabajoAML.T0053AML.M0028Exfiltración con bajo ancho de banda: pequeñas operaciones de escritura salientes y repetidas a través de una herramienta autorizadaAML.T0086AML.M0033Acceso a credenciales fuera del ámbito de aplicación: se leen datos secretos no relacionados con la tarea en ejecuciónAML.T0098AML.M0026Anomalía en la escritura en memoria: escrituras en la memoria persistente fuera del turno del usuarioAML.T0080.000AML.M0029

Tabla 7: Cinco señales de detección en tiempo de ejecución de un agente de IA comprometido, asignadas a la técnica de ATLAS que cada una de ellas observa y a la medida de mitigación que la limita.

Céntrate en las medidas de mitigación en lugar de en las capacidades del producto, ya que las medidas de mitigación seguirán siendo válidas dentro de un año. AML.M0033 Validación de entradas y salidas para los componentes de los agentes de IA y AML.M0030 «Restringir la invocación de la herramienta de agentes de IA con datos no fiables» son las dos opciones que generan la telemetría más relevante para la detección. Y ten en cuenta que la intervención humana no es una recomendación opcional en este caso: es AML.M0029 «Intervención humana en el bucle de las acciones de los agentes de IA», una medida de mitigación específica, a la que se hace referencia en una sección dedicada en La guía rápida de seguridad de los agentes de IA de OWASP y una subsección sobre la intervención humana en la guía conjunta del Gobierno.

En cuanto a la medición, un laboratorio de investigación ha propuesto el único conjunto de métricas nativas de los agentes que se ha publicado hasta la fecha, y ningún proveedor lo ha adoptado: «cobertura (la fracción de tráfico supervisada), recuperación (la fracción de comportamientos anómalos detectados) y tiempo de respuesta». El mismo trabajo aboga por tratar a los agentes de IA no fiables como potenciales «amenazas internas», lo cual es la postura correcta. La adopción de estas tres métricas proporciona información que ir más allá del mero recuento de alertas. La observabilidad genuina del tiempo de ejecución de los agentes —es decir, que las invocaciones de herramientas se registren como eventos de primer orden en lugar de como indicaciones registradas como texto— es el requisito previo, y va de la mano de la práctica más amplia de la observabilidad de la seguridad.

El argumento más sólido a favor de la detección en tiempo de ejecución son los datos sobre exploits. A fecha de la versión 2026.08.24 del catálogo, publicada el 24 de agosto de 2026, el catálogo de vulnerabilidades explotadas de la CISA contaba con 1.675 entradas, de las cuales 11 están relacionadas con la pila de IA y agentes: seis entradas de Langflow, dos de LiteLLM y una de MLflow, n8n y Ray, respectivamente. El hecho de que seis de las once entradas se concentren en una única plataforma de flujo de trabajo de agentes es, en sí mismo, digno de mención. Aún más revelador es el intervalo de tiempo. La entrada de Ray, CVE-2025-62593, se publicó en el NVD el 26 de noviembre de 2025 y se añadió al catálogo el 17 de agosto de 2026, lo que supone un intervalo de 264 días. Por el contrario, el CVE-2026-64849 de MLflow se publicó el 17 de agosto de 2026, se añadió el 19 de agosto de 2026 y tiene como fecha límite de corrección el 2 de septiembre de 2026, lo que supone un desfase de dos días. Si una vulnerabilidad de la que se sabe que está siendo explotada en tu pila de agentes puede permanecer sin detectarse durante nueve meses antes de que alguien te avise de ello, la periodicidad de los parches no puede ser el único control. Algo tiene que supervisar el comportamiento durante ese intervalo.

Volume transmite el mismo mensaje desde el otro extremo. El propio seguimiento de OWASP, basado en una instantánea de abril de 2026 de los repositorios de GitHub supervisados, registra un recuento de avisos de 57 para n8n, 22 para Claude Code, 15 para AutoGPT, 13 para Dify y 11 para Roo-Code. Se trata de recuentos por repositorio supervisado, no de un censo de proyectos de agentes. Las pruebas adversarias de tus propios agentes forman parte del «red teaming» de IA, y la mitad del problema relacionada con la capa del modelo recae en la seguridad de la IA generativa.

Marcos normativos, directrices gubernamentales y normativa

En estos momentos se están elaborando catálogos de control específicos para cada agente, lo que hace que la correcta datación de cada referencia del marco sea un indicador visible de calidad, más que una simple minuciosidad.

Tabla 8: Cuadro comparativo de marcos normativos y reglamentarios en materia de seguridad de los agentes de IA, con la edición y la fecha de cada instrumento.

La guía conjunta sobre la adopción prudente de servicios de IA con capacidad de acción constituye la guía de control específica para agentes más exhaustiva publicada hasta la fecha. Sus 29 páginas organizan el problema en cinco categorías de riesgo, y conviene utilizar la propia terminología de la guía en lugar de la paráfrasis que circula en los medios: riesgos relacionados con los privilegios (página 7), riesgos de diseño y configuración (página 9), riesgos de comportamiento (página 9), riesgos estructurales (página 11) y riesgos de rendición de cuentas (página 12). Su contenido sobre buenas prácticas se organiza en un ciclo de vida de cuatro fases que abarca el diseño, el desarrollo, la implementación y el funcionamiento de agentes seguros. Seis organismos de cinco países han colaborado en su elaboración: el ACSC de la Dirección Australiana de Señales, la CISA, la NSA, el Centro Canadiense de Ciberseguridad, el NCSC-NZ y el NCSC-UK.

En lo que respecta a la normativa, las fechas han cambiado y gran parte de las orientaciones publicadas aún no se han actualizado. El Reglamento (UE) 2026/1744 se adoptó el 8 de julio de 2026, se publicó en el Diario Oficial el 24 de julio de 2026 y entró en vigor el 27 de julio de 2026. Se aplicarán las obligaciones de alto riesgo del anexo III, de forma independiente, a partir del 2 de diciembre de 2027, y las obligaciones de alto riesgo del anexo I, integradas, a partir del 2 de agosto de 2028. Solo las obligaciones de transparencia del artículo 50 se aplicaron a partir del 2 de agosto de 2026. Un agente empresarial que tome decisiones o influya de manera significativa en ellas en un ámbito del anexo III se considera un sistema de IA de alto riesgo, por lo que diciembre de 2027 es el horizonte de planificación operativo, mientras que la obligación de divulgación del artículo 50 ya se aplica hoy en día a los agentes que interactúan con los clientes.

Lo que se avecina merece la atención, pero sin exagerar. Las medidas de control del NIST para la seguridad de los sistemas de IA incluyen dos casos de uso de agentes con nombre propio: «Uso de sistemas de agentes de IA (agentes de IA) – Agente único» y «Uso de sistemas de agentes de IA (agentes de IA) – Agentes múltiples». Ambos están previstos y ninguno se ha redactado aún: solo existen un documento conceptual y un esquema comentado para el caso de uso de la IA predictiva. Por otra parte, la Iniciativa de Normas para Agentes de IA del NIST, anunciada el 17 de febrero de 2026, establece tres pilares que incluyen la investigación sobre la seguridad y la identidad de los agentes.

Dos notas sobre las fuentes corrigen errores reales en este caso. La lista LLM de 2026 es la primera edición ponderada por datos de incidentes, y en su prefacio se recoge un corpus de 7.714 incidentes reales, de los cuales 6.639 contienen suficientes detalles para su clasificación, con el voto de la comunidad representando tres cuartas partes de la ponderación y los datos de incidentes, la cuarta parte restante. Consulta esas cifras y los números ordinales en el repositorio de origen, en lugar de en una página de destino. Del mismo modo, consulta la versión que figura en la portada del PDF de «OWASP Agentic AI Threats and Mitigations v1.1», en lugar de la fecha que aparece en su página, y ten en cuenta que la «CSA AI Controls Matrix v1.1» incluye 247 objetivos de control, mientras que la URL sin sufijo sigue remitiendo a la versión anterior, con 243. El complemento a todo esto en la capa de aplicación es la seguridad de GenAI, y la capa de arquitectura agentica se trata en el OWASP Top 10 para aplicaciones agenticas.

Enfoques modernos sobre la seguridad de los agentes de IA

Las herramientas para la seguridad de los agentes de IA empresariales están apareciendo rápidamente y, en la actualidad, se clasifican en seis categorías en lugar de una sola.

• Detección e inventario de agentes. Localización de agentes que nadie ha registrado y su cotejo con un registro.
• Evaluación de riesgos por agente. Calificación de un agente en función del alcance de sus herramientas y credenciales, en lugar de por su modelo.
• Control de acceso a herramientas y al MCP. Regulación de las herramientas que un agente puede utilizar y en qué condiciones.
• Control de las acciones de los agentes. Aprobar, restringir o bloquear una acción concreta en tiempo de ejecución.
• Detección del comportamiento en tiempo de ejecución. Observar lo que hace realmente el agente y alertar ante cualquier desviación.
• Controles de identidad y delegación para sujetos no humanos. Credenciales con ámbito de aplicación, cadenas de delegación y revocación.

Hay cuatro preguntas que distinguen las soluciones de seguridad para agentes de IA que resultarán eficaces de las que no lo serán. ¿Enumera los agentes que no has registrado o solo hace un inventario de los que le has indicado? ¿Detecta las invocaciones de herramientas o solo las solicitudes de comandos? ¿Asigna los hallazgos a una taxonomía pública de técnicas que puedas auditar? ¿Y es capaz de restringir una sola herramienta sin desactivar el agente, lo cual marca la diferencia entre un control y un interruptor de apagado?

La evolución del mercado está bastante clara. La identidad de los agentes se está integrando en las categorías existentes de seguridad de la identidad, en lugar de convertirse en una categoría independiente, y los catálogos de control se están elaborando en estos momentos, en lugar de estar ya consolidados. Cabe señalar también que varios proveedores destacados en este ámbito cambiaron de manos entre diciembre de 2025 y junio de 2026, por lo que conviene comprobar su independencia en lugar de darla por sentada. Los modelos de implementación basados en agentes y sin agentes son una cuestión totalmente distinta, que se aborda en el ámbito de las soluciones de ciberseguridad.

La visión de « Vectra AI » sobre la seguridad de los agentes de IA

Un agente de IA es un nuevo tipo de identidad que opera en la misma red que el resto de elementos, por lo que se le aplica la misma cuestión de «suponer que está comprometido». Si las credenciales de un agente se utilizan para hacer algo que ese agente nunca debió hacer, ¿hay algo en tu entorno que lo detecte? La postura de Vectra AI es que el comportamiento del agente debe observarse allí donde actúa, a través de la red, la identidad y cloud, en lugar de inferirse a partir de la orden que lo puso en marcha. Ese es el mismo enfoque de Attack Signal Intelligence™ que aplicamos a cualquier entidad comprometida: observar lo que hace, no lo que dice ser. El panorama general de la seguridad de la IA establece el contexto para esa postura.

Conclusión

La cuestión que distingue la seguridad de los agentes de IA de la seguridad de la IA en general no es «¿es seguro el modelo?», sino «¿qué se le permite hacer a este agente y se daría cuenta alguien si hiciera algo diferente?». Todos los incidentes documentados hasta la fecha responden mal a la primera parte y aún peor a la segunda. El trabajo al que se enfrentan la mayoría de los equipos de seguridad es poco glamuroso y secuencial: enumerar los agentes, designar un responsable para cada uno, centrarse en las herramientas en lugar de en el modelo, e incorporar las invocaciones de las herramientas a la telemetría, donde puedan ser detectadas. MITRE ATLAS v2026.07 ofrece 29 identificadores de técnicas y siete medidas de mitigación para enmarcar ese trabajo en una taxonomía pública.

Si estás analizando cuestiones relacionadas con la arquitectura, el ciclo de vida y la gobernanza, nuestra guía sobre seguridad de la IA agentiva continúa donde termina esta página.

‍