La advertencia de Google sobre LLM-jacking revela un mercado negro de acceso a IA robado
Google ha advertido que los ataques de LLM-jacking están aumentando, a medida que los delincuentes roban cada vez más cuentas de IA, credenciales de API y capacidad de nube empresarial.
Según informes, vendedores clandestinos anuncian acceso no autorizado a modelos de Google, Anthropic y OpenAI con descuentos de hasta el 97%. Esa cifra describe anuncios observados en mercados, no un precio medio de transacción verificado de forma independiente.
El hallazgo más importante está detrás del titular. El acceso a la IA se ha convertido en un activo criminal comerciable, al igual que las tarjetas de pago robadas, las cuentas en la nube y las conexiones de proxy residenciales.
Google Threat Intelligence Group afirma que observó más compradores y vendedores de cuentas de IA durante 2026. La demanda se concentró en credenciales de Claude y Gemini, junto con productos de programación con IA como Cursor Pro y Devin.
No se trata simplemente de fraude de suscripción. Los atacantes pueden robar una clave de API o una identidad en la nube, canalizar solicitudes a través de la cuenta de otra empresa y dejar a la víctima responsable de la actividad.
La exposición resultante combina consumo inesperado, filtración de datos, interrupción del servicio y uso delictivo de infraestructura de confianza. También pone en cuestión los programas de seguridad que aún tratan el gasto en IA como un presupuesto de software, en lugar de como un recurso informático controlado.
Las campañas anteriores de secuestro de recursos solían buscar minería de criptomonedas o capacidad de proxy. El LLM-jacking redirige la misma lógica económica hacia la inferencia de modelos, los agentes para desarrolladores y la infraestructura necesaria para operarlos.
Por tanto, el conflicto es mayor que los delincuentes frente a los proveedores de IA. Es acceso robado frente a control empresarial, y cada clave sin seguimiento o carga de trabajo con privilegios excesivos amplía la oferta del mercado.
Lo que realmente dice la advertencia de Google sobre LLM-jacking
Las pruebas de Google muestran que los delincuentes están creando una cadena de suministro en torno al acceso comprometido a IA, no simplemente experimentando con cuentas robadas aisladas.
El rastreador de amenazas de IA de septiembre de 2026 de la empresa describe un aumento en el robo, la exfiltración y la venta de cuentas de IA en comunidades de ciberdelincuencia.
Google afirma que más identidades clandestinas buscaron cuentas relacionadas con IA en 2026. También observó más vendedores anunciando esas cuentas en comparación con el año anterior.
Los precios medios por cuenta en los mercados se duplicaron con creces durante 2026, según publicaciones rastreadas por Google. Ese aumento sugiere que la demanda creció incluso cuando algunos anuncios individuales prometían descuentos extremos.
La aparente contradicción tiene sentido dentro de un mercado ilícito. Los compradores valoran el acceso porque la inferencia legítima y la computación de alto rendimiento requieren recursos escasos y facturables.
Una cuenta robada puede trasladar esos costes a la víctima. Por tanto, un vendedor puede rebajar el acceso legítimo sin operar infraestructura comparable.
Los informes sobre descuentos de hasta el 97% parecen describir las ofertas clandestinas más agresivas. El informe público de Google no establece ese porcentaje como una media de todo el mercado.
Tampoco revela un número total de víctimas, pérdidas financieras agregadas ni volumen de transacciones verificado. Estas omisiones limitan cualquier intento de medir el tamaño total del mercado.
Sin embargo, la actividad subyacente está documentada con mayor solidez que el porcentaje del titular. Google observó un aumento de la demanda, robo selectivo de credenciales y compromisos de nube que respaldan cargas de trabajo de IA no autorizadas.
La empresa denomina “LLMJacking” a la versión relacionada con infraestructura. El término abarca el secuestro de recursos empresariales en la nube para ejecutar modelos de IA o consumir servicios de modelos alojados sin autorización.
Google también identifica métodos para obtener cuentas más allá del robo directo. Los actores de amenazas utilizan registros automatizados, agrupación de cuentas, relés proxy y middleware que agrega múltiples claves.
Estos sistemas pueden distribuir solicitudes entre cuentas y ocultar su origen. También pueden reemplazar credenciales deshabilitadas sin cambiar la interfaz del comprador.
Esa estructura convierte el acceso comprometido en un servicio. Los compradores no necesitan saber qué organización paga la factura subyacente.
Según se informa, el mercado incluye credenciales para cuentas de IA orientadas al consumidor, asistentes de programación y API de modelos. Estos activos difieren significativamente en lo que exponen.
Una cuenta de chat robada puede revelar el historial de conversaciones y documentos cargados. Una credencial de API puede proporcionar acceso programable a una cuota, un modelo o un proyecto de nube conectado.
Una identidad de nube comprometida presenta el riesgo más amplio. Puede permitir a un intruso aprovisionar infraestructura, descubrir credenciales almacenadas o acceder a servicios empresariales adyacentes.
La advertencia de Google conecta estas capas en una sola economía. Las cuentas robadas proporcionan acceso inmediato, mientras que la infraestructura comprometida ofrece capacidad informática duradera.
Esa combinación explica por qué la amenaza importa más allá de un solo proveedor. Google, Anthropic y OpenAI compiten por clientes legítimos, pero los delincuentes pueden comerciar con acceso a los tres como inventario intercambiable.
Por qué el acceso a IA se convirtió en un valioso inventario criminal
El auge del LLM-jacking refleja un cambio económico básico: el acceso a modelos proporciona ahora capacidad informática útil y escalable que los delincuentes no quieren financiar por sí mismos.
Los grupos criminales llevan mucho tiempo robando infraestructura cuando el recurso robado podía generar ingresos. La minería de criptomonedas hizo valiosos los procesadores comprometidos porque la potencia informática se traducía directamente en activos digitales.
El proxyjacking creó otro mercado al enrutar tráfico a través de los sistemas de las víctimas. Los atacantes podían vender ancho de banda y direcciones residenciales o empresariales que parecían fiables.
El LLM-jacking extiende ese modelo a la inferencia. El recurso robado es la capacidad de enviar prompts, generar resultados, operar agentes o ejecutar modelos en hardware secuestrado.
MITRE clasifica este comportamiento más amplio como secuestro de recursos. Su marco incluye abuso de computación, ancho de banda, mensajería y servicios en la nube.
La IA hace que la oportunidad sea más flexible. Una credencial puede respaldar generación de código, reconocimiento, producción de contenido, traducción, preparación de phishing o un flujo de trabajo ofensivo automatizado.
La misma credencial también puede proporcionar acceso a límites o capacidades superiores no disponibles mediante una cuenta gratuita anónima. Esa diferencia importa cuando una operación depende de automatización sostenida.
Google afirma que el acceso premium y la computación de alto rendimiento siguen siendo barreras importantes para los atacantes. Robar esos recursos reduce la barrera sin exigir a los delincuentes construir una plataforma de IA.
El mercado puede atender a varios tipos de compradores. Algunos buscan acceso económico a modelos generales, mientras que otros persiguen cuentas que soporten un uso de gran volumen o que infrinja las políticas.
Los grupos más capaces pueden conectar el acceso robado a sistemas de orquestación. Esos sistemas seleccionan cuentas automáticamente, rotan endpoints, reintentan solicitudes fallidas y distribuyen el trabajo.
La investigación sobre amenazas de Google de mayo de 2026 documentó relés proxy y canales de registro automatizado utilizados para industrializar el acceso a modelos comerciales.
El informe describió navegadores antidetección, grupos de cuentas y middleware personalizado diseñado para eludir restricciones de facturación o la aplicación de normas por parte de las plataformas. Estos mecanismos reducen la dependencia de una sola credencial.
También complican la atribución. El tráfico que llega a un proveedor puede pasar por relés y proyectos comprometidos antes de producir un resultado malicioso en otro lugar.
Para una víctima empresarial, la primera señal evidente podría ser un consumo anormal del modelo. Sin embargo, el atacante puede haber entrado a través de un dispositivo de desarrollador días antes.
Un infostealer, un malware diseñado para recopilar credenciales y datos de sesión, puede buscar información de configuración de IA en archivos locales. Después puede exportar cualquier elemento útil a su controlador.
Google observó controladores de ACRSTEALER atacando almacenes de configuración asociados con Cline y Continue AI. Esos archivos pueden contener claves de API en texto sin formato o endpoints de enrutamiento personalizados.
Este detalle hace especialmente importantes los entornos de desarrollo de IA. Los asistentes de programación suelen estar cerca de repositorios de código fuente, registros de paquetes, terminales y herramientas de nube.
Una credencial robada de ese entorno puede proporcionar más que acceso a modelos. Puede ayudar a los atacantes a trazar el stack de desarrollo o identificar una ruta hacia los sistemas de producción.
Por tanto, el mercado creciente presiona al mismo tiempo a líderes de seguridad, responsables de ingeniería y equipos de finanzas en la nube. Cada grupo ve un fragmento diferente del incidente.
Seguridad ve una identidad comprometida. Ingeniería ve solicitudes fallidas o cuotas agotadas. Finanzas ve consumo inexplicable después de que el acceso ya se haya monetizado.
Sin una supervisión compartida, esos fragmentos pueden no llegar a convertirse nunca en un único incidente. El mercado negro se beneficia de ese retraso organizativo.
La advertencia de Google sobre LLM-jacking presiona los controles de identidad
El problema central no es que los modelos se hayan vuelto de repente fáciles de hackear. Los atacantes están robando las identidades y la infraestructura que los rodean.
La investigación de Google distingue los ataques contra activos de IA de los compromisos exitosos de los propios modelos de frontera. La actividad observada se centra en gran medida en credenciales, conectores, configuraciones de desarrollador, proyectos en la nube y capas de orquestación.
Esta distinción importa porque los controles de seguridad de los modelos no pueden revocar una clave empresarial filtrada. Tampoco pueden corregir un rol de identidad que concede acceso innecesario en un entorno de nube.
Una credencial de portador permite a quien la posee actuar con los permisos asignados a esa credencial. Es posible que el sistema no sepa si la solicitud procede de su propietario o de un ladrón.
Las claves de API de larga duración dificultan la gestión de esa debilidad. A menudo sobreviven a cambios de personal, prototipos abandonados y migraciones entre proveedores de IA.
Los desarrolladores pueden copiarlas en archivos de configuración locales por comodidad. Las herramientas automatizadas también pueden generar claves sin incluirlas en un inventario de seguridad establecido.
El resultado es la proliferación de credenciales. Las organizaciones saben qué herramientas de IA aprobaron, pero no necesariamente qué identidades, claves, extensiones y agentes locales pueden acceder a ellas.
El LLM-jacking convierte esa brecha de gobernanza en inventario para los delincuentes. Cada credencial reutilizable se convierte en un producto potencial.
El desafío de seguridad crece cuando las organizaciones conectan modelos a datos internos. Un asistente de IA puede tener acceso a código fuente, documentos técnicos, registros de soporte o conversaciones de proyectos.
Si un intruso roba la sesión del asistente, el incidente podría exponer conversaciones almacenadas o recursos conectados. Si el atacante roba únicamente una clave de API, la exposición directa de datos depende de sus permisos.
Estos escenarios no deben fusionarse en una sola afirmación. Una clave comprometida no concede automáticamente acceso a cada prompt ni a todos los sistemas internos.
Sin embargo, los equipos tampoco deben asumir que el uso no autorizado genera solo un problema de facturación. Los registros, resultados del modelo, herramientas conectadas y el contexto de la aplicación pueden contener información sensible.
El riesgo se vuelve más agudo con los agentes. Un agente puede llamar herramientas, recuperar documentos, ejecutar acciones aprobadas y conservar contexto operativo durante un flujo de trabajo.
Estas capacidades son útiles porque reducen el trabajo manual. Son peligrosas cuando la identidad subyacente carece de permisos limitados y registros de auditoría fiables.
Google informó que los atacantes están avanzando hacia operaciones agénticas con menos demora humana. En un caso del segundo trimestre, un recurso en la nube comprometido respaldó una campaña masiva de recolección de credenciales en menos de seis horas.
Ese ejemplo no prueba que cada cuenta de IA robada vaya a impulsar un ataque autónomo. Muestra por qué las cadenas lentas de aprobación manual no pueden seguir siendo el único mecanismo defensivo.
Las empresas deben saber qué identidades pueden consumir modelos, qué aplicaciones las poseen y cómo es el consumo normal. También necesitan un método rápido para suspender el acceso.
Esto exige coordinación más allá del centro de operaciones de seguridad. Los equipos de plataforma deben hacer observables las credenciales, mientras que los equipos de compras deben vincular las facturas con propietarios y cargas de trabajo específicos.
Los desarrolladores también necesitan rutas aprobadas de almacenamiento y rotación que sigan siendo prácticas. Si el proceso seguro genera demasiada fricción, las alternativas locales no gestionadas seguirán propagándose.
El ganador de este conflicto no será la empresa con la política de uso aceptable más extensa. Será la empresa capaz de identificar, limitar y revocar rápidamente el acceso a la IA.
La cadena de ataque comienza antes del primer prompt sospechoso
El LLM-jacking suele tener éxito mediante el robo habitual de credenciales y el abuso de la nube, y después utiliza el consumo de IA como capa de monetización.
Una ruta habitual comienza en la estación de trabajo de un desarrollador. El phishing, el software malicioso, un paquete comprometido o una extensión engañosa del navegador pueden instalar un infostealer.
El malware busca en navegadores, directorios de configuración, historiales de comandos, archivos de entorno y almacenes de aplicaciones. Las herramientas de desarrollo de IA crean objetivos adicionales porque muchas requieren credenciales de modelos.
Una vez robada, una clave puede probarse automáticamente. Los operadores criminales pueden identificar su proveedor, la cuota disponible, las restricciones y si la credencial sigue funcionando.
Las credenciales útiles pueden venderse directamente o cargarse en un relay. Un relay acepta solicitudes de clientes y las reenvía a través de una o más cuentas comprometidas.
El cliente ve un endpoint de servicio estable. Detrás de él, el operador puede sustituir una credencial revocada, distribuir el consumo o dirigir cargas de trabajo específicas a distintos modelos.
Esta separación protege al comprador de la inestabilidad de las cuentas robadas individuales. También permite al vendedor monetizar una colección de credenciales entre muchos clientes.
El compromiso de la nube crea otra ruta. Los atacantes pueden obtener una identidad que les permita activar servicios de modelos o desplegar infraestructura autoalojada.
Después pueden consumir inferencia alojada a través del proyecto de la víctima. Como alternativa, pueden utilizar capacidad de cómputo robada para ejecutar un modelo directamente.
La empresa de seguridad Sysdig acuñó el término LLMjacking en 2024 para describir el uso de credenciales de nube robadas para consumir servicios de modelos de pago. Su posterior investigación sobre LLMjacking describe una progresión hacia cargas de trabajo agénticas ofensivas.
Los modelos autoalojados crean una exposición relacionada. Un servidor de inferencia accesible desde Internet sin autenticación puede ofrecer capacidad gratuita a cualquiera que lo descubra.
Esa ruta no requiere una clave API robada. La debilidad reside en un servicio expuesto y controles de red inadecuados.
El resultado aún puede parecerse al LLM-jacking porque un tercero consume la infraestructura de IA de una organización. Sin embargo, la remediación difiere de una investigación de robo de cuentas.
Los equipos deben distinguir al menos tres tipos de incidentes: sesiones de usuario comprometidas, credenciales de modelos robadas e infraestructura de nube o autoalojada secuestrada.
El robo de sesiones exige revocación de cuentas, investigación de dispositivos y revisión de contenido expuesto. El robo de claves API requiere rotación de claves, análisis de registros y validación de los permisos asociados.
El compromiso de infraestructura exige una respuesta a incidentes más amplia. Los investigadores deben determinar cómo entró el atacante, qué recursos se crearon y si persiste algún mecanismo de permanencia.
Las anomalías de consumo pueden revelar los tres casos, pero por sí solas no son suficientes. El lanzamiento legítimo de un producto también puede generar tráfico repentino de modelos.
Una detección útil combina volumen, identidad, geografía, horarios, selección de modelos y comportamiento de aplicaciones. Una carga de trabajo que cambia varias dimensiones a la vez merece una revisión rápida.
Los equipos también deben supervisar las solicitudes rechazadas por controles de seguridad. Estos eventos pueden indicar abuso, aunque los atacantes sofisticados pueden usar tareas benignas o sus propios modelos.
Los mejores controles reducen tanto la probabilidad como el impacto. Las credenciales de corta duración reducen la ventana de oportunidad, mientras que las identidades específicas para cada carga de trabajo limitan a qué puede acceder una credencial robada.
Las restricciones de red pueden bloquear el uso desde entornos inesperados. Las cuotas y límites de consumo pueden ralentizar el abuso mientras los equipos de respuesta investigan.
Ninguno de estos controles ofrece certeza. Juntos, hacen que el acceso robado sea menos fiable y, por tanto, menos valioso para los vendedores clandestinos.
Lo que la afirmación de un descuento del 97% no demuestra
El descuento llamativo es una señal de alerta útil, pero no mide el tamaño real del mercado, su fiabilidad ni su impacto financiero.
Un anuncio clandestino no es una venta completada. Los vendedores pueden exagerar la calidad del acceso, el tipo de cuenta, la cuota restante o la duración antes de la revocación.
El producto anunciado también puede diferir del acceso legítimo. Los compradores pueden recibir un proxy compartido, una sesión de navegador o una cuenta de corta duración, en lugar de una suscripción transferible.
Esa distinción cambia el cálculo del descuento. Comparar un relay criminal inestable con acceso fiable y con soporte puede producir un porcentaje engañoso.
La cifra tampoco revela quién asumió el consumo subyacente. Parte del acceso puede proceder de credenciales robadas, mientras que otras ofertas pueden explotar pruebas gratuitas o creación automatizada de cuentas.
Google ha documentado todas esas vías de adquisición. La evidencia pública no asigna un porcentaje del mercado a cada una.
El informe tampoco establece que los atacantes vulneraran la infraestructura central de modelos de Google, Anthropic u OpenAI. El mercado observado depende en gran medida de clientes comprometidos y ecosistemas de cuentas.
Ese matiz debe orientar la respuesta. Las empresas no pueden esperar a que los proveedores resuelvan todos los casos porque muchas vulnerabilidades existen dentro de identidades y dispositivos gestionados por el cliente.
Los proveedores aún tienen una responsabilidad significativa. Pueden detectar agrupación de cuentas, relays sospechosos, patrones de uso imposibles y abuso coordinado de registros en sus plataformas.
Google afirma que utiliza inteligencia de amenazas para reforzar las salvaguardas y desactivar proyectos o cuentas maliciosos. Esa aplicación de medidas puede aumentar el coste de mantener un servicio clandestino.
Sin embargo, la acción del proveedor introduce otra incertidumbre. El bloqueo automatizado agresivo puede interrumpir infraestructura compartida legítima o equipos de desarrollo distribuidos globalmente.
Por ello, los sistemas de seguridad necesitan evidencia más allá de un único pico de tráfico. Deben distinguir rápidamente entre el lanzamiento de un producto, una aplicación mal configurada y una credencial robada.
La ausencia de datos agregados sobre pérdidas también limita las comparaciones con ransomware, cryptojacking y otras amenazas en la nube. El LLM-jacking podría estar extendido y, aun así, producir pérdidas modestas por víctima.
También es posible el patrón contrario. Un número menor de compromisos en la nube podría generar una exposición grave porque la identidad robada alcanza datos e infraestructura valiosos.
La telemetría de Google representa otro límite. Ofrece una sólida visibilidad de su propio ecosistema y de su trabajo de respuesta a incidentes, pero no de todos los proveedores ni de todas las transacciones clandestinas.
La investigación independiente ayuda a confirmar el patrón de ataque. Aun así, no puede convertir observaciones fragmentadas en una estimación completa del mercado global.
La conclusión defendible es más acotada y útil. Existe demanda criminal, los vendedores están respondiendo y el acceso robado a IA cuenta ahora con una vía de monetización repetible.
Esa conclusión no exige aceptar cada anuncio de la dark web al pie de la letra. Exige tratar las credenciales de IA como activos que los atacantes buscan activamente.
Por tanto, una lectura escéptica refuerza la lección operativa. Los equipos deben responder a mecanismos de ataque verificados, no construir políticas en torno a una cifra promocional de un vendedor ilícito.
Tres señales mostrarán si el LLM-jacking sigue creciendo
La siguiente etapa será visible a través de la focalización de los ladrones de credenciales, la aplicación de medidas por parte de los proveedores y las anomalías de consumo empresarial.
La primera señal es si los infostealers amplían su búsqueda hacia archivos de configuración de IA. Google ya ha observado controladores de malware buscando secretos específicos de asistentes de programación.
Nuevas reglas dirigidas a agentes adicionales, routers de modelos y herramientas locales para desarrolladores indicarían que los atacantes siguen encontrando credenciales valiosas allí.
Por ello, los equipos de seguridad deben inspeccionar las detecciones de endpoints en busca de exploraciones desconocidas en directorios de configuración. También deben inventariar las aplicaciones que almacenan localmente credenciales de modelos.
La segunda señal es la aplicación de medidas por parte de los proveedores. Esté atento a revelaciones sobre grupos de cuentas desactivados, redes de relay desmanteladas, comprobaciones de registro más estrictas y opciones de autenticación más limitadas.
Una mayor aplicación de medidas confirmaría que los proveedores detectan abuso coordinado a una escala significativa. También podría empujar a los criminales hacia modelos autoalojados y el compromiso directo de la nube.
Ese desplazamiento importa. Bloquear cuentas de consumidores robadas no elimina la demanda de capacidad de cómputo de bajo coste.
La tercera señal es la telemetría empresarial. Aumentos inexplicables de solicitudes de inferencia, nuevo uso de modelos, regiones desconocidas o consumo fuera de las ventanas de despliegue pueden exponer accesos comprometidos.
El modelo de secuestro de servicios en la nube de MITRE recomienda buscar cambios repentinos de recursos y consumo no autorizado de servicios. Los equipos de IA pueden adaptar esa lógica a tokens, solicitudes, endpoints y familias de modelos.
La guía de claves API de Google recomienda restricciones, supervisión del uso, claves aisladas, rotación periódica y autenticación más fuerte cuando esté disponible.
Los equipos deben traducir esos principios en reglas de propiedad. Cada credencial de modelo necesita una aplicación con nombre, un equipo responsable, un entorno aprobado y una ruta de revocación documentada.
Evite compartir una sola clave entre personas y cargas de trabajo. Las credenciales separadas crean mejores rastros de auditoría y reducen el alcance de un único compromiso.
No almacene secretos de producción en repositorios, notebooks, código accesible desde el navegador ni archivos locales gestionados de forma poco rigurosa. Utilice un almacén de secretos gestionado y automatice la entrega de credenciales.
Prefiera credenciales de identidad de corta duración cuando los proveedores las admitan. Una credencial temporal da a los atacantes menos tiempo para probar, empaquetar y revender el acceso.
Configure alertas de consumo a nivel de carga de trabajo, no solo para la cuenta general de la nube. La facturación agregada puede ocultar abusos dentro del crecimiento normal de la empresa.
Supervise las solicitudes rechazadas y los cambios bruscos en la selección de modelos. Una aplicación comprometida que de repente llama a modelos distintos puede revelar experimentación por parte de un atacante.
Restrinja qué servicios, aplicaciones, redes y métodos puede utilizar cada identidad. El privilegio mínimo convierte una clave robada de una credencial maestra en un activo limitado.
Revise las herramientas conectadas a IA con la misma disciplina aplicada a los repositorios de código fuente y las consolas en la nube. Los agentes pueden heredar permisos sensibles a través de conectores que los equipos pasan por alto.
Mantenga un manual de respuesta a incidentes para credenciales de IA. Debe cubrir revocación, preservación de registros, inspección de endpoints, notificación al proveedor y comprobaciones de acceso adyacente a la nube.
Una base de conocimiento de ingeniería con capacidad de búsqueda puede ayudar a los equipos a conservar registros de propiedad y procedimientos de respuesta. Nunca debe contener secretos activos.
La advertencia de Google sobre el LLM-jacking cambia la pregunta que deberían plantearse las empresas. El problema ya no es si los delincuentes valoran el acceso a la IA, porque el mercado clandestino demuestra que sí.
La cuestión práctica es si su organización puede identificar todas las credenciales que llegan a un modelo, detectar usos anómalos y revocar el acceso antes de que se convierta en inventario.
Audite esas credenciales ahora. Asigne un responsable a cada clave restante, elimine los accesos abandonados y pruebe el proceso de revocación en condiciones realistas.
