npm install && pray

Hola, Node Congress. Muchas gracias por invitarme. Soy Jo Franchetti y soy DevRel en Deno, y voy a sumergirme de inmediato y hablemos de algunas cosas aterradoras.

Hay un ritual que todo desarrollador de JavaScript conoce. Estás construyendo algo, necesitas pasar fechas o validar un correo electrónico o formatear una moneda. Así que haces lo que cualquier persona razonable haría. Abres tu terminal y escribes npm install, y eliges un paquete con unos pocos millones de descargas semanales y un readme amigable. Confías en él. Lo envías.

Y durante mucho tiempo, eso funcionó muy bien. Y nuestro ecosistema creció gracias a esa confianza, porque alguien podía publicar una utilidad a las 2 a.m. y por la mañana, los desarrolladores del otro lado del mundo ya la estaban usando en producción. Y esa apertura es genuinamente hermosa. Es por eso que JavaScript se convirtió en lo que es. Pero necesitamos hablar sobre lo que esa confianza nos cuesta ahora.

En septiembre de 2025, investigadores de Reversing Labs identificaron algo que no se había visto antes en el ecosistema npm. Era un gusano autorreplicante, y lo llamaron shyhoo lewd en honor al gusano de arena de June, lo cual es bastante apropiado porque una vez que entró en el ecosistema, fue muy difícil de detener. Y esto es lo que hizo. Comenzó con un solo paquete malicioso. En este caso, era rxnt authentication. Y una vez que un desarrollador lo instalaba, el malware escaneaba su entorno en busca de credenciales npm. Luego usaba esas credenciales para publicar una versión maliciosa de otros paquetes que ese desarrollador mantenía o a los que tenía acceso. Era literalmente viral.

Cada nueva víctima se convertía en un nuevo vector de ataque. Para cuando fue contenido, más de 500 paquetes npm habían sido comprometidos. Luego hubo una segunda ola, shyhoo lewd 2.0, que golpeó en noviembre y comprometió 796 paquetes más. Y eso representó más de 20 millones de descargas semanales. ¿Y qué estaba robando realmente el malware? Bueno, cualquier cosa que pudiera encontrar. Buscaba variables de entorno, tokens de AWS y GCP, credenciales de GitHub, tokens de autenticación npm. Y hacía todo esto silenciosamente a través de HTTP en segundo plano mientras tu aplicación funcionaba perfectamente.

Nunca lo sabrías. Y un mes antes, en septiembre de 2025, un ataque diferente golpeó aún más fuerte. Quizás hayas oído hablar de los paquetes Chalk o Debug, dos de los paquetes más descargados en todo el ecosistema npm. Y un mantenedor muy prolífico gestionaba ambos junto con otros 16 paquetes ampliamente utilizados. En conjunto, tenían más de 2 mil millones de descargas semanales.

Lo que hicieron los atacantes fue registrar el dominio npmjs.help. Y luego, tres días después de registrarlo, enviaron al mantenedor un correo electrónico desde support at npmjs.help. Y estaban suplantando al soporte de npm. El correo electrónico fue lo suficientemente convincente como para que el mantenedor ingresara sus credenciales en una página de inicio de sesión falsa. Y con esas credenciales, los atacantes luego tuvieron derechos de publicación completos para los 18 de sus paquetes.

Y lanzaron un montón de actualizaciones que inyectaron código que secuestraría transacciones de criptomonedas desde los navegadores de los usuarios. No fue un exploit técnico particularmente sofisticado. Fue solo un correo electrónico de phishing y una página de inicio de sesión falsa. Así que tomemos un momento para entender la mecánica porque eso es importante para lo que vamos a hablar a continuación. Los ataques a la cadena de suministro en el ecosistema npm funcionan debido a una combinación de factores. Primero está la confianza implícita en los rangos de versiones. Todos lo hacemos. La mayoría de los archivos npm, nuestros archivos package.json, usan un sombrero o una tilde delante de los números de versión. Eso significa que cuando un mantenedor lanza, digamos, 2.1.1 para corregir un error, tu CI lo va a incorporar automáticamente.

No hay revisión. No obtienes ninguna aprobación. Simplemente llega a producción. La segunda superficie de ataque es el propio mantenedor, no el código. El ataque a Chalk no requirió encontrar una vulnerabilidad en el código de Chalk, requirió encontrar una vulnerabilidad en un ser humano. Específicamente, su tendencia a confiar en un correo electrónico que parece oficial y estar demasiado ocupado y cansado para verificar adecuadamente. Si comprometes a la persona, puedes potencialmente comprometer todos sus paquetes.

En tercer lugar, el malware no necesita ser obvio. Unas pocas líneas de código que se ejecutan en el momento de la instalación con un script post-instalación o código que solo se activa cuando están presentes variables de entorno específicas o código que silenciosamente genera un subproceso, todos estos pueden pasar una revisión de código casual. Aquí es donde me gustaría introducir algo, pero también quiero ser cuidadoso sobre cómo lo enmarco porque no quiero que esto suene como un discurso de ventas. Esto se trata de decisiones de diseño que tienen consecuencias reales.

Así que por defecto, Node.js da a cada paquete que instalas los mismos permisos que tu cuenta de usuario. Cuando ejecutas npm install y se activa un script post-instalación, ese script puede leer tu directorio .ssh. Puede hacer solicitudes HTTP. Puede escribir en tu sistema de archivos. Puede generar procesos. Deno toma un enfoque ligeramente diferente. Por defecto, un programa Deno no tiene acceso a APIs sensibles sin permisos explícitos. Así que en Deno, tenemos allowenv para dar acceso a variables de entorno, allownet para permitir acceso a Internet, allowread para dar acceso de lectura al sistema de archivos, allowwrite, que te permite escribir en el sistema de archivos, y allowrun, que te permite generar subprocesos. Y crucialmente, puedes delimitar estos.

Así que podríamos hacer algo como allowenv igual a database URL, lo que significa que el proceso solo puede leer esa variable de entorno database URL y nada más. O podríamos hacer algo como allownet igual a api.stripe.com, lo que significa que el proceso puede alcanzar Stripe y a ningún otro lugar.

Y hay una capa más que vale la pena entender. Mencioné antes el problema post-instalación. Así que cuando ejecutas npm install, npm ejecuta cualquier script de ciclo de vida que el paquete declare pre-install, install, o post-install. Y así es como Shai Walood ejecutó su payload. El atacante no requería que importaras el paquete. Se ejecutó en el momento en que lo instalaste.

Deno no tiene scripts de instalación. No hay gancho post-instalación. Cuando Deno descarga un paquete, lo almacena en caché y luego se detiene. No se ejecuta ningún código. Y esa es una decisión de diseño intencional. No es una omisión. Y pnpm ha tomado una posición similar recientemente. Las versiones más nuevas requieren que permitas explícitamente a los paquetes ejecutar scripts de construcción a través de una lista de permisos solo para dependencias construidas.

Así que estás optando por participar en lugar de optar por no participar. Y npm tiene una opción para no participar. Tenemos el comando npm install menos menos ignore scripts. Pero no está activado por defecto. No se muestra de manera prominente y puede romper paquetes que legítimamente necesitan compilar extensiones nativas. Y honestamente, la mayoría de los equipos simplemente no lo usan.

Así que podemos cerrar un vector de ataque deshabilitando nuestros scripts de instalación, lo cual es significativo. Pero no nos salva de todo. Digamos que tienes un paquete que ejecuta código malicioso en tiempo de ejecución. Código que se ejecuta cuando lo importas, cuando llamas a una de sus funciones, cuando registra un efecto secundario o al cargar el módulo. Eso no se ve afectado en absoluto por el comando ignore scripts.

El malware simplemente se mueve del tiempo de instalación al tiempo de ejecución. El gusano seguirá ejecutándose, solo esperará hasta que tu aplicación esté en funcionamiento. Y las herramientas que detectan este tipo de cosas se llaman escáneres SAST y DAST. Así que tenemos nuestras herramientas de análisis estático y dinámico que buscan patrones sospechosos en nuestro código de dependencias. Y se ejecutan en un horario de CI o en un PR.

No se ejecutan en el momento en que un desarrollador agrega un paquete y escribe node index.js para ejecutar algo localmente. Esa brecha entre agregar un paquete y el siguiente escaneo de CI es donde viven los ataques en tiempo de ejecución. Y es exactamente ahí donde la aplicación de permisos de DNO es más importante.

Así que vamos a echar un vistazo a una pequeña demostración y ver qué sucede cuando intentas hacer lo que hizo ShyWooLoo. Así que echemos un vistazo a un pequeño script aquí abajo. Supongamos que tenemos este script aquí. Va a intentar leer tu entorno y hacer una solicitud HTTP saliente, exactamente lo que estaba haciendo la carga útil del gusano. Y si intento ejecutar esto con DNO, así que si hago dno run worm.ts, en realidad no se ejecuta. Lo primero que sucede es que recibo un aviso preguntando si quiero o no otorgar esos permisos. Se detiene inmediatamente antes de que se envíe un solo byte. Y luego puedo verificar qué está haciendo este código y asegurarme de que está haciendo lo que quiero que haga y lo que pensé que debería estar haciendo.

Ahora, quiero ser preciso sobre contra qué protege esto y contra qué no. El sistema de permisos de DNO es una gran defensa contra el código que intenta hacer cosas malas a nivel del sistema. Pero es una noticia un poco vieja. Todos lo han visto antes. Y no resuelve todos los problemas que enfrentamos. Podrías haber sabido que esto venía. Ryan Dahl, el creador de Node y DNO, tuiteó recientemente que la era de los humanos escribiendo código ha terminado. Y, por supuesto, los asistentes de codificación de IA son genuinamente útiles. Los uso. Asumo que tú los usas. Aceleran el código repetitivo. Son buenos explicando código desconocido. Detectan errores que ciertamente pasaría por alto. Y, ya sabes, no voy a sentarme aquí y decirte que dejes de usarlos.

Pero pueden introducirnos a una categoría completamente nueva de problemas. Y está relacionado con todo lo que acabo de mencionar. Se trata del código que no escribiste. Que no controlas completamente haciendo cosas que no pretendes que haga.

Así que echemos un vistazo a otro ejemplo del mundo real. A principios de 2025, investigadores de Truffle Security realizaron un análisis del conjunto de datos Common Crawl, que es solo una instantánea pública masiva de la web. Y se utiliza para entrenar modelos de IA. Y lo que encontraron fue bastante alarmante. Casi 12,000 secretos válidos en vivo estaban incrustados en esos datos de entrenamiento.

Eso incluye cosas como claves de AWS, claves de API, tokens de Slack, credenciales de GitHub. Y estos no eran solo secretos que habían sido rotados. Estos estaban activos y funcionando y algunos de ellos todavía están funcionando ahora mismo. Y luego, en mayo de 2025, un desarrollador de XAI, que si no lo sabes es la empresa de IA de Musk, publicó accidentalmente una clave de API privada en un repositorio público de GitHub. Y esa clave tenía acceso a al menos 60 LLMs ajustados y privados, incluidos modelos entrenados con datos de SpaceX y Tesla. Y estuvo activa durante un período de tiempo desconocido antes de que fuera detectada e informada por Brian Krebs.

Y por separado e interesantemente, Wiz.io encontró que el 65% de las empresas en la lista Forbes AI 50 han filtrado secretos verificados en GitHub. 65%. Incluso las empresas que están construyendo las herramientas de IA tienen el mismo problema que todos los demás. Entonces, ¿por qué sigue ocurriendo esto? Bueno, no es aleatorio. Es un problema estructural.

Hay algunas cosas que están sucediendo aquí. Los proyectos de IA se mueven muy rápido. Y cuando nos movemos rápido, nuestras prácticas de seguridad tienden a quedarse atrás. Los asistentes de codificación de IA a veces pueden sugerir patrones incorrectos que codifican directamente nuestras credenciales en el código. Nuestro código generado a veces puede omitir la indirecta de la variable de entorno .env que mantiene los secretos seguros. Y los desarrolladores, sabemos cómo somos.

Tenemos una tendencia a revisar la salida de IA un poco menos cuidadosamente que el código que nosotros o nuestros colegas escribimos nosotros mismos. Hay una sutil difusión de responsabilidad que ocurre aquí cuando usamos IA para generar código para nosotros. Y en 2025, GitHub Copilot fue asignado una vulnerabilidad de ciberseguridad. Esta fue CVE-2025-53773, si quieres buscarla. La teoría de esta vulnerabilidad era que un atacante podría potencialmente incrustar instrucciones de inyección de comandos en un repositorio a través de comentarios en el código. O comentarios en el repositorio, más bien.

Esta es una forma de inyección indirecta de prompts. La superficie de ataque ya no es tu propio código. Es cualquier código o copia que tu asistente de IA revise. Y no solo eso, no sé si has oído hablar de esta idea de envenenamiento de modelos. Todavía es algo experimental, pero en realidad bastante real. Los investigadores han demostrado que inyectar tan solo 250 documentos maliciosos en los datos de preentrenamiento puede crear una puerta trasera en un LLM con una tasa de éxito del 90% en el ataque. Ni siquiera sabrías que el modelo fue comprometido. Se comportaría normalmente excepto cuando se cumplen condiciones específicas.

Así que dejemos de lado las cosas aterradoras por un momento y hablemos del riesgo cotidiano y aburrido, porque honestamente, eso es lo que es más probable que te afecte. El código generado por IA, por supuesto, comete errores. No necesariamente errores maliciosos, solo código incorrecto. Un script que se suponía que limpiaría archivos temporales puede eliminar el directorio equivocado. Una utilidad de sincronización de archivos puede sobrescribir la fuente en lugar del destino. Un script de migración de datos puede ejecutarse en la base de datos equivocada. Estos no son modos de falla exóticos. Son solo modos de falla normales de software escrito por alguien que no comprende completamente tu entorno, que es exactamente lo que es el código escrito por IA.

Y es cuando ejecutas ese código localmente, con permisos completos, que realmente pueden ocurrir cosas malas, y los errores pueden convertirse no solo en bugs, pueden convertirse en pérdida de datos. Entonces, ¿qué funciona y qué no para mantenerte seguro? Comparemos dos soluciones comunes, Docker y los permisos de Dino que mencioné anteriormente. Por supuesto, los contenedores de Docker son la respuesta estándar de oro aquí. Estamos ejecutando código generado por IA dentro de un contenedor para darnos un aislamiento genuino. Tenemos un sistema de archivos separado, red separada, espacio de proceso separado. Así que si el código hace algo extraño, sucede dentro de este pequeño contenedor. El problema con Docker es el costo de configuración.

Para usar la aislamiento de Docker para cada script generado por IA que quieras probar, necesitas que el demonio de Docker esté en funcionamiento, necesitas construir o descargar una imagen, necesitas gestionar el ciclo de vida del contenedor. Y eso es un costo significativo cuando estás en medio de un flujo de desarrollo y solo quieres validar algo rápidamente. Y como mencioné anteriormente, por supuesto, también tenemos las banderas de permisos de Dino. Y estas ayudan si estás ejecutando código generado por IA sin darle los permisos, no puede leer tus archivos ni tocar la red. Pero, por supuesto, hay un límite aquí. Algún código va a necesitar permisos para hacer cosas útiles. Y si el script necesita legítimamente acceso a la red, tendrás que concedérselo. Y luego volvemos a confiar en el código nuevamente. Y los permisos de Dino protegen contra operaciones a nivel de Dino. No protegerán contra cosas como errores lógicos. No detendrán un script de iterar sobre datos en el orden incorrecto o hacer la llamada API incorrecta porque ya has concedido acceso.

Así que lo que realmente necesitamos es una forma rápida y de bajo costo para ejecutar código arbitrario en aislamiento genuino con un sistema de archivos separado, un espacio de nombres de red separado, sin acceso a nuestro entorno anfitrión, algo que pueda iniciarse súper rápido y no requiera configuración de infraestructura. Y aquí es donde entra en juego la función de sandbox de Dino. El paquete de sandbox te da acceso programático a sandboxes basados en micro VM. Estos no son contenedores, son micro VMs completas. Cada sandbox es una micro VM de Linux independiente, lo que significa que cada sandbox tiene sus propios permisos estrictos, políticas de red, directorios y secretos aislados, haciendo que el sandbox de Dino sea perfecto para agentes de IA o cualquier otra carga de trabajo dinámica donde la velocidad y la seguridad son primordiales. Tienen un kernel separado, un sistema de archivos separado, una red separada, aislamiento completo del anfitrión. Y el tiempo de inicio es inferior a 200 milisegundos, lo cual es lo suficientemente rápido como para ser práctico si lo estás usando en un bucle de agente de IA donde estás ejecutando código generado como parte de un pipeline.

Así que hagamos un pequeño desvío para explicar las dos capas de aislamiento que están en juego en el sandbox de Dino. En primer lugar, tenemos nuestros V8 isolates. Así es como Dino y Node y Chrome aíslan los contextos de ejecución de JavaScript. Cada uno tiene su propio heap, su propio recolector de basura, sin acceso directo a otros isolates. Son ligeros y rápidos. Y Dino deploy usa isolates para ejecutar miles de funciones en hardware compartido de manera muy eficiente. Los isolates son excelentes para código JavaScript no confiable, pero están ejecutándose en el mismo proceso del sistema operativo. Mientras que las micro VMs van un poco más allá. La micro VM de Linux es una máquina virtual real. Tiene su propio kernel, su propio sistema de archivos, su propia pila de red. Así que el código que se ejecuta dentro de ella no tiene camino de regreso a tu máquina anfitriona. Y este es el tipo de aislamiento que deseas cuando los riesgos son un poco más altos.

Si estás ejecutando código generado por IA que podría potencialmente hacer cualquier cosa. Y la función de sandbox de Dino aplica ambas capas. El JavaScript se ejecuta en el V8 isolate, y ese isolate se ejecuta dentro de una micro VM. Así obtienes la velocidad de la ejecución basada en isolate con las garantías de seguridad de la virtualización a nivel de hardware.

Veamos los sandboxes en la práctica. Voy a usar la API de cloud para generar algo de código, y luego lo voy a ejecutar dentro del sandbox de Dino. Así que incluso si cloud produce algo que intenta leer mi sistema de archivos o hacer llamadas de red inesperadas, se ejecuta en completo aislamiento.

Así que si me disculpan, aquí hay uno que hice antes. Vamos a sumergirnos. Así que lo primero que vamos a hacer, ya he añadido nuestra Anthropic API, nuestro Anthropic SDK, perdón, y nuestro Dino sandbox SDK. Así que voy a empezar importándolos en este proyecto.

El Anthropic SDK es lo que nos permite hablar con cloud, y el Dino sandbox SDK es por supuesto lo que nos permite iniciar una micro VM segura. Luego voy a crear un cliente Anthropic. Y luego le voy a decir que realmente haga algo. Ahora el cliente Anthropic va a recoger automáticamente mi clave API de Anthropic de mi archivo de variables de entorno aquí.

No, no voy a compartir mi clave API con todos ustedes. Así que ahora le voy a pedir a Claude que realmente escriba algo para nosotros. Así que aquí acabo de decir, escribe un script de Dino que obtenga el precio actual de Bitcoin de CoinGecko y lo imprima. Y Claude va a devolver eso envuelto en un bloque de código markdown. Luego lo que quiero hacer es extraer el código generado de la respuesta de Claude. Así que vamos a obtener esa respuesta, vamos a obtener el bloque de código, y vamos a hacer una pequeña verificación en él. Así que es un bloque de texto, lo vamos a limpiar, y obtener el código fuente en bruto.

Así que eso es solo limpiando nuestro markdown allí. Y ahora vamos a hacer la parte genial. Así que ahora vamos a crear realmente un sandbox.

Así que voy a usar el await sandbox.create, y vamos a await using. Y la sintaxis await using aquí, es solo un nuevo fragmento de JavaScript. Es un nuevo fragmento de sintaxis de JavaScript, que se destruye automáticamente cuando el alcance termina. Así que no vamos a filtrar recursos aquí, incluso si algo lanza.

Luego voy a tomar ese código generado por IA que escribimos antes, y lo voy a escribir en el sistema de archivos del sandbox. Como mencioné, el sandbox tiene su propio sistema de archivos aislado, así que nada aquí toca mi host. Luego voy a ejecutar realmente ese código dentro de un sandbox. Y solo le voy a dar acceso a la red a api.

coingecko.com, el único host al que realmente necesita acceso. Y luego voy a canalizar la salida y los errores para que pueda capturarlos y mostrarlos. A continuación, voy a añadir un tiempo de espera estricto.

Y luego finalmente, voy a esperar a que el proceso termine, y voy a imprimir los resultados. Así que probémoslo, ¿de acuerdo? Entonces puedo hacer dno menos a, lo que va a dar todos los permisos. Y voy a hacer menos menos m file. Lo que le va a dar acceso a las variables de entorno en ese m file. Y voy a decir run. Oh, no. Vamos a hacerlo bien. No, run. Dios, no puedo escribir hoy. M file, y es main.ts lo que quiero ejecutar. Así que lo que está haciendo ahora es crear un sandbox, y luego va a pedir a Claude que genere ese código, y lo va a mostrar, lo cual ha hecho aquí.

Brillante. Y claro, eso no fue súper impresionante de ver, pero lo importante que ha sucedido aquí es que aunque el código fue generado por una IA, y no he leído cada línea de él, no he leído ninguna línea de él, para ser honesto, solo puede alcanzar api.coingecko, no puede leer ninguno de mis m file, no puede escribir en mi sistema de archivos, no puede llamar a casa, y si se ejecuta por más de 10 segundos, va a ser terminado. Y sí, este es un ejemplo algo artificial, pero quería algo que pudiera mostrarles rápidamente.

Y dado que estos sandboxes son VMs completas, podrías, por supuesto, instalar Claude directamente en un sandbox y usar eso para generar código, en lugar de lo que he hecho aquí, que es generarlo en mi máquina local. Y los sandboxes permiten la creación de instantáneas de tu VM, así que podrías, en teoría, instalar Claude, cualquier otra herramienta que desees, tomar una instantánea de la VM, y luego podrías lanzar múltiples versiones de eso en menos de 200 milisegundos, permitiendo tiempos de ejecución de código realmente rápidos para tus prompts y código de Claude.

Pero hay un problema más aquí del que no he hablado todavía. Si estás ejecutando código generado por IA que necesita hacer una llamada API, vas a necesitar pasarle tu clave API, y eso va a causar un problema. El código necesita las credenciales, pero si inyectas esas credenciales como una variable de entorno en tu sandbox, vuelves a la situación con la que empezamos, código no confiable que puede leer tus secretos y enviarlos a cualquier parte. Y lo genial de esto es que los sandboxes de Deno tienen una opción de secretos, específicamente para este caso.

Así que echemos otro vistazo a una demostración. Voy a pasar esa clave API desde mi archivo de entorno al sandbox, y voy a imprimir la clave API en los registros del sandbox. Así que echemos un vistazo a eso. Así que cuando creé mi sandbox antes, voy a pasarle una opción de secretos. Así que aquí, puedes ver que le he dado secretos, le he pasado mi clave API de Anthropic, que está obteniendo de mis variables de entorno. Y estoy diciendo que lo único a lo que se le permite ser enviado es a api.anthropic.com.

Y ahora si imprimo mi clave API, hagámoslo justo al final, y lo ejecutamos de nuevo. Así que aquí estamos levantando otro sandbox. Ahora creando otra aplicación y con suerte obteniendo nuestro precio de Bitcoin nuevamente. Ahí vamos. Bien, obtuvimos un nuevo precio esta vez. Obtuvimos una salida ligeramente diferente porque generamos un código completamente nuevo. Y notarás que nuestra clave API ha sido reemplazada por un marcador de posición secreto. Lo único que el sandbox puede ver es esta cadena de marcador de posición. Y la clave real solo se reemplaza cuando el sandbox realiza una llamada API saliente a un host aprobado.

Y lo está haciendo a través de un proxy que conoce ese marcador de posición y puede intercambiar la clave real por el marcador de posición. Si tu código inyectado por prompt intenta exfiltrar tu clave API, todo lo que obtiene es un marcador de posición inútil. Así que intentemos juntar todo esto.

El ecosistema de JavaScript tiene un problema de cadena de suministro y está empeorando. Los ataques de Chalk ya no son teóricos. ShaiHuLu'd comprometió cientos de paquetes y millones de descargas. El ataque de Chalk no requirió nada más sofisticado que un correo electrónico de phishing. Y el malware, cuando aterriza, va directamente por tus credenciales y tus variables de entorno.

Y los asistentes de IA, los amamos. Son genuinamente útiles, pero también son genuinamente riesgosos. Pueden exponer tus claves API. El código que generas puede hacer cosas no intencionadas. Y a medida que la investigación sobre inyección de prompts madura, la cuestión de si un asistente de codificación de IA puede volverse en tu contra está pasando de ser teórica a práctica muy rápidamente. Pero la buena noticia es que tenemos defensas reales y efectivas.

En primer lugar, asegúrate de que siempre ejecutas tu código con el menor privilegio posible. Cualquiera que sea el entorno de ejecución que uses, dale al código los permisos mínimos que necesita. Asume que cualquier paquete que instales podría ser malicioso porque algún día, uno de ellos lo será. Siempre trata tu código generado por IA como si fuera código no confiable. Revísalo. Ejecútalo en aislamiento, al menos la primera vez. Y no le des la misma confianza implícita que le darías al código que escribiste tú mismo. Y finalmente, usa sandboxing para la ejecución que no controlas. Ya sea generado por IA o generado por el usuario o simplemente paquetes en los que no confías, no ejecutes código en el que no confías en tu propia máquina. No le des acceso a tus secretos. Mantén tu trabajo y tus datos seguros.