TL; DR
El término "amenazas a la seguridad de la IA" abarca dos cosas diferentes: ataques dirigidos a sistemas de IA y ataques que utilizan la IA como arma. Necesitan controles, propietarios y evidencias diferentes, y la mayoría de las listas los mezclan, por lo que resulta muy difícil actuar en consecuencia. Los primeros cinco elementos que aparecen a continuación se dirigen a tu IA. Los cinco siguientes utilizan la IA contra tu cadena de suministro.
- Las amenazas a los sistemas de IA residen principalmente en la configuración, no en el modelo. Ámbito de la herramienta, la credencial con la que se ejecuta un agente, un archivo de reglas, un
.mcp/servers.jsonentrada. No se puede acceder a nada desde el punto final del modelo, por lo que las pruebas de red teaming por sí solas no dan resultado. - Los ataques impulsados por IA llegan principalmente a través de dependencias, no a través de su perímetro de seguridad. Nombres de paquetes ficticios registrados por atacantes, gusanos que se autopropagan utilizando credenciales de desarrollador y claves de proveedores de IA como objetivo.
- Nueve de las diez preguntas se refieren a temas específicos. ¿Qué servidores MCP, qué agentes, qué ámbito, qué credenciales, qué archivo de reglas, qué paquete? Un documento de política no responde a ninguna de estas preguntas.
- Cada uno de los diez comparte una condición previa. No se puede defender un activo de IA que nunca se ha mapeado, lo que convierte el descubrimiento en el paso previo a los controles, en lugar del posterior.
¿Cuáles son los dos tipos de amenazas a la seguridad de la IA?
La mayoría de las listas de amenazas a la seguridad de la IA mezclan ambos tipos de amenazas, por lo que resulta difícil tomar medidas al respecto.
- Amenazas a los sistemas de IA Trata tu IA como si fuera el objetivo. Alguien manipula un modelo, altera las instrucciones que sigue o abusa de los permisos otorgados a un agente. La tarea del defensor es la contención: reducir el alcance de una IA comprometida.
- Ataques impulsados por IA Considera la IA como la herramienta del atacante. El objetivo es tu software habitual: dependencias, credenciales, sistemas de compilación, desarrolladores. La tarea del defensor es la detección rápida, porque la economía del ataque ha cambiado y el volumen ha aumentado.
Necesitan controles, propietarios y evidencias diferentes. Un equipo que ha sometido a su chatbot a pruebas de penetración no ha hecho nada respecto al slopsquatting. Un equipo con una excelente verificación de dependencias puede seguir ejecutando un agente con acceso de escritura a los repositorios de producción y sin límite de alcance. Ambas son amenazas a la seguridad de la IA. Ninguna cubre a la otra.
Amenazas para los sistemas de IA: las cinco que se presentan con mayor frecuencia
01. Inyección inmediata que llega a un sumidero de herramientas
Llega contenido no confiable, se concatena en un mensaje del sistema y el agente en el otro extremo puede invocar herramientas. El mensaje no es la vulnerabilidad. El problema radica en el camino que va desde la entrada no confiable hasta una funcionalidad peligrosa.
Por eso, el filtrado instantáneo por sí solo resulta decepcionante. Refuerza un extremo de la cadena, mientras que la pregunta interesante es si existe algún tipo de barrera entre la entrada y la llamada a la herramienta. Los 10 mejores candidatos para el Máster en Derecho de OWASP Mantiene la inyección inmediata en lo más alto de la lista, pero la combina con una agencia excesiva precisamente por esta razón.
Qué buscar: Entrada no confiable que llega a una solicitud del sistema, recuperación que alimenta el contexto sin saneamiento y sumideros de herramientas accesibles sin ninguna protección intermedia.
02. Reglas maliciosas y archivos de habilidades
Un archivo de reglas es texto plano. Es committed como documentación y revisado como documentación, e instruye al asistente sobre qué hacer. Los caracteres de ancho cero hacen que las líneas sean invisibles en un pull request diff sin dejar de ser perfectamente legible para el agente.
ATLAS DE MITRE Se cataloga como puerta trasera de archivo de reglas, caso de éxito AML.CS0041. El revisor aprueba una convención de formato. El agente lee una instrucción para importar desde un paquete controlado por el atacante y no decir nada al respecto.
Qué buscar: Los archivos de reglas, los archivos de habilidades y las plantillas de indicaciones se analizan como código en lugar de prosa, con detección de caracteres invisibles.
03. Configuración insegura del servidor MCP
Configuración de MCP Es donde un agente recibe órdenes y donde se acumulan las credenciales. Ambas partes representan un problema. La vulnerabilidad CVE-2025-6514, revelada en julio de 2025, era una inyección crítica de comandos del sistema operativo en un puente MCP ampliamente utilizado, con una puntuación CVSS de 9.6, que permitía la ejecución de comandos arbitrarios en el host cliente al conectarse a un servidor no confiable.
La parte de las credenciales es peor porque es pasiva. Una investigación realizada en 2026 encontró más de 24,000 Secretos en archivos de configuración de MCP en GitHub público, de los cuales más de 2,000 seguían siendo válidos.
Qué buscar: un inventario de los servidores MCP en uso, sus versiones, las herramientas declaradas y la detección de Secretos que se ejecuta sobre los archivos de configuración.
04. Agencia excesiva
Un agente con amplios permisos y credenciales de larga duración representa una escalada de privilegios constante a la espera de un desencadenante. No es necesario explotar ninguna vulnerabilidad para que esto cause daños. Un agente confundido y uno comprometido pueden provocar daños similares cuando ambos tienen acceso de escritura que nunca necesitaron.
Este es el elemento menos atractivo de la lista y el más común. Además, tiene la solución más económica, que es la reducción del alcance, y rara vez se aplica porque nadie es el responsable de la pregunta.
Qué buscar: qué agentes existen, qué puede invocar cada uno, bajo qué credenciales y si alguien aprobó ese alcance.
05. Modelos, conjuntos de datos y dependencias de IA contaminados
La pila de IA se basa en paquetes comunes y artefactos alojados. Los modelos se descargan de repositorios públicos. Los conjuntos de datos se obtienen de cualquier fuente. Ambos presentan el mismo problema de procedencia que cualquier dependencia, con menos herramientas y un control mucho menor.
Qué buscar: modelos, marcos y conjuntos de datos tratados como componentes de la cadena de suministro, con el mismo análisis de composición y el mismo Realiza el seguimiento de CVE como con el resto de tus dependencias.
Ataques impulsados por IA: los cinco que están transformando su cadena de suministro
06. Slopsquatting
Una investigación presentada en USENIX Security en 2025 generó 2.23 millones de muestras de código en 16 modelos y descubrió que el 19.7 % de los paquetes recomendados no existían, produciendo más de 205 000 nombres ficticios únicos. Alrededor del 43 % de esos nombres se repetían en ejecuciones sucesivas del mismo mensaje, lo que permite su explotación.
Los atacantes ya no necesitan comprometer la seguridad de un responsable del mantenimiento. Registran el nombre que inventó tu agente y esperan a que se complete la instalación. El paquete no tiene firma ni aviso, porque es nuevo y nadie lo ha visto antes.
Qué buscar: Un sistema de detección de malware que se basa en el comportamiento en lugar de la reputación, aplicado a cada dependencia que agrega un agente.
07. Gusanos de la cadena de suministro que se autopropagan
El Gusano npm de septiembre de 2025 Se marcó el punto en el que las máquinas de los desarrolladores se convirtieron en el mecanismo de distribución en lugar del objetivo. Este patrón se repitió a gran escala hasta 2026. Cada credencial de desarrollador comprometida publica la siguiente ronda de paquetes comprometidos, y el radio de explosión se acumula en lugar de sumarse.
Qué buscar: actividad editorial anómala, inusual commit patrones y uso de credenciales que no coinciden con el comportamiento normal del desarrollador.
08. Ataque de los estados nación a las credenciales de IA
En marzo de 2026, un paquete con aproximadamente 100 millones de descargas semanales fue comprometido durante un período de horas, con el objetivo de obtener las claves API de un proveedor de IA. El lapso fue deliberadamente corto: lo suficientemente largo para extraer información, pero lo suficientemente corto para reducir la probabilidad de detección.
Las credenciales de IA se han convertido en un objetivo prioritario por derecho propio, ya que otorgan capacidad de procesamiento, acceso y una identidad verosímil. Los ataques dirigidos a robarlas aumentaron drásticamente entre finales de 2025 y principios de 2026.
Qué buscar: Las claves de los proveedores de IA se tratan como Secretos, con los mismos procedimientos de detección y revocación que las credenciales en la nube.
09. Malware creado o implantado mediante un LLM
Para 2026, se documentaron casos en los que se utilizó un modelo de lenguaje para insertar código malicioso en el flujo de trabajo de un agente. La importancia radica no en que el malware fuera novedoso, sino en que la autoría dejó de ser un obstáculo, y, en consecuencia, aumentó la cantidad de código malicioso de apariencia plausible disponible para un atacante.
Qué buscar: detección Eso no depende de haber visto la muestra con anterioridad.
10. Revisión del colapso de capacidad
Esto no es un ataque, por eso está al final y es lo más importante. Cuando un agente genera mil archivos en una semana, la revisión de código deja de ser un control y se convierte en una cola. Todas las demás amenazas de esta lista se vuelven más fáciles cuando la última revisión humana se ve desbordada.
Qué buscar: Los hallazgos se clasifican según su vulnerabilidad a la explotación, en lugar de por su gravedad bruta, de modo que el pequeño número de casos que amenazan la producción llegan realmente a un desarrollador.
Diez amenazas es el mapa. Qué hacer con cada una lleva más tiempo que una entrada de blog, así que tuvimos la conversación adecuada. En este episodio de Charlas de SafeDevJesús Cuadrado, CEO de Xygeni, se sienta con Atanas Nikolov, experto en DevSecOps y SSDLC Líder técnico en malware polimórfico, inyección instantánea, manipulación de modelos y qué métodos resisten realmente estas tácticas. Sin formulario, sin puerta de enlace.
¿Por qué no puedes defender los activos de IA que no has mapeado?
Vuelve a leer las diez preguntas y verás que el patrón es inconfundible. Nueve de ellas tratan sobre aspectos específicos: qué servidores MCP, qué agentes, qué ámbito, qué credencial, qué archivo de reglas, qué paquete.
Ninguna de esas preguntas puede responderse con un documento de política. Se responden con un inventario, y la mayoría de las organizaciones no tienen uno. La IA llegó gracias a la rapidez de los desarrolladores, sin un ticket, un proceso de adquisición ni una entrada en un repositorio que la identificara como IA.
Esto convierte el mapeo en una condición previa, no en el primer paso. Un programa de seguridad de IA que comience con controles los aplicará a la IA que conoce, un subconjunto que no puede dimensionar. El descubrimiento debe ser prioritario: modelos, marcos de trabajo, conjuntos de datos, puntos finales de inferencia, agentes, servidores MCP, habilidades, indicaciones y las herramientas de codificación de IA que utilizan sus desarrolladores, junto con las relaciones entre ellos, ya que un activo aislado aporta muy poca información y el riesgo se concentra en la cadena.
El Marco de gestión de riesgos de IA del NIST Por la misma razón, coloca map antes que measure y manage. Es la función menos interesante del framework y de la que depende todo lo demás.
¿Ante qué amenazas a la seguridad de la IA debería actuar primero?
No es lo más sofisticado. Es lo más accesible.
- Esta semana: Cuenta tus servidores MCP y ejecuta la detección de Secretos en sus archivos de configuración. La amenaza 03 tiene la mayor relación exposición/esfuerzo de la lista, y casi nadie la ha analizado.
- Este mes: Localiza a tus agentes y anota qué acciones puede realizar cada uno y con qué credenciales. Esto aborda la amenaza 04, que es la más común y la más económica de mitigar.
- Este trimestre: Implementar un análisis de malware basado en el comportamiento antes de cada dependencia que agregue un agente. Esto abarca las amenazas 06, 07 y 09 simultáneamente, ya que las tres eluden las comprobaciones basadas en la reputación al ser nuevas.
Todo lo demás puede esperar después de esos tres, porque todo lo demás presupone que ya sabes lo que tienes.
Las organizaciones que mejor gestionen las amenazas a la seguridad de la IA en 2027 no serán las que tengan las mejores evaluaciones de modelos. Serán las que puedan responder, cualquier martes, qué IA se ejecuta en su software y hasta dónde se le permite llegar. Esa es la posición. xygeni se construyó en torno a: descubrimiento continuo de cada activo de IA en todos los repositorios y pipelines, riesgo evaluado según los marcos que sus auditores ya reconocen, y el control de la cadena de suministro que detecta lo que aún no tiene firma.
Diez amenazas, dos categorías, un mapa que las describe a ambas.
Preguntas Frecuentes
¿Son realmente diferentes las amenazas a la seguridad de la IA de las amenazas a la seguridad de las aplicaciones comunes?
En parte. Las consecuencias son conocidas: ejecución de código, robo de credenciales, exposición de datos. Lo que cambia es el punto de entrada y la velocidad. Los archivos de configuración que antes eran inertes ahora contienen instrucciones que activan algún proceso, y el costo para un atacante de producir código malicioso convincente ha disminuido. Sus controles actuales siguen siendo válidos; simplemente ya no cubren toda la superficie.
¿Las pruebas de estrés (red teaming) que realizamos con nuestros modelos solucionan la mayoría de estas amenazas?
Aborda parcialmente una de ellas. El análisis de red teaming determina si se puede persuadir a un modelo para que acepte algo que debería rechazar, lo cual resulta realmente útil. No puede ver el alcance de la herramienta, la credencial, el archivo de reglas ni la configuración de MCP, ya que ninguno de ellos es accesible a través del punto final del modelo. Un informe de red teaming impecable y un agente con privilegios excesivos coexisten sin contradicción.
¿Cuál de estas amenazas a la seguridad de la IA es la más subestimada?
Existe una agencia excesiva, por un amplio margen. No tiene CVE, ni exploit que demostrar, ni proveedor que venda un producto específico para ello, por lo que no genera urgencia. Además, marca la diferencia entre un incidente contenido y uno no contenido, ya que el alcance determina hasta dónde se propaga cualquier cosa tras el primer error.
¿Cómo cambian los ataques impulsados por IA lo que debemos medir?
Cambian la métrica útil de la gravedad al tiempo. Cuando se generan paquetes maliciosos más rápido de lo que se publican las firmas, la cantidad de vulnerabilidades críticas abiertas importa menos que la rapidez con la que se detecta una nueva amenaza. Mide el tiempo transcurrido entre la entrada de una dependencia en tu código y su análisis, y el tiempo transcurrido entre la detección de una vulnerabilidad y su llegada a un desarrollador que pueda tomar medidas al respecto.
