Los ataques de LLM-jacking de Google convierten el acceso a la IA en una mercancía robada
Google afirma que los delincuentes están robando cuentas de IA y credenciales de nube a medida que el coste de los modelos premium crea un creciente mercado clandestino de acceso.
La advertencia de septiembre de 2026 cambia el foco de la seguridad de la IA. Las empresas han dedicado años a debatir si los atacantes pueden manipular o comprometer los propios modelos. Google describe ahora un problema más inmediato: los atacantes están robando las cuentas, las claves de API, los archivos de configuración y los recursos en la nube que rodean a esos modelos.
Los consiguientes ataques de LLM-jacking de Google enfrentan el acceso a la IA, que se expande rápidamente, con controles de identidad diseñados para servicios de software convencionales. El LLM-jacking consiste en usar credenciales comprometidas para consumir el acceso de pago a modelos o la capacidad de cómputo de otra persona. La técnica salió a la luz públicamente en 2024, pero las evidencias de Google sugieren que ha entrado en una economía criminal más amplia.
Los ataques de LLM-jacking de Google se expanden más allá de las claves de API robadas
La conclusión central de Google es que el acceso a la IA se ha vuelto lo suficientemente valioso como para ser robado, comercializado, agrupado y revendido.
La evaluación de amenazas de septiembre provino del Google Threat Intelligence Group, o GTIG. Sus evidencias se basan en trabajos de respuesta a incidentes de Mandiant, seguimiento de actores de amenazas, foros clandestinos y actividad observada en los servicios de Google.
GTIG encontró más compradores buscando cuentas relacionadas con IA durante 2026. Los investigadores también observaron a más vendedores anunciándolas. Según los informes, la demanda se concentró en credenciales para Claude y Gemini, mientras que las cuentas para entornos de programación autónoma también despertaron interés.
Google no publicó un número total de cuentas robadas. Sí informó de que los precios medios clandestinos por cuenta se duplicaron con creces durante 2026. Ese detalle importa porque apunta a una respuesta del mercado, no simplemente a robos aislados de credenciales.
Los atacantes buscan acceso premium a la IA por varias razones. Las cuentas de pago ofrecen límites de uso más altos, modelos más potentes y menos interrupciones que las cuentas gratuitas desechables. Las credenciales de API también pueden respaldar cargas de trabajo automatizadas que sería difícil mantener mediante una interfaz de chat para consumidores.
Las credenciales de nube tienen un valor aún mayor. Una identidad comprometida puede exponer modelos alojados, permisos de despliegue, almacenamiento y costosos recursos de cómputo. Los atacantes pueden entonces ejecutar cargas de trabajo de inferencia mientras la víctima asume las consecuencias de uso y operativas.
Google vincula este comportamiento con el LLM-jacking, mediante el cual los delincuentes se apoderan de servicios de modelos de pago o infraestructura de nube sin autorización. El objetivo inmediato puede ser el acceso gratuito, pero la misma infraestructura puede respaldar phishing, investigación de vulnerabilidades, desarrollo de malware o reventa.
Esto va más allá de que alguien encuentre una clave de API filtrada en un repositorio público. Google observó un ecosistema que incluye cuentas robadas, registros automatizados, agrupación de cuentas, agregación de API, servicios proxy y herramientas de evasión de detección.
La agrupación de cuentas combina varias identidades o claves de API detrás de un mismo servicio. Esa disposición puede distribuir el uso, reducir el efecto de prohibiciones individuales y dificultar la atribución de la actividad. Un agregador también puede presentar varios proveedores a través de una única interfaz compatible.
Google documentó anteriormente actores que utilizaban servicios que consolidaban cuentas de Gemini, Claude y OpenAI. Su informe de amenazas de mayo describió herramientas para registro automatizado, verificación, enrutamiento, seguimiento de cuotas y ocultación de huellas digitales del navegador.
Algunas de esas herramientas tienen usos legítimos. Los desarrolladores suelen enrutar solicitudes entre modelos para mejorar la disponibilidad o controlar cargas de trabajo internas. La preocupación de seguridad surge cuando los operadores llenan esos sistemas con cuentas robadas o creadas fraudulentamente.
Esa distinción evita un error analítico común. El software proxy no prueba por sí solo una actividad delictiva. Sin embargo, la combinación de credenciales robadas, registro evasivo, tráfico oculto y reventa no autorizada crea una cadena de abuso reconocible.
Google también encontró atacantes que apuntaban a almacenes de configuración locales utilizados por asistentes de programación con IA. En mayo de 2026, controladores asociados con la familia de malware ACRSTEALER emitieron reglas de captura de archivos para secrets.json de Cline y config.yaml de Continue AI.
Estos archivos pueden contener claves de API en texto plano o endpoints personalizados de enrutamiento de modelos. Una sesión de navegador robada podría exponer una cuenta de usuario, mientras que una configuración de desarrollador puede abrir una vía hacia cuotas e infraestructura organizacionales.
Por tanto, el límite práctico de una cuenta de IA se ha vuelto difícil de definir. Puede incluir una identidad, un token de sesión, un secreto de API, una configuración de línea de comandos, un rol en la nube y permiso para invocar varios modelos externos.
Para los equipos de seguridad, ese límite ampliado genera la tensión central del artículo. Las organizaciones quieren integrar el acceso a modelos en todo el trabajo cotidiano, pero cada integración conveniente crea otro lugar desde el que pueden escapar credenciales valiosas.
Por qué el robo de cuentas de IA presiona ahora a todos los clientes de nube
La presión recae sobre las organizaciones que adoptan la IA con mayor rapidez porque su acceso a modelos se está extendiendo más rápido que la responsabilidad de su seguridad.
Una cuenta de software convencional robada suele dar a un atacante acceso a datos o funciones de aplicaciones. Una cuenta de IA robada puede añadir consumo medido de modelos, cómputo en la nube, herramientas autónomas y conexiones con conocimiento interno.
Esa combinación cambia el daño potencial. Una credencial comprometida puede generar una factura, exponer información confidencial y proporcionar infraestructura para ataques contra otros objetivos. Al principio, la víctima puede observar solo un uso inusual en lugar de una señal de intrusión conocida.
Los desarrolladores afrontan una exposición particular. Los asistentes de programación con IA suelen ejecutarse junto a repositorios de código fuente, terminales, gestores de paquetes y herramientas de despliegue. Sus archivos de configuración pueden revelar credenciales con un alcance mucho mayor que el de un único historial de chat.
El uso creciente de IA agéntica eleva aún más lo que está en juego. Un sistema agéntico permite que un modelo planifique pasos y opere herramientas con menor intervención humana. Sus credenciales pueden autorizar acceso a archivos, ejecución de código, navegación o comunicación con servicios externos.
Google informó de que los actores de amenazas también están adoptando marcos multiagente para flujos de trabajo ofensivos. Estos sistemas pueden coordinar escaneos, resolver errores y gestionar la recolección de credenciales con menos pausas para decisiones humanas.
Un caso del segundo trimestre de 2026 condensó ese cambio en una cronología llamativa. GTIG observó que los atacantes comprometieron un recurso en la nube y, después, planificaron, construyeron y ejecutaron una campaña masiva de recolección de credenciales habilitada por agentes en menos de seis horas.
Ese hallazgo no significa que todos los grupos delictivos operen ya sistemas autónomos de ataque. Muestra que la automatización puede acortar el periodo entre el acceso inicial y la explotación escalable.
Tradicionalmente, los defensores dependen del tiempo entre esas etapas. Una alerta puede desencadenar una investigación antes de que un atacante amplíe el acceso, establezca persistencia o llegue a sistemas sensibles. Un ciclo de construcción y ejecución de seis horas deja mucho menos margen para la clasificación manual.
El valor de las credenciales de IA robadas también se extiende más allá de sus cuotas directas. Un archivo de configuración puede exponer un endpoint privado, mientras que la identidad de nube relacionada puede revelar registros, almacenes de datos o aplicaciones conectadas.
Por ello, las organizaciones deberían tratar el robo de cuentas de IA de Google como un problema de seguridad de identidad, y no solo como una cuestión de gobernanza de IA. El punto de control suele ser la credencial y sus permisos circundantes, más que la capa de seguridad del modelo.
Los secretos de larga duración crean el riesgo más evidente. Pueden seguir siendo utilizables después de que un empleado cierre un portátil o cambie una contraseña web. Los atacantes pueden probarlos discretamente, enrutar tráfico a través de proxies y aumentar el uso tras confirmar los servicios disponibles.
Las cuentas compartidas de desarrolladores crean otra debilidad. Cuando varias personas o sistemas automatizados usan una misma identidad, resulta más difícil atribuir actividad inusual. Revocar el acceso también puede interrumpir trabajo legítimo, lo que puede retrasar la contención.
Los clientes de nube afrontan un segundo problema: el consumo parece normal en el nivel de infraestructura. Una clave válida que realiza solicitudes válidas a modelos puede no activar controles diseñados para detectar malware o tráfico de red prohibido.
Los equipos necesitan señales de comportamiento en su lugar. Los indicadores útiles incluyen nuevos orígenes geográficos, activación inesperada de modelos, cambios repentinos de cuota, pasarelas de API desconocidas, tiempos anómalos de las solicitudes y uso incoherente con el propietario de la credencial.
Los proveedores de modelos también soportan presión. Deben distinguir la agregación legítima de la agrupación criminal sin bloquear arquitecturas empresariales habituales. También necesitan conectar señales de cuentas, red, pagos, dispositivos y uso en productos que cambian rápidamente.
La respuesta impuesta es un rediseño de la identidad en torno al acceso a la IA. Las organizaciones necesitan credenciales de corta duración, permisos más limitados, identidades de servicio separadas, límites de uso, revocación rápida y monitorización vinculada al comportamiento esperado.
Estas medidas resultan familiares porque los fallos subyacentes también lo son. Lo que ha cambiado es el activo que se monetiza y la velocidad con la que el acceso robado puede respaldar más operaciones.
La verdadera disyuntiva es la comodidad de la IA frente al control de credenciales
La adopción de la IA elimina fricción para los usuarios, pero esa misma comodidad puede ocultar credenciales en herramientas, complementos, agentes y archivos locales.
La mayoría de las organizaciones no despliega un único sistema de IA gestionado centralmente. Los empleados usan aplicaciones de navegador, asistentes de programación, clientes de línea de comandos, pasarelas de modelos, plataformas de nube, extensiones y automatizaciones personalizadas.
Cada vía de acceso gestiona la identidad de manera diferente. Una puede usar una cookie de sesión, otra una clave de API y otra un rol de nube heredado del entorno del usuario. Los equipos de seguridad pueden tener dificultades para inventariar las tres.
Las herramientas de programación con IA hacen especialmente visible esta disyuntiva. Los desarrolladores esperan una configuración rápida y acceso ininterrumpido a los modelos. Guardar una clave en un archivo de configuración es cómodo, pero el malware que ya busca en sistemas locales puede añadir ese archivo a su lista de recopilación.
Los hallazgos de Google muestran que los infostealers se están adaptando en consecuencia. Operadores de LUMMAC.V2, STEALC.V2, VIDAR y ACRSTEALER mostraron interés en configuraciones de desarrolladores de IA, yendo más allá del robo de perfiles de navegador.
Los infostealers son malware diseñado para recopilar información valiosa de un dispositivo infectado. Suelen apuntar a contraseñas, cookies, billeteras y datos de aplicaciones. Añadir archivos de configuración de IA es una extensión lógica de un modelo de negocio establecido.
Este mecanismo ayuda a explicar por qué el problema puede crecer sin un avance drástico contra los modelos de frontera. Los atacantes no necesitan derrotar la arquitectura de seguridad central de un modelo si pueden hacerse pasar por un usuario de pago.
Google ha trazado repetidamente esa distinción. Sus hallazgos de febrero indicaron que los atacantes necesitaban claves de API y recursos para hacer un uso indebido de los servicios LLM a escala. Ese requisito crea un incentivo directo para secuestrar organizaciones con una capacidad sustancial de IA.
El conflicto se agudiza cuando los agentes reciben permisos amplios para usar herramientas. Un agente puede necesitar acceso a repositorios, documentación, rastreadores de incidencias y sistemas de despliegue para ofrecer asistencia útil. Cada conector añadido incrementa tanto la utilidad como la exposición potencial.
Una credencial de IA robada no concede automáticamente todos esos permisos conectados. El resultado depende de cómo la organización diseñó la autenticación y autorización. Sin embargo, las identidades mal separadas pueden convertir un secreto robado en varias vías de acceso.
Los secretos no deben estar en prompts, archivos de código fuente, notebooks ni directorios de configuración de lectura amplia. Las organizaciones deben almacenarlos en sistemas de gestión de secretos y entregarlos únicamente a la carga de trabajo que los necesita.
Esa recomendación es fácil de formular y más difícil de aplicar. Los desarrolladores pueden crear experimentos temporales fuera de las plataformas centrales. Los equipos pueden compartir credenciales para cumplir un plazo, mientras que prototipos abandonados pueden conservar claves activas durante meses.
Las puertas de enlace de IA pueden reducir la dispersión al centralizar la autenticación y las políticas. También pueden convertirse en objetivos de alto valor. Si una puerta de enlace tiene acceso a muchos proveedores y cuotas amplias, comprometerla proporciona a un atacante un conjunto concentrado de capacidad.
La respuesta no es evitar las puertas de enlace. Es limitar lo que puede invocar cada identidad de puerta de enlace, establecer atribución por usuario e impedir que un componente comprometido active servicios no relacionados.
Las organizaciones también deben separar el acceso a modelos del acceso administrativo. Un servicio que envía solicitudes de inferencia no debería recibir automáticamente permiso para modificar la facturación, habilitar nuevos modelos, crear identidades o recuperar secretos de nube no relacionados.
La autenticación sólida importa para las cuentas interactivas, pero la autenticación multifactor no resuelve todas las vías. Las claves de API y las identidades de servicio suelen operar sin un desafío interactivo, y el material de sesión robado a veces puede eludir un inicio de sesión reciente.
Las credenciales de corta duración reducen esa exposición. También lo hacen los sistemas de identidad de cargas de trabajo que sustituyen claves estáticas por tokens temporales basados en el contexto verificado de la aplicación en ejecución.
Los controles de uso aportan otra capa. Los presupuestos por identidad, límites de tasa, listas de modelos permitidos y alertas para nuevas regiones pueden reducir el tiempo y la capacidad disponibles para un atacante.
Los registros también deben conservar suficiente contexto para la investigación. Una solicitud a un modelo debe poder rastrearse hasta un usuario, servicio, entorno y propósito aprobado sin exponer innecesariamente el contenido sensible de los prompts.
Para los trabajadores del conocimiento, la lección es más personal. Una extensión de navegador, una utilidad de programación descargada o un cliente no oficial pueden situarse entre el usuario y varios servicios de IA de pago. Instalar uno implica una decisión de confianza sobre cómo almacena y transmite las credenciales.
Los empleados no deben pegar claves de API de la organización en herramientas no aprobadas. También deben informar de alertas de inicio de sesión inesperadas, avisos de uso de modelos y agotamiento repentino de cuotas como posibles incidentes de seguridad, en lugar de tratarlos como errores de facturación ordinarios.
La disyuntiva entre comodidad y control no puede eliminarse. Las herramientas de IA resultan útiles al acceder a más información y realizar más acciones. El enfoque defendible consiste en hacer que cada conexión sea visible, limitada, atribuible y fácil de revocar.
La advertencia de Google no mide la escala completa del LLM-jacking
La evidencia muestra una amenaza real y en proceso de maduración, pero no establece cuántas organizaciones han sufrido pérdidas por LLM-jacking.
El informe de Google utiliza lenguaje direccional como “mayor focalización” y “número creciente de intrusiones”. Ofrece ejemplos, tácticas observadas, tendencias de mercado y casos de respuesta a incidentes, en lugar de una estimación completa de prevalencia.
Esa limitación importa. La inteligencia de amenazas refleja los entornos, clientes, plataformas y espacios clandestinos visibles para los investigadores que la recopilan. La actividad fuera de ese campo de visión puede no contabilizarse, mientras que los actores sometidos a una intensa vigilancia pueden parecer más relevantes.
La duplicación reportada del precio promedio de las cuentas clandestinas es informativa, pero incompleta. Google no publicó el tamaño de muestra subyacente, la distribución de precios ni la metodología necesaria para comparar ese mercado rigurosamente a lo largo del tiempo.
Los precios más altos pueden indicar una demanda creciente, oferta restringida, mejor calidad de las cuentas o cambios en los mercados que se siguen. No demuestran de forma independiente que el robo exitoso de cuentas se haya duplicado.
Por tanto, el encuadre de un “aumento” debe interpretarse como evidencia de un incremento de la actividad observada, no como un censo de incidentes globales. Las afirmaciones más sólidas de Google se refieren a lo que sus equipos vieron directamente: más compradores y vendedores, robo dirigido de configuraciones y compromisos de nube que respaldan cargas de trabajo no autorizadas.
También existe un problema terminológico. LLM-jacking puede describir varios comportamientos relacionados, desde usar una única clave de API robada hasta secuestrar un entorno de nube empresarial. Agruparlos bajo una sola etiqueta puede ocultar diferencias sustanciales de impacto.
La investigación pública original sobre credenciales de nube robadas definió el LLM-jacking en torno al uso no autorizado de servicios de modelos alojados. Informes posteriores ampliaron el panorama hacia redes proxy, reventa y desarrollo de agentes ofensivos.
Esa historia ofrece una comparación útil. El cryptojacking en la nube siguió una lógica económica similar: los atacantes robaban capacidad informática porque la víctima pagaba la factura. Las cargas de trabajo de IA crean otro uso monetizable para la infraestructura comprometida.
Sin embargo, el LLM-jacking puede generar riesgos más allá de los costes de consumo. El acceso a modelos puede ayudar a un atacante a analizar código robado, generar señuelos localizados, automatizar investigaciones o crear servicios para otros delincuentes.
Los propios hallazgos de Google requieren otra salvedad. La empresa afirma que los atacantes se están convirtiendo en usuarios más capaces de la IA, pero también ha informado de que muchos intentos de abuso de modelos activaron sistemas de seguridad o no produjeron un salto significativo de capacidades.
En investigaciones anteriores, grupos respaldados por Estados utilizaron Gemini para investigación, programación, traducción y resolución de problemas. Google deshabilitó activos relacionados y actualizó sus defensas. No concluyó que esos actores hubieran derrotado las salvaguardas principales del modelo.
Ese contraste es importante. El robo de cuentas proporciona acceso, pero el acceso no garantiza resultados sin restricciones ni operaciones exitosas. Los proveedores aún pueden detectar abusos, aplicar políticas, deshabilitar cuentas y actualizar las protecciones de los modelos.
Los delincuentes también pueden preferir cuentas robadas precisamente porque la aplicación de medidas de seguridad sigue activa. Los conjuntos de identidades desechables pueden ayudarles a absorber bloqueos, distribuir solicitudes y ocultar el patrón general.
El conflicto resultante no consiste simplemente en atacantes contra las barreras de seguridad de los modelos. Se trata de atacantes que rotan identidades más rápido de lo que proveedores y clientes pueden conectar comportamientos sospechosos entre cuentas.
La investigación independiente respalda el mecanismo subyacente. Sysdig documentó el LLM-jacking en 2024 y más tarde informó de objetivos y tácticas más variados. Sin embargo, la investigación de proveedores suele proceder de incidentes seleccionados, en lugar de una muestra global representativa.
Los lectores deben evitar dos conclusiones opuestas. Sería erróneo descartar la amenaza porque Google carece de un recuento global. También sería erróneo afirmar que toda cuenta de IA o cliente de nube afronta un compromiso inmediato.
La conclusión defendible es más limitada. El acceso robado a IA ahora tiene valor observable en mercados, vías técnicas establecidas y uso delictivo demostrado. Eso basta para justificar controles específicos sin inflar la evidencia disponible.
Qué vigilar tras la advertencia de Google sobre el robo de cuentas de IA
La próxima fase estará definida por la telemetría de los proveedores, la focalización de los infostealers y la capacidad de las empresas para aislar las identidades de IA antes de que los atacantes escalen su acceso.
La primera señal será una información más detallada de los proveedores de modelos y nube. Google ha establecido una dirección, pero los informes futuros necesitan recuentos de incidentes, tipos de credenciales afectados, duración del abuso y una metodología de mercado más clara.
Esas divulgaciones reforzarían la tesis de que los ataques de LLM-jacking de Google representan una categoría de crecimiento diferenciada. La ausencia de una expansión medible sugeriría que los informes actuales combinan varias formas consolidadas de abuso de credenciales bajo una etiqueta específica de IA.
La segunda señal es el comportamiento de los operadores de infostealers. Google observó reglas dirigidas a configuraciones de asistentes de programación con IA, lo que demuestra que los delincuentes saben dónde almacenan los desarrolladores las credenciales de modelos.
Los defensores deben vigilar si más familias de malware añaden sistemáticamente clientes de IA, marcos de agentes y puertas de enlace de modelos a sus listas de recopilación. Una adopción generalizada demostraría que los secretos de IA se han convertido en un objetivo estándar junto a las cookies del navegador y las carteras de criptomonedas.
Los equipos de seguridad pueden buscar este cambio internamente. Las detecciones en endpoints que involucren rutas de configuración de IA merecen revisión incluso cuando no parezcan afectados ni código fuente ni un almacén de contraseñas tradicional.
La tercera señal es la arquitectura de identidad empresarial. Las organizaciones seguirán emitiendo secretos portátiles y de larga duración o avanzarán hacia credenciales temporales de cargas de trabajo con permisos restringidos y atribución por usuario.
Esa transición determinará si el acceso robado sigue siendo fácil de reutilizar y revender. Inventarios centralizados, rotación rápida, límites de uso predeterminados y alertas de activación de modelos pueden hacer que las credenciales comprometidas sean menos valiosas.
Los proveedores de modelos también tienen un papel. Pueden identificar agrupaciones de cuentas mediante señales de red, dispositivo, pago y patrones de solicitudes. Pueden exigir verificaciones más sólidas cuando la actividad cruza de forma repentina regiones, modelos o perfiles de uso.
Esas protecciones deben evitar penalizar el enrutamiento empresarial legítimo. Una empresa puede distribuir intencionadamente las cargas de trabajo entre regiones o proveedores. Los sistemas de detección necesitan contexto procedente de las políticas del cliente, no solo umbrales genéricos de anomalías.
Las organizaciones deben empezar con un inventario concreto. Identificar quién puede acceder a modelos de pago, qué aplicaciones conservan credenciales, qué roles de nube pueden habilitar servicios y dónde se registran las solicitudes a modelos.
Después deben probar la revocación. Una credencial que no puede localizarse y deshabilitarse con rapidez ya es una responsabilidad para la respuesta a incidentes. Los equipos deben confirmar que retirar una identidad no exige apagar cargas de trabajo de IA no relacionadas.
Los desarrolladores pueden reducir el riesgo sustituyendo claves estáticas locales, separando las cuentas experimentales de los sistemas de producción y negándose a compartir credenciales mediante chat o repositorios de código fuente. Los equipos de seguridad deben hacer que la vía aprobada sea más fácil que la alternativa informal.
Los ejecutivos deben plantear una pregunta sencilla: si una credencial de IA fuera robada esta noche, ¿la organización detectaría primero al atacante, la factura o los datos filtrados?
La advertencia de Google hace urgente esa pregunta porque los atacantes ya no ven el acceso a IA como una novedad. Lo ven como un activo que puede adquirirse, agruparse, consumirse y venderse.
Los próximos meses deberían revelar si los proveedores publican mediciones más sólidas y si los infostealers amplían sus listas de objetivos. Los lectores deben aprovechar ese periodo para auditar el acceso a IA antes de que el mercado clandestino madure aún más.
