Cadena de suministro en aplicaciones con IA: modelos, dependencias y MCP

Qué forma la cadena de suministro de una aplicación con IA

Una aplicación con IA hereda los riesgos de cualquier software y añade piezas nuevas. OWASP los recoge en Supply Chain, la LLM04 en la edición de 2026 del OWASP Top 10 for LLM Applications y la LLM03 en la de 2025. Cada componente de terceros se ejecuta con los privilegios de la aplicación o influye en lo que responde el modelo, así que comprometer uno equivale a comprometer el sistema. Estas son las piezas que hay que inventariar:

• Modelos preentrenados y adaptadores, como los LoRA, descargados de repositorios públicos.
• Datasets de entrenamiento, de ajuste fino y de evaluación.
• Librerías de inferencia, de orquestación de agentes y de procesamiento de datos.
• Servidores MCP, plugins y herramientas que usa el agente.
• Pipelines de datos que alimentan el RAG o el reentrenamiento.

Ficheros de modelo que ejecutan código al cargarse

Un modelo descargado parece un fichero de datos, pero algunos formatos permiten ejecutar código. El caso más conocido es pickle, el formato de serialización de Python que muchas herramientas de aprendizaje automático han usado para guardar modelos (ficheros .pkl, .pt, .pth o .bin, entre otros). Al deserializar un pickle, Python puede llamar a la función que indique el fichero, de modo que cargar un modelo de origen desconocido equivale a ejecutar un programa de origen desconocido.

Hay más casos: formatos que admiten capas con código propio y librerías con una opción para ejecutar el código remoto que acompaña al modelo. En repositorios públicos se han encontrado modelos con cargas maliciosas de este tipo.

Dependencias, modelos suplantados y paquetes inventados

Las librerías de IA cambian rápido y arrastran muchas dependencias, lo que favorece los ataques clásicos: paquetes con nombres casi idénticos a los legítimos (typosquatting), cuentas de mantenedores comprometidas y confusión de dependencias entre repositorios internos y públicos. En los repositorios de modelos ocurre lo mismo: un modelo publicado con un nombre parecido al de una organización conocida puede pasar por el original.

Los asistentes de código añaden un riesgo propio. A veces recomiendan paquetes que no existen, y un atacante puede registrar esos nombres con código malicioso para que los instale quien siga la sugerencia.

Un modelo también puede traer una puerta trasera en los pesos: se comporta con normalidad salvo ante un disparador concreto. Eso no se ve inspeccionando el fichero, solo evaluando su comportamiento.

Servidores MCP y pipelines de datos de terceros

Un servidor MCP instalado desde un registro público es código de un tercero que corre en tu máquina o con tus credenciales. Además de los riesgos de cualquier dependencia, tiene dos propios. Las descripciones de sus herramientas entran en el contexto del modelo y pueden llevar instrucciones ocultas, lo que se conoce como envenenamiento de herramientas (tool poisoning). Y el servidor puede cambiar esas descripciones o su comportamiento después de que lo hayas revisado y aprobado.

Los pipelines de datos son otra cadena de confianza. Un paso que descarga datos externos, los transforma y los entrega al entrenamiento o al índice del RAG suele tener credenciales amplias, y si se compromete, todo lo que viene después hereda el problema. Lo mismo vale para los sistemas de integración continua que construyen y publican modelos.

Cómo se defiende la cadena de suministro de IA

La idea de fondo es la del software tradicional: saber qué usas, de dónde viene y qué permisos tiene.

• Inventario de modelos, datasets, dependencias y servidores MCP con versión, origen y responsable, lo que se suele llamar SBOM o, para componentes de IA, AI BOM.
• Formatos seguros como safetensors, que solo guardan tensores, y rechazo de pickles de origen no confiable. Si no queda alternativa, cargarlos en un entorno aislado, sin red ni credenciales.
• Escáneres de modelos que buscan operaciones peligrosas en ficheros serializados, sabiendo que no lo detectan todo.
• Versiones fijadas, hashes o firmas verificados y un repositorio interno con lo aprobado.
• La ejecución de código remoto al cargar un modelo, desactivada por defecto.
• Servidores MCP revisados antes de conectarlos, con versión fija, aviso cuando cambian sus herramientas, ejecución aislada y credenciales mínimas.
• Evaluación de cada modelo antes de desplegarlo, con pruebas de comportamiento y red teaming.
• Pipelines con mínimo privilegio en cada paso, validación de los datos de entrada y registro de su procedencia.

Dónde practicarlo en AI Labs

• FORGEChatbot · Medium · Agente MCP
• DataPipe AnalyticsMáquina · Hard
• KernelForgeMáquina · Hard