Gestión de claves de API de LLM: presupuestos, rotación y acceso más seguro para apps

Una clave de API de LLM es una credencial que puede autorizar gastos y acceso. Administrarla bien implica responder cuatro preguntas: ¿dónde se almacena, qué puede hacer, cuánto puede consumir su carga de trabajo y qué tan rápido puedes revocarla?

Una primera solicitud exitosa no responde ninguna de esas preguntas. Antes de que un prototipo se convierta en una aplicación compartida, establece un ciclo de vida de la clave y un límite de acceso que puedas explicar sin abrir las credenciales sin procesar de nadie.

Mantén la clave del proveedor detrás de tu aplicación

No incrustes una clave de API de proveedor de larga duración en JavaScript del navegador, en el paquete de una aplicación móvil ni en el almacenamiento del navegador. Enviar un secreto al dispositivo de un usuario final lo deja disponible fuera del control de tu servidor. OpenAI recomienda explícitamente enrutar las solicitudes a través de un backend en lugar de exponer claves en entornos del lado del cliente. Guía de seguridad de claves de API de OpenAI

Para una aplicación web convencional, usa este límite:

Signed-in user → your authenticated backend → LLM provider

El navegador se autentica con tu aplicación. Tu backend elige el modelo permitido y recupera la credencial del proveedor desde el almacenamiento de secretos del lado del servidor.

Pero mover una clave a un backend no es suficiente. Un proxy sin autenticación todavía puede permitir que desconocidos gasten tu saldo sin siquiera ver el secreto. Aplica autorización de usuarios, límites de tamaño de solicitud, operaciones permitidas y controles de uso por usuario antes de reenviar el trabajo. No dejes que una URL arbitraria proporcionada por el cliente decida a dónde envía tu backend su encabezado de autorización.

Separa las cargas de trabajo antes de compartir credenciales

Evita usar una sola clave para producción, staging, la laptop de un desarrollador y una importación programada. La separación facilita identificar el uso y revocar una carga de trabajo sin romper todo lo demás.

Un inventario inicial útil no contiene secretos sin procesar:

Campo	Ejemplo
Carga de trabajo	Resumidor de soporte al cliente
Entorno	Producción
Responsable	Equipo de la aplicación
Referencia del secreto	Nombre de la entrada en el gestor de secretos
Acceso previsto	Modelo de resumen aprobado
Disparador de revisión	Cambio de despliegue o salida del responsable
Procedimiento de revocación	Enlace al runbook interno

Usa límites de proyecto o de cuenta de servicio del proveedor cuando estén disponibles, en lugar de solo renombrar claves que conservan permisos idénticos. La documentación de proyectos de OpenAI, por ejemplo, describe cuentas de servicio y recursos con alcance de proyecto. Esa es una capacidad específica del proveedor, no una garantía de que cada gateway compatible ofrezca el mismo aislamiento. Administración de proyectos de OpenAI

Almacena los secretos sin distribuirlos innecesariamente

Prefiere un sistema designado de gestión de secretos con acceso limitado a las cargas de trabajo y a los operadores que lo necesiten. Registra los metadatos de propiedad y ciclo de vida por separado del valor de la credencial. OWASP recomienda acceso detallado y gestionar los secretos a lo largo de la creación, rotación, revocación y expiración. Hoja de referencia de gestión de secretos de OWASP

Para una implementación pequeña, una variable de entorno protegida del servidor puede ser un mecanismo de integración, pero no es una estrategia de seguridad completa. Revisa quién puede leer la configuración de la implementación, ejecutar comandos de depuración o inspeccionar reportes de fallos. Nunca imprimas todo el entorno cuando diagnostiques un problema de conexión.

Mantén las credenciales fuera de los archivos de código, las imágenes de contenedor, las capturas de pantalla, los tickets y los mensajes de chat. Usa ejemplos de configuración censurados en la documentación. Un compañero de equipo que soluciona un error generalmente necesita el endpoint, el modelo, el error saneado y el identificador de la solicitud, no la clave en sí.

Define qué significa realmente “presupuesto”

No trates cada presupuesto del panel como un límite máximo de gasto inmediato. Antes de confiar en un control, establece:

• Si envía una alerta o rechaza solicitudes adicionales.
• Si aplica a una clave, un proyecto, una cuenta o un usuario de la aplicación.
• Su periodo de reinicio y zona horaria, si corresponde.
• Cómo se manejan las solicitudes simultáneas y la contabilización retrasada del uso.
• Quién recibe las alertas y quién puede cambiar la configuración.

Documenta lo que no sabes en lugar de suponer un comportamiento favorable. Mantén los controles de admisión y el monitoreo del lado de la aplicación incluso cuando el proveedor ofrezca una función de presupuesto.

Por ejemplo, una aplicación de soporte podría permitir solo su modelo aprobado, restringir el tamaño de la entrada, limitar la salida solicitada y limitar las operaciones diarias de cada cliente. Estos controles cumplen propósitos distintos: una restricción de modelo limita las opciones, un límite de solicitudes limita el volumen y un control de gasto limita la exposición monetaria. Ninguno reemplaza a los demás.

Configura los controles de clave publicados de cheapaimodel

La página de precios pública de cheapaimodel describe presupuestos por clave, fechas de vencimiento, listas de modelos permitidos y listas de IP permitidas. También indica que el presupuesto de una clave no puede exceder lo que el saldo de la cuenta puede financiar, y que un saldo de cuenta agotado hace que las solicitudes a la pasarela devuelvan 403.

Para una nueva integración, elige una lista de modelos permitidos reducida y un presupuesto adecuado para esa carga de trabajo. Asigna una fecha de vencimiento a las integraciones temporales. Considera una lista de IP permitidas cuando tu servidor tenga direcciones de salida conocidas y estables; toma en cuenta la infraestructura de conmutación por error antes de habilitarla.

Estas recomendaciones se basan en la descripción publicada del producto, no en una auditoría independiente de los tiempos de aplicación. No prometas un gasto excedente cero en condiciones de simultaneidad ni confundas una restricción de IP con un reemplazo del secreto de las credenciales. Consulta la documentación actual de cheapaimodel antes de configurar una implementación.

Rota de forma deliberada; revoca con urgencia cuando haya exposición

Para una rotación planificada, usa un traspaso controlado:

1. Identifica cada implementación y trabajo en segundo plano que use la credencial anterior.
2. Crea un reemplazo con las restricciones previstas.
3. Actualiza la referencia o el valor del secreto mediante tu proceso normal de implementación.
4. Confirma que las cargas de trabajo afectadas estén usando el reemplazo.
5. Revoca la credencial anterior y registra que terminaste.

Cualquier superposición debe ser deliberada y breve. No dejes una clave antigua activa indefinidamente “por si acaso”. La expiración también necesita un responsable: una credencial que vence sin un plan de renovación puede convertirse en una interrupción evitable.

Una clave expuesta es diferente. Prioriza la revocación y la contención en lugar de conservar una ventana de migración cómoda. Inspecciona el uso, identifica los despliegues afectados y restaura el servicio con un reemplazo entregado a través del canal de secretos aprobado.

Eliminar una clave filtrada del último commit de Git no la invalida ni elimina las copias existentes. La guía de GitHub coloca la revocación o rotación de credenciales antes de la limpieza del historial del repositorio y explica por qué la limpieza requiere coordinación. Guía de GitHub para eliminar datos sensibles

Haz operativa la propiedad de las claves

Antes del lanzamiento, confirma que alguien pueda responder: ¿quién es dueño de esta clave, qué servicio la consume, qué detiene el uso abusivo y cómo la deshabilitamos?

Una integración manejable tiene respuestas específicas. Si la respuesta es “todos usan la misma clave”, corrige ese límite antes de escalar el tráfico. Una gestión de claves más segura tiene menos que ver con un truco ingenioso de almacenamiento que con mantener el acceso limitado, el gasto visible y la revocación práctica.