F14 - 14.0 INTRODUCCIÓN: POR QUÉ LA CADENA DE SUMINISTRO DE IA ES EL NUEVO BLIND SPOT

14.0 Introducción: Por Qué la Cadena de Suministro de IA es el Nuevo Blind Spot

14.1 El AI Bill of Materials (AIBOM): Visibilidad como Prerequisito de Seguridad

14.2 Riesgos de Modelos Open Source: Hugging Face, Pickle Attacks y Namespace Hijacking

14.3 Shadow AI: El Riesgo Invisible Dentro de la Organización

14.4 MCP Server Security: El Nuevo Riesgo de Supply Chain Agéntico

14.5 LLMjacking y Robo de Credenciales de IA

14.6 Evaluación de Terceros en el Ecosistema M365: Plugins, Conectores y RAG

14.7 Plan de Acción para CISO: Programa de Supply Chain Security de IA

14.8 Métricas e Integración con el AI Governance Framework

14.9 Referencias (R361–R390)

14.0 INTRODUCCIÓN: POR QUÉ LA CADENA DE SUMINISTRO DE IA ES EL NUEVO BLIND SPOT

La cadena de suministro de software fue el blind spot crítico de la seguridad empresarial hasta que el incidente SolarWinds en 2020 demostró que un solo componente comprometido podía afectar a decenas de miles de organizaciones simultáneamente. La industria respondió con SBOMs obligatorios (Executive Order 14028, 2021) y frameworks de seguridad de supply chain. La cadena de suministro de IA es el siguiente blind spot — con una complejidad adicional: un modelo de IA comprometido no solo ejecuta código malicioso, sino que manipula el razonamiento, sesga las decisiones, y exfiltra datos de formas que ninguna herramienta de seguridad tradicional puede detectar.

La escala del problema es concreta: Hugging Face, el mayor repositorio de modelos open source del mundo, hospeda casi 1.9 millones de modelos con uno nuevo publicado cada 7 segundos. Protect AI escaneó 4.47 millones de versiones únicas de modelos y encontró 352,000 problemas de seguridad en 51,700 modelos. JFrog encontró 400 modelos con código malicioso de un millón analizado. Y el 25% de las organizaciones no sabe qué servicios de IA o datasets tiene activos en su entorno (Wiz 2025). Sin visibilidad, no hay seguridad posible.

DIMENSIÓN	SUPPLY CHAIN SOFTWARE CLÁSICO	SUPPLY CHAIN DE IA	RIESGO DIFERENCIAL
Componente vulnerable	Biblioteca con CVE conocido: detectable, parcheable. Comportamiento determinístico.	Modelo con backdoor: activación por triggers específicos, comportamiento dormante hasta que se activa la condición.	INVISIBLE: los backdoors en modelos de IA no son detectables por scanners de código estático ni CVE databases.
Vector de ataque	Dependencia comprometida en package registry (npm, PyPI). Typosquatting de nombres de paquetes conocidos.	Modelo malicioso en Hugging Face. Model namespace hijacking: el namespace original se borra y un atacante lo reclama con un modelo trojanizado.	DINÁMICO: el namespace de un modelo puede ser reclamado por un atacante en cualquier momento si el autor original borra su cuenta.
Detección	SBOM + scanner de CVEs. Herramientas maduras (Snyk, OWASP Dependency Check, GitHub Dependabot).	AIBOM + behavioral testing de modelos. Herramientas emergentes. Serialization scanning (Pickle/Safetensors). Sin CVE database equivalente para backdoors de IA.	INMADURO: el ecosistema de seguridad de IA tiene 3-5 años de retraso frente al de software tradicional.
Impacto de compromiso	Ejecución de código malicioso, exfiltración técnica.	Decisiones sesgadas, exfiltración de datos vía outputs del modelo, backdoors que producen outputs específicos ante triggers, credenciales de IA robadas (LLMjacking).	DIFUSO: el daño de un modelo comprometido puede ser difícil de distinguir de comportamiento normal del LLM, complicando la investigación forense.
Remediación	Actualizar o reemplazar la librería. Proceso bien conocido.	Reemplazar el modelo, retestear toda la aplicación, revisar si datos de producción fueron exfiltrados durante el tiempo de exposición.	COSTOSO Y LENTO: a diferencia de un parche de librería, reemplazar un modelo puede requerir reentrenamiento, evaluación de calidad, y migración de aplicaciones.
Superficie de ataque nueva: Shadow AI	No hay equivalente directo.	49% de empleados usa herramientas de IA no aprobadas por IT. Shadow AI breaches cuestan en promedio USD 670,000 más que incidentes tradicionales (Reco AI 2025). Promedio de detección: 247 días.	MASIVA: la superficie de ataque del Shadow AI es inherentemente invisible para el equipo de seguridad porque los controles de visibilidad no están desplegados donde el riesgo existe.

La Fase 14 completa la arquitectura de seguridad del CISO ante la IA desde la perspectiva del supply chain: ¿qué entra en nuestro ecosistema de IA (modelos, datos, plugins, MCP servers), quién lo publicó, está verificado, y cómo lo gestionamos de forma continua? Es la capa de seguridad que empieza antes del primer prompt — en el momento en que la organización decide qué componentes de IA usará.

14.1 EL AI BILL OF MATERIALS (AIBOM): VISIBILIDAD COMO PREREQUISITO

Un AI Bill of Materials (AIBOM) es el inventario estructurado de todos los componentes que constituyen un sistema de IA: modelos y sus versiones, datos de entrenamiento y su procedencia, dependencias de software, infraestructura de despliegue, y las relaciones entre todos estos elementos. Es el equivalente del SBOM para sistemas de IA — con la diferencia crítica de que los sistemas de IA son dinámicos: se reentrenan, se fine-tunean, ingieren datos continuamente, y sus dependencias evolucionan. El AIBOM no es un documento estático sino un artefacto vivo.

El EU AI Act (GPAI obligations, agosto 2025) requiere transparencia sobre datos de entrenamiento, medidas de mitigación de riesgos y Safety and Security Model Reports para sistemas de IA de propósito general. Los reguladores pueden solicitar auditorías de procedencia y las reclamaciones de secreto comercial sin documentación no serán suficientes. El AIBOM es la respuesta operacional a esta obligación regulatoria.

14.1.1 Componentes del AIBOM: Qué Documentar

COMPONENTE	QUÉ INCLUYE	POR QUÉ IMPORTA PARA SEGURIDAD	HERRAMIENTA
Metadatos del Modelo	Nombre, versión, arquitectura (ej: transformer, 70B parámetros), proveedor, fecha de creación, URL de descarga, hash/checksum del archivo de pesos, licencia de uso.	El hash/checksum permite detectar si el modelo descargado fue alterado respecto al publicado por el autor. Sin hash, no hay integridad verificable.	CycloneDX ML-BOM, SPDX AI profile, model registries (Azure AI Model Catalog, Hugging Face Model Card).
Procedencia del Modelo (Model Provenance)	Quién entrenó el modelo, cuándo, con qué datos de entrenamiento, qué fine-tuning fue aplicado y cuándo, quién aprobó cada versión para uso en producción.	Sin procedencia documentada, no se puede determinar si el modelo fue comprometido durante el entrenamiento (data poisoning) o si las fuentes de datos tienen restricciones legales (copyright, PII).	MLflow experiment tracking, W&B (Weights & Biases), Azure ML Model Registry, HuggingFace Model Cards.
Datos de Entrenamiento	Fuentes de datos usadas, fechas de corte, licencias de los datasets, transformaciones de preprocesamiento, clasificación de sensibilidad de los datos.	Identifica exposición a: (1) data poisoning si una fuente de datos fue comprometida, (2) riesgos legales si los datos de entrenamiento incluyen contenido protegido por copyright o datos personales sin consentimiento.	Data lineage tools: Azure Purview, Apache Atlas, dbt, DVC (Data Version Control).
Dependencias de Software	Frameworks de ML (PyTorch, TensorFlow, Keras), librerías de inferencia (transformers, llama.cpp, ONNX), versiones exactas, CVEs conocidos.	Los frameworks de ML tienen CVEs propios que pueden ser explotados durante la carga del modelo. CVE-2025-1550 en Keras permite ejecución de código malicioso a través de custom layers.	SBOM tools estándar (Syft, Trivy) + scanners específicos de ML (Protect AI Guardian, ClamAV 1.5 para modelos).
Infraestructura de Despliegue	Endpoints de inferencia (URLs, versiones de API), entornos de ejecución (contenedores, GPUs), configuraciones de red y acceso, credenciales de servicio usadas.	Un endpoint de inferencia sin autenticación adecuada o con credenciales estáticas expuestas es un vector de LLMjacking. La infraestructura es parte del supply chain.	Azure AI Foundry deployment registry, Kubernetes SBOM tools, gestión de secretos (Azure Key Vault).
Integraciones y Conectores	Plugins, conectores MCP, APIs externas llamadas por el sistema de IA, fuentes de datos RAG, webhooks.	Cada integración es un punto de entrada para prompt injection indirecta y un vector de supply chain. Un conector comprometido puede manipular las respuestas del LLM.	Inventario de conectores de Copilot Studio, registro de MCP servers en uso, revisión de permisos de cada integración.
Evaluaciones y Resultados de Testing	Resultados de red teaming (ver Fase 13), benchmarks de calidad, evaluaciones de sesgo, testing de safety, fecha del último test.	Sin registro de evaluaciones históricas, no se puede detectar drift de comportamiento: si el modelo empieza a comportarse diferente tras una actualización, ¿cómo lo sabemos si no tenemos la baseline?	PyRIT scorecards, Azure AI Foundry evaluation runs, Promptfoo risk assessments.

14.1.2 Estándares de AIBOM: CycloneDX ML-BOM y SPDX AI Profile

ESTÁNDAR	DESCRIPCIÓN	SOPORTE AIBOM	ADOPCIÓN EN MICROSOFT
CycloneDX v1.5+(OWASP gestiona)	El estándar SBOM más adoptado para software. La versión 1.5 incorpora el Machine Learning BOM (ML-BOM) que extiende CycloneDX con campos específicos para AI/ML: modelos, datasets, data lineage.	Soporte nativo para: model architecture, training datasets con provenance, AI/ML dependencies, hyperparameters. Formato machine-readable (JSON/XML). Compatible con la mayoría de herramientas SBOM existentes.	Azure DevOps puede generar CycloneDX SBOMs. Integración planificada con Azure AI Foundry para AIBOM generation en los pipelines de ML (roadmap 2026).
SPDX v3.0(Linux Foundation gestiona)	Estándar abierto del sector para SBOM. La versión 3.0 añade un AI Profile con elementos específicos para sistemas de IA y ML: campos para datos de entrenamiento, modelos, y sus relaciones.	AI Profile incluye: campos para autonomy type, safety risk assessment, data preprocessing steps. Interoperable con CycloneDX. Gobierno conjunto SPDX-OWASP para estandarización.	SPDX es soportado como formato de exportación en herramientas de compliance de GitHub Advanced Security.
Model Card(Google / Hugging Face)	Documento semi-estructurado que describe un modelo: sus capacidades, limitaciones, datos de entrenamiento, evaluaciones de sesgo, casos de uso intended y usos fuera de scope.	Estándar de facto para documentación de modelos en la comunidad open source. Menos estructurado que CycloneDX/SPDX pero más adoptado. Hugging Face lo requiere para modelos publicados.	Azure AI Studio genera Model Cards para modelos desplegados. Microsoft publica Model Cards para sus modelos propietarios (phi-4, Florence, etc).
Sigma / CLSigStore(Cosign para ML)	Estándar de firma criptográfica para artefactos de software. La comunidad de ML está trabajando en la extensión a modelos: firmas digitales para verificar la integridad y procedencia de archivos de pesos.	Emergente: aún no hay un estándar de firma de modelos ampliamente adoptado. Cisco propone Model Artifact Trust Standard. CycloneDX soporta attestation fields.	Microsoft trabaja en firmado de modelos propios. Sin estándar enterprise claro aún — área en evolución activa (2026-2027 probablemente el año de estandarización).

📌 Insight SD Times, enero 2026: Enterprise customers and regulators are moving beyond standard SOC 2 reports to demand Ingredient Transparency. Some vendor evaluations have stalled not because of firewall configurations, but because the vendor could not demonstrate the provenance of its training data. For the modern C-Suite, the AI BOM is becoming the standard Certificate of Analysis required to greenlight any AI-driven partnership.

14.2 RIESGOS DE MODELOS OPEN SOURCE: HUGGING FACE, PICKLE ATTACKS Y NAMESPACE HIJACKING

Hugging Face es para los modelos de IA lo que npm es para JavaScript o PyPI para Python: el repositorio de facto donde la comunidad comparte, descarga y usa modelos. Con casi 1.9 millones de modelos y uno nuevo publicado cada 7 segundos, es también el vector de supply chain de mayor riesgo para organizaciones que desarrollan aplicaciones de IA propias o usan modelos open source en Azure AI Foundry. Los ataques documentados en 2025 demuestran que la apertura del ecosistema que lo hace valioso es exactamente lo que lo hace peligroso.

14.2.1 Taxonomía de Ataques a Modelos Open Source

TIPO DE ATAQUE	MECÁNICA TÉCNICA	INCIDENTE REAL DOCUMENTADO	DETECCIÓN Y MITIGACIÓN
Pickle Deserialization (Malicious Pickling)	El formato Pickle de Python permite ejecutar código arbitrario durante la deserialización del modelo (el momento en que PyTorch carga el archivo .pt o .pkl). Un atacante embebe un payload malicioso en el archivo Pickle que se ejecuta automáticamente cuando el desarrollador carga el modelo con torch.load().	ReversingLabs (febrero 2025): técnica 'NullifAI'. Dos modelos en Hugging Face con payload malicioso al inicio del stream Pickle, evadiendo Picklescan (el scanner de Hugging Face). Los modelos tenían tag 'No issue'. El payload creaba nuevos procesos y ejecutaba comandos del sistema operativo. Hugging Face los eliminó en 24h tras notificación.	MIGRAR a formato Safetensors: diseñado sin capacidad de ejecución de código, solo datos. Usar Protect AI Guardian, ClamAV 1.5 (Cisco Foundation AI) para scanning pre-uso. NUNCA usar torch.load() con weights_only=False en modelos de fuentes externas. Verificar hash SHA-256 del archivo antes de cargar.
Model Namespace Hijacking (Reclamación de Namespaces)	Un desarrollador o organización publica un modelo en Hugging Face bajo su namespace (Author/ModelName). Posteriormente, la cuenta del autor se elimina, liberando el namespace. Un atacante registra el mismo namespace y publica un modelo malicioso con el mismo nombre. Todos los sistemas que hacen pull del modelo por nombre (sin pin de hash) descargan automáticamente la versión comprometida.	Palo Alto Networks Unit 42 (septiembre 2025): caso DentalAI / toothfAIry. La organización DentalAI borró su cuenta de Hugging Face. Un actor malicioso reclamó el namespace y publicó un modelo comprometido bajo el mismo nombre. Pipelines que referenciaban el modelo por nombre (sin hash pin) lo descargaron automáticamente.	Siempre referenciar modelos por hash/commit ID, no solo por nombre. Usar un Model Registry interno (Azure AI Foundry Model Catalog) que valide la integridad del modelo en el momento de importación. Monitorear cambios en los modelos usados. Política: solo modelos de fuentes verificadas ingresados al registry interno.
Framework Vulnerabilities (CVEs en ML Frameworks)	Los frameworks de ML (Keras, TensorFlow, PyTorch, ONNX) tienen CVEs propios que pueden ser explotados a través de modelos especialmente crafteados. Los mecanismos de extensibilidad de los frameworks (custom layers, plugins, callbacks) son vectores de ataque.	CVE-2025-1550 en Keras: custom layers pueden ejecutar código arbitrario a pesar de las features de seguridad. Protect AI Guardian alertó a usuarios en Hugging Face antes de que la vulnerabilidad fuera divulgada públicamente.	Mantener frameworks de ML actualizados — tratarlos como dependencias de software con política de patch. Incluir versiones de frameworks en el SBOM. Usar ambientes aislados (contenedores, sandboxing) para cargar y ejecutar modelos de fuentes externas.
Data Poisoning en Training/Fine-tuning	Un actor malicioso introduce datos envenenados en el pipeline de entrenamiento o fine-tuning: datos diseñados para crear backdoors que el modelo activa solo ante triggers específicos, o para sesgar sistemáticamente las respuestas en una dirección deseada por el atacante.	Investigación Trend Micro 2025: modelos con backdoors embedded como triggers estadísticos son prácticamente invisibles a análisis estático, SBOMs y revisión de código. El comportamiento malicioso solo emerge bajo condiciones específicas que el atacante controla.	Validación diferencial de datos de entrenamiento (clustering + anomaly detection). Isolation de ambientes de fine-tuning. Shadow testing de modelos nuevos antes de promotion a producción. Behavioral testing post-entrenamiento con dataset de validación adversarial.
Trojanized PyPI Packages (AI SDKs falsos)	Atacantes publican paquetes en PyPI que se hacen pasar por SDKs legítimos de proveedores de IA (Aliyun AI Labs, Alibaba Cloud AI Research). Los paquetes contienen malware oculto en el mismo formato Pickle, aprovechando que los desarrolladores confían en PyPI más que en repositorios desconocidos.	ReversingLabs 2025: paquetes trojanizados en PyPI posando como SDKs para servicios de IA cloud, usando el mismo vector Pickle para ocultar el malware.	Igual que software tradicional: SBOM + dependency scanning (Snyk, Trivy, GitHub Dependabot) para todos los paquetes Python en proyectos de IA. Política de dependencias aprobadas. Auditoría de PyPI packages en proyectos de ML.

14.2.2 Herramientas de Seguridad para Modelos Open Source

HERRAMIENTA	PROVEEDOR	CAPACIDADES	APLICACIÓN PARA CISO
Protect AI Guardian	Protect AI (partnership con Hugging Face)	Escanea modelos en Hugging Face: deserialization attacks, CVEs en frameworks, código malicioso en extensiones. 4.47M modelos escaneados en 6 meses. Detecta: archive slip, Joblib code execution, TensorFlow backdoors, Llamafile malicious execution.	Integrar en el proceso de importación de modelos externos al Azure AI Model Catalog. Cualquier modelo de Hugging Face debe pasar por Guardian antes de ser admitido al registro interno.
ClamAV 1.5 + Cisco Cerberus	Cisco Foundation AI	ClamAV 1.5 (open source): detecta malware en formatos de modelos .pt y .pkl. Cerberus: inspección 24/7 en tiempo real de modelos subidos a Hugging Face, resultados en threat feeds estandarizados.	ClamAV es el único antivirus en VirusTotal que detecta malware en modelos de IA. Integrar en pipelines de CI/CD para escanear modelos antes de deployment.
Azure AI Foundry Model Catalog	Microsoft	Registry curado de modelos con vetting de proveedores. Incluye modelos de Microsoft, Meta, Mistral, OpenAI, y otros validados. Alternativa a consumir directamente de Hugging Face para organizaciones enterprise.	Política: para cualquier modelo en aplicaciones de producción, usar solo modelos del Azure AI Model Catalog o modelos de Hugging Face que hayan pasado por escaneo Guardian/ClamAV y estén importados al registry interno.
VirusTotal para Modelos	Google / VirusTotal	Permite upload y escaneo de archivos de modelos .pt, .pkl. ClamAV es el único motor AV actualmente con capacidad de detectar malware específico de ML.	Scan ad-hoc de modelos sospechosos. No como mecanismo principal (sin automatización), sino como herramienta de investigación cuando surge una alerta.
Picklescan + Safetensors	Hugging Face / EleutherAI	Picklescan: scanner de código de seguridad para archivos Pickle en Hugging Face (con las limitaciones demostradas por NullifAI). Safetensors: formato alternativo a Pickle que no permite ejecución de código — solo almacena tensores.	Requerir uso de Safetensors en todos los modelos propios desarrollados internamente. Para modelos externos, dar preferencia a versiones en Safetensors cuando disponibles.

14.3 SHADOW AI: EL RIESGO INVISIBLE DENTRO DE LA ORGANIZACIÓN

El Shadow AI es el conjunto de herramientas, modelos y sistemas de IA que los empleados adoptan sin el conocimiento ni la aprobación del equipo de IT y seguridad. No es un fenómeno marginal: según una encuesta de 2,000 empleados en EE.UU. y Reino Unido, el 49% usa herramientas de IA no aprobadas por sus empleadores, y más de la mitad no entiende cómo sus inputs son almacenados y analizados por esas herramientas. LayerX 2025 encontró que el 77% de empleados enterprise que usa IA ha pegado datos corporativos en un chatbot, y el 22% de esos casos incluía datos financieros o personales confidenciales.

14.3.1 El Ecosistema del Shadow AI y Sus Vectores de Riesgo

TIPO DE SHADOW AI	DESCRIPCIÓN	DATO CUANTITATIVO	RIESGO PRINCIPAL
Chatbots públicos no aprobados	ChatGPT, Claude, Gemini, Copilot, DeepSeek accedidos directamente por empleados con datos corporativos. El caso Samsung (ingenieros que pegaron código propietario en ChatGPT) fue el primero masivamente documentado.	77% de empleados enterprise que usa IA ha pegado datos corporativos en un chatbot (LayerX 2025). Samsung baneó herramientas de IA externas tras el incidente. JPMorgan y Goldman Sachs restringieron ChatGPT.	EXFILTRACIÓN DE DATOS: el proveedor del chatbot puede usar los inputs para entrenamiento (dependiendo de los términos de servicio y configuración ZDR). Datos de clientes, código fuente, estrategias de M&A, datos financieros no-públicos enviados sin control.
Plugins y extensiones de browser	Extensiones de Chrome/Edge con IA que interceptan el contenido de páginas web, emails, y documentos antes de que el usuario interactúe con ellos. Muchas solicitan permisos amplios (leer todos los datos de todos los sitios web).	Gartner: 80% de los empleados en empresas con 10,000+ empleados usan al menos una extensión de browser sin aprobación de IT.	INTERCEPTACIÓN: las extensiones de IA pueden capturar credenciales, cookies de sesión, contenido de SaaS corporativos (Salesforce, ServiceNow, HubSpot) y enviarlo a servidores externos sin que el usuario o IT lo sepa.
Herramientas de AI coding no aprobadas	Desarrolladores usando Cursor, Tabnine, Codeium, Continue u otras herramientas de AI coding que no forman parte del stack aprobado. El código corporativo (incluidos secretos embebidos) se envía a los modelos de los proveedores.	Sonar Survey 2026: 60% de empleados en empresas grandes dicen que usan herramientas de IA no aprobadas si aumentan la productividad, aunque reconocen el riesgo de seguridad.	CÓDIGO SECRETO: los modelos de AI coding reciben fragmentos de código que pueden incluir API keys, credenciales hardcodeadas, lógica de negocio propietaria, y código de sistemas clasificados como no para divulgación.
Agentes de IA no gestionados	OpenClaw y similares: agentes de IA open source que empleados instalan y conectan a sus cuentas corporativas de Slack, Google Workspace, Microsoft 365 sin aprobación de IT. Los agentes tienen permisos OAuth sobre los sistemas corporativos.	OpenClaw: 150,000 GitHub stars en enero 2026. Gartner lo describió como 'inaceptable liability de ciberseguridad' y recomendó bloquearlo inmediatamente. 21,000 instancias expuestas.	AGENTE PRIVILEGIADO: un agente no gestionado conectado a M365 con OAuth tiene permisos sobre Email, Teams, SharePoint, OneDrive. Si el agente es comprometido (o tiene vulnerabilidades propias), el atacante hereda esos permisos.
Modelos locales no gestionados	Desarrolladores descargando y ejecutando modelos de Hugging Face localmente (LLaMA 3, Mistral, DeepSeek) en sus laptops corporativas, a veces conectados a datos internos a través de frameworks como Ollama+LangChain.	25% de organizaciones no saben qué servicios de IA o datasets tienen activos en su entorno (Wiz 2025).	SUPPLY CHAIN + DATA: combina los riesgos de modelos open source sin vetting con el riesgo de que esos modelos accedan a datos corporativos en la laptop del desarrollador.
SaaS de IA con integración OAuth	Herramientas SaaS de IA que los empleados conectan a sus cuentas corporativas vía OAuth: herramientas de summarización de emails, asistentes de calendario, herramientas de notas inteligentes. Cada una tiene acceso a datos corporativos.	Reco AI 2025: Shadow AI breaches cuestan promedio USD 670,000 más que incidentes tradicionales. Promedio de detección: 247 días. Afectan principalmente PII de clientes (65%) e IP (40%).	ACCESO LATENTE: las integraciones OAuth de Shadow AI son la forma más difícil de detectar. El acceso parece legítimo (viene de un OAuth grant real), no es malware, y no genera alertas de seguridad tradicionales.

14.3.2 Controles para Shadow AI

CAPA DE CONTROL	CONTROLES ESPECÍFICOS	IMPLEMENTACIÓN EN MICROSOFT ECOSYSTEM
Visibilidad y Descubrimiento	Descubrir qué herramientas de IA ya están en uso (antes de prohibir o aprobar): auditar OAuth grants en M365, revisar logs de DLP por envío de datos a dominios de IA, escanear el tráfico de red para identificar conexiones a APIs de IA.	Microsoft Defender for Cloud Apps (MCAS): discovery de shadow IT incluyendo herramientas de IA. Azure AD sign-in logs: OAuth consents otorgados por usuarios. Microsoft Purview DLP: alertas cuando datos etiquetados se envían a dominios externos de IA.
Política y Clasificación	Implementar un registro de herramientas de IA aprobadas (AI Approved Tools Registry) con nivel de datos permitido para cada herramienta. Ejemplo: ChatGPT Plus con ZDR habilitado → datos internos non-confidential OK; Microsoft 365 Copilot → todos los datos OK; ChatGPT gratuito → solo datos públicos.	Microsoft Entra Conditional Access: bloquear acceso OAuth a dominios de IA no aprobados. Intune: gestionar qué extensiones de browser se pueden instalar en dispositivos corporativos. MIP sensitivity labels: datos con etiqueta Confidential/Restricted no pueden pegarse en aplicaciones no aprobadas.
DLP para IA	Implementar políticas de DLP específicas para el flujo de datos hacia sistemas de IA: alertar o bloquear cuando datos clasificados como confidenciales se envían a endpoints de IA no aprobados.	Microsoft Purview DLP: políticas para detectar envío de PII, datos financieros, o datos clasificados a dominios externos de IA (.openai.com, .anthropic.com, .deepseek.com). Integración con sensitivity labels para DLP automatizado basado en clasificación.
Gestión de OAuth Grants	Auditar y revocar OAuth grants no autorizados a herramientas de IA externas. Implementar proceso de aprobación para nuevas OAuth connections a aplicaciones de IA.	Microsoft Entra ID: revisar Enterprise Applications para OAuth consents de usuarios. Reco o Obsidian Security: herramientas especializadas en Shadow AI discovery a través de análisis de OAuth grants. Proceso: revisión mensual de nuevos OAuth grants, revocación de no-aprobados.
Educación y Habilitación	La prohibición sin alternativa fuerza al Shadow AI a la clandestinidad total. La estrategia más efectiva es ofrecer alternativas aprobadas que cubran los casos de uso legítimos: M365 Copilot aprobado para productividad, GitHub Copilot Enterprise para desarrollo.	Programa de AI Champions: empleados certificados que ayudan a sus equipos a usar herramientas de IA aprobadas efectivamente. Política clara: qué está aprobado, con qué tipos de datos, y cómo solicitarle aprobación a IT para una herramienta nueva.

14.4 MCP SERVER SECURITY: EL NUEVO RIESGO DE SUPPLY CHAIN AGÉNTICO

El Model Context Protocol (MCP), introducido por Anthropic en noviembre 2024, se ha convertido en el estándar de facto para que los LLMs interactúen con fuentes de datos externas y herramientas. En menos de un año, hay más de 20,000 servidores MCP publicados en GitHub y el protocolo es soportado nativamente por Visual Studio Code, Claude Code CLI, Cursor, y otras herramientas de desarrollo. La adopción masiva precedió a la madurez de seguridad del ecosistema — exactamente el patrón que en el pasado llevó a las crisis de supply chain más graves.

El estudio de Astrix Security sobre 20,000 implementaciones de MCP servers en GitHub revela la realidad: el 88% requiere credenciales para funcionar, el 53% usa API keys estáticas o Personal Access Tokens de larga vida, y solo el 8.5% usa OAuth (el método moderno de delegación segura). El 79% de las API keys se pasan a través de simples variables de entorno. El ecosistema MCP es, en términos de gestión de credenciales, similar al estado del cloud en 2013: funcional pero fundamentalmente inseguro.

14.4.1 Vectores de Riesgo de los MCP Servers

VECTOR	MECÁNICA	INCIDENTE/INVESTIGACIÓN	CONTROL
Supply Chain: Código Malicioso en MCP Servers	Los MCP servers se distribuyen principalmente a través de GitHub (repositorios privados y públicos) sin registros oficiales verificados ni estándares de signing. Cualquier desarrollador puede publicar un MCP server. La instalación equivale a ejecutar código arbitrario: los instaladores automáticos (mcp-installer) facilitan la instalación de servidores sin inspección del código.	Investigación Wiz: 'instalar un MCP server local es definitivamente ejecutar código arbitrario en tu máquina'. Cursor IDE: investigadores demostraron cómo un MCP server rogue puede inyectar código malicioso en el browser integrado del IDE.	Usar solo MCP servers de fuentes verificadas (Microsoft, proveedores conocidos). Revisar el código fuente antes de instalar cualquier MCP server de terceros. Política: MCP servers requieren aprobación del equipo de seguridad antes de uso en entornos con datos corporativos.
Credenciales Estáticas Expuestas	53% de MCP servers usan API keys o PATs de larga vida pasados como variables de entorno o embebidos en archivos de configuración. Estas credenciales son de largo plazo (a veces sin expiración), tienen scope amplio (típicamente más permisos de los necesarios), y se distribuyen con el código.	Astrix Research 2025: análisis de 20,000 implementaciones de MCP servers en GitHub. 88% requiere credenciales. 53% usa API keys estáticas. 79% las pasa vía environment variables. Solo 8.5% usa OAuth.	Herramienta open source: Astrix MCP Secret Wrapper — wrappea cualquier MCP server existente y reemplaza credenciales estáticas por pull dinámico desde un vault (AWS Secrets Manager, Azure Key Vault). Principio: short-lived credentials, just-in-time access, least privilege scope.
Prompt Hijacking y Session ID Guessing	La comunicación entre clientes MCP y servidores MCP remotos no siempre es segura. Los session IDs que identifican una sesión activa pueden ser predecibles o suficientemente cortos para ser adivinados por un atacante, que puede entonces secuestrar la sesión y acceder a los datos y herramientas del servidor.	CSO Online (diciembre 2025): MCP servers remotos expuestos a 'prompt hijacking' por session IDs predecibles. LangSmith vulnerability (Noma Security): vulnerabilidad en herramienta de IA que permitía robo de API keys y hijacking de respuestas del LLM.	Implementar TLS mutuo para comunicaciones cliente-servidor MCP. Session IDs cryptographically random de longitud suficiente. Autenticación basada en OAuth 2.0 para servidores remotos. Validar el modelo de autorización de MCP antes de desplegarlo en producción.
Tool Poisoning (Descripción Maliciosa de Herramientas)	Un MCP server malicioso puede proporcionar al LLM descripciones de herramientas manipuladas que instigan al modelo a tomar acciones no intencionadas cuando las herramientas son llamadas — incluso si el código de las herramientas en sí es benigno.	Investigación académica 2025: demostración de cómo un MCP server puede describir una herramienta de 'leer archivo' de forma que el LLM la usa para leer archivos de credenciales cuando el prompt del usuario es suficientemente ambiguo.	Tratar las descripciones de herramientas MCP como inputs no confiables. Validar que las acciones que el agente toma corresponden a la intención del usuario. Monitorear los tool calls de los agentes para detectar patrones anómalos (ver Fase 10 — Defender for AI).
Privilege Escalation entre Servidores MCP	En arquitecturas con múltiples servidores MCP, un servidor de baja confianza puede intentar hacer llamadas a un servidor de alta confianza a través del LLM actuando como intermediario, efectuando una escalada de privilegios indirecta.	Caso ServiceNow (diciembre 2025): 'second-order' prompt injection entre agentes con distintos niveles de privilegio. Un agente de baja confianza manipulaba a un agente de alta confianza para exportar un case file completo a una URL externa.	Arquitectura de confianza: cada servidor MCP tiene un nivel de confianza explícito. El LLM no puede pedir a un servidor de alta confianza que ejecute acciones iniciadas por un servidor de baja confianza sin validación humana.

14.5 LLMJACKING Y ROBO DE CREDENCIALES DE IA

LLMjacking es el nombre que la comunidad de seguridad dio al robo y abuso de credenciales de APIs de LLM (OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Google Vertex AI). Los atacantes roban API keys corporativas y las usan para acceder a los modelos en nombre de la organización víctima — generando facturas masivas y, más crítico, usando los modelos para generar contenido que bypasea los guardrails éticos configurados para usuarios empresariales. Microsoft presentó una demanda civil en 2025 contra un grupo especializado en LLMjacking que usaba las credenciales robadas para construir servicios de pago para otros criminales.

ASPECTO	DETALLE	IMPACTO CUANTIFICADO	CONTROL
Vectores de robo de API keys	Los atacantes obtienen API keys a través de: (1) repositorios de código público con keys hardcodeadas (GitHub, GitLab), (2) credenciales en archivos .env versionados, (3) secrets en logs o variables de entorno expuestas, (4) compromiso de sistemas de CI/CD, (5) apps de terceros que almacenan las keys del usuario.	Wiz (junio 2025): escaneo de repositorios públicos encontró AI-related secret leaks masivos — notebooks de Jupyter con keys hardcodeadas son el vector más común.	Rotación regular de API keys. Nunca almacenar en repos. Usar Azure Key Vault para gestión de secrets. GitHub secret scanning + push protection.
Escala del abuso	Un atacante con acceso a múltiples API keys roba capacidad de compute de múltiples organizaciones simultáneamente. El acceso a modelos de última generación (GPT-4, Claude 3.5 Sonnet, Gemini Ultra) cuesta significativamente más que modelos anteriores.	Investigadores estiman costos potenciales de más de USD 100,000 por día cuando se consultan modelos frontier con una API key robada. El costo se factura a la organización víctima.	Billing alerts: configurar alertas de Azure para consumo inusual de Azure OpenAI. Dashboards de uso por usuario/aplicación. Rate limiting por aplicación.
El servicio criminal resultante	El grupo demandado por Microsoft usaba las API keys robadas para construir un servicio de pago que ofrecía a otros criminales acceso a modelos de IA configurados para generar contenido que normalmente violaría los términos de servicio de los proveedores: malware, phishing, deepfakes, CSAM.	Los compradores del servicio criminal obtenían: (1) acceso al modelo sin pagar, (2) jailbreak de los guardrails del proveedor que el modelo enterprise tiene configurados, (3) ausencia de logging en la cuenta del comprador (el logging está en la víctima).	Monitorear anomalías en los patterns de uso de Azure OpenAI. Keys por aplicación (no una key maestra para todo). Scope mínimo por key.
Exposición de datos de la organización	Cuando un atacante usa la API key robada, el prompt y la respuesta se registran en los logs de la organización víctima (no del atacante). Si la key tiene acceso a modelos con datos de la organización (fine-tuning, RAG), el atacante puede potencialmente extraer esos datos.	Menos documentado pero potencialmente más grave que el costo financiero: el atacante puede usar la key para interrogar el sistema de IA de la organización y extraer información propietaria embebida en el contexto del modelo.	Auditoría de logs de Azure OpenAI: revisar patrones de uso fuera del horario laboral, desde IPs inusuales, con prompts que no corresponden al uso normal de la aplicación.

14.6 EVALUACIÓN DE TERCEROS EN EL ECOSISTEMA M365: PLUGINS, CONECTORES Y RAG

El ecosistema de Microsoft 365 Copilot y Copilot Studio tiene una arquitectura de extensibilidad que permite a terceros publicar plugins, conectores de Graph, agentes de voz y conectores de datos que amplían las capacidades del Copilot. Para el CISO, cada extensión de terceros es un componente de la cadena de suministro de IA que requiere evaluación antes de que la organización lo adopte. La superficie de ataque del Copilot se expande con cada plugin activado.

TIPO DE EXTENSIÓN M365	ACCESO QUE OTORGA	RIESGO PRINCIPAL	DUE DILIGENCE REQUERIDO
Plugins de Copilot M365 (marketplace de Microsoft)	Acceso a los datos del usuario en M365 según permisos OAuth otorgados. Algunos plugins tienen capacidades de read/write.	Supply chain: un plugin comprometido tiene acceso a todos los datos a los que el usuario tiene acceso, más los datos que el Copilot ha procesado en la sesión.	(1) Verificar que el plugin está en el catálogo oficial aprobado de Microsoft. (2) Revisar los permisos OAuth que solicita — ¿son mínimos necesarios? (3) Leer la política de privacidad del proveedor: ¿cómo maneja los datos del usuario? (4) Verificar certificaciones de seguridad del proveedor (SOC 2 Type II, ISO 27001). (5) Bloquear todos los plugins por defecto y aprobar solo los necesarios.
Conectores de Copilot Studio (Graph connectors, Power Platform)	Acceso a fuentes de datos externas (Salesforce, ServiceNow, SAP, DBs propias) para el RAG del agente. Los datos de estas fuentes alimentan el contexto del LLM.	Data ingestion sin control: los datos de los sistemas conectados pasan a ser contexto del LLM. Si esos datos incluyen PII, secretos, o información confidencial, pasan a estar disponibles para el agente — y potencialmente para exfiltración.	(1) Inventariar TODOS los conectores configurados en cada agente de Copilot Studio. (2) Para cada conector: ¿qué datos exactos están en scope? ¿Están clasificados con MIP labels? (3) Verificar que las credenciales del conector están en Azure Key Vault (no hardcodeadas en el agente). (4) Auditar los logs de uso del conector: ¿quién está accediendo a los datos a través del agente?
MCP Servers para Claude Code / Copilot	Acceso a herramientas específicas: filesystem, APIs, databases, servicios cloud. Potencialmente ilimitado dependiendo del server.	El más peligroso: MCP servers de terceros con acceso a sistemas de producción. Un server comprometido o malicioso tiene acceso a todo lo que el desarrollador tiene.	(1) Policy: PROHIBIDOS los MCP servers de fuentes desconocidas en entornos con datos corporativos. (2) Lista blanca de MCP servers aprobados. (3) Code review del código fuente de cualquier MCP server antes de aprobación. (4) Gestión de credenciales: Azure Key Vault para todas las credenciales de MCP servers. (5) Monitoreo de acciones: logs completos de tool calls del agente.
RAG Data Sources (SharePoint, bases de datos, APIs)	Los documentos y datos indexados en el RAG del agente se convierten en contexto disponible para el LLM y, potencialmente, para los usuarios del agente.	Corpus poisoning: un documento malicioso en el corpus RAG puede contener instrucciones de prompt injection que se activan cuando son recuperadas. Data leakage: el RAG puede exponer documentos a usuarios que no tienen permiso directo sobre ellos.	(1) Aplicar el principio de least data: solo indexar los documentos estrictamente necesarios para el caso de uso del agente. (2) Verificar que los permisos del RAG respetan los permisos de SharePoint del usuario (Copilot for M365 hace esto nativamente, pero los agentes custom pueden no hacerlo). (3) Auditar el corpus del RAG periódicamente: ¿hay documentos desactualizados, de clasificación incorrecta, o que no deberían estar en scope?

14.7 PLAN DE ACCIÓN PARA CISO: PROGRAMA DE SUPPLY CHAIN SECURITY DE IA

El programa de supply chain security de IA para una organización con 20,000+ licencias M365 E5 debe construirse en tres niveles simultáneos: visibilidad (saber qué hay), control (gestionar qué entra), y monitoreo continuo (detectar cambios en lo que ya está). Los 12 pasos que siguen son acciones concretas ordenadas por prioridad y horizonte temporal.

	PRIORIDAD	ACCIÓN	DETALLE DE IMPLEMENTACIÓN	HORIZONTE
1	CRÍTICO — VISIBILIDAD	Inventario de todos los componentes de IA (AIBOM inicial)	Ejecutar un inventario completo: (1) Qué modelos están en uso (incluyendo Azure AI Foundry deployments, modelos fine-tuned propios, y modelos locales en laptops de desarrolladores). (2) Qué conectores y plugins están activados en Copilot Studio. (3) Qué MCP servers están instalados en los entornos de desarrollo. (4) Qué herramientas de IA externas están siendo accedidas (Shadow AI discovery vía Defender for Cloud Apps). Resultado: AIBOM v1 en formato CycloneDX.	30 días
2	CRÍTICO — SHADOW AI	Desplegar Shadow AI Discovery y DLP para IA	Activar Defender for Cloud Apps para discovery de aplicaciones de IA no aprobadas. Implementar política de DLP en Microsoft Purview para detectar envío de datos clasificados (Confidential, Highly Confidential) a dominios de IA externos. Auditar OAuth consents en Azure AD: revocar consents a aplicaciones de IA no aprobadas. Reportar hallazgos al AI Governance Committee (ver Fase 7).	30 días
3	CRÍTICO — CREDENCIALES	Auditar y proteger todas las API keys de IA	Inventariar todas las API keys de servicios de IA (Azure OpenAI, OpenAI, Anthropic, Google Vertex) que la organización tiene. Verificar que NINGUNA está en repositorios de código (GitHub secret scanning). Migrar todas al Azure Key Vault. Implementar rotación automática con períodos máximos de 90 días. Activar billing alerts en Azure para detectar consumo anómalo de Azure OpenAI.	30 días
4	ALTO — MCP	Política de MCP Servers y lista blanca	Emitir política explícita: (1) PROHIBIDOS los MCP servers de fuentes no verificadas en cualquier entorno con datos corporativos. (2) Lista blanca inicial: solo MCP servers de Microsoft y partners de confianza nivel Tier-1. (3) Proceso de aprobación: cualquier nuevo MCP server requiere code review de seguridad + aprobación del equipo de seguridad. (4) Usar Astrix MCP Secret Wrapper para todos los MCP servers aprobados que usen credenciales.	30-60 días
5	ALTO — PLUGINS	Governance de plugins y conectores de Copilot Studio	Inventariar todos los plugins activados en el tenant de M365. Deshabilitar todos los plugins no en la lista de aprobados. Establecer proceso formal de aprobación de nuevos plugins: due diligence del proveedor (SOC 2, política de privacidad), revisión de permisos OAuth, aprobación del CISO para plugins con acceso a datos de nivel Confidential o superior.	30-60 días
6	ALTO — MODELO REGISTRY	Implementar Azure AI Model Registry como punto único de entrada para modelos	Establecer como política: ningún modelo de IA externo puede usarse en aplicaciones de producción sin haber sido importado al Azure AI Model Catalog interno. Proceso de importación: (1) Escaneo con Protect AI Guardian o ClamAV 1.5. (2) Verificación de hash SHA-256. (3) Documentación en el AIBOM (procedencia, versión, licencia). (4) Aprobación del equipo de seguridad. (5) Pin de versión específica (no float al latest).	60 días
7	ALTO — SBOM+AIBOM	Integrar generación automática de AIBOM en pipelines de CI/CD	Para todos los proyectos internos que desarrollan o consumen modelos de IA: integrar generación de AIBOM (CycloneDX format) en el pipeline de CI/CD. El AIBOM se genera automáticamente con cada build que incluye un modelo o dependencia de IA nueva. Los AIBOMs se almacenan en un repositorio central (Azure Artifacts o similar) y se actualizan con cada release.	60-90 días
8	MEDIO — RAG GOVERNANCE	Auditoría y governance del corpus RAG de todos los agentes	Para cada agente de Copilot Studio que usa RAG: (1) Documentar exactamente qué fuentes de datos están indexadas. (2) Verificar que los permisos de acceso del RAG corresponden a los permisos del usuario (no over-sharing). (3) Implementar data classification review: ¿hay documentos Confidential en corpus públicos? (4) Proceso de re-auditoría trimestral.	60-90 días
9	MEDIO — SAFETENSORS	Mandato de uso de Safetensors para modelos propios	Para todos los modelos fine-tuned propietarios desarrollados internamente: mandato de guardar y distribuir en formato Safetensors en lugar de Pickle. Safetensors no permite ejecución de código durante la deserialización, eliminando la clase completa de ataques de malicious Pickling.	90 días
10	MEDIO — MONITOREO	Activar Defender for AI y logging completo de Azure OpenAI	Activar el logging completo de Azure OpenAI Service: todos los prompts y respuestas logueados en Azure Monitor/Log Analytics (con configuración de retención y acceso apropiados). Defender for Cloud / Defender for AI: activar threat detection para AI workloads. Configurar alertas para: consumo de tokens fuera del baseline, IPs inusuales accediendo a los endpoints, patrones de prompt injection conocidos.	90 días
11	MEDIO — EDUCACIÓN	Programa de AI Security Awareness para desarrolladores	Training específico para el equipo de desarrollo sobre supply chain security de IA: (1) Por qué no se debe usar torch.load() sin weights_only=True. (2) Cómo verificar la integridad de un modelo descargado. (3) Por qué las API keys no van en el código. (4) Qué herramientas de IA están aprobadas y cómo solicitarle aprobación a IT para una nueva. Formato: módulo de 30 minutos, completión obligatoria, quiz de verificación.	90 días
12	CICLO — CONTINUO	Programa de revisión continua de AIBOM y monitoreo de supply chain	Establecer proceso mensual de revisión del AIBOM: ¿hay nuevos modelos en uso no registrados? ¿Algún modelo cambió de versión inesperadamente (posible namespace hijacking)? ¿Hay nuevos CVEs en los frameworks de ML usados? Suscribirse a threat feeds de AI supply chain: Protect AI Vulnerability Database, Cisco Cerberus alerts. Revisar nuevas publicaciones de MITRE ATLAS sobre supply chain attacks.	Mensual, continuo

14.8 MÉTRICAS E INTEGRACIÓN CON EL AI GOVERNANCE FRAMEWORK

El programa de supply chain security de IA se integra con el AI Governance Framework establecido en la Fase 7 del proyecto. Las métricas de supply chain security son KPIs del AI Governance Committee y complementan el scorecard de red teaming de la Fase 13.

MÉTRICA	FÓRMULA	TARGET	FUENTE
Cobertura de AIBOM	# sistemas de IA con AIBOM actualizado en los últimos 90 días / total sistemas IA en producción × 100	>90% cobertura. 100% para sistemas de alto riesgo.	Azure AI Foundry registry + SBOM pipeline CI/CD.
Shadow AI Incidents	# herramientas de IA no aprobadas detectadas (nuevas por mes). Trend: ¿descendente o ascendente?	Tendencia descendente. <5 nuevas detecciones/mes indica que el programa de awareness está funcionando.	Defender for Cloud Apps discovery. DLP alerts.
API Key Hygiene Score	# API keys en repos de código / total API keys × 100 (inverso). O: % de API keys con menos de 90 días de edad.	0 API keys en repos de código. 100% de API keys con rotación activa. 0 API keys sin expiración configurada.	GitHub Secret Scanning. Azure Key Vault audit logs.
Model Verification Rate	# modelos en producción que pasaron por el proceso de verificación (Guardian/ClamAV + hash + registry) / total modelos × 100	>95%. El 5% residual debe estar documentado con justificación (modelos propios de Microsoft que no requieren verificación externa).	Azure AI Model Catalog. Registro de aprobaciones.
MCP Server Compliance	# MCP servers en uso de la lista blanca aprobada / total MCP servers detectados en el entorno × 100	>95%. Cualquier MCP server fuera de la lista debe generar alerta inmediata.	Inventario de MCP servers (GitHub Copilot logs, Claude Code logs, VSCode extension audit).
Time to Detect LLMjacking	Tiempo desde que comienza el uso anómalo de una API key hasta que se detecta la anomalía	<24 horas para detección automática vía billing alert. <1 hora para consumo masivo (>10x baseline).	Azure Monitor billing alerts. Azure OpenAI usage dashboard.
Connector/Plugin Security Reviews	# plugins y conectores nuevos aprobados que pasaron por el proceso de security review / total nuevos × 100	100%. Ningún plugin/conector se activa sin review de seguridad.	Registro de aprobaciones del AI Governance Committee.

🔗 Integración con fases anteriores del proyecto: Supply Chain Security (F14) + Red Teaming (F13) + Gobernanza Post-Implementación (F7) + ROI/TCO (F9) forman el ciclo completo de seguridad operacional de IA: F7 establece el framework de gobernanza; F9 justifica financieramente las inversiones; F13 testa los sistemas desplegados; F14 asegura que lo que entra al ecosistema es confiable antes de que llegue al testing. Es un ciclo, no una secuencia.

14.9 REFERENCIAS (R361–R390)

AI Bill of Materials (AIBOM) y Estándares:

R361. Manifest Cyber, 'AI Bill of Materials (AIBOM): Transparency for AI Supply Chains', 2025. AIBOM como artefacto vivo operacional (no documento estático). Componentes: datasets, modelos, dependencias, entornos de deployment. Frameworks aplicables: EU AI Act, NIST AI RMF, DoD AI security directives. manifestcyber.com/aibom.

R362. Mend.io, 'Creating an AI Bill of Materials (AI BOM) for Secure GenAI', octubre 2025. Componentes AIBOM: model metadata (arquitectura, versioning, provenance), training datasets, software dependencies, deployment environment. Beneficios: data leakage prevention, adversarial risk detection, model tampering visibility.

R363. Noma Security, 'Securing AI Systems Through Transparency: The Critical Role of AI Bill of Materials (AIBOM)', julio 2025. La rápida integración de IA ha superado el desarrollo de frameworks de governance. AIBOM: estándar en evolución basado en CycloneDX MLBOM extension y SPDX v3.0 AI profile. noma.security.

R364. Palo Alto Networks, 'What Is an AI-BOM (AI Bill of Materials)?', 2025. McKinsey 2025: 88% de organizaciones usan IA regularmente en al menos una función de negocio (vs. 78% año anterior). EU AI Act GPAI obligations: transparencia obligatoria sobre datos de entrenamiento. paloaltonetworks.com/cyberpedia.

R365. SD Times, 'From SBOM to AI BOM: Rethinking supply chain security for AI native software', enero 2026. EU AI Act GPAI obligations (agosto 2025): reguladores pueden solicitar provenance audits, las reclamaciones de trade secret no serán suficientes. Wiz: 25% de organizaciones no saben qué servicios de IA o datasets tienen activos. sdtimes.com.

R366. Diginomica, 'How an AI Bill of Materials could build trust in enterprise AI', diciembre 2025. CycloneDX v1.5: Machine Learning BOM. SPDX v3.0: AI profile. AIBOMs se convertirán en estándar para AI-focused security. Desafío: AI systems son dinámicos, requieren lifecycle tracking continuo.

R367. Sonatype, 'How AI Governance Reduces Risk in Software Supply Chain Security', diciembre 2025. AIBOM como prerequisito de compliance. Automatización esencial: CI/CD integration para AIBOM generation. Sin automatización, los registros quedan obsoletos rápidamente.

R368. OWASP CycloneDX Project. CycloneDX v1.5 Machine Learning BOM specification. OWASP AIBOM project: guidance para AI transparency, auditability, accountability. cyclonedx.org.

R369. SPDX v3.0 AI Profile. Linux Foundation. AI profile fields: autonomy type, safety risk assessment, data preprocessing steps. Interoperable con CycloneDX. spdx.dev.

Riesgos de Modelos Open Source y Hugging Face:

R370. Protect AI + Hugging Face, '4M Models Scanned: 6 Months In', abril 2025. 4.47 millones de versiones únicas escaneadas. 352,000 problemas de seguridad en 51,700 modelos. Módulos de detección: PAIT-ARV-100 (archive slip), PAIT-JOBLIB-101 (Joblib code execution), PAIT-TF-200 (TensorFlow architectural backdoor), PAIT-LMAFL-300 (Llamafile malicious code). CVE-2025-1550 en Keras. huggingface.co/blog/pai-6-month.

R371. ReversingLabs, 'Malicious ML Models on Hugging Face Platform', febrero 2025. Técnica 'NullifAI': payload al inicio del stream Pickle evade Picklescan. Modelos en PyTorch format (Pickle comprimido) usando 7z en lugar de ZIP para evadir el scanner. Hugging Face tags 'No issue' en modelos maliciosos. reversinglabs.com.

R372. Dark Reading, 'Open Source AI Models: Big Risks for Malicious Code, Vulnerabilities', febrero 2025. La apertura del ecosistema facilita la publicación de modelos maliciosos. Empresas no deben depender de las medidas de seguridad de repositorios públicos para su propia seguridad. darkreading.com.

R373. Trend Micro, 'Exploiting Trust in Open-Source AI: The Hidden Supply Chain Risk No One Is Watching', 2025. JFrog: 400 modelos con código malicioso de un millón analizado. Backdoored models: triggers estadísticos, prácticamente invisibles a análisis estático. Real-world incidents: Hugging Face (tokens expuestos, Wiz Research 2023), model poisoning vía unvetted training pipelines. trendmicro.com.

R374. Palo Alto Networks Unit 42, 'Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust', septiembre 2025. Caso DentalAI/toothfAIry: namespace reclamado por actor malicioso. Alcanza a usuarios de Azure AI Foundry Model Catalog y Vertex AI que consumen modelos de Hugging Face. unit42.paloaltonetworks.com.

R375. Infosecurity Magazine, 'Malicious AI Models on Hugging Face Exploit Novel Attack Technique', febrero 2025. Pickle: serialización sin capacidad de seguridad por diseño. Picklescan: blacklist-based, no escalable. Alternativa: Safetensors (EleutherAI). infosecurity-magazine.com.

R376. Cisco Foundation AI, 'Cisco Foundation AI Advances AI Supply Chain Security with Hugging Face', agosto 2025. ClamAV 1.5: detección de malware en .pt y .pkl (milliseconds). Cerberus: inspección 24/7 en tiempo real. Cisco Secure Access: configuración de acceso granular a Hugging Face basada en riesgo. blogs.cisco.com.

Shadow AI:

R377. CSO Online, 'Top 5 real-world AI security threats revealed in 2025', diciembre 2025. Survey 2,000 empleados EE.UU. + UK: 49% usa herramientas de IA no aprobadas por el empleador. Más de la mitad no entiende cómo sus inputs son almacenados y analizados. Samsung incident (código propietario en ChatGPT). JPMorgan, Goldman Sachs restricciones ChatGPT. csoonline.com.

R378. LayerX, 'Enterprise AI Usage Report 2025'. 77% de empleados enterprise que usa IA ha pegado datos corporativos en un chatbot. 22% de esas instancias incluían datos confidenciales personales o financieros.

R379. Reco AI, 'AI & Cloud Security Breaches: 2025 Year in Review', diciembre 2025. Shadow AI breaches: promedio USD 670,000 más caro que incidentes tradicionales. Tiempo promedio de detección: 247 días (vs. 241 para incidentes tradicionales). Afectan PII de clientes (65%) e IP (40%). 97% de organizaciones con AI-related breaches carecían de controles básicos de acceso. reco.ai.

R380. Netwrix, '12 Critical Shadow AI Security Risks Your Organization Needs to Monitor in 2026', febrero 2026. Netwrix Cybersecurity Trends Report 2025: 37% de organizaciones ajustaron estrategias de seguridad por amenazas de IA. MCP servers y LangChain tools como nuevo vector de Shadow AI. netwrix.com.

R381. Sombrainc, 'LLM Security Risks in 2026: Prompt Injection, RAG, and Shadow AI', enero 2026. Samsung incident: ingenieros pegaron código propietario en ChatGPT para debug. Wall Street restrictions. ServiceNow second-order prompt injection entre agentes. sombrainc.com.

MCP Server Security:

R382. Wiz, 'MCP and LLM Security Research Briefing', abril 2025. 20,000+ MCP servers públicos. Local MCP server = ejecutar código arbitrario. Supply chain risk: builders independientes sin estándares de desarrollo seguro. Sin pinning, signing, o package locking en la especificación actual. wiz.io/blog.

R383. Astrix Security, 'State of MCP Server Security 2025: Research Report', 2025. 20,000 implementaciones analizadas en GitHub. 88% requieren credenciales. 53% usan static API keys o PATs. Solo 8.5% OAuth. 79% de API keys via environment variables. MCP Secret Wrapper (open source): alternativa a credenciales estáticas. astrix.security.

R384. Fortune, 'AI coding tools exploded in 2025. The first security exploits show what could go wrong', diciembre 2025. CrowdStrike: LangFlow AI explotado para deployment de malware. Prompt injection en herramientas de AI coding: Cursor, GitHub Copilot, Google Gemini. MCP como vector de prompt injection. fortune.com.

R385. CSO Online, 'OpenClaw integrates VirusTotal malware scanning', febrero 2026. OpenClaw: 150,000 GitHub stars, primer AI agent security crisis de 2026. 21,000 instancias expuestas. Gartner: 'inaceptable cybersecurity liability'. ClawHavoc: exploits en el skills marketplace. csoonline.com.

LLMjacking y Credenciales de IA:

R386. CSO Online, 'Top 5 real-world AI security threats revealed in 2025 — LLMjacking section', diciembre 2025. LLMjacking: robo de credenciales API de LLMs para acceder en nombre de la organización víctima. Microsoft demanda civil contra grupo especializado en LLMjacking. Costos estimados: >USD 100,000/día con modelos frontier. csoonline.com.

R387. Wiz Research, 'Leaking AI Secrets in Public Code', junio 2025. Escaneo de repositorios públicos: AI-related secret leaks masivos. Jupyter notebooks con API keys hardcodeadas son el vector más común. wiz.io.

R388. OpenSSF Blog / IDC / Canonical / Google Cloud, 'Securing AI: The Next Cybersecurity Battleground', agosto 2025. Survey enterprise practitioners: mayor desafío en AI security — falta de guías maduras para el ciclo de vida de IA (48.2% respondentes). openssf.org.

Frameworks de Supply Chain Security de IA:

R389. Hodeitek, 'CISO Playbook: AI Supply Chain Security Strategies, Risks, and Controls for 2025', noviembre 2025. AI supply chain = board-level issue. Extend SBOM to AIBOM (Model BOM): training data sources, preprocessing steps, libraries, model architectures, weight versions, known dependencies vulnerabilities. Third-party dataset due diligence: provenance, licensing, contractual clauses. hodeitek.com.

R390. Trend Micro, 'State of AI Security Report 1H 2025'. Redis vector database: use-after-free vulnerability explotable (Wiz Research). NVIDIA Container Toolkit: External Initialization of Trusted Variables. CoSAI (Coalition for Secure AI): model signing, machine readable model cards, incident response for AI, zero trust for AI, MCP security. trendmicro.com.