Durant els darrers anys, la seguretat de les aplicacions tenia un límit clar: el repositori i el pipelineAllà era on es trobaven els controls, on s'executaven els escanejos, on els equips decidien si alguna cosa s'enviava a producció. Tot es basava en una suposició: un desenvolupador triava explícitament quin codi i quines dependències entraven al sistema.
Aquesta suposició ja no es compleix. Una part creixent del codi actual l'escriu, suggereix o instal·la un agent d'IA, sovint sense que ningú miri el nom del que s'està extreient. Quan el decisA mesura que es mou el que entra al codi, també ho fa l'atac. Es mou a la part més frontal del procés: en el moment en què es crea el codi, dins del mateix assistent i als fitxers que el configuren.
Aquesta és la vostra superfície d'atac de la IA: tots els models, agents, servidors MCP, habilitats i dependències suggerides per la IA que ara poden introduir riscos abans que un humà els revisi. La mateixa IA en què confien els vostres desenvolupadors ara en forma part. Això no és un risc futur. És un canvi que ja ha ocorregut, i així és com es veu a la pràctica.
Una onada d'atacs, no un incident aïllat
Cap dels següents és un exercici de laboratoricise o una hipòtesi. Són incidents públics i documentats, gairebé tots de l'any passat, i cadascun d'ells s'acosta una mica més a l'agent d'IA en si:
- Agost de 2025, singularitat: Uns atacants van robar un token de publicació de Nx, un dels sistemes de compilació més utilitzats, i van enviar versions malicioses a npm, utilitzant eines d'IA per buscar secrets a les màquines dels desenvolupadors.
- Setembre de 2025, chalk/debug: un dels compromisos més grans de npm pel que fa a l'abast, 18 paquets amb més de dos mil milions de descàrregues setmanals, adquirits mitjançant el segrest del compte d'un únic mantenidor.
- Setembre de 2025, Shai-Hulud: un dels primers cucs documentats capaços d'autopropagar-se via npm. La seva segona onada, al novembre, va ser més agressiva i estava lligada a secrets exposats en més de 25,000 repositoris.
- Octubre de 2025, importacions no utilitzades: part de la campanya PhantomRaven, on les al·lucinacions de la IA van introduir programari maliciós real a npm mitjançant una tècnica de slopsquatting.
- Aquest any, ClawHub: un registre d'habilitats d'IA enverinat on cinc de les set habilitats més descarregades eren programari maliciós.
La indústria està formalitzant la mateixa conclusió. L'OWASP Top 10 per a aplicacions LLM situa la injecció ràpida al primer lloc. L'OWASP MCP Top 10 (actualment en versió beta) se centra en el protocol que utilitzen els agents per comunicar-se amb les eines. L'OWASP Agentic Skills Top 10, un nou projecte en fase d'incubadora, assenyala les habilitats malicioses com el seu principal risc. L'OWASP sol moure's amb cura; obrir tres fronts alhora, un d'ells urgentment, diu alguna cosa sobre la rapidesa amb què avança això.
Totes tres convergeixen en la mateixa idea: les instruccions, les eines i les configuracions al voltant d'un model ara formen part de la superfície d'atac de la IA i normalment resideixen dins del vostre propi repositori. Això planteja la primera pregunta que val la pena fer als vostres equips: qui revisa els fitxers de regles, les habilitats i les configuracions de MCP que resideixen al vostre repositori?
Vector 1: l'habilitat enverinada
Una habilitat és un fitxer d'instruccions i capacitats que ensenya a un agent d'IA com realitzar una tasca. No és l'única manera de modelar el comportament d'un agent (fitxers de regles, hooks, i les configuracions MCP fan el mateix), però totes comparteixen una propietat: viatgen dins del repositori, amb el codi.
La investigació d'aquest any ha revisat 4,000 d'aquestes habilitats:
- El 36% tenia almenys una falla de seguretat.
- El 13.4% eren crítics.
- Prop de 100 tenien càrregues útils malicioses directament.
El canvi central: l'atacant ja no té com a objectiu el vostre codi. Ataca l'agent que escriu el vostre codi, plantant instruccions ocultes (de vegades utilitzant caràcters invisibles) que el model llegeix i tracta com a operatives. Un revisor humà aprova el pull request de bona fe perquè, als seus ulls, l'arxiu sembla net. El model interpreta instruccions que el revisor no va veure mai.
Això no és teòric. La CVE-2025-59536 (CVSS 8.7) permetia iniciar Claude Code des d'un repositori no fiable, on una configuració maliciosa podia executar ordres abans que l'usuari acceptés el diàleg de confiança. Una segona vulnerabilitat, la CVE-2026-21852, permetia l'exfiltració d'una clau API a través d'una configuració controlada pel projecte, sense que l'usuari aprovés res.
H2: Vector 2: slopsquatting
El nom barreja "slop" (la brossa que de vegades genera una IA) amb el clàssic atac de typosquatting. El typosquatting depèn de l'error humà: un atacant registra un nom de paquet proper a un de popular i espera una errada tipogràfica. És aleatori.
Agafades inclinades no espera un error. A l'estudi al qual es fa referència durant aquesta sessió, El 19.7% de les referències de paquets generades pels models d'IA apuntaven a paquets que no existeixen. Els models tendeixen a al·lucinar els mateixos noms repetidament, de manera que un atacant observa quins noms inventa la IA, registra aquests noms amb codi maliciós i espera que la següent instal·lació suggerida per la IA l'incorpori a l'aplicació.
L'escala no és petita: El 2025 es van identificar més de 450,000 nous paquets maliciosos. Dos exemples ho concreten:
- Un investigador va plantar un paquet de prova inofensiu anomenat huggingface-cli per demostrar el punt. Es va registrar més de 30,000 descàrregues en tres mesos.
- importacions no utilitzades, de la cronologia anterior, es va confirmar que hi havia programari maliciós, en un registre públic, utilitzant exactament aquesta tècnica. Aquella no era una prova.
La pregunta no és si això li pot passar al vostre equip. Sinó quants paquets suggerits per IA estan introduint el vostre codi avui sense que ningú els miri.
La resposta: standards'estan posant al dia
Dues forces corren en paral·lel. Mentre els atacs s'acceleren, standardels cossos estan reaccionant:
- NIST SP 800-218A estén el marc de desenvolupament de programari segur amb pràctiques específiques per a models d'IA, incloent-hi proves d'integritat i procedència.
- In Maig 2026, CISA i els seus socis internacionals del G7 va publicar una guia sobre una llista de materials de programari per a IA, que defineix què pertany a aquest inventari: models, conjunts de dades, components, proveïdors i dependències.
La direcció és clara: la SBOM s'està expandint cap a una IA-BOM. No es pot certificar ni donar fe del que no es pot inventariar. I avui dia, la majoria d'organitzacions no poden:
- 43% no poden auditar ni inventariar les eines d'IA que ja utilitzen.
- 79% no tenen visibilitat dels agents d'IA i els sistemes MCP que s'executen en el seu propi entorn.
En entorns regulats, aquest inventari està passant de les bones pràctiques a les expectatives contractuals o a l'obligació de compliment. Però un inventari només indica el que es té. Per si sol, no bloqueja un atac.
La bretxa: un EDR per a AppSec
SAST i SCA Les eines estan dissenyades per analitzar codi i dependències, no el comportament d'un agent o la seva configuració. Un EDR veu processos i connexions de xarxa, però normalment no té el context de seguretat de l'aplicació per interpretar una dependència o una configuració d'agent. Entre aquestes dues categories d'eines hi ha una bretxa, exactament on es crea el codi ara i exactament on es troba la superfície d'atac de la IA.
Aquesta bretxa té tres punts cecs:
- Actius d'IA. Els models, agents i servidors MCP no apareixen a la teva SASTés o SCAEl radar de . No pots inventariar allò que no pots veure.
- Fitxers de configuració. Les habilitats, les regles i les configuracions de MCP influeixen en el comportament dels agents, però normalment es revisen com si fossin text pla inofensiu.
- Instal·lacions de paquets. A una dependència maliciosa es pot executar abans que se sàpiga que és maliciosa, i després exfiltrar secrets i tokens sense que ningú ho aprovi.
Com ho tanca Xygeni
Què fa un EDR pels punts finals, Xígeni Shield fa el cicle de vida del desenvolupament assistit per IA: protegeix on es crea el codi i alhora entén el context de seguretat de l'aplicació.
- Visibilitat on SAST i SCA no arribis. Xygeni marca fitxers d'habilitats i regles malicioses, analitza les configuracions de MCP i crea un sistema llest per a auditories. IA-BOM, correlacionat amb els 10 millors programes de màster en LLM, MCP i Agentic Skills d'OWASP.
- Intel·ligència, no només signatures. MEW (Alerta Precoç de Malware) analitza el comportament i el risc d'un paquet per bloquejar-lo abans que existeixi un CVE, un avís o una signatura pública. La intel·ligència de xarxa actualitzada talla les connexions a la infraestructura coneguda com a maliciosa.
- Un punt de control, des del codi fins al punt final. Un agent únic, desplegat sense reestructurar l'entorn, amb sobirania de dades europea i evidència de compliment integrada.
En una demostració en directe, aquesta aplicació de polítiques va bloquejar l'intent d'un agent d'IA d'instal·lar un paquet maliciós a través de tres rutes d'instal·lació diferents (entorn virtual, gestor de paquets i descàrrega directa) abans que es completés la instal·lació, tot registrat en temps real i exportable a un SOC. La incorporació d'un primer projecte sol trigar aproximadament una hora; l'ampliació de la cobertura a tota una organització sol trigar d'una a dues setmanes, depenent de l'estructura.
FAQ
Quina és la superfície d'atac de la IA en un paràgraf?
La superfície d'atac de la IA és el conjunt de models, agents, servidors MCP, habilitats, fitxers de regles i dependències suggerides per la IA a través dels quals el risc pot entrar a una aplicació, sovint abans que un humà el revisi. S'estén més enllà del codi i les dependències tradicionals per incloure els fitxers de configuració i les instruccions que configuren el comportament d'un agent d'IA.
Com puc saber si un nom de paquet suggerit pel meu assistent d'IA és una al·lucinació o simplement legítim però desconegut?
Valida abans d'instal·lar: comproveu el registre i analitzeu el contingut i la intenció reals del paquet en lloc de confiar només en el nom. Xygeni automatitza aquesta validació en temps real durant la generació de codi, de manera que una instal·lació s'aprova o es bloqueja abans d'executar-se, tant si el paquet és un que reconeixeu com si no.
L'slopsquatting afecta tots els models d'IA per igual?
La investigació que hi ha darrere de la xifra del 19.7% va abastar diversos models i va trobar que el problema estava àmpliament distribuït, amb només una petita variació entre ells. Aquest és un patró en el desenvolupament assistit per IA, no un defecte específic d'un assistent.
Podem comprovar retroactivament si ja hem instal·lat un paquet al·lucinat o maliciós?
Sí. La plataforma de Xygeni ofereix als clients accés a una base de dades mantinguda de paquets maliciosos detectats, que es pot cercar amb l'inventari de components existent, de manera que poden confirmar amb un parell de clics si alguna cosa ja instal·lada és una amenaça coneguda.
Quant de temps triga la implementació per a una organització mitjana amb diversos equips?
La incorporació d'un primer projecte sol trigar aproximadament una hora. L'escalat a tota una organització sol trigar d'una a dues setmanes, depenent de l'estructura de l'equip i les formes de treballar.
Mapeja la teva superfície d'atac d'IA, gratuïtament
Mapeu la petjada d'IA de la vostra aplicació gratuïtament: creeu un compte i executar una primera exploració en minutsComença amb una sola aplicació, observa quina IA hi ha a dins i quina part de la teva superfície d'atac d'IA és perillosa.
*Algunes de les capacitats esmentades anteriorment s'apliquen mitjançant Xygeni Shield i ASPM/Mòduls de seguretat d'IA; la disponibilitat pot variar segons el pla. Vegeu xygeni.io per obtenir detalls del producte actual.
