Los modelos de código alucinan nombres de paquetes inexistentes de forma predecible (19,7% del código, y el 43% de los nombres se repiten), lo que permite a un atacante registrarlos antes con payload malicioso. La defensa: verificar que todo paquete sugerido por la IA exista y sea legítimo antes de instalarlo.
Imagina que le pides a un asistente que te traiga un tornillo de una ferretería, y en vez de admitir que no sabe cuál, se inventa el nombre de una marca que suena perfectamente plausible: «Tornillos Kraften M8». Tú, confiado, vas a pedirlo. Y resulta que alguien, anticipándose exactamente a esa invención, ya abrió una tienda con ese nombre y llenó la caja con explosivos. Eso, trasladado al software, tiene nombre desde 2025: slopsquatting. Tu IA inventa una librería que no existe, y un atacante la registra antes que tú para meterle código malicioso. Es el vector de ataque de cadena de suministro más elegante y silencioso que ha traído la era de la programación asistida, y casi nadie en tu equipo sabe que existe.
La alucinación dejó de ser un chiste y se volvió una superficie de ataque
Durante años tratamos las alucinaciones de la IA como una anécdota graciosa: el modelo se inventa una cita, un dato, una fecha. Molesto, pero inofensivo. Con el código, la alucinación cambia de naturaleza. Cuando un modelo escribe `import requestz` en lugar de `requests`, o inventa un `pandas-utils-pro` que jamás existió, no está soltando un chiste: está firmando un cheque que otro puede cobrar. Porque a diferencia de una cita falsa, un nombre de paquete es una dirección. Y las direcciones se pueden ocupar. El día que la alucinación tuvo una dirección postal registrable en npm o PyPI, dejó de ser un error de estilo para convertirse en una puerta.
El dato duro: casi 1 de cada 5 fragmentos de código sugería un paquete fantasma
Un estudio presentado en USENIX Security 2025 lo midió a escala industrial: 2,23 millones de muestras de código generadas por 16 modelos distintos. El resultado es el que deberías tener pegado en el monitor: el 19,7% de las muestras incluía al menos un paquete alucinado — uno que simplemente no existe. Y el sesgo por familia de modelo es brutal: los modelos open-source inventaron paquetes el 21,7% de las veces, frente al 5,2% de los comerciales. Traducido: casi una de cada cinco veces que un modelo te tiende la mano con una dependencia, te está tendiendo una que no existe. Multiplícalo por los millones de `pip install` y `npm install` que se ejecutan al día bajo la fe ciega del «si lo escribió la IA, existirá», y tienes la superficie de ataque.
Lo verdaderamente peligroso no es que invente: es que invente SIEMPRE LO MISMO
Si las alucinaciones fueran ruido aleatorio, el ataque sería inviable: un atacante tendría que registrar millones de nombres al azar para acertar uno. El hallazgo que convierte esto en un problema real es otro: el 43% de los nombres alucinados reaparecen en todas las corridas. No es ruido, es una firma. El modelo, ante el mismo prompt, tiende a inventar el mismo nombre falso una y otra vez. Eso es oro para el atacante: solo tiene que observar qué inventa el modelo, quedarse con los nombres que se repiten, registrarlos con un payload malicioso, y esperar. No necesita hackear nada. Le montaste la trampa tú, y tu propio agente la instala con permisos de tu build. Seth Larson, de la Python Software Foundation, bautizó el patrón: slopsquatting — el primo del typosquatting, pero donde el error no lo comete tu dedo, lo comete tu modelo.
Por qué la programación por agentes multiplica el riesgo en vez de contenerlo
Un desarrollador humano que ve `import fastapi-turbo` en una sugerencia suele levantar una ceja: «¿eso existe?». Un agente autónomo no levanta cejas. Le dijiste «haz que funcione», tropieza con un import que falla, y su reflejo entrenado es resolver: ejecuta el `install`, y si el paquete existe (porque el atacante lo registró), lo instala sin fricción y sigue. El bucle que hace mágica a la programación agéntica — probar, fallar, corregir, seguir — es exactamente el que salta la única barrera que nos protegía: la duda humana. Cuanto más autónomo el agente, menos ojos entre la alucinación y el `install`. La autonomía sin verificación no es velocidad, es velocidad hacia el precipicio con los faros apagados.
La lección: en la era de la IA, la confianza en un nombre es una decisión de seguridad
El marco mental que te puedes llevar y compartir es este: un nombre de paquete sugerido por una IA no es un hecho, es una hipótesis. Y toda hipótesis que va a ejecutar código con los permisos de tu build merece ser verificada antes, no después. La acción concreta cabe en una frase: antes de instalar cualquier dependencia que sugirió un modelo, confirma que el paquete existe de verdad, que es el que crees, y que no nació la semana pasada con cero historia. Un lockfile con hashes fijados, un allowlist de dependencias, y una mirada de dos segundos a «¿este paquete tiene años y descargas o apareció el martes?» desactivan por completo este ataque. No hace falta un cortafuegos de IA: hace falta dejar de tratar la salida del modelo como escritura sagrada. La misma disciplina, por cierto, que separa una demo de un producto — de eso hablamos en la matemática del 27%.
Cómo lo vemos nosotros
En NeuralOS partimos de un axioma incómodo: la IA es un colaborador brillante y un mentiroso ocasional, y hay que diseñar para ambas cosas a la vez. Por eso pensamos la seguridad no como una capa que se pega al final, sino como el suelo sobre el que se construye. Algunas piezas de ese suelo ya son tangibles: los secretos se redactan por valor en cada log, y las credenciales viven en un Vault cifrado por-tenant que nunca se expone al modelo. Otras son dirección declarada, no promesa cumplida: en la misma línea creamos y regalamos Sentinel, un guardián de seguridad de código abierto que caza el bug antes de que llegue a producción. Nosotros no podemos evitar que un modelo alucine un nombre — nadie puede, es física del sistema. Lo que sí perseguimos, pieza a pieza y con honestidad sobre lo que ya existe y lo que aún es camino, es levantar el foso entre esa alucinación y tu build: que la duda que un agente ya no tiene, la vaya teniendo la plataforma por ti. Porque en la era de construir con IA sin ser programador, tu ventaja no es confiar más rápido: es que la verificación no dependa solo de tu buena fe.