La IA escribe código e instala paquetes: 5 comprobaciones antes de llevar una aplicación a producción

Un asistente de IA ha creado un área de usuario, conectado la base de datos y mostrado una página que funciona. Ahora consulta la API con la identidad de otro usuario: si devuelve un perfil ajeno, la aplicación no puede publicarse. Que las pruebas pasen no descarta este problema, sobre todo si solo comprueban que se puede iniciar sesión y cargar la página.

Habr ha publicado un análisis práctico sobre la seguridad del código escrito con IA y de los agentes que lo ejecutan. Su idea central es sencilla y útil: al acelerar el desarrollo, el equipo también asume más acciones que debe verificar. El asistente propone bibliotecas, instala dependencias, lee archivos y ejecuta comandos. Cada una de estas acciones necesita límites de acceso claros.

Para los desarrolladores, es un motivo para replantear la revisión del código. Para responsables de producto y fundadores, supone añadir al criterio de «la demo funciona» varias comprobaciones sin las cuales el lanzamiento sigue siendo una lotería.

Empieza por el perfil de otra persona

Las comprobaciones más útiles suelen parecer aburridas. ¿Puede un usuario leer un pedido ajeno cambiando el identificador de una petición? ¿Se puede acceder a una tabla sin autenticación? ¿El nombre introducido por el usuario se inserta directamente en el HTML?

El artículo presenta el ejemplo de una aplicación con Supabase. Una clave pública en el frontend no implica por sí sola una filtración: las políticas de Row Level Security deben restringir el acceso a las filas. El error aparece cuando la aplicación ya está conectada a la base de datos, pero las reglas de acceso todavía no se han configurado o conceden demasiados permisos.

Conviene probarlo con escenarios separados: una petición sin token, una petición de un usuario a un recurso propio y otra del mismo usuario a un recurso ajeno. La última es especialmente importante. Comprobar que «la persona ha iniciado sesión» todavía no responde a la pregunta «¿le pertenece este documento?».

El análisis estático ayuda a detectar operaciones peligrosas y secretos expuestos. Pero, sin las reglas de tu producto, normalmente no puede determinar quién tiene derecho a leer un pedido concreto. Para eso hacen falta revisiones y comprobaciones de autorización.

La comprobación de una dependencia empieza por su nombre

El segundo problema aparece incluso antes de ejecutar la aplicación. El modelo puede sugerir un nombre verosímil para una biblioteca que nunca ha existido. Si un atacante registra ese nombre, la siguiente instalación introducirá su código en el entorno del desarrollador.

Imagina que el agente necesita una biblioteca para procesar documentos. Propone un paquete, lo instala y sigue trabajando. El desarrollador ve una función terminada, pero nadie ha comprobado el origen de la dependencia. En algunos ecosistemas, el código de terceros puede ejecutarse durante la propia instalación.

Por eso, conviene contrastar cada nueva dependencia con la documentación oficial del proyecto. Después, hay que fijar la versión y utilizar un archivo de bloqueo al compilar. Esto hace que la instalación sea reproducible, aunque por sí solo no demuestra que el paquete elegido sea seguro.

Desactivar los scripts de instalación también tiene límites: la biblioteca puede ejecutar código malicioso más adelante, cuando la aplicación la importe. Además, un escáner de vulnerabilidades conocidas puede pasar por alto un paquete malicioso recién publicado. Estas medidas complementan la comprobación del origen del paquete.

El agente necesita límites en sus permisos

Cuando el asistente obtiene acceso a la terminal, el riesgo va más allá del código generado. Puede instalar un paquete, leer un archivo con claves o ejecutar una instrucción encontrada en un README ajeno. El texto externo se vuelve peligroso si el agente lo interpreta como permiso para actuar.

La respuesta práctica es conceder acceso según la tarea. Para corregir una interfaz, normalmente no hacen falta secretos de producción ni permisos para publicar paquetes. Los comandos de instalación de dependencias, el acceso a secretos y los cambios de infraestructura merecen un control específico.

Antes del próximo lanzamiento, se pueden elegir cinco comprobaciones: acceso a recursos de otros usuarios, origen de los nuevos paquetes, reproducibilidad de la instalación, secretos en el código y los registros, y permisos del agente. Son puntos concretos en los que un pequeño error puede convertirse en una filtración o en la ejecución de código de terceros.

El propio análisis sigue siendo una visión general: los ejemplos y estudios aislados no permiten calcular la probabilidad de que tu servicio concreto sufra un ataque exitoso. Pedirle al modelo que «compruebe la seguridad» tampoco ofrece garantías. Los resultados útiles llegan cuando el equipo convierte las recomendaciones en criterios de lanzamiento verificables y asigna una persona responsable de cada uno.