Durante os últimos anos, a seguridade das aplicacións tiña un límite claro: o repositorio e o pipelineAlí era onde se atopaban os controis, onde se executaban as análises, onde os equipos decidían se algo se enviaba a produción. Todo baseábase nunha suposición: un desenvolvedor elixía explicitamente que código e que dependencias entraban no sistema.
Esa suposición xa non se sostén. Unha parte crecente do código actual é escrito, suxerido ou instalado por un axente de IA, a miúdo sen que ninguén mire o nome do que se está a extraer. Cando o decisA medida que se move o elemento que entra no código, tamén o fai o ataque. Móvese á fronte do proceso: no momento en que se crea o código, dentro do propio asistente e nos ficheiros que o configuran.
Esta é a túa superficie de ataque da IA: cada modelo, axente, servidor MCP, habilidade e dependencia suxerida pola IA que agora pode introducir risco antes de que un humano o revise. A mesma IA na que confían os teus desenvolvedores agora forma parte dela. Este non é un risco futuro. É un cambio que xa ocorreu e así é como se ve na práctica.
Unha onda de ataques, non un incidente illado
Ningún dos seguintes é un exercicio de laboratoriocise ou unha hipótese. Trátase de incidentes públicos e documentados, case todos do ano pasado, e cada un deles achégase un pouco máis ao propio axente de IA:
- Agosto de 2025, singularidade: Uns atacantes roubaron un token de publicación de Nx, un dos sistemas de compilación máis empregados, e enviaron versións maliciosas a npm, empregando ferramentas de IA para buscar segredos nas máquinas dos desenvolvedores.
- Setembro de 2025, chalk/debug: Un dos maiores compromisos de npm en canto ao alcance, 18 paquetes con máis de dous mil millóns de descargas semanais, asumidos mediante o secuestro da conta dun único responsable do mantemento.
- Setembro de 2025, Shai-Hulud: un dos primeiros vermes documentados capaces de autopropagarse a través de npm. A súa segunda onda, en novembro, foi máis agresiva e estaba ligada a segredos expostos en máis de 25,000 repositorios.
- Outubro de 2025, importacións non utilizadas: parte da campaña PhantomRaven, onde a alucinación de IA introduciu malware real en npm mediante unha técnica de slopsquatting.
- Este ano, ClawHub: un rexistro de habilidades de IA envelenado onde cinco das sete habilidades máis descargadas eran software malicioso.
A industria está a formalizar a mesma conclusión. O OWASP Top 10 para aplicacións LLM sitúa a inxección rápida no primeiro posto. O OWASP MCP Top 10 (actualmente en fase beta) céntrase no protocolo que os axentes usan para comunicarse coas ferramentas. O OWASP Agentic Skills Top 10, un novo proxecto en fase de incubadora, sinala as habilidades maliciosas como o seu principal risco. OWASP adoita moverse con coidado; abrir tres frontes á vez, unha delas con urxencia, di algo sobre a rapidez coa que se está a mover isto.
Os tres converxen na mesma idea: as instrucións, as ferramentas e as configuracións arredor dun modelo agora forman parte da superficie de ataque da IA e adoitan estar dentro do teu propio repositorio. O que suscita a primeira pregunta que paga a pena facerlles aos teus equipos: quen revisa os ficheiros de regras, as habilidades e as configuracións de MCP que se atopan no teu repositorio?
Vector 1: a habilidade envelenada
Unha habilidade é un ficheiro de instrucións e capacidades que lle ensina a un axente de IA como realizar unha tarefa. Non é a única forma de dar forma ao comportamento dun axente (ficheiros de regras, hookse as configuracións de MCP fan o mesmo), pero todas comparten unha propiedade: viaxan dentro do repositorio co código.
A investigación deste ano revisou 4,000 destas habilidades:
- O 36 % tiña polo menos un fallo de seguridade.
- O 13.4 % eran críticos.
- Preto de 100 tiñan cargas útiles maliciosas directamente.
O cambio fundamental: o atacante xa non ten como obxectivo o teu código. Ten como obxectivo o axente que escribe o teu código, colocando instrucións ocultas (ás veces usando caracteres invisibles) que o modelo le e trata como operativas. Un revisor humano aproba o pull request de boa fe porque, aos seus ollos, o arquivo parece limpo. O modelo interpreta instrucións que o revisor nunca viu.
Isto non é teórico. A CVE-2025-59536 (CVSS 8.7) permitía iniciar Claude Code desde un repositorio non fiable, onde unha configuración maliciosa podía executar comandos antes de que o usuario aceptase o diálogo de confianza. Unha segunda vulnerabilidade, a CVE-2026-21852, permitía a exfiltración dunha clave API a través dunha configuración controlada polo proxecto, sen que o usuario aprobase nada.
H2: Vector 2: agachamento desprazado
O nome mestura "slop" (o lixo que ás veces xera unha IA) co clásico ataque de typosquatting. O typosquatting depende do erro humano: un atacante rexistra un nome de paquete semellante a un popular e agarda un erro tipográfico. É aleatorio.
Agachamentos inclinados non agarda a que haxa un erro. No estudo ao que se fai referencia durante esta sesión, O 19.7 % das referencias de paquetes xeradas polos modelos de IA apuntaban a paquetes que non existen. Os modelos tenden a alucinar os mesmos nomes repetidamente, polo que un atacante observa que nomes inventa a IA, rexistra eses nomes con código malicioso e agarda a que a seguinte instalación suxerida pola IA a introduza na túa aplicación.
A escala non é pequena: Identificáronse máis de 450,000 novos paquetes maliciosos en 2025. Dous exemplos o fan concreto:
- Un investigador colocou un paquete de probas inofensivo chamado abrazacara-cli para demostrar o punto. Rexistrou máis de 30,000 descargas en tres meses.
- importacións non utilizadas, da liña de tempo anterior, confirmouse que había software malicioso, nun rexistro público, usando exactamente esta técnica. Esa non era unha proba.
A cuestión non é se isto lle pode pasar ao teu equipo. É cantos paquetes suxeridos pola IA están a introducir o teu código hoxe en día sen que ninguén os mire.
A resposta: standardestán poñendose ao día
Dúas forzas corren en paralelo. Mentres os ataques se aceleran, standardos corpos están reaccionando:
- NIST SP 800-218A amplía o marco de desenvolvemento de software seguro con prácticas específicas para modelos de IA, incluíndo probas de integridade e procedencia.
- In 2026, CISA e os seus socios internacionais do G7 publicou unha guía sobre unha lista de materiais de software para IA, na que se define o que pertence a ese inventario: modelos, conxuntos de datos, compoñentes, provedores e dependencias.
A dirección é clara: o SBOM está a expandirse a unha IA-BOM. Non podes certificar nin dar fe do que non podes inventariar. E hoxe en día, a maioría das organizacións non poden:
- 43% non poden auditar nin inventariar as ferramentas de IA que xa están a usar.
- 79% non teñen visibilidade dos axentes de IA e dos sistemas MCP que se executan no seu propio entorno.
En contornas reguladas, este inventario está a pasar de ser unha boa práctica a unha expectativa contractual ou unha obriga de cumprimento. Pero un inventario só indica o que se ten. Por si só, non bloquea un ataque.
A brecha: un EDR para AppSec
SAST SCA As ferramentas están deseñadas para analizar código e dependencias, non o comportamento dun axente nin a súa configuración. Un EDR ve procesos e conexións de rede, pero normalmente carece do contexto de seguridade da aplicación para interpretar unha dependencia ou unha configuración de axente. Entre estas dúas categorías de ferramentas atópase unha brecha, exactamente onde se crea o código agora e exactamente onde reside a superficie de ataque da IA.
Esa brecha ten tres puntos cegos:
- Activos de IA. Os modelos, axentes e servidores MCP non aparecen na túa SASTé ou SCARadar de . Non podes inventariar o que non podes ver.
- Ficheiros de configuración. As habilidades, as regras e as configuracións de MCP configuran o comportamento do axente, pero normalmente revísanse coma se fosen texto sen formato inofensivo.
- Instalacións de paquetes. A Unha dependencia maliciosa pode executarse antes de que se saiba que é maliciosae, a continuación, exfiltrar segredos e tokens sen que ninguén o aprobe.
Como o pecha Xygeni
Que fai un EDR polos puntos finais, Xíxeno Shield fai polo ciclo de vida do desenvolvemento asistido por IA: protexe onde se crea o código e, ao mesmo tempo, comprende o contexto de seguridade da aplicación.
- Visibilidade onde SAST SCA non chegues. Xygeni sinala ficheiros de habilidades e regras maliciosas, analiza as configuracións de MCP e crea un sistema listo para auditorías. IA-BOM, mapeado ás 10 mellores habilidades de OWASP LLM, MCP e Agentic Skills.
- Intelixencia, non só sinaturas. MEW (Alerta anticipada de malware) analiza o comportamento e o risco dun paquete para bloquealo antes de que exista un CVE, un aviso ou unha sinatura pública. A intelixencia de rede actualizada corta as conexións coa infraestrutura maliciosa coñecida.
- Un punto de control, dende o código ata o punto final. Un único axente, despregado sen rearquitecturar o entorno, con soberanía de datos europea e evidencia de cumprimento integradas.
Nunha demostración en directo, a aplicación desta política bloqueou o intento dun axente de IA de instalar un paquete malicioso en tres rutas de instalación diferentes (ambiente virtual, xestor de paquetes e descarga directa) antes de que se completase a instalación, todo rexistrado en tempo real e exportable a un SOC. A incorporación dun primeiro proxecto adoita levar aproximadamente unha hora; a ampliación da cobertura a toda unha organización adoita levar dunha a dúas semanas, dependendo da estrutura.
FAQ
Cal é a superficie de ataque da IA nun parágrafo?
A superficie de ataque da IA é o conxunto de modelos, axentes, servidores MCP, habilidades, ficheiros de regras e dependencias suxeridas pola IA a través dos cales o risco pode entrar nunha aplicación, a miúdo antes de que un humano o revise. Vai máis alá do código e as dependencias tradicionais para incluír os ficheiros de configuración e as instrucións que configuran o comportamento dun axente de IA.
Como podo saber se un nome de paquete suxerido polo meu asistente de IA é unha alucinación ou simplemente lexítimo pero descoñecido?
Validar antes da instalación: comproba o rexistro e analiza o contido e a intención reais do paquete en lugar de confiar só no nome. Xygeni automatiza esta validación en tempo real durante a xeración de código, polo que unha instalación se aproba ou se bloquea antes de executarse, independentemente de que o paquete sexa ou non un que recoñezas.
Afecta a slopsquatting a todos os modelos de IA por igual?
A investigación que xustifica a cifra do 19.7 % abarcou varios modelos e descubriu que o problema estaba amplamente distribuído, con só unha pequena variación entre eles. Este é un patrón no desenvolvemento asistido por IA, non un defecto específico dun asistente.
Podemos comprobar retroactivamente se xa instalamos un paquete alucinado ou malicioso?
Si. A plataforma de Xygeni ofrece aos clientes acceso a unha base de datos mantida cos paquetes maliciosos detectados, que se poden consultar no inventario de compoñentes existente, para que poidan confirmar con só uns clics se algo xa instalado é unha ameaza coñecida.
Canto tempo leva a implementación para unha organización mediana con varios equipos?
A incorporación dun primeiro proxecto adoita levar arredor dunha hora. A ampliación a toda unha organización adoita levar dunha a dúas semanas, dependendo da estrutura do equipo e das formas de traballar.
Mapea a túa superficie de ataque de IA, de balde
Mapea a pegada de IA da túa aplicación de balde: crea unha conta e executar unha primeira análise en minutosComeza cunha única aplicación, observa que IA hai no seu interior e descubre que parte da túa superficie de ataque de IA é perigosa.
*Algunhas das funcionalidades mencionadas anteriormente aplícanse mediante Xygeni Shield e ASPMMódulos de seguridade de IA; a dispoñibilidade pode variar segundo o plan. Consulta xygeni.io para obter detalles actuais do produto.
