Acceder a modelos de IA cuesta dinero, y hay atacantes que prefieren que pague otra persona. Un reportaje del Financial Times del 26 de septiembre aborda el robo de cuentas y servidores para actividades de IA. Una investigación anterior del equipo de inteligencia de amenazas de Google describe la base técnica del fenómeno: robar credenciales y aprovechar la infraestructura de organizaciones para ejecutar cargas de trabajo sin autorización.
El fenómeno se denomina a veces LLM-jacking. No se limita a secuestrar una conversación con un chatbot: una clave API o un permiso de nube pueden permitir consumir una cuota de pago y, en ocasiones, recursos informáticos que la organización nunca pretendió poner a disposición de ese actor.
La cuenta es solo una de las vías de entrada
El informe de Google, publicado a principios de septiembre, describe la demanda de credenciales de servicios de IA y los intentos de robar archivos de configuración de herramientas de desarrollo. Estos archivos pueden contener claves o direcciones de servicios utilizados por los asistentes de programación.
Según los investigadores, los atacantes no buscan únicamente la contraseña del usuario en el navegador. También les interesa cómo se conecta la herramienta de trabajo al modelo, a qué cuenta se le factura y qué permisos se le han concedido.
Es importante distinguir entre las dos fechas de publicación: el artículo del Financial Times es el nuevo reportaje; la investigación de Google es la fuente de contexto para la descripción técnica. Los hallazgos del estudio anterior no deben presentarse como si todos se hubieran revelado por primera vez durante el fin de semana.
El uso no autorizado puede parecer trabajo normal
Para el titular de la cuenta, la primera señal puede ser una cuota agotada, un cargo inusual o una actividad que no ha iniciado. La existencia de ese cargo no demuestra por sí sola una intrusión, pero justifica revisar el historial de uso y las credenciales activas.
Una clave API válida permite a un programa identificarse ante un servicio. Si se expone, cambiar únicamente la contraseña de acceso no necesariamente la invalida. Hay que revisar la propia clave y los permisos asociados.
Qué conviene comprobar en una organización
Se recomienda separar las claves entre sistemas, conceder a cada una solo los permisos necesarios y configurar alertas de uso y presupuesto cuando el servicio lo permita. Una clave expuesta debe revocarse y sustituirse, no solo eliminarse del documento en el que apareció.
Conviene ampliar la revisión a los repositorios de código y los entornos de desarrollo. Cuando la IA pasa a formar parte de las herramientas de trabajo, sus credenciales se convierten en un activo que debe gestionarse como cualquier otro secreto de la organización. La protección empieza por identificar quién puede utilizar el recurso, no solo quién puede abrir la interfaz del chat.