AI Supply Chain Risk

Qué incorporamos y qué autoridad obtiene

AI Supply Chain Risk es el riesgo introducido por los componentes, artefactos y procesos externos de los que depende un sistema AI durante su adquisición, construcción y operación. Incluye código, modelos, datasets, adaptadores, configuración, herramientas y servicios. La cadena no termina al descargar un paquete ni empieza solamente cuando el modelo recibe un prompt.

NIST SP 800-218A amplía prácticas de desarrollo seguro para modelos generativos y sistemas que los utilizan. La entrada Supply Chain de OWASP LLM 2026 trata artefactos y transformaciones del ecosistema AI. El Atlas conserva el problema general de dependencias y especializa sus activos, sin crear una definición alternativa de seguridad de software.

Inventario según lo que se consume

Una revisión necesita saber qué se utiliza realmente: versión del runtime, librerías, artefacto del modelo, tokenizer, adaptadores, corpus, configuración de serving y herramientas conectadas. Un nombre de producto no identifica por sí solo esas piezas.

Los activos pueden cambiar de manera independiente. Actualizar una descripción de herramienta puede alterar lo que el modelo decide; actualizar un script puede cambiar lo que se ejecuta antes de invocarlo. Un proveedor remoto puede cambiar un comportamiento sin un commit local. Esas diferencias afectan qué se puede fijar, observar y reproducir.

Model Serving conserva la operación de inferencia. MLOps / LLMOps Operations conecta versiones y comportamiento en producción. La pregunta de supply chain es qué origen y transformación hicieron que una pieza llegara a esa ejecución y por qué se decidió confiar en ella.

Código y artefactos de modelos

Una dependencia puede ejecutar lógica en instalación, importación, build o runtime. Un artefacto de modelo también puede venir acompañado por código de carga, configuración o transformaciones que requieren revisión. El formato, el parser y el runtime forman parte de los supuestos de seguridad; un nombre de extensión no certifica todo el comportamiento.

Data and Model Poisoning desarrolla corrupción duradera de datos y comportamiento. Supply chain puede ser el canal que la introduce, pero también incluye vulnerabilidades, sustitución de artefactos y código con efectos no autorizados. No todo riesgo de cadena equivale a poisoning.

Un resultado favorable en una evaluación de calidad tampoco demuestra que el paquete de distribución sea seguro de ejecutar. Revisar comportamiento funcional e integridad de adquisición son evidencias relacionadas y diferentes.

Skills, hooks y paquetes

Agent Skills puede reunir instrucciones y recursos de apoyo. Lifecycle Hooks puede disparar comandos según eventos. Agent Extension Packages distribuye capacidades y configuración. Su instalación no establece automáticamente autoridad sobre el repositorio, la red o las credenciales.

Un script de apoyo puede ejecutarse fuera de la revisión que el modelo aplica a texto. Un hook puede actuar antes de una decisión del agente. Por eso la seguridad de estas extensiones exige examinar activación y efectos, además de leer sus descripciones.

Una fuente comunitaria conocida reduce algunas dudas de procedencia, pero no elimina cambios de mantenedor, componentes transitivos ni incompatibilidades. La revisión necesita la versión y el contenido aceptados, no únicamente una reputación general.

MCP y servicios externos

Model Context Protocol define interoperabilidad. No concede confianza a todo servidor ni hace equivalentes las políticas de cada cliente. La publicación Agentic Applications de OWASP identifica la cadena de componentes agentes como una preocupación específica.

Un servidor local agrega código ejecutado en el entorno; uno remoto agrega un tercero que recibe solicitudes y puede devolver contenido. Ambos requieren conocer operaciones, destinos e identidad. Una conexión autorizada no convierte sus resultados en instrucciones de mayor autoridad.

La lista de herramientas y sus descripciones también puede cambiar. Una integración nueva o una ampliación de capacidades merece revisar el alcance, aunque el endpoint conserve su nombre. Trust Boundaries permite separar procedencia del componente, confianza en sus datos y autorización para actuar.

Fijación, procedencia y verificación

Un lockfile o digest ayuda a identificar exactamente lo aceptado. No demuestra que esa versión sea inocua. Una firma puede autenticar el origen bajo determinados supuestos; no certifica la calidad de las decisiones del firmante.

SLSA describe provenance como información verificable para rastrear el origen y la producción de artefactos. En una integración concreta interesa qué identidad produjo la evidencia, qué transformación cubre y qué política decide aceptarla. Guardar una attestation sin verificarla no aplica esa política.

También importa qué queda fuera: un digest de imagen no fija necesariamente el comportamiento de una API externa que usa la aplicación. La evidencia debe conservar esa limitación en lugar de prometer reproducibilidad completa.

Ejemplo: un paquete propuesto para Payments

Un coding agent propone instalar una librería para interpretar un formato de pagos. Antes de aceptar, el equipo comprueba que el paquete corresponde al proyecto esperado, revisa la versión, los cambios de resolución y los scripts que se ejecutarían. El nombre sugerido por el modelo no es evidencia de existencia, origen ni mantenimiento.

Si la necesidad se satisface sin una dependencia nueva, evitarla reduce una parte de la cadena. Si se necesita, el alcance debe justificarla y probar compatibilidad. El objetivo es comprender el riesgo efectivo, no perseguir un contador de audit en cero mediante cambios amplios.

Least Privilege for Agents limita qué pueden alcanzar los procesos y servicios incorporados. Agent Sandboxing puede reducir consecuencias de código no confiable, pero no elimina la necesidad de examinar autoridad externa y salidas de datos.

Fuentes y alcance

• NIST SP 800-218A.
• OWASP LLM Top 10 2026: Supply Chain.
• OWASP Top 10 for Agentic Applications.
• SLSA v1.2: Provenance.

Fuentes consultadas el 2026-11-05. El ejemplo y los criterios de integración son síntesis del Atlas. Este documento no impone una plataforma de compras, un formato de inventario ni una herramienta de análisis.