Una empresa había integrado la API de inferencia de IA de un proveedor en sus flujos de trabajo de ciencia de datos, lo que daba a sus analistas y científicos de datos acceso programático al modelo de lenguaje del proveedor para apoyo en investigación y procesamiento de documentos. El portal para desarrolladores del proveedor emitía claves de API que autenticaban el acceso al endpoint de inferencia. Las claves se generaban por proyecto mediante un portal de autoservicio y no estaban sujetas a los controles estándar de gestión de credenciales de la empresa, que se aplicaban a las credenciales de infraestructura pero no se habían extendido a las claves de API de IA. Un científico de datos que trabajaba en un proyecto de prueba de concepto incrustó la clave de API en un notebook de Jupyter para simplificar el flujo de trabajo de desarrollo. El notebook se confirmó en un repositorio de GitHub compartido con colegas para colaborar. El repositorio estaba configurado como público por defecto: el desarrollador tenía la intención de hacerlo privado, pero no lo había hecho antes de confirmar el notebook con la clave incrustada. Un bot de búsqueda de credenciales descubrió la clave expuesta en un plazo de seis semanas y comenzó a usarla para realizar llamadas de inferencia al modelo de IA del proveedor. El operador del bot consumió una parte significativa de la cuota mensual de límite de solicitudes de la empresa, generó cargos de API en la cuenta de la empresa y tuvo acceso a los patrones de consulta que se enviaban al modelo, lo que podía revelar los temas de investigación de la empresa y sus flujos de trabajo de procesamiento de documentos. El modelo de IA del proveedor no fue vulnerado. La clave de API de la empresa, generada por los canales normales, gestionada fuera del programa de gestión de credenciales y expuesta mediante un flujo de trabajo de desarrollo estándar, constituía toda la superficie de ataque.
¿Qué es realmente la exposición de claves de API de IA?
La exposición de claves de API de IA es el riesgo de seguridad que se genera cuando las credenciales que autentican el acceso a las API de modelos de IA (claves emitidas por portales para desarrolladores de proveedores de IA, endpoints de inferencia e infraestructura de servicio de modelos) se generan, gestionan, almacenan y usan fuera del programa de gestión de credenciales establecido por la empresa. La proliferación de claves de API de IA mediante portales de autoservicio para desarrolladores, entornos de notebooks de ciencia de datos y herramientas de desarrollo basadas en IA ha creado una nueva categoría de credenciales a la que las empresas no siempre han extendido sus prácticas estándar de higiene de credenciales.
La vía de exposición en los flujos de trabajo de desarrollo es el principal mecanismo de riesgo. Las claves de API de IA se utilizan con frecuencia en contextos exploratorios y de desarrollo (notebooks de ciencia de datos, proyectos de prueba de concepto, prototipado rápido), donde el flujo de trabajo de desarrollo prioriza la velocidad de iteración sobre la higiene de seguridad. Incrustar credenciales en notebooks de Jupyter, configurarlas en archivos de entorno que se confirman en el control de versiones y compartir directorios de proyectos que contienen credenciales mediante herramientas de colaboración son patrones habituales en los flujos de trabajo de ciencia de datos que generan riesgos sistemáticos de exposición de credenciales.
El punto ciego de la categoría de credenciales de IA es la brecha de gobernanza. Los programas empresariales de gestión de credenciales suelen abordar las credenciales de infraestructura (claves de acceso de proveedores de nube, credenciales de bases de datos, tokens de cuentas de servicio) mediante políticas, herramientas y supervisión. Las claves de API de IA de los portales para desarrolladores de los proveedores suelen quedar fuera del alcance de estos programas porque no son credenciales de infraestructura en el sentido tradicional. Se emiten por un canal diferente (el portal para desarrolladores del proveedor), se usan en un contexto diferente (notebooks de ciencia de datos en lugar de infraestructura de producción) y las gestionan personas diferentes (científicos de datos y analistas en lugar de equipos de TI). El punto ciego del programa de gestión de credenciales es la credencial del portal del proveedor de IA.
La variación del radio de impacto entre proveedores de IA es una dimensión importante. La consecuencia de una clave de API de IA expuesta varía significativamente según el proveedor y el alcance de los permisos de la clave. Una clave con acceso solo a llamadas de inferencia expone a la empresa al abuso de costos de API y a la divulgación de sus patrones de consulta. Una clave con acceso al ajuste fino de modelos expone a la empresa al entrenamiento no autorizado de modelos en la infraestructura del proveedor. Una clave con acceso a las API de gestión de datos del proveedor puede exponer datos de entrenamiento o datos de la organización almacenados en el proveedor. Comprender el alcance de los permisos de las claves de API emitidas es esencial para evaluar la consecuencia de la exposición.
Por qué es importante
La exposición de claves de API de IA es relevante para TPRM porque las relaciones de la empresa con proveedores de IA, cada vez más numerosas a medida que la IA se integra en todas las funciones del negocio, generan una población creciente de credenciales que autentican el acceso a capacidades sensibles de IA y pueden exponer al modelo del proveedor los patrones de consulta y los datos de la empresa. Cada relación con un proveedor de IA que genera claves de API fuera del programa de gestión de credenciales de la empresa es un riesgo sistemático de exposición de credenciales.
Dónde se equivocan la mayoría de los equipos
La falla más sistemática es extender la gobernanza de la gestión de credenciales a las credenciales de infraestructura y tratar las claves de API de los proveedores de IA como ajenas al alcance del programa, porque las emiten los portales para desarrolladores de los proveedores en lugar de aprovisionarlas TI, y porque sus principales usuarios son científicos de datos y no ingenieros.
- Claves de API de proveedores de IA fuera del programa de gestión de credenciales
- Emisión de claves en el portal para desarrolladores sin seguimiento por parte de TI ni de seguridad
- Entorno de notebooks de ciencia de datos no cubierto por la política de higiene de credenciales
- Alcance de los permisos de la clave no evaluado: a qué puede acceder la clave más allá de la inferencia
- Análisis de credenciales no aplicado a los repositorios de proyectos de IA
Cómo se ve una buena práctica
Los programas maduros de seguridad de credenciales de IA extienden explícitamente la gobernanza de la gestión de credenciales a las claves de API de los proveedores de IA, lo que incluye el seguimiento de su emisión, su almacenamiento en una infraestructura aprobada de gestión de secretos, políticas de rotación y el análisis automatizado de los repositorios de desarrollo en busca de credenciales de IA expuestas.
- Registro de claves de API de IA: todas las claves con seguimiento de responsable, alcance y vencimiento
- Integración de la gestión de secretos: claves de IA almacenadas en un almacén seguro, no en notebooks ni en archivos de configuración
- Análisis automatizado de credenciales: los repositorios se analizan en busca de claves de API de IA expuestas
- Delimitación de los permisos de las claves: los permisos mínimos necesarios para el caso de uso de cada clave
- Política para los flujos de trabajo de desarrollo: requisitos de manejo de claves de API de IA en los entornos de ciencia de datos
Herramientas
Análisis de credenciales: GitHub secret scanning, GitLeaks, TruffleHog para la detección de claves de API de IA
Las herramientas de análisis de credenciales detectan claves de API y secretos en los repositorios de control de versiones. La mayoría de las principales herramientas de análisis incluyen patrones de detección para los formatos de claves de API de los principales proveedores de IA: OpenAI, Anthropic, Cohere, Hugging Face. Para los profesionales de TPRM, preguntar si los repositorios de desarrollo del proveedor se analizan con una herramienta automatizada en busca de credenciales de API de IA expuestas aporta una pregunta concreta sobre la exposición de credenciales.
Gestión de secretos: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault para el almacenamiento de credenciales de IA
Las plataformas de gestión de secretos ofrecen almacenamiento centralizado, rotación y registro de accesos para credenciales, incluidas las claves de API de IA. Para los profesionales de TPRM, preguntar si las claves de API de IA del proveedor se almacenan en una plataforma de gestión de secretos en lugar de en la configuración de aplicaciones, notebooks o archivos de entorno aporta una pregunta concreta sobre la higiene de credenciales.
Desafíos de gobernanza
El desafío de gobernanza en la gestión de claves de API de IA es la tensión con la cultura de los desarrolladores. Los flujos de trabajo de ciencia de datos y de ingeniería de ML han funcionado tradicionalmente con más informalidad en la gestión de credenciales que la ingeniería de producción: la naturaleza exploratoria del trabajo genera presión para priorizar la comodidad sobre la higiene. La solución de gobernanza son herramientas que hagan de la gestión segura de credenciales el camino de menor resistencia: la inyección de secretos en los entornos de desarrollo que elimine la necesidad de incrustar credenciales en notebooks o archivos de configuración.
- Extienda explícitamente la política de gestión de credenciales a las claves de API de los proveedores de IA
- Implemente el análisis automatizado de claves de API de IA en todos los repositorios de desarrollo
- Exija la gestión de secretos para las credenciales de IA: nada de incrustarlas en notebooks ni en archivos de configuración
- Haga seguimiento de la emisión de claves de API en los portales para desarrolladores: notifique al equipo de seguridad cada generación de una nueva clave
- Limite las claves de API de IA a los permisos mínimos necesarios
Si usted forma parte de un equipo pequeño
Ejecute un análisis de credenciales en todos los repositorios donde se realiza desarrollo de ciencia de datos e IA, buscando específicamente los formatos de claves de API de todos los proveedores de IA que utiliza la empresa. La mayoría de las principales herramientas de análisis tienen patrones para las claves de OpenAI, Anthropic, Cohere y Hugging Face. Ese único análisis revelará si se han confirmado credenciales de IA en el control de versiones. Después, pida a sus proveedores de IA que enumeren todas las claves de API activas emitidas a su organización: comparar esa lista con lo que contiene su inventario de credenciales revelará las claves de las que TI y seguridad no hacen seguimiento.
- Ejecute un análisis de credenciales en todos los repositorios de proyectos de ciencia de datos e IA
- Pida a los proveedores de IA que enumeren todas las claves de API activas emitidas a su organización
- Compare la lista de claves del proveedor con el inventario de credenciales de la empresa
- Exija la gestión de secretos para todas las credenciales de API de IA
Qué exigir
Pregunte directamente:
“¿Pueden proporcionar una lista de todas las claves de API emitidas actualmente a nuestra organización, con el alcance de los permisos y la fecha del último uso de cada una? ¿Cuentan con una supervisión que alertaría a nuestro equipo de seguridad si una clave emitida a nosotros se usara desde una dirección IP fuera de nuestro rango de red esperado?”
Evidencia que debe esperar
- Inventario de claves de API activas de la organización
- Alcance de los permisos de cada clave emitida
- Capacidad de alerta ante usos anómalos de las claves
- Proceso y plazo de revocación de claves
A un proveedor que confirma la autenticación mediante claves de API se le debe solicitar el inventario de claves activas. La autenticación confirma que el mecanismo funciona. El inventario de claves revela si lo que autentica está bajo el control de la empresa.
Cómo demostrarlo
- Registro e inventario de claves de API de IA
- Registros del análisis de credenciales en los repositorios de proyectos de IA
- Implementación de la gestión de secretos para las credenciales de IA
- Registros del alcance y la rotación de las claves
Conclusión clave
Portal para desarrolladores. Clave de API. Notebook de Jupyter. Repositorio público de GitHub. Bot de búsqueda de credenciales. Seis semanas. La clave siguió el camino normal desde su emisión hasta su exposición sin activar ninguna detección en el programa de gestión de credenciales de la empresa, porque las claves de API de IA de los portales para desarrolladores de los proveedores quedaban fuera del alcance del programa. Las credenciales de infraestructura se gestionan. Las claves de los proveedores de IA son credenciales de los flujos de trabajo de ciencia de datos a las que el programa no se extendió. El análisis detecta las claves expuestas. El registro hace seguimiento de las emitidas. La plataforma de gestión de secretos impide la incrustación. La delimitación del alcance limita el radio de impacto cuando la exposición ocurre pese a la prevención. Las cuatro medidas son necesarias para cerrar la brecha entre el portal para desarrolladores y el repositorio público.