Claves API olvidadas: cómo revocarlas sin detener el servicio

Una revisión interna de OpenRouter detectó más de 1.000 claves API activas entre 85 empleados; según la empresa, 168 claves no se habían utilizado en meses. Estas cifras proceden de una auditoría interna de OpenRouter, no de un estudio independiente del sector. Pero incluso como ejemplo particular, muestran una trampa de ingeniería conocida: es fácil olvidar una clave, pero no la aplicación que depende de ella. La empresa fechó el anuncio de Security Center el 28 de septiembre de 2026.

El problema no consiste simplemente en encontrar la credencial más antigua y eliminarla. El equipo debe identificar a su propietario, averiguar dónde se usa la clave y entender cómo sustituirla sin interrumpir una tarea poco frecuente o un servicio olvidado. Sin esa información, revocar el acceso pasa de ser una labor de limpieza a un experimento arriesgado.

Qué muestra Security Center y qué no demuestra

Según la descripción de OpenRouter, Security Center reúne las claves de una cuenta y muestra el propietario, el último uso, el límite de gasto y la fecha de vencimiento; los administradores de la organización pueden ver todas las claves y los miembros, solo las que han creado. Para las acciones en bloque se pueden seleccionar hasta 500 claves: desactivarlas, archivarlas o establecer un límite de gasto. La desactivación es reversible; el archivado, no. Estas son características de la herramienta descritas por el propio proveedor, no una evaluación independiente de su eficacia.

Es especialmente importante interpretar el estado «se puede eliminar» como una indicación para comprobar, no como prueba de que no haya dependencias. La métrica de uso muestra las solicitudes pasadas, pero no necesariamente explica a qué tarea programada, escenario de emergencia o proceso estacional pertenece la clave. OpenRouter recomienda confirmar la eliminación con el propietario; la documentación sobre la configuración de seguridad también advierte que hay que comprobar las dependencias antes de desactivar o archivar una clave.

Las restricciones de red tienen una salvedad propia: la lista de IP permitidas está disponible para los administradores del plan Enterprise y se aplica a todas las claves de la organización. Las solicitudes desde direcciones que no figuren en la lista se rechazan con un error 403, y los cambios se aplican de inmediato. Por eso, antes de activar la restricción, hay que tener en cuenta las direcciones de los servidores de producción, la red de la oficina y los ejecutores de CI; de lo contrario, la propia medida de seguridad podría interrumpir llamadas legítimas.

Proceso de limpieza: primero el propietario, después la revocación

1. Elabora un inventario. Registra el propietario, la finalidad, el entorno, los consumidores, el límite de gasto y la fecha de vencimiento de cada clave. Si el sistema solo identifica al propietario como una persona, asigna también un equipo o servicio que se haga responsable cuando esa persona se vaya.
2. Comprueba el uso y las dependencias. Compara la hora de la última solicitud con los horarios de las tareas en segundo plano, los escenarios de recuperación, los pipelines de lanzamiento y las integraciones externas. La falta de actividad reciente es motivo para preguntar al propietario, no justificación suficiente para eliminar la clave de inmediato.
3. Reduce el riesgo antes de la migración. Cuando sea posible, establece un límite de gasto razonable y una fecha de vencimiento. Consulta el principio de mínimo privilegio y las normas de almacenamiento de secretos: la guía de OWASP para la gestión de secretos trata el inventario, el acceso y el ciclo de vida de las credenciales como partes diferenciadas del proceso.
4. Crea un reemplazo y migra a los consumidores. Actualiza el secreto en el almacén o en la configuración de despliegue y, después, migra las aplicaciones por etapas. No incluyas el valor de la clave en tickets, registros ni código fuente.
5. Verifica producción antes de revocar. Asegúrate de que la nueva clave funcione en todos los consumidores conocidos, incluidos CI y las tareas poco frecuentes. Después, desactiva primero la clave anterior si existe una operación reversible; archívala o elimínala cuando hayas confirmado la migración y haya transcurrido el periodo de observación previsto.

La secuencia «crear una clave nueva → migrar las aplicaciones → comprobar que todo funciona → eliminar la clave antigua» coincide con las instrucciones de OpenRouter para rotar claves. Es el orden recomendado, no una garantía de que no haya interrupciones: el resultado depende de si has encontrado todos los sistemas que utilizan la credencial.

Las claves de un servicio no son todos los secretos de la organización

El panel de un proveedor concreto ayuda a gestionar las claves de ese servicio, pero no centraliza por sí solo los secretos de la nube, las bases de datos, CI/CD y otras API. Las recomendaciones de OWASP sobre el ciclo de vida de los secretos abarcan el almacenamiento centralizado, el control de acceso, las auditorías, la rotación y la revocación. Por su parte, las recomendaciones de Google Cloud aconsejan limitar el ámbito de uso de las claves, eliminar las credenciales innecesarias y supervisar su utilización.

OpenRouter también afirma que Security Center utiliza metadatos de las claves, gastos y fechas de vencimiento, y no lee los prompts ni las respuestas. Esta es una declaración del propio proveedor; entre las fuentes examinadas no hay una verificación técnica independiente. En general, la existencia de un panel tampoco demuestra que el equipo ya haya reducido los incidentes o los gastos: en los materiales consultados no se encontraron resultados públicos posteriores al lanzamiento.