llm 0.37.2: la CLI de IA que filtraba tu API key

Qué corrige llm 0.37.2 y por qué importa

llm 0.37.2 es una actualización de una sola cosa: seguridad. La versión, publicada el 11 de noviembre por Simon Willison, cierra dos caminos por los que tu API key de OpenAI podía terminar enviada a un proveedor externo sin que lo supieras.

El fallo lo reportó Daniel de Araujo y quedó registrado en dos avisos de seguridad de GitHub: GHSA-v9h7-jj4g-f862 y GHSA-r639-rr7r-x72w. Las notas de la versión se limitan al parche de seguridad.

Para quien no conoce la herramienta: llm es una utilidad de línea de comandos para acceder a modelos de lenguaje desde la terminal. Su valor está en que permite probar un modelo, comparar proveedores o automatizar una tarea repetitiva sin escribir código, algo que en un equipo chico se traduce en horas de trabajo ahorradas.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Cómo se filtraba la API key: los dos caminos

El mecanismo en el centro del problema es extra-openai-models.yaml, el archivo con el que llm se conecta a endpoints compatibles con la API de OpenAI que ofrecen otros proveedores. Desde la versión 0.37 ese archivo se gestiona con el comando llm openai endpoint add.

Según el aviso de seguridad, había dos formas de que la key configurada para OpenAI se enviara al proveedor equivocado:

Si la key nombrada en el campo api_key_name nunca se había guardado, llm podía usar la key de OpenAI en su lugar.
Si se ejecutaba un modelo marcado con responses: true usando la opción -o chat_completions 1, la key podía viajar al endpoint de terceros.

Los dos casos son de configuración, no de ataque. Nadie necesitaba explotar nada de forma activa: bastaba con tener un endpoint de terceros mal configurado y una credencial ausente para que la key de OpenAI saliera de tu máquina hacia un servidor que no era el suyo.

Eso es lo que hace a este tipo de bug especialmente incómodo. No hay exploit sofisticado ni malware de por medio: hay un archivo YAML mal armado y una credencial que se manda donde no corresponde.

Por qué una API key filtrada es más grave de lo que parece

Una key de OpenAI no es un dato menor. Es una credencial con facturación asociada: quien la tenga puede consumir tu cuota y generar costos a tu nombre, además de acceder a lo que el proveedor permita con esa credencial.

El problema es sistémico. Investigadores de Wake Forest University analizaron 444 aplicaciones iOS con funciones de LLM y encontraron que 282 exponían credenciales o mecanismos de acceso explotables, según reportó Help Net Security. Entre las vulnerables, 136 exponían tokens de autenticación, 92 permitían acceso no autenticado al backend y 54 dejaban API keys en texto plano.

El mismo reporte señala que las aplicaciones con LLM alcanzaron 17.000 millones de descargas en 2025 y representaron el 13% de todas las descargas móviles. Y que, tras la divulgación responsable, solo el 28% de las apps vulnerables remedió el problema: el 23% seguía explotable 90 días después.

La lección para cualquier equipo que construye con IA es directa: la fuga de credenciales no es un problema de apps mal hechas. Es un problema de arquitectura y de hábitos de configuración, y aparece igual en herramientas de escritorio, en backends propios y en servicios cloud.

El otro frente: la confianza en las herramientas de IA

Hay un dato que explica por qué este parche importa más allá de la anécdota técnica. En una encuesta informal a 103 desarrolladores publicada por SD Times, el 87% ya usa o planea adoptar herramientas de IA para programar, pero solo el 31% confía en la exactitud de lo que estas generan, y apenas el 4% declara confianza alta.

El mismo sondeo reporta que el 58% tiene una opinión favorable de estas herramientas, por debajo del 70% que registraban años anteriores, y que solo el 13% cree que los agentes de IA mejoraron la colaboración en equipo.

Ese es el terreno donde se juega la adopción real. Los equipos ya adoptaron la IA; lo que todavía no resolvieron es si pueden confiar en ella. Cada incidente como el de llm 0.37.2 empuja la balanza hacia el lado de la desconfianza, y cada parche rápido y transparente la empuja de vuelta.

Vale la pena notar que el ecosistema de agentes de línea de comandos se está profesionalizando rápido. OpenAI publicó una serie de artículos técnicos sobre el funcionamiento interno de su Codex CLI, incluyendo su bucle de agente y su modelo de sandboxing, según cubrió InfoQ. Cuando los propios laboratorios documentan cómo construyen estas herramientas, el estándar de seguridad que se espera de todo el resto sube.

¿Qué significa esto para tu startup?

Si tu equipo usa llm, la acción es inmediata: actualizar a 0.37.2. Pero el aprendizaje va más allá de una versión.

Audita tus endpoints de terceros. Revisa cada entrada de extra-openai-models.yaml y confirma que el api_key_name que declaras existe realmente y apunta a la credencial correcta. Un nombre mal escrito alcanza para que la herramienta use la key equivocada.
Separa las keys por proveedor y por proyecto. Si una sola key de OpenAI se reutiliza para todo, cualquier error de configuración tiene alcance total. Credenciales distintas por entorno limitan el daño y hacen que un consumo anómalo sea detectable.
Pon límites de gasto y alertas. La mayoría de los proveedores permite fijar un tope mensual. Es la diferencia entre detectar una fuga en horas y descubrirla en la factura.
Rota credenciales ante la duda. Si corriste un modelo con responses: true y -o chat_completions 1 contra un endpoint de terceros, o si tuviste un api_key_name sin guardar, rotar la key es más barato que investigar si algo pasó.

Conclusión

llm 0.37.2 es un parche pequeño con una lección grande: en un stack de IA, la superficie de riesgo más común no es el modelo, es la configuración. Un archivo YAML, un nombre de variable mal escrito y una credencial compartida alcanzan para mandar tu key a un servidor ajeno.

Para un founder, la conclusión práctica es que la seguridad de las herramientas de IA dejó de ser un tema exclusivo de infraestructura y pasó a ser parte del producto. Los datos de Help Net Security muestran que la fuga de credenciales es sistémica; los de SD Times, que la confianza es el freno real a la adopción. Atender ambas cosas, con parches al día y credenciales bien separadas, es hoy parte del trabajo básico de cualquier equipo que construya con IA.