Un archivo de habilidades. Un archivo de reglas. Una configuración de servidor MCP. Tres líneas de texto plano, commitSe presentan como documentación, se revisan como documentación y ninguno parece código. Sin embargo, cada uno puede reescribir silenciosamente lo que se le indica a tu asistente de IA que haga y a qué tiene permitido acceder. Esa es la incómoda verdad detrás de la seguridad de la IA. en 2026Durante dos años, la industria se preocupó por el contenido del código generado por IA. El verdadero problema resultó ser la propia cadena de suministro de IA: los modelos, agentes, servidores MCP y archivos de configuración que ahora coexisten con el código fuente y las dependencias de código abierto, en gran medida sin inventariar ni revisar. Precisamente por eso, la seguridad de la cadena de suministro de IA se ha convertido en una disciplina propia, y por eso elegir la empresa de seguridad de IA adecuada es tan importante como elegir el escáner adecuado.
La superficie de ataque que nadie presupuestó
El software solía tener un puñado de lugares donde un atacante podía llegar: el código, las dependencias, el pipelineLa IA añadió dos más, y ambas se integran directamente en la cadena de suministro de IA.
La modelo y el agente. Manipulación de herramientas, inyección de comandos, autonomía del agente que va más allá de lo previsto. Una instrucción oculta en la descripción de un servidor MCP puede redirigir silenciosamente las acciones de un copiloto, sin que el desarrollador se dé cuenta.
El entorno propio del desarrollador. Entornos de desarrollo integrados (IDE), copilotos de IA, servidores MCP, interfaces de línea de comandos (CLI) de agentes. Invisibles para los escáneres de seguridad de aplicaciones heredados, que no saben qué es un modelo, e invisibles para EDR, que supervisa el sistema operativo y no tiene idea de qué es una dependencia o una llamada MCP.
Nada de esto es teórico. En los últimos dieciocho meses:
- Una vulnerabilidad oculta en el archivo de reglas Unicode permitía a los atacantes inyectar instrucciones invisibles en los archivos de configuración que leían Copilot y Cursor, creando así una puerta trasera silenciosa en el código generado por el asistente. GitHub añadió una advertencia al respecto en 2025.
- Una vulnerabilidad de inyección de comandos en un popular puente MCP (CVSS 9.6) afectó a más de 400,000 descargas antes de ser corregida, siendo el primer caso documentado de ejecución remota completa de código desencadenada simplemente por conectarse a un servidor MCP no confiable.
- Un gusano npm de propagación automática convirtió a los propios desarrolladores en el mecanismo de distribución, y el patrón se repitió a gran escala en los meses siguientes en otros ecosistemas, un ejemplo clásico de fallo de seguridad en la cadena de suministro de IA.
- Los investigadores descubrieron que una parte importante de los paquetes que recomiendan los modelos LLM no existen en absoluto; se trata de nombres "apropiados indebidamente" que un atacante registra antes de que un desarrollador real le pida al modelo que los importe.
La propia investigación de Google sobre la seguridad de la cadena de suministro de software de IA llega a una conclusión similar desde una perspectiva diferente: los modelos que circulaban en 2023 y 2024 parecían legítimos, pero contenían código que podía extraer datos o instalar una puerta trasera una vez descargado. La solución no radicaba tanto en una nueva categoría de herramienta, sino en aplicar disciplina a la cadena de suministro, como la procedencia y la firma digital, a elementos que nadie había rastreado hasta entonces. En resumen, el problema de seguridad de la cadena de suministro de IA es el siguiente: los elementos son nuevos, pero la disciplina que requieren no lo es.
Por qué sus herramientas actuales se quedan cortas
SAST lee código. SCA Se lee un manifiesto de dependencias. Ninguno sabe qué es un modelo, qué expone un servidor MCP ni qué instrucciones le da un archivo de habilidades a un agente. Esa brecha es precisamente donde aterrizan los ataques de la era de la IA, en el espacio entre el "código que analizamos" y la "IA que adoptamos silenciosamente".
El resultado es una categoría de IA en la sombra no CISActualmente, O puede responder a preguntas como: ¿qué modelos estamos ejecutando?, ¿qué agentes pueden acceder a qué?, y ¿a qué servidor MCP se conectó alguien el martes pasado sin avisar a nadie? Responder correctamente a esta pregunta es la función de la seguridad de la cadena de suministro de IA, y es la razón por la que las herramientas genéricas de seguridad de aplicaciones siguen siendo insuficientes en este aspecto.
Qué significa realmente la seguridad de la IA
xygeni es la empresa de seguridad de IA que trata esto como tres movimientos conectados a través de la SDLC: descubrir, detectar y hacer cumplir.
Descubre: conoce la IA que realmente tienes
El descubrimiento continuo y automático en sus repositorios muestra todos los activos de IA: modelos, marcos, conjuntos de datos, puntos finales de inferencia, agentes, servidores MCP, habilidades, indicaciones, guardrailsy las herramientas de codificación de IA que sus desarrolladores realmente utilizan. Sin encuestas. Sin autoinformes. Si dejó un rastro en un repositorio, aparece en el inventario, el primer y más básico requisito para una verdadera seguridad en la cadena de suministro de IA.
El gráfico de IA muestra cómo se conectan esos activos: qué modelo alimenta un conjunto de datos, qué agente invoca qué herramienta, qué servidor MCP se encuentra detrás de qué asistente. Un activo aislado no aporta mucha información. El gráfico muestra dónde se concentra el riesgo.
A partir de ese mismo descubrimiento, Xygeni genera un AI-BOMUn inventario legible por máquina y listo para auditorías de todo lo relacionado con la IA en su software. Cuando un regulador, un auditor o un cliente pregunte qué IA está utilizando, la respuesta se convierte en una descarga en lugar de una tarea frenética de tres semanas.
Detectar: los riesgos que los escáneres convencionales no pueden ver.
Un escáner de IA dedicado busca los modos de falla que son específicos de los sistemas de IA: inyección de indicaciones, inyección de herramientas e invocación de herramientas no confiables, fuga de datos a través de la recuperación, omisión de indicaciones del sistema, agencia excesiva. Cada hallazgo se corresponde con el Los 10 mejores candidatos para el Máster en Derecho de OWASP y señala el archivo y la línea exactos que generan la exposición, no una alerta vaga del tipo "revise su uso de IA".
La misma capa de detección trata los archivos de habilidades, los archivos de reglas y las configuraciones de MCP como los artefactos de seguridad que son, no como documentación inofensiva. Marca las habilidades maliciosas o infectadas, inspecciona las configuraciones del servidor MCP en busca de manipulación de herramientas y muestra las indicaciones que realmente impulsan las cargas de trabajo de IA.
Priorizar: el embudo que elimina el ruido, no los atajos.
Cada hallazgo se filtra progresivamente: primero, lo que es accesible en el código de la aplicación; luego, lo que es realmente explotable; y finalmente, lo que se encuentra en el código que tu equipo está desarrollando activamente. Lo que llega a la cola de un desarrollador es la lista reducida que realmente amenaza la producción, con la referencia del framework, el período de exposición y las recomendaciones para mitigar el riesgo.
Aplicar: deténgalo antes de que se ejecute.
Shield Lleva la aplicación de políticas al propio punto final del desarrollador: bloquea las instalaciones no autorizadas y maliciosas, los modelos no aprobados y los servidores MCP no sancionados antes de que se ejecute nada. Debajo se encuentra Xygeni. Alerta temprana de malware (MEW), que detecta paquetes maliciosos antes de que exista una firma, la capa en la que las herramientas basadas en reputación aún confían porque nadie ha informado del paquete todavía. Es la mitad de la aplicación de la seguridad de la cadena de suministro de IA: el descubrimiento y la detección te dicen qué está mal, Shield Eso es lo que realmente lo detiene.
Tu exposición a la IA no se limita solo a tu código de IA.
Para obtener una visión completa de la seguridad de la cadena de suministro basada en IA se necesita algo más que un inventario modelo, y rara vez se trata solo de lo más llamativo:
- credenciales de proveedor de IA dejados en archivos de solicitud, configuraciones de agente o pipeline Los registros son Secretos como cualquier otro, y la detección de Secretos de Xygeni los intercepta antes de que lleguen a un registro público.
- Dependencias vulnerables de IA y ML Contienen vulnerabilidades CVE comunes, detectadas mediante el mismo análisis de composición de software que ya cubre el resto de la pila tecnológica. Investigaciones independientes sobre la adopción de la IA han puesto de manifiesto la gran cantidad de paquetes externos y componentes ocultos que componen la pila tecnológica moderna de IA, precisamente la superficie que el análisis de composición de software se diseñó para cubrir.
- Paquetes maliciosos publicado más rápido que cualquier aviso pipeline pueden catalogarlos, se capturan antes de la firma, la misma capacidad MEW protege al resto de su cadena de suministro.
La capa de agentes: DevAI y CoreAI
El descubrimiento y la detección abarcan lo que ya se encuentra en sus repositorios. DevAI Funciona donde se origina el riesgo: dentro del IDE, como una capa continua y proactiva que analiza el código generado por humanos e IA a medida que se escribe, sin necesidad de indicaciones. Explica la ruta completa de explotación detrás de un hallazgo y propone soluciones validadas por MCP que el desarrollador puede aplicar con confianza, sin interrumpir la compilación.
CoreAI se sitúa por encima de los escáneres individuales como la capa de inteligencia: correlaciona el código, la dependencia, pipeliney posiciona los datos en un modelo de riesgo único, responde preguntas en lenguaje natural y genera los informes listos para la dirección que un líder de seguridad necesita para demostrar que la gobernanza realmente se está llevando a cabo, y no solo se está afirmando.
Amplía lo que tienes en Seguridad de IA. No elimines nada.
La objeción más común a una nueva categoría de seguridad es "ya tenemos suficientes herramientas". Como empresa de seguridad de IA, Xygeni no le pide que reemplace nada: el mismo triaje, explicación y priorización que se aplica a sus propios hallazgos se aplica igualmente a los hallazgos de sus herramientas existentes. SAST, SCAy escáneres de terceros. Su infraestructura actual se convierte en un insumo, no en una víctima, y la seguridad de su cadena de suministro de IA mejora sin necesidad de un proyecto de reemplazo total.
Por qué esto importa ahora y no después
Los reguladores coinciden en la misma expectativa, aunque desde distintas perspectivas: la Ley de IA de la UE, la NIS2 y la ENS española impulsan la creación de inventarios y la trazabilidad de los sistemas de IA, la misma evidencia que se supone que debe generar una lista de materiales para IA. La tendencia es clara, incluso cuando los mecanismos exactos de cumplimiento aún se están definiendo: no se puede certificar una IA que nunca se ha inventariado, ni se puede garantizar la seguridad de la cadena de suministro de IA si la propia cadena de suministro es invisible.
Cómo elegir una empresa de seguridad de IA
No todas las empresas de seguridad de IA definen sus límites de la misma manera. Algunas se limitan a analizar el código generado por la IA. Otras se centran en el punto final. La seguridad de la cadena de suministro de IA es un tema mucho más complejo que cualquiera de estas partes por separado: abarca el modelo, el agente, el servidor MCP, el archivo de habilidades y las dependencias subyacentes. Esta visión integral del ciclo de vida, desde el descubrimiento hasta la aplicación de la seguridad, integrada en una consola junto con el resto de los resultados de seguridad de la aplicación, es lo que se debe buscar al evaluar una empresa de seguridad de IA, en lugar de una herramienta aislada.
Los archivos que nadie revisaba se convirtieron en la puerta de entrada. La seguridad de la IA es la disciplina de revisarlos, y la seguridad de la cadena de suministro de la IA es lo que garantiza que esa disciplina se mantenga de principio a fin, en la misma plataforma donde ya se revisa todo lo demás.
Descubre qué es lo que tu IA tiene permitido hacer realmente. Empieza gratis or programa una demostración.
Preguntas Frecuentes
¿El código de Xygeni sale alguna vez de mi infraestructura?
No. Los escaneos se ejecutan dentro de su propio entorno y el código fuente nunca se carga en los servidores de Xygeni. El inventario de IA y la lista de materiales de IA (AI-BOM) se generan a partir de lo que el escáner detecta localmente, no de una copia enviada externamente.
¿Cuál es la diferencia entre AI Security, DevAI y CoreAI?
AI Security descubre y detecta: crea el inventario de IA, la lista de materiales de IA (AI-BOM), y encuentra riesgos como la inyección de código o archivos de habilidades manipulados. DevAI funciona dentro del IDE mientras los desarrolladores escriben código, proponiendo soluciones a medida que avanzan. CoreAI se sitúa por encima de ambos, correlacionando los hallazgos en toda la plataforma y respondiendo preguntas sobre su postura de seguridad en lenguaje natural.
¿Con qué marcos de seguridad de IA se alinea Xygeni?
Los hallazgos se corresponden con el Top 10 de OWASP para aplicaciones LLM, el Top 10 de OWASP para MCP y el Top 10 de OWASP para habilidades de agente, junto con NIST SP 800-218A y CISGuía A/G7 sobre listas de materiales para IA. Este mapeo es lo que permite utilizar la lista de materiales para IA como evidencia de cumplimiento, en lugar de simplemente como un inventario.
¿Esto marcará como riesgo a todas las bibliotecas o modelos de IA?
No. El embudo de priorización reduce los hallazgos a lo que es accesible en el código de la aplicación, realmente explotable y en desarrollo activo, por lo que la lista que ve un desarrollador es corta, no un volcado de todos los recursos de IA detectados.
