Las credenciales de asistentes de programación y plataformas de IA ya tienen valor operativo: compran capacidad, abren modelos, revelan configuraciones y pueden conectar con repositorios o nubes empresariales. Google Threat Intelligence Group observó durante 2026 un crecimiento del robo y comercio de cuentas de IA, además del secuestro de infraestructura cloud para ejecutar cargas no autorizadas, una práctica conocida como LLM-jacking. Para una empresa colombiana, el riesgo no termina en una factura inesperada: una clave robada puede exponer datos, código, propiedad intelectual y relaciones de confianza.
El informe describe infostealers que buscan archivos de configuración de asistentes de código, API keys y rutas personalizadas. También muestra a actores que comprometen recursos cloud y automatizan campañas en pocas horas. La lección no es prohibir la IA: es tratar sus identidades, secretos, cuotas y datos como activos gobernados. Esta guía explica cómo construir ese control sin frenar equipos de desarrollo ni confundir una herramienta aprobada con un uso seguro.
Qué cambió: la cuenta de IA ya es un objetivo
Las primeras conversaciones empresariales se centraron en lo que un empleado podía copiar en un chatbot. Ese riesgo continúa, pero el perímetro se amplió. Los atacantes buscan cuentas premium, configuraciones de IDE, secretos en estaciones de trabajo, tokens de repositorios y credenciales cloud porque permiten consumir recursos, acceder a información o apoyar operaciones posteriores. Una identidad de IA comprometida puede tener un alcance diferente al de una contraseña personal y pasar inadvertida si nadie controla costos, modelos y llamadas.
Google documentó interés de malware de robo de información por archivos como secrets.json o config.yaml usados por herramientas de desarrollo. La presencia exacta y el contenido dependen del producto y la configuración; no todos esos archivos almacenan claves ni toda instalación está expuesta. El punto defendible es otro: los equipos deben saber dónde se guardan los secretos y evitar que queden en texto plano, perfiles sincronizados, repositorios o copias sin protección.
De una clave local a una pérdida empresarial
La cadena de impacto de una credencial de IA
Malware, repositorio, archivo o engaño.
Cuenta, API, modelo o infraestructura.
Consumo, extracción o automatización.
Costo, fuga, fraude o interrupción.
El impacto económico puede ser el primer indicador. Una clave utilizada para cargas intensivas puede generar consumo fuera de horario o en regiones inesperadas. Pero limitar la respuesta a bloquear la facturación deja preguntas abiertas: ¿qué prompts, archivos o repositorios eran accesibles?, ¿la cuenta podía crear otros tokens?, ¿existían conectores con herramientas internas?, ¿el atacante obtuvo secretos adicionales?
La respuesta debe reconstruir permisos y flujo de datos. Una API key con cuota limitada y sin acceso a información corporativa no equivale a un asistente conectado a repositorios privados. Clasifique por capacidad, no por nombre del proveedor. El inventario de IA publicado por la organización debe incluir identidad técnica, propietario, entorno, datos autorizados, conectores, presupuesto y procedimiento de revocación.
Inventarie identidades y secretos, no solo aplicaciones
Preguntar «qué herramientas de IA usamos» produce una lista incompleta. Añada quién administra la suscripción, cómo se autentican usuarios, dónde viven las claves, qué proyectos comparten cuenta, qué modelos se consumen, qué datos se envían y qué alertas existen. Incluya pruebas gratuitas, extensiones, asistentes locales, pipelines de CI/CD y cuentas personales utilizadas para trabajo.
Asigne un propietario de negocio y uno técnico. El primero explica la finalidad y los datos permitidos; el segundo administra autenticación, integración, rotación y registros. En equipos pequeños una persona puede cumplir ambos papeles, pero las decisiones deben quedar explícitas. Un CISO as a Service puede ayudar a ordenar responsabilidad, riesgo y excepciones cuando no existe dirección dedicada.
Cómo proteger las credenciales sin frenar desarrollo
Elimine secretos de código y archivos sincronizados. Use un gestor de secretos compatible con el entorno; inyecte valores en tiempo de ejecución y evite registrarlos en logs. Si una clave llegó a un commit, borrarla del último archivo no elimina necesariamente su historial: revóquela y revise el alcance.
Separe desarrollo, pruebas y producción. Una misma clave para todos los ambientes amplía el impacto. Use proyectos, cuentas de servicio o tokens diferentes, con cuotas y permisos mínimos. Establezca expiración o rotación cuando el proveedor lo permita y documente qué servicio fallará al revocar.
Proteja la estación del desarrollador. Los infostealers convierten el endpoint en un punto crítico. Mantenga sistema y navegador actualizados, controle extensiones, aplique protección de endpoint y limite privilegios locales. Una evaluación de vulnerabilidades puede identificar exposición técnica, pero debe complementarse con procesos de secretos y monitoreo.
Diseñe recuperación. Revocar una clave durante un incidente puede detener una aplicación. Mantenga un inventario de dependencias, responsable de rotación y prueba posterior. La velocidad importa, pero la recuperación debe impedir que el equipo restaure una copia que contiene el mismo secreto comprometido.
Señales útiles para detectar LLM-jacking
Observe consumo por proyecto, modelo, región, horario, identidad y volumen. Configure presupuestos y alertas con umbrales adaptados al uso normal. Busque creación inesperada de tokens, cambios de cuota, errores de autenticación, llamadas desde infraestructura desconocida y aumentos bruscos. La facturación es una fuente de telemetría, no la única.
Cuatro señales que conviene correlacionar
Correlacione estas señales con repositorios, CI/CD, nube y endpoints. Un aumento puede responder a un lanzamiento legítimo; una llamada desde otra región puede provenir de un servicio administrado. Defina quién valida la anomalía y cuánto tiempo tiene para hacerlo. Alertas sin propietario se convierten en ruido.
Qué hacer si sospecha que una clave fue robada
Registre el identificador sin copiar el secreto, preserve logs y determine su alcance. Revoque o rote con una secuencia controlada; busque otros secretos en el mismo endpoint o repositorio; invalide sesiones cuando corresponda; revise consumo y accesos; y documente datos potencialmente expuestos. Si existe actividad maliciosa o fuga posible, active respuesta a incidentes y considere obligaciones contractuales o legales con asesoría apropiada.
No publique la clave en tickets, chats o capturas. Restrinja la evidencia a quienes la necesitan y registre decisiones. Si no hay logs suficientes, exprese esa limitación. La ausencia de una factura alta tampoco descarta acceso a propiedad intelectual o configuraciones.
Una política breve que sí pueda cumplirse
Defina herramientas aprobadas, datos prohibidos o condicionados, método de adquisición, identidades permitidas, almacenamiento de secretos, revisión de conectores, monitoreo, respuesta y baja. Evite una prohibición absoluta que empuje el uso a cuentas personales invisibles. Ofrezca una ruta rápida para evaluar una necesidad y documentar una excepción.
Mida cobertura del inventario, claves con propietario, secretos rotables, proyectos con presupuestos y tiempo de revocación probado. No mida seguridad por número de licencias ni por bloqueos. Una política funciona cuando el equipo sabe cómo pedir acceso, desarrollar, vigilar y cerrar el uso.
Compras y finanzas también forman parte del control
La adopción suele comenzar con una tarjeta corporativa o un reembolso, antes de que tecnología conozca la cuenta. Compras puede exigir propietario, finalidad, tratamiento de datos, región, condiciones de baja y capacidad de exportar registros. Finanzas puede asociar el gasto con un proyecto y alertar variaciones, mientras seguridad define umbrales técnicos. Ninguna función ve por sí sola el panorama completo.
Evite que la factura sea la única fuente de descubrimiento. Un cargo estable no demuestra que los datos estén protegidos, y un aumento no prueba un ataque. Combine contrato, identidad, telemetría y contexto de negocio. Cuando termine un proyecto, cierre la suscripción, revoque tokens, retire conectores y confirme qué datos conserva el proveedor conforme a las condiciones aplicables.
Controles dentro del ciclo de desarrollo
Incluya detección de secretos antes del commit y en la integración continua, con una ruta clara para tratar falsos positivos. Revise permisos de asistentes que leen repositorios completos y separe el contexto que necesita cada tarea. Un desarrollador no debería copiar credenciales reales para obtener ayuda con un error; proporcione datos sintéticos, entornos de prueba y ejemplos seguros.
Cuando una herramienta genere código, mantenga revisión humana, pruebas y análisis de dependencias. El riesgo de credenciales robadas no reemplaza los riesgos de calidad o cadena de suministro. Una práctica de desarrollo seguro conecta secretos, dependencias, revisión y despliegue sin convertir la IA en una excepción fuera del ciclo normal.
Plan de 30 días para una empresa colombiana
Semana 1: identifique herramientas, cuentas y proyectos; priorice desarrollo, datos de clientes y nube. Semana 2: mueva secretos expuestos a un gestor, separe ambientes y active alertas de consumo. Semana 3: simule la revocación de una clave y compruebe continuidad. Semana 4: revise endpoints y repositorios, cierre cuentas huérfanas y presente riesgos pendientes a dirección.
Adapte el alcance a contratos, protección de datos y arquitectura. Este artículo no afirma una obligación específica para todas las empresas colombianas. La utilidad está en convertir un riesgo emergente en controles verificables sin detener la adopción responsable.
Preguntas frecuentes
¿LLM-jacking significa que el modelo fue alterado?
No necesariamente. El término suele describir el uso no autorizado de cuentas, credenciales o infraestructura para consumir servicios de modelos. El impacto exacto depende de accesos y conectores.
¿Una alerta de costo basta?
No. Ayuda a detectar abuso, pero debe combinarse con identidad, origen, modelos, datos y actividad de repositorios o nube.
¿Debemos prohibir asistentes de código?
No como respuesta automática. Evalúe datos, permisos, almacenamiento de secretos y beneficios. Prohibir sin alternativa puede desplazar el uso a canales personales.
¿Rotar una API key elimina el riesgo?
Corta el uso futuro de esa credencial, pero todavía debe investigarse qué ocurrió, qué datos eran accesibles y si se robaron otros secretos.
Fuentes y límites
Fuente primaria consultada el 12 de octubre de 2026: Google Threat Intelligence Group, AI Threat Tracker: From Prompting to Autonomy, publicado el 8 de septiembre de 2026. Se contrastaron las recomendaciones generales con guías de OWASP para aplicaciones con LLM. Los ejemplos son generales; no prueban que una herramienta o empresa concreta haya sido comprometida.
