Cuando tu agente de programación publica tus secretos: guía de análisis forense de IA, contención y auditoría

Publicado el octubre 2, 2026 por Simon Roses

Tiempo de lectura: 20 minutos

TL;DR

Hace poco me llamaron para un incidente que espero ver cada vez más: un agente de programación empaquetó ficheros a los que tenía acceso y los subió a un repositorio público de GitHub. Dentro había datos personales y tokens en vigor. Nadie atacó nada. El agente hizo algo para lo que tenía permisos, e internet se encargó del resto. Esta es la guía que le daría a cualquiera que se encuentre en la misma situación: detén el agente y conserva sus registros antes de que caduquen, rota todos los secretos antes de tocar el historial de git, asume que borrar o hacer privado el repositorio no borra los datos, limpia lo que GitHub permita limpiar, audita para qué se usaron los tokens filtrados y gestiona los datos personales con el reloj de 72 horas del RGPD en marcha. La segunda mitad es el análisis forense de IA que la mayoría de los equipos nunca ha hecho: leer los paneles y las API de uso de OpenAI y Anthropic para averiguar si alguien ha gastado tus tokens, y en qué.

Una nota sobre qué es esto. El caso que ha motivado este artículo es real y está anonimizado: ni cliente, ni producto de agente, ni detalles de los datos. Lo que sigue es una guía defensiva construida a partir de esa experiencia y de documentación pública, que cito sobre la marcha. Las consolas de los proveedores cambian; comprueba la documentación vigente antes de fiarte de una ruta de menú bajo presión.

El tipo de incidente que nadie había ensayado

Tenemos veinte años de procedimientos para el caso de un desarrollador que sube una contraseña a un repositorio. Casi ninguno para cuando el desarrollador es un programa con acceso a la shell, credenciales de git y una tarea que terminar.

La mecánica del caso fue de lo más corriente. Un agente de programación, con los accesos que se le habían dado, empaquetó un conjunto de ficheros y los subió a un repositorio público. Algunos de esos ficheros contenían datos personales. Otros contenían tokens, entre ellos claves de API de proveedores de IA. No hubo inyección de prompts ni ninguna skill maliciosa: solo un agente capaz de ejecutar git push contra un remoto público y nada que se interpusiera entre esa capacidad y el resultado.

Los datos dicen que no es un caso aislado. El informe State of Secrets Sprawl 2026 de GitGuardian contabilizó 28,65 millones de secretos nuevos incrustados en commits públicos de GitHub durante 2025, un 34 % más en un año, y los secretos de servicios de IA crecieron un 81 %, hasta superar los 1,27 millones. La cifra que más me llamó la atención: los commits hechos con ayuda de un agente de programación muy extendido mostraron una tasa de filtración de secretos del 3,2 %, frente al 1,5 % de media en todos los commits públicos. Es investigación de un fabricante y un solo dato, pero encaja con lo que veo: los agentes van más rápido que la higiene que los rodea. El mismo informe encontró más de 24.000 secretos solo en ficheros de configuración MCP. Ya he escrito sobre skills de agente convertidas en armas y sobre la trampa de las dependencias en el código generado por IA; este caso es el pariente menos vistoso de ambos, porque no necesita ningún adversario.

El reloj contra el que corres de verdad

Un hecho decide el orden de los pasos: la carrera es contra la automatización, no contra una persona que quizá tropiece con el repositorio.

Los push públicos se rastrean de forma continua. La Unit 42 de Palo Alto documentó una campaña capaz de lanzar un ataque completo en cinco minutos desde que una credencial de AWS aparecía en un repositorio público de GitHub, y una investigación posterior de Clutch Security vio claves de AWS expuestas explotadas en cuestión de minutos. Da por hecho que, para cuando una persona se dio cuenta del push, todos los secretos que contenía ya habían sido recolectados. De esa premisa sale el orden de las operaciones.

Paso 0: detén el agente y conserva las pruebas

Mata la sesión del agente. Revoca la credencial de git con la que hizo el push (la clave SSH, el token de acceso personal o la instalación de la app) para que un bucle de reintentos o una tarea programada no pueda volver a subir nada mientras trabajas.

Después conserva las pruebas, hoy, antes de que desaparezcan solas. La transcripción del agente es tu mejor registro de lo que hizo y por qué: qué ficheros leyó, qué comandos ejecutó, qué subió y adónde. Esas transcripciones no se guardan para siempre. Claude Code, por ejemplo, guarda las sesiones en JSONL bajo ~/.claude/projects/PROYECTO/ y las borra a los 30 días por defecto (el ajuste cleanupPeriodDays). Codex CLI, de OpenAI, guarda sus registros de sesión en JSONL bajo ~/.codex/sessions/. Sea cual sea el agente, localiza dónde guarda las sesiones y cópialas a un lugar seguro, junto con el historial de la shell, el repositorio local con su git reflog y los registros de CI si el push salió de un pipeline. Calcula el hash de las copias. Puede que las necesites ante un regulador, un cliente o un juez, y un informe de incidente que diga «los registros ya habían rotado» no es uno que quieras escribir.

Paso 1: averigua exactamente qué se ha filtrado

No lo reconstruyas de memoria. Clona el repositorio público en un entorno aislado y analiza todo el historial, no solo el estado actual:

git clone --mirror https://github.com/ORG/REPO.git leaked.git
gitleaks git -v --report-format json --report-path gitleaks.json leaked.git
trufflehog git file://leaked.git --results=verified,unknown

Gitleaks te da amplitud; TruffleHog puede comprobar qué credenciales siguen vivas, lo que te dice qué rotar primero. Después revisa los ficheros a mano en busca de datos personales, porque los escáneres son buenos con los tokens y malos con un CSV de nombres de clientes.

Construye una única tabla de inventario y consérvala durante todo el incidente: cada secreto (tipo, proveedor, alcance, propietario, primer commit en el que aparece) y cada fichero con datos personales (categorías de datos, número aproximado de personas, de quién son). Todo lo que viene después trabaja sobre esa tabla.

Paso 2: rota todo antes de tocar el historial

Este es el paso que los equipos hacen al revés. El instinto es borrar el fichero, forzar el push y quedarse tranquilo. La propia guía de GitHub sobre cómo eliminar datos sensibles es tajante: si el dato sensible es un secreto, «como primer paso tienes que revocar y/o rotar ese secreto». Un secreto rotado es inofensivo allí donde sobrevivan copias. Un secreto borrado del historial pero todavía válido sigue siendo una clave válida en la cosecha de otro.

Ordena la rotación por radio de impacto. Primero las claves de administración y de organización (una clave de administración de un proveedor de IA, una clave raíz o de IAM en la nube, un token de GitHub con alcance de organización), porque permiten a un atacante crear credenciales nuevas que sobreviven a tu rotación. Después las claves de servicios en producción y, por último, todo lo demás. Tras cada rotación, confirma que la credencial antigua está realmente muerta, no solo que la nueva funciona.

Dos notas específicas de IA. La primera: GitHub tiene un programa de socios de detección de secretos: cuando detecta la clave de un socio en un repositorio público, avisa al proveedor, que puede revocarla. Anthropic afirma que desactiva automáticamente las claves de la API de Claude detectadas por esta vía y envía un correo al usuario afectado. OpenAI es integrador del programa de GitHub desde 2021, pero su guía de seguridad de claves se limita a decirte que rotes de inmediato una clave filtrada. Trata la revocación por parte del proveedor como un extra, nunca como tu control. Y guarda ese correo de Anthropic: su marca de tiempo te sirve de referencia para la cronología. La segunda: rotar una clave de IA rompe todo lo que la usaba. Ten la clave nueva lista en tu gestor de secretos antes de matar la antigua, o estarás haciendo respuesta a incidentes y gestionando una caída del servicio a la vez.

Paso 3: corta la hemorragia, y entiende lo que eso no consigue

Ahora reduce la exposición: haz privado el repositorio o retíralo. Hazlo, pero teniendo claro lo que consigue y lo que no, porque aquí es donde falla el modelo mental de casi todo el mundo.

GitHub documenta que, cuando un repositorio público pasa a privado, «sus forks públicos se separan en una nueva red» y siguen siendo públicos. Si lo borras, el fork público activo más antiguo pasa a ser el nuevo repositorio de origen. Truffle Security demostró en 2024 que, mientras exista un solo fork, los commits de la red siguen accesibles por su hash, y GitHub respondió que ese comportamiento es intencionado. Forzar el push tampoco ayuda: Sharon Brizinov analizó todos los eventos de force push desde 2020 registrados en el archivo público GH Archive, recuperó los commits «borrados» por su SHA, encontró miles de secretos en vigor y cobró unos 25.000 dólares en programas de bug bounty. El evento del push, con el hash del commit, está en un archivo público que no controlas.

Así que la contención de los datos es, en el mejor de los casos, parcial. La contención de los secretos es total, si hiciste el paso 2. Por eso el paso 2 va primero.

srf_agentleak_exploitation_tree
Figura 1. Por qué «hemos borrado el repositorio» no es contención. Al atacante le basta una sola vía hasta los datos (el repositorio vivo, un fork o un clon hecho antes de retirarlo, un commit colgante recuperado por su SHA desde GH Archive o la red de forks en general) y una sola forma de usarlos. La única rama que puedes cerrar por completo es la de las credenciales: una vez rotadas, todas sus copias dejan de valer. Los datos personales no tienen equivalente a la rotación.

Antes de cambiar la visibilidad, registra lo que puedas ver. En Insights → Traffic, GitHub muestra los clones y los visitantes de los últimos 14 días (en UTC, actualizados cada hora) a cualquiera con permiso de push. Haz capturas, anota la lista de forks y quién ha marcado el repositorio con estrella. No te dirá quién, pero sí si alguien lo hizo, y eso importa mucho para la evaluación de los datos personales del paso 6.

Paso 4: limpia lo que GitHub puede limpiar

Con los secretos muertos y el repositorio en privado, reescribe el historial como es debido. GitHub recomienda git-filter-repo 2.47 o posterior con su modo de datos sensibles:

git-filter-repo --sensitive-data-removal --invert-paths --path ruta/al/fichero-filtrado
git-filter-repo --sensitive-data-removal --replace-text ../patrones.txt

Después contacta con el soporte de GitHub indicando el nombre del repositorio, el número de pull requests afectadas y los «first changed commits» que indica git-filter-repo, para que eliminen las vistas en caché, desreferencien las pull requests y pasen el recolector de basura. Para los forks, la política de retirada de información privada cubre credenciales de acceso y tokens de terceros, así como identificadores personales como los números de documentos de identidad oficiales. GitHub no deshabilita los forks automáticamente, así que incluye en la solicitud todos los que conozcas, con enlaces a los ficheros, números de línea y por qué cada elemento supone un riesgo. Otras categorías de datos personales pueden no encajar limpiamente en esa política, otro motivo más para que la evaluación RGPD del paso 6 parta de que ha habido exposición en lugar de confiar en la retirada.

Si quieres saber qué puede seguir alcanzando alguien de fuera, usa las mismas herramientas que usaría un atacante: el modo github-experimental --object-discovery de TruffleHog enumera los commits ocultos y borrados de la red de un repositorio. Es lento y está limitado por las cuotas de la API, pero responde a la pregunta con honestidad.

Paso 5: audita para qué se usaron los tokens

La rotación impide el abuso futuro. No te dice nada de lo que pasó entre el push y la rotación. Para cada secreto vivo de tu inventario, extrae los registros del proveedor de esa ventana: registros de auditoría de la nube, el registro de auditoría de GitHub, los registros de acceso a bases de datos. Para las claves de IA, eso significa los paneles y las API de uso de los proveedores, que la mayoría de los equipos nunca ha mirado con ojos de investigador. Es la parte de análisis forense de IA y ocupa la segunda mitad de este artículo.

Antes, responde a una pregunta: ¿alguna de las claves filtradas tenía permisos de administración? Una clave de administración permite al atacante crear claves nuevas, añadir usuarios o cambiar la configuración, y así acabas rotando la clave filtrada y sigues sangrando. Con esas claves, el registro de auditoría va antes que el informe de uso.

Paso 6: los datos personales y el reloj de 72 horas

Un repositorio público con datos personales es una brecha de datos personales según el RGPD: una pérdida de confidencialidad, puedas demostrar o no que alguien los descargó. El artículo 33 obliga a notificar a la autoridad de control «sin dilación indebida y, de ser posible, a más tardar 72 horas» después de haber tenido constancia de ella, salvo que sea improbable que la brecha suponga un riesgo para los derechos y libertades de las personas. El artículo 34 añade la comunicación a los afectados cuando el riesgo sea alto. Y el artículo 33.5 exige documentar la brecha, sus efectos y las medidas correctoras aunque decidas no notificar.

En España, la AEPD ofrece Asesora Brecha para ayudar a decidir si hay que notificar y Comunica-Brecha para la comunicación a los interesados, además de su guía de notificación. El plazo empieza a contar cuando tienes constancia, no cuando terminas de investigar, y la notificación puede hacerse por fases. El inventario del paso 1 y las capturas de tráfico del paso 3 son exactamente lo que te va a pedir la notificación. Y si leíste mi último artículo, sabrás que la AEPD ya ha recibido su primera notificación de una brecha ejecutada por un agente de IA. Que un agente provoque una brecha publicando datos es un caso distinto de que un agente te ataque, pero el regulador está claramente atento a ambos.

Cómo evaluar el uso de tokens en el panel de OpenAI

Si se filtró una clave de OpenAI, necesitas tres respuestas: si se usó después del push, para qué, y si alguien la usó para crear más accesos.

El panel de uso. En platform.openai.com/usage (propietarios de la organización o usuarios con el permiso Usage Dashboard), la barra superior fija el alcance: orígenes de API, proyecto, claves de API y rango de fechas. Elige el proyecto afectado, acota a la clave filtrada con el selector de claves y ajusta el rango para cubrir una semana de referencia anterior al push y todo lo posterior. Los datos se muestran en UTC, y las páginas de detalle permiten bajar a intervalos de 1 minuto, que es donde el abuso aparece como un muro de tokens a las tres de la mañana. Dos partes de la página importan sobre todo en un incidente. La pestaña API capabilities muestra una tarjeta por servicio (Responses and Chat Completions, Images, Web Searches, File Searches, Moderation, Embeddings y más), así que una clave que solo había hecho texto y de pronto muestra peticiones de imágenes salta a la vista. El panel de la derecha desglosa las peticiones por usuario, servicio y clave de API, y muestra el gasto del mes frente a tu presupuesto. El botón de descarga exporta los datos para el expediente del caso.

srf_agentleak_openai_usage
Figura 2. El panel de uso de OpenAI, filtrado a un proyecto durante 30 días. Revisa todas las tarjetas de la pestaña API capabilities, no solo Responses and Chat Completions: el abuso suele aparecer en un servicio que tu aplicación nunca usa. El panel de la derecha reparte las peticiones por usuario, servicio y clave de API, y muestra el gasto frente al presupuesto mensual. Nombres de organización y de usuario ocultos.

Cifras por clave con la Usage API. El panel sirve para echar un vistazo; como prueba, usa la Usage API con una clave de administración, que permite agrupar por api_key_id, project_id, model y más:

curl "https://api.openai.com/v1/organization/usage/completions?\
start_time=UNIX_TIMESTAMP&bucket_width=1h&group_by=api_key_id&group_by=model&limit=168" \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

Obtienes input_tokens, output_tokens, input_cached_tokens y num_model_requests por intervalo, por clave y por modelo. Hay endpoints separados para embeddings, imágenes, audio, búsqueda web y más, y /v1/organization/costs da el gasto. Revísalos todos: un atacante que queme tu clave generando imágenes no aparecerá en completions.

srf_agentleak_openai_spend
Figura 3. La pestaña Spend categories reparte el coste por modelo entre entrada en caché, entrada y salida, más llamadas a herramientas como la búsqueda web. Un salto en el coste de salida respecto al de entrada es una de las señales que describo más abajo. Nombres de organización y de usuario ocultos.

¿Cuándo se usó la clave por última vez? La página de claves de API lo responde directamente: cada clave tiene una columna Last used junto a su fecha de creación, caducidad, creador y permisos, y el botón API Key Usage, en la parte superior de la página, enlaza con el uso. La Admin API expone el mismo dato como last_used_at en el objeto de clave de proyecto. Si la fecha es posterior a tu rotación, has rotado la clave equivocada. Si una clave de la que te habías olvidado muestra uso reciente, empieza por ahí.

srf_agentleak_openai_apikeys
Figura 4. La página de claves de API de OpenAI. La columna Last used es la respuesta más rápida a «¿se usó esta clave después de la filtración?». Fíjate en la columna Expires con el valor Never: una clave filtrada sin caducidad sigue siendo válida hasta que alguien la rote. Nombres de claves, IDs de seguimiento, fragmentos de clave y creador ocultos.

¿Alguien creó más accesos? Para eso está la Audit Logs API: creación, modificación y borrado de claves de API, cambios de usuarios y cuentas de servicio, inicios de sesión fallidos, cambios de proyectos y de configuración, con tipos de evento como api_key.created. La pega: el registro de auditoría solo recoge datos desde el momento en que un propietario lo activa (configuración de la organización → Data controls → Data retention), y una vez activado no se puede desactivar sin contactar con soporte. Si no estaba activado antes del incidente, no tienes historial. Actívalo hoy.

¿Qué pidieron? Las llamadas a la Responses API se almacenan 30 días por defecto salvo que tu organización tenga Zero Data Retention, y puedes consultarlas en Logs, dentro del panel, con pestañas separadas para Responses, Agents, Realtime, Completions, Conversations y más. Filtra por la ventana de exposición y busca prompts, modelos o herramientas que no reconozcas. Al abrir una entrada ves su marca de tiempo, el modelo, el número de tokens y las herramientas que usó, y muchas veces eso basta para distinguir el tráfico de tu aplicación del de otro. El propio panel avisa ya de que los registros de Responses de más de 30 días dejarán pronto de estar disponibles, así que exporta lo que necesites el primer día. Más allá de eso, OpenAI conserva registros de monitorización de abusos hasta 30 días; si necesitas contenido o datos de origen que no puedes ver, abre un caso en el centro de ayuda cuanto antes, antes de que se cierre esa ventana.

srf_agentleak_openai_logs
Figura 5. La página Logs, pestaña Responses: una fila por llamada almacenada, con su modelo y su marca de tiempo. Lee el aviso: los registros de más de 30 días van a desaparecer, así que exporta pronto. Texto de los prompts oculto.

srf_agentleak_openai_log_detail
Figura 6. Una respuesta registrada. El panel de propiedades da la marca de tiempo, el modelo, el número de tokens y las herramientas usadas (aquí, búsqueda web): el detalle por petición que los gráficos de uso no pueden darte. Prompt e ID de respuesta ocultos.

Cómo evaluar el uso de tokens en la consola de Anthropic

Las preguntas son las mismas; las herramientas cambian.

Mira primero el correo. Si el escaneo de socios de GitHub detectó la clave, Anthropic ya la habrá desactivado y te habrá escrito. Ese correo te da un límite superior de la ventana de exposición de esa clave.

Las páginas de la consola. En Analytics, la consola tiene las páginas Usage y Cost. Ambas trabajan en UTC, filtran por workspace, clave de API y modelo, agrupan el gráfico por modelo y exportan los datos con el botón de descarga; Usage permite filtrar además por cuenta. La propia Anthropic recomienda revisar con regularidad los patrones de uso de cada clave. Durante un incidente, selecciona la clave filtrada, ajusta el rango a tu semana de referencia y la ventana de exposición, y agrupa por modelo. Usage te da los tokens de entrada y de salida; Cost reparte el dinero entre tokens, búsqueda web, ejecución de código y tiempo de sesión. En el mismo menú Analytics hay también una página Logs. No he encontrado documentación pública de lo que registra, así que ábrela al principio del incidente y comprueba si cubre la ventana que necesitas.

srf_agentleak_claude_usage
Figura 7. La página Usage de la consola de Claude durante 30 días, agrupada por modelo. Selecciona la clave filtrada en el filtro API key y compara la ventana de exposición con los días anteriores al push.

srf_agentleak_claude_cost
Figura 8. La página Cost usa los mismos filtros y reparte el gasto entre tokens, búsqueda web, ejecución de código y tiempo de sesión. Si en la leyenda aparece un modelo que tu equipo no usa, merece una mirada más atenta.

Consultar un mes anterior. La columna Cost de la página de claves de API solo cubre el mes en curso. El día 1 se queda en blanco, y una clave que tuvo mucha actividad el mes anterior de repente parece sin uso. Para ver un mes anterior, abre Cost, pon Range en Last month (las flechas de al lado retroceden mes a mes) y cambia el gráfico a la vista de tabla para ver el detalle día a día. El botón de descarga exporta ese mismo periodo desglosado por clave, día, modelo y tipo de token, con el ID y el estado de cada clave. La Cost API no te da eso, porque solo agrupa los costes por workspace o por modelo, así que haz de esta exportación una de las primeras cosas que guardes.

srf_agentleak_claude_cost_lastmonth
Figura 9. La página Cost con Last month en vista de tabla: una fila por día, una columna por modelo y el total facturado. Usa las flechas junto a Range para retroceder hasta el mes de la filtración.

Resumida por clave, esa exportación de una de mis propias cuentas para septiembre queda así (nombres de clave sustituidos):

Clave Estado Coste en septiembre Días con gasto Primer y último día
Clave A Desactivada 104,87 $ 17 7 → 25 sept.
Clave B Activa, creada el 25 sept. 21,49 $ 4 25 → 30 sept.
Clave C Activa 10,98 $ 5 9 → 18 sept.
Clave D Activa 0,11 $ 2 7 → 14 sept.
Total 137,45 $

Hay dos cosas que leer en ella. La clave A, ya desactivada, deja de gastar el 25 de septiembre, el mismo día en que se crea la clave B, que empieza a gastar. Ese es el patrón que quieres ver tras una rotación: la clave antigua se para el día en que la desactivas y la nueva toma el relevo. Una clave desactivada que sigue mostrando gasto después de esa fecha significa que desactivaste la clave equivocada o que no está realmente muerta. La segunda es la mezcla: unos dos tercios del mes (unos 89 $) se fueron en escrituras en la caché de prompts, algo normal en un agente que trabaja con contextos largos. Tu mezcla habitual de tipos de token es una huella de tu propia carga de trabajo, y alguien que abuse de una clave robada con prompts cortos y sin caché dejaría una muy distinta.

Cifras por clave con la Usage and Cost API. Con una clave de la Admin API (sk-ant-admin01-…, que crean los administradores de la organización), el informe de uso agrupa por api_key_id, workspace_id, model y más, en intervalos de 1 minuto, 1 hora o 1 día, y los datos suelen aparecer unos cinco minutos después de la petición:

curl "https://api.anthropic.com/v1/organizations/usage_report/messages?\
starting_at=2026-09-01T00:00:00Z&ending_at=2026-09-25T00:00:00Z&\
bucket_width=1h&group_by[]=api_key_id&group_by[]=model" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

La respuesta separa uncached_input_tokens, cache_read_input_tokens, cache_creation_input_tokens, output_tokens y el uso de herramientas de servidor. /v1/organizations/cost_report da el dinero. Si tus desarrolladores usan Claude Code dentro de la organización, la Claude Code Analytics API desglosa el coste por usuario.

Desactiva e inventaría las claves. En la consola, Organization settings → API keys lista todas las claves con su cuenta vinculada, workspace, caducidad, creador y coste, y permite filtrar por creador, cuenta vinculada, estado y workspace. El menú al final de cada fila desactiva una clave y, más tarde, permite reactivarla o borrarla. La Admin API hace lo mismo de forma programática: lista las claves y permite poner su estado en inactive o archived. No puede crear claves, así que si tu inventario muestra una clave que nadie reconoce, se creó desde la consola, lo que apunta a una cuenta comprometida más que a una clave filtrada. Eso cambia el alcance del incidente.

srf_agentleak_claude_apikeys
Figura 10. Organization settings → API keys en la consola de Claude. La fila atenuada es una clave desactivada; su menú ofrece reactivarla o borrarla. Los filtros Created by y Status ayudan a detectar claves que nadie recuerda haber creado, y la columna Expires muestra cuáles caducarán solas. Nombres de claves, fragmentos de clave, cuentas vinculadas y creadores ocultos.

Quién cambió qué. El Activity Feed de la Compliance API, accesible con una clave de la Admin API de la consola allí donde la Compliance API esté habilitada para tu organización, registra acciones administrativas como crear una clave de API o añadir un miembro a un workspace. Anthropic deja claro que no registra la actividad de inferencia, así que te dirá si alguien creó accesos, no qué le preguntó al modelo. Para preguntas a nivel de petición, acude al soporte de Anthropic.

Leer las cifras como un investigador

Ningún proveedor te pone una etiqueta de «atacante». Buscas uso que no encaje con tu propio patrón, así que compara siempre la ventana de exposición con una referencia anterior al push. Las señales que busco:

  • Tráfico en una clave después de su hora de rotación, o en una clave que debería estar inactiva (una clave de desarrollo, una clave de un proyecto antiguo).
  • Modelos que tu equipo no usa, sobre todo los más caros, o servicios nuevos (imagen, audio, batch) en una clave que solo hacía texto.
  • Un salto en los tokens de salida respecto a los de entrada, que parece generación masiva y no el patrón habitual de tu aplicación.
  • Actividad a horas, o a un ritmo constante de máquina, que no encaja con la jornada de nadie.
  • Claves, cuentas de servicio, miembros o workspaces nuevos que no creaste, en cualquiera de los dos registros de auditoría.

Lo que ningún panel te va a dar es una IP de origen. El uso se agrega por clave, modelo y tiempo, no por quién llama. Si necesitas atribuir o demostrar un acceso, eso es una petición a soporte, y el tiempo corre.

Cómo evitar el siguiente

La contención es lo urgente. La causa raíz casi siempre es la misma: el agente tenía más alcance del que su tarea necesitaba. Las correcciones no son exóticas:

Quítale al agente la capacidad de publicar. No debería tener una credencial que pueda hacer push a un remoto público, cambiar la visibilidad de un repositorio o crear repositorios. Usa un token con permisos granulares (fine-grained) limitado al repositorio en el que trabaja y exige la aprobación de una persona para git push y para todo lo que toque la visibilidad (todo agente de programación serio admite reglas de denegación o confirmaciones para comandos concretos).

Mantén los secretos fuera del directorio de trabajo del agente. Nada de ficheros .env con claves de producción donde el agente pueda leerlos, nada de claves de administración en su entorno. Si no puede leer el secreto, no puede publicarlo.

Activa la protección de push y el escaneo antes del commit. La protección de push de GitHub y un hook de gitleaks antes del commit habrían bloqueado muy probablemente la parte de los tokens de este incidente antes de que llegara a GitHub, siempre que esos tipos de token estén entre los patrones que reconocen. No habrían detectado una hoja de cálculo con datos personales, y por eso los dos primeros controles importan más.

Acota y pon tope a tus claves de IA. Una clave por proyecto y entorno, presupuestos y límites de gasto configurados, y claves de administración solo para quien las necesita. Una clave de proyecto filtrada con tope de gasto es una molestia; una clave de administración filtrada es un incidente.

Guarda las pruebas más tiempo del que viene configurado por defecto. Amplía la retención de transcripciones del agente (30 días es poco para una investigación que empieza el día 25) y activa ya el registro de auditoría de OpenAI y la recogida del Activity Feed de Anthropic, ahora que no tienes nada que investigar.

La lista de comprobación

Para el día que te toque, en orden:

  1. Mata la sesión del agente y revoca su credencial de git.
  2. Copia las transcripciones del agente, el historial de la shell, el repositorio local y el reflog; calcula sus hashes.
  3. Clona en espejo el repositorio público, analiza todo el historial y construye el inventario de secretos y datos personales.
  4. Rota todos los secretos, primero las claves de administración, y comprueba que las antiguas están muertas.
  5. Haz capturas del tráfico, los forks y las estrellas; después pon el repositorio en privado.
  6. Reescribe el historial con git-filter-repo, contacta con el soporte de GitHub y pide la retirada en los forks conocidos.
  7. Extrae los registros del proveedor de cada secreto filtrado: uso, auditoría, actividad. Para las claves de IA, usa los paneles y las API de arriba.
  8. Haz la evaluación RGPD, notifica en las 72 horas desde que tuviste constancia si procede y documéntalo en cualquier caso.
  9. Corrige los permisos del agente antes de volver a ponerlo en marcha.

En resumen

La lección incómoda de este caso es que nadie hizo nada malicioso y, aun así, terminó en una brecha con consecuencias regulatorias. Llevamos dos años preocupados por que los agentes se vuelvan contra nosotros mediante inyección de prompts y herramientas envenenadas. Esas amenazas son reales. Pero el fallo más común es más simple: le dimos a un programa las mismas credenciales y el mismo alcance que a un ingeniero sénior, sin nada de su criterio, y lo pusimos a correr contra una fecha de entrega.

Todo equipo que use agentes de programación debería ensayar este incidente antes de que ocurra. Elige un repositorio de pruebas, planta un canary token, deja que el agente lo suba y mide cuánto tardas en rotar, auditar y responder a las preguntas del regulador. Si hoy, sin nada ardiendo, no sabes leer el uso de tu proveedor de IA por clave, no lo vas a aprender a las dos de la mañana con el reloj de 72 horas en marcha.

Mantente paranoico. Rota primero. Y nunca le des a un agente un push que no necesita.

Lecturas recomendadas:

¿Preguntas o comentarios? Contacta a través de:

Contacto: info@vulnex.com

Publicado en AI, Economia, IA, Privacidad, Seguridad, Tecnologia | Etiquetado , , , , , , | Deja un comentario

Intención, no sofisticación: el atacante de IA ya consta en acta

Publicado el septiembre 24, 2026 por Simon Roses

Tiempo de lectura: 16 minutos

TL;DR

Este mes han aterrizado, con días de diferencia, dos documentos de dos fuentes que no tienen nada en común salvo lo que describen. El 14 de septiembre, la autoridad española de protección de datos, la AEPD, anunció que había recibido la primera notificación de brecha de datos personales bajo el RGPD por un ataque ejecutado por un agente de IA autónomo: una búsqueda de vulnerabilidades, un inicio de sesión correcto, una caza autónoma de agujeros en la aplicación, datos personales modificados y facturas accedidas, todo encadenado por el agente sin un humano al volante. Días antes, Anthropic había publicado un informe de amenazas que catalogaba su propio modelo usado de la misma forma a escala global: enjambres de agentes, malware que se reconstruye para esquivar la detección, un hacktivista en solitario manejando operaciones que antes necesitaban un equipo estatal. Un regulador sin producto que vender y un proveedor con todos los incentivos para quedar bien, describiendo de forma independiente el mismo animal. El titular que te sirve el proveedor es contundente («los ataques sofisticados ya no requieren atacantes sofisticados») y la frase que yo enmarcaría lo es aún más: «el principal rasgo distintivo entre estas clases de actores ya no es la sofisticación, sino la intención». La brecha de competencia no se encogió. Se derrumbó, y ahora consta en acta en el blog de un regulador español. Esta es la lectura de un profesional, no un resumen: los tres cambios que de verdad cambian tu trabajo, por qué el caso del regulador importa más que el informe del proveedor, y una lista para el lunes en la que las dos fuentes coinciden casi línea por línea.

Una nota sobre qué es esto. No desarticulé ninguna de estas operaciones y no puedo verificar ninguna de forma independiente. Una fuente es un proveedor informando sobre su propio modelo; la otra es un regulador resumiendo una notificación que recibió. Tomaré ambas en serio, porque encajan entre sí y con lo que el resto vemos desde fuera, y seré claro sobre dónde divergen los incentivos del proveedor y los intereses del lector. Enfoque defensivo en todo momento, sin detalle operativo, a nivel de vector de amenaza: las reglas de la casa de siempre.

De vez en cuando aterrizan dos documentos que dicen, con voces que tienen más datos que la mía, aquello que llevas un año diciendo contra el viento. Este mes me han llegado dos, desde extremos opuestos del mundo y extremos opuestos del espectro de incentivos.

El primero es pequeño, español y, para mí, el más importante. El 14 de septiembre la AEPD, la autoridad española de protección de datos, anunció que había recibido la primera notificación de una brecha de datos personales en la que el incidente, en el condicional prudente del regulador, «habría sido ejecutado» mediante un agente de IA que utilizó un conocido modelo de lenguaje. No asistido por IA, el género del correo de phishing escrito por un chatbot que ya conocemos todos. Ejecutado por IA. Según el relato de la notificación, el agente «inició una búsqueda de vulnerabilidades en archivos genéricos, y realizó un login correcto»; una vez dentro, se puso a buscar por su cuenta vulnerabilidades en la aplicación y, cuando encontró una, modificó datos personales y llegó hasta las facturas. La AEPD es explícita en que esto es un «cambio cualitativo»: un agente, en sus palabras, «puede recibir un objetivo, planificar tareas intermedias, utilizar herramientas, ejecutar código, consultar fuentes, interpretar resultados y modificar su actuación, de forma autónoma, en función de lo que encuentra». Un tercero, dice el regulador, lo habría utilizado «como instrumento para encadenar exitosamente distintas fases del ataque». La empresa no se nombra, el relato procede de la notificación de la propia empresa y la AEPD advierte de que aún requiere un análisis posterior. El regulador también es cuidadoso en un punto que quiero conservar: utilizar un modelo concreto no implica que el modelo o la infraestructura de su proveedor hayan sido comprometidos, ni que la herramienta se diseñara para fines maliciosos. Lo que importa es que un regulador europeo ha puesto ya por escrito, a partir de un caso real, lo que llevo todo el año argumentando.

El segundo documento es grande, estadounidense y viene con una salvedad a la que llegaré. Días antes del texto de la AEPD, Anthropic publicó su informe de inteligencia de amenazas de septiembre de 2026, que cataloga, a lo largo de siete áreas de daño y ocho meses (de diciembre de 2025 a agosto de 2026), un desfile de «Grupos de Amenaza Generativa» que usaron su modelo, Claude, para operaciones cibernéticas, campañas de influencia, fraude y vigilancia. Donde la AEPD te da una empresa y un agente, el proveedor te da la misma forma a escala planetaria.

Mi propio historial sobre esto es largo. En 2026 he escrito que el modelo se está convirtiendo en el atacante, que las skills de agente son un arma cargada y que la cadena de suministro de la IA es un objetivo blando. A principios de este mes escribí sobre un investigador de un laboratorio puntero que dimitía con una advertencia de que pronto serían «sistemas que pueden hackear cualquier cosa», y después sobre la llamada del CEO a frenar y por qué marcar el ritmo de la frontera no hace nada por la capacidad que ya anda suelta en el valle. Este artículo son los recibos, y el sentido de abrir con el caso español es que ya no son solo los recibos del proveedor.

Déjame hacer lo que un profesional debería hacer con documentos así: no recapitularlos (los resúmenes estarán por todas partes), sino extraer lo que de verdad cambia tu trabajo, y ser honesto sobre qué creer.

La única frase que importa

Reduce ambos documentos a una sola afirmación que lo sostenga todo y es la del proveedor: «el principal rasgo distintivo entre estas clases de actores ya no es la sofisticación, sino la intención».

Durante toda mi carrera, el modelo de amenaza se ha estratificado por capacidad. Los script kiddies abajo, el crimen organizado en medio, los estados-nación arriba, y tus defensas calibradas según quién creías que se molestaría contigo. Esa escalera es lo que ambos documentos dicen que se ha caído. Cuando un hacktivista en solitario puede desplegar el mismo oficio autónomo que un equipo de espionaje estatal, y cuando un tercero sin identificar puede apuntar un agente de serie a una empresa española y salir con registros modificados y facturas, «quién es lo bastante sofisticado como para hacerme daño» deja de ser una pregunta útil. La única variable que queda es quién quiere, y la intención es barata, abundante e imposible de parchear.

El proveedor dice sin rodeos la parte que se suele callar: «los ataques sofisticados ya no requieren atacantes sofisticados», porque la IA «ha derrumbado la brecha de mano de obra y herramientas que separaba a las operaciones estatales bien financiadas de los operadores individuales». El regulador dice lo mismo en prosa más seca: los agentes de IA no introducen técnicas nuevas, pero sí aumentan «la velocidad, escala y capacidad de adaptación de técnicas maliciosas ya conocidas, reduciendo el tiempo disponible para detectarlas y contenerlas». Los ataques de siempre. Ritmo nuevo, operadores nuevos.

Hay un detalle más del informe del proveedor que merece frase propia, porque cambia cómo debes leer todo lo que viene después. Anthropic afirma que los casos de abuso corrieron sobre sus modelos Haiku, Sonnet y Opus, y que «ninguno de los casos de abuso implicó el uso de modelos Claude Fable o de clase Mythos, con la excepción de un caso de destilación ilícita». Nadie en este catálogo necesitó la frontera. Cada operación corrió sobre el escalón que ya está en todas partes, que ya es barato y cuyos equivalentes aproximados puedes descargar y ejecutar sin que nadie mire. Ese es el valle que llevo señalando, descrito por el laboratorio dueño de la cumbre.

Tres cambios que de verdad cambian tu trabajo

Bajo los casos de estudio, tres cambios estructurales hacen el trabajo de verdad. Estas son las partes que merecen tu atención, y señalaré dónde el caso español y los datos del proveedor dicen lo mismo.

1. La brecha de competencia se derrumbó

El reparto del proveedor es la pista. Un grupo de espionaje chino (designado GTG-10007) cuyos operadores incluyen, según el informe, a dos estudiantes universitarios de Changsha, manejó «enjambres de agentes» que descomponían el reconocimiento en subagentes paralelos y mantenía un programa autónomo de investigación de vulnerabilidades que sacó a la luz múltiples vulnerabilidades desconocidas hasta entonces en productos de seguridad. Un único hacktivista francés (GTG-50029) entró en al menos catorce organizaciones y construyó una plataforma de doxing con pipelines de ingesta reales. Un operador con motivación económica (GTG-50014) dirigió la IA hacia objetivos y la dejó «evaluar entornos y ejecutar de forma iterativa» (el informe lo llama «vibe hacking», y sí, el nombre escuece) y luego descompiló 1,8 millones de APK de Android para cosechar secretos incrustados y salió de una aerolínea con decenas de millones de registros de pasajeros.

Ahora pon el caso de la AEPD al lado. Un agente, un objetivo, una empresa, y las mismas fases (escaneo, acceso, búsqueda de vulnerabilidades, datos) encadenadas de forma autónoma. Es el patrón del proveedor a la menor escala posible, y es la escala en la que de verdad viven la mayoría de mis lectores. Ninguna de estas personas, sobre el papel, debería poder hacer lo que hizo. La IA es el multiplicador de fuerza que permite a la intención saltarse la década de aprendizaje que antes exigía.

2. La estructura de costes invertida: el bucle se cierra más rápido que el tuyo

Esta es la idea técnica más importante del informe del proveedor, y por la que quien defiende debería perder el sueño. En el caso de espionaje ruso (GTG-20006), cuando un producto de seguridad marcaba el malware del grupo, «los agentes se ponían entonces a modificar y reconstruir el malware de forma autónoma para evadir las detecciones existentes». Anthropic saca la conclusión sin rodeos: antes un defensor podía frenar a un atacante desplegando una detección nueva; ahora «los adversarios capaces pueden ‘cerrar el bucle’, esquivando las detecciones de seguridad tradicionales más rápido de lo que los defensores pueden desarrollarlas y desplegarlas».

La AEPD llega al mismo sitio desde la otra dirección. Entre sus lecciones: «los procedimientos diseñados para ataques ejecutados manualmente pueden resultar insuficientes cuando un agente analiza simultáneamente múltiples activos», y «la supervisión humana continúa siendo imprescindible, pero debe apoyarse en mecanismos de detección, contención y respuesta capaces de operar con la rapidez suficiente». Un regulador y un proveedor, de forma independiente, describiendo la misma carrera.

Léelo como ingeniero de seguridad y es un cambio de fase. La detección siempre ha tenido una vida útil, pero esa vida útil se medía contra el ritmo de un atacante humano. Cuando el bucle evadir-reconstruir-redesplegar del atacante es autónomo, puede girar más rápido que tu bucle observar-analizar-escribir-probar-desplegar, que todavía tiene humanos dentro. La economía de la defensa se ha invertido en silencio: gana el bando que puede cerrar su bucle más rápido, y por primera vez ese no es automáticamente el defensor.

srf_atr_inverted_cost_loop
Figura 1. La estructura de costes invertida. El bucle del atacante (desplegar, ser detectado, dejar que el modelo reconstruya y mute el malware, redesplegar) puede cerrarse ahora en horas, de forma autónoma. El bucle del defensor (observar la técnica nueva, analizarla, escribir una detección, probarla y desplegarla) todavía tiene humanos dentro y se cierra en días o semanas. Cuando el bucle rojo gira más rápido que el azul, una detección queda obsoleta antes de desplegarse.

3. La cadena de suministro de la IA es ahora un objetivo, no solo una herramienta

Llevo tocando este tambor desde el trabajo sobre la trampa de las dependencias, y el informe del proveedor lo eleva de teoría a campaña. Un grupo (GTG-50020) comprometió el entorno de evaluación (sandbox) de un proveedor de IA, extrajo claves de API de producción de varios proveedores, golpeó a unas treinta empresas de IA en unos cuatro días y, el detalle que no me quito de la cabeza, buscó explícitamente acceso a modelos previos al lanzamiento (fracasó; todas las vías que probó estaban cerradas). Otro (GTG-50021) montó un revendedor fraudulento de Claude, ofreciendo acceso barato mientras redirigía el tráfico a otra parte y cosechaba las credenciales para revenderlas. Otros inyectaron prompts en servicios envoltorio (wrapper) LiteLLM para sacar las claves de producción directamente.

La AEPD, por su lado, aterriza sobre el mismo objeto. Sus palabras: «un agente que obtiene una cuenta, una clave API o un token con permisos excesivos puede operar a la velocidad de una máquina». La propia recomendación del proveedor es la que yo habría escrito, tratar «las claves de IA y las integraciones de agentes con el mismo nivel de seriedad» que las credenciales de producción, y la del regulador es la imagen especular, desde el lado de la víctima. Una clave de API a un modelo capaz es botín (revendido), cómputo (tu factura, su ataque) y tapadera (su actividad, tu nombre), todo a la vez. Si tu modelo de amenaza todavía archiva las «claves de IA» junto a los «inicios de sesión de SaaS que ya rotaremos», está desactualizado, y ahora un regulador está de acuerdo.

Junta los tres cambios y forman una sola estructura. La he modelado como un árbol de ataque, construido por completo a partir del informe del proveedor, porque lo importante no es ninguna rama concreta, sino la forma del conjunto.

srf_atr_ai_enabled_operation_tree
Figura 2. Anatomía de una operación habilitada por IA, extraída del informe del proveedor. Cuatro fases encadenadas con AND: bajar el suelo de competencia (marcos de ataque listos para usar como PentAGI, vibe hacking, enjambres de agentes), ejecutar el bucle autónomo (reconocimiento y explotación, investigación autónoma de vulnerabilidades, malware que se automodifica, exfiltración masiva sin supervisión), atacar la cadena de suministro de la IA (cosechar claves de producción, comprometer un sandbox de evaluación, revendedor fraudulento, inyectar prompts en un wrapper) y monetizar (exfiltrar a escala, revender credenciales, ejecutar ataques a cargo de la víctima, influencia como servicio). Dentro de cada fase las ramas son OR: basta con una vía. Con el suelo tan bajo, lo que distingue a un equipo estatal de un operador en solitario ya no es la sofisticación, sino la intención.

El resto del catálogo, en breve

Los casos cibernéticos son la columna vertebral, pero el informe del proveedor es más amplio, y otros dos hilos merecen la ojeada de un lector de seguridad. En operaciones de influencia, documenta la influencia como servicio comercial: una agencia con base en Francia (GTG-54002) que produjo en masa 8.913 artículos en unos setenta sitios de noticias falsos en cerca de veinte idiomas, amplificados por más de 250 cuentas no auténticas, cambiando de postura política según el cliente en lugar de por ideología: propaganda como producto de suscripción. Y una firma en Estambul (GTG-84005) que vendía una plataforma «de grado militar, impulsada por IA» de operaciones políticas que manejaba unas mil cuentas falsas para trabajarse unas elecciones malasias circunscripción a circunscripción. La misma automatización, apuntada a democracias en lugar de a redes.

El tejido conectivo, en el propio marco del proveedor, es que el oficio ofensivo de IA está proliferando: marcos de agentes disponibles públicamente como PentAGI «reproducen buena parte del mismo andamiaje» y automatizan cada paso de la cadena de ataque, así que esto ya no es dominio de los bien financiados. El suelo subió hasta alcanzar a todos. La empresa española de la notificación a la AEPD es lo que parece cuando ese suelo llega a un negocio que nunca imaginó ser un objetivo.

La salvedad honesta, y por qué ya no te frena

Ahora la parte que un buen profesional no puede saltarse.

El informe del proveedor es Anthropic informando sobre Anthropic. Los grupos de amenaza son autodesignados, las desarticulaciones las cuenta el propio proveedor (cuentas cerradas, monitorización añadida, inteligencia «compartida con las autoridades y con socios del sector cuando procede») y nada de ello es verificable de forma independiente desde donde tú y yo estamos. Y una divulgación así nunca es desinteresada: un informe que dice «nuestro modelo es tan capaz que estados y criminales corren a abusar de él, y los pillamos» demuestra a la vez responsabilidad, publicita la potencia del producto y da a los reguladores un motivo para preferir a los actores ya establecidos, que pueden permitirse esta clase de monitorización. Las tres cosas pueden ser ciertas a la vez. Lo dije cuando lo leí por primera vez, y lo mantengo.

Pero justo por eso el caso de la AEPD importa más de lo que sugiere su modesto tamaño. Un regulador de protección de datos no tiene modelo que vender, ni capacidad que inflar, ni motivo para adular al proveedor. Tiene una notificación, presentada por obligación legal por una empresa que habría preferido con mucho no presentarla. Cuando la parte con todos los incentivos para quedar bien y la parte sin ninguno describen el mismo ataque en la misma semana, el patrón es real. El informe del proveedor me dijo que la amenaza era global; la entrada del regulador me dijo que estaba dentro de la aplicación de una empresa española corriente, editando registros. Toma la inteligencia del proveedor, sopesa el marco del proveedor, y luego fíjate en que un regulador acaba de confirmar la sustancia desde el otro lado de la mesa.

Hay una tensión más callada que dejaré sin resolver. Cada operación del informe del proveedor corrió sobre un modelo cerrado, con entrenamiento de seguridad y un equipo de trust-and-safety que acabó pillándola, lo que, leído de una manera, es un argumento a favor del modelo cerrado y vigilado. Leído de otra, es un recordatorio de que ese mismo escalón de capacidad se está difundiendo hacia modelos abiertos que ningún proveedor vigila, donde no hay nadie que escriba siquiera el informe de desarticulación. El caso de la AEPD, significativamente, no dice qué modelo usó el atacante, solo que era uno conocido, y se molesta en aclarar que el proveedor no fue comprometido. Puede que no importe cuál. Prefiero quedarme en esa incomodidad a fingir que un lado tiene obviamente razón.

Tu lista para el lunes: donde las dos fuentes convergen

Donde la inteligencia de proveedor siempre flojea es justo donde la AEPD es inusualmente fuerte: en qué debe hacer quien defiende. Y aquí está lo que me convenció más que cualquier estadística. Las recomendaciones del regulador y las que yo ya había redactado a partir del informe del proveedor coinciden casi una por una. Cuando dos fuentes sin nada en común llegan a los mismos controles, esa es tu lista.

Mete los ataques ejecutados por IA en tu modelo de amenaza, por su nombre. La primera lección de la AEPD: «no basta con incluir una referencia genérica a malware, phishing o acceso no autorizado» en el análisis de riesgos; los ataques asistidos o ejecutados mediante IA entran expresamente, como adversario propio. Calibra según la intención y según el suelo de IA disponible ahora para cualquiera, no según la habilidad supuesta.

Trata las credenciales de IA como joyas de la corona. Guárdalas en un gestor de secretos, acótalas, rótalas y vigila su uso como vigilas una cuenta de administrador de dominio. Ambas fuentes aterrizan aquí de forma independiente. Una clave de modelo expuesta, o un token de API con más permisos de los que necesita, no es una molestia; es botín, cómputo y tapadera en una sola cadena, y una cuenta con permisos excesivos es exactamente lo que, según el regulador, permite a un agente operar a velocidad de máquina una vez dentro.

Instrumenta la capa de agentes, porque no puedes responder a un incidente que no ves. Si hay agentes autónomos actuando en tu entorno o contra él, necesitas telemetría en esa capa: qué se ejecutó, qué tocó, qué salió. Es el mayor hueco de visibilidad en la mayoría de las organizaciones, y ambos documentos son el argumento para cerrarlo ya.

Asume que tus detecciones tienen una vida útil más corta, y detecta a velocidad de máquina. Si el adversario puede reconstruir en torno a una firma de forma autónoma, la defensa estática y cargada de firmas se degrada rápido. La versión de la AEPD: la supervisión humana se queda, pero tiene que apoyarse en una detección, contención y respuesta que le sigan el ritmo. Desplaza el peso hacia la detección por comportamiento y las líneas base de anomalías, y hacia una respuesta que no espere a que un humano lea un ticket.

Inventaría y vigila tu propia cadena de suministro de IA. Cada envoltorio, proxy, servidor MCP y sandbox de evaluación que toca una clave de producción es ahora superficie de ataque. La inyección de prompts contra un envoltorio LiteLLM está en el informe del proveedor; trata esa clase de componente como infraestructura relevante para la seguridad, no como código pegamento.

Ensaya el reloj. El caso español terminó donde termina toda brecha europea: en una notificación al regulador, que el artículo 33 del RGPD exige en un plazo de 72 horas desde que se tiene constancia de ella. Cuando el propio ataque lo ejecuta un agente que escanea, entra, encuentra un agujero y edita datos en una sola pasada, responder a «qué ha pasado, en qué registros y cuándo» en tres días es bastante más difícil de lo que era. Si tu telemetría en la capa de agentes es fina, ese es el momento en el que lo vas a descubrir.

No olvides los cimientos aburridos. El regulador no lo hizo. La AEPD cierra, con sensatez, con lo básico y poco glamuroso: «conocer los tratamientos, minimizar los datos, limitar los accesos, corregir vulnerabilidades, controlar a los proveedores y estar preparados para responder». Un agente autónomo es un atacante nuevo; sigue entrando por una puerta vieja. En Europa esos cimientos ya no son solo buena práctica: con la nueva Directiva de Responsabilidad por Productos, un parche que falta va camino de ser un defecto del que respondes.

En resumen

La versión cómoda de la IA-y-la-seguridad dice que las capacidades peligrosas están a años vista, en manos de un puñado de laboratorios. Este mes un proveedor publicó ocho meses de evidencia de que están aquí, en manos de estudiantes universitarios, hacktivistas en solitario y grupos criminales de nivel medio, corriendo sobre modelos una generación por detrás de su mejor modelo, y un regulador español publicó el primer registro formal de uno de ellos entrando en los sistemas de una empresa corriente y sirviéndose. Lo único que separa a esos actores de un estado-nación es lo que decidieron hacer un martes cualquiera. Intención, no sofisticación.

Eso no es una condena. Es una orden de trabajo, y por una vez viene firmada por dos. El proveedor te dice que la amenaza es global; el regulador te dice que es local, que consta en acta y que está sujeta a la obligación de notificar. La respuesta a un terreno de juego nivelado no es la desesperación; es nivelar hacia arriba la defensa: nombra al atacante de IA en tu modelo de amenaza, custodia las claves, instrumenta la capa de agentes, asume que tus detecciones se pudren más rápido, ensaya el reloj y conserva los cimientos aburridos que el agente sigue necesitando para entrar. Toma el regalo del proveedor y lee las huellas del envoltorio. Luego lee la entrada del regulador, que no tiene envoltorio alguno.

Mantente paranoico. Custodia tus claves. Asume que el bucle se cierra más rápido que el tuyo, y asume que la próxima notificación podría ser la tuya.

Lecturas recomendadas:

¿Preguntas o comentarios? Contacta a través de:

Contacto: info@vulnex.com

Publicado en AI, IA, Privacidad, Seguridad, Tecnologia | Etiquetado , , , , , , | Deja un comentario

Marca el ritmo de la frontera, defiende el valle: una réplica de seguridad a Dario Amodei

Publicado el septiembre 15, 2026 por Simon Roses

Tiempo de lectura: 11 minutos

TL;DR

El CEO de Anthropic, Dario Amodei, ha publicado We Must Pace the Frontier («Debemos marcar el ritmo de la frontera») — un argumento inusualmente franco, viniendo del jefe de un laboratorio puntero, de que la industria debe frenar deliberadamente la velocidad a la que mejora las capacidades de los modelos, apoyado en evaluadores externos integrados, coordinación del sector y seguridad dura sobre los pesos de los modelos. Creo que tiene razón en gran medida, y quiero darle al texto lo suyo, porque es raro y valiente que quien dirige una de estas empresas lo diga en voz alta. Pero escribo desde la silla de la seguridad, y desde esa silla el texto tiene un punto ciego estructural: marcar el ritmo gobierna la cumbre —la capacidad que aún no se ha lanzado— mientras que la batalla de seguridad ya está abajo, en el valle, entre las capacidades que se han escapado, se han difundido a modelos abiertos y han caído en manos de los estudiantes universitarios y hacktivistas en solitario que documentó el propio informe de amenazas de Anthropic la semana pasada. Y en las cuarenta y ocho horas siguientes a su texto, los dos gobiernos de los que depende su plan dijeron que no — Washington con «quien gana la IA, gana», Pekín con «alarmismo» — mientras el propio jefe de los espías chinos advertía de que la IA amenaza el control del Partido. Puedes marcar el ritmo de la frontera y aun así perder el terreno que queda detrás. Este es el tercero y último de un breve arco —la advertencia, los recibos y ahora la política— y mi única aportación a la conversación es sencilla: frenar lo que viene no hace nada por retirar lo que ya anda suelto, y defender el valle es otro trabajo, y empieza hoy.

Una nota sobre qué es esto. Opinión, de un profesional, sobre un argumento de política pública hecho por el CEO de la empresa que fabrica el modelo sobre el que llevo un año escribiendo. La gobernanza de la IA está genuinamente en disputa; le daré crédito a Amodei donde creo que acierta, añadiré la pieza que creo que le falta y señalaré dónde divergen sus incentivos y los míos. No soy investigador de alineamiento y no pretendo dirimir la p(doom). Me dedico a defender sistemas, y esa es la única silla desde la que hablo.

Algo ha cambiado en las últimas dos semanas, y vale la pena nombrarlo antes de discrepar de nada. Un investigador de un laboratorio puntero dimitió con una advertencia de que los laboratorios se están jugando nuestras vidas. Días después, Anthropic publicó un informe de amenazas que documentaba su propio modelo usado, a escala, para ataques reales. Y ahora el CEO de esa misma empresa ha publicado un argumento largo y serio de que la industria debe frenar. La advertencia, los recibos y la respuesta de política pública — el mismo edificio, las mismas dos semanas. Se piense lo que se piense de ello, no es poca cosa.

Así que empiezo por donde estoy de acuerdo, porque lo estoy, y porque la crítica contraria por reflejo sería la fácil.

Donde Amodei acierta

La afirmación central de Amodei es que esto no es 2023, cuando las cartas por una «pausa» pedían a la industria que detuviera algo que aún no podía hacer mucho daño. Su argumento es que los modelos de hoy pueden actuar como agentes, engañar a sus propias evaluaciones y ejecutar ciberataques — así que el caso para frenar el crecimiento de capacidades es ahora concreto, no especulativo. Como alguien que ha pasado el año documentando justo esos comportamientos, no voy a fingir que se equivoca. Acierta, y es notable que cite el incidente de OpenAI/Hugging Face —el mismo que desmenucé en Cuando el modelo es el atacante— como uno de los dos sucesos que le hicieron cambiar de opinión. Cuando el CEO y el profesional de fuera leen el mismo incidente de la misma forma, es una señal digna de respeto.

Los mecanismos que propone son además más concretos que la habitual vaguedad de la gobernanza. Los evaluadores integrados —auditores externos con acceso de nivel empleado que pueden publicar hallazgos que la empresa no puede editar— es una idea genuinamente buena, y que Anthropic se comprometa a ello de forma unilateral en lugar de esperar a un mandato es la manera correcta de mover ficha primero. Su lista de excelencia operativa —monitorización de verdad, sandboxing, higiene de datos— es, casi palabra por palabra, la postura defensiva que llevo defendiendo. Y su insistencia en una seguridad dura en torno a los pesos de los modelos es exactamente correcta: los pesos son las joyas de la corona, y he visto a atacantes salir a buscar acceso a modelos previos al lanzamiento en la práctica. En todo eso, crédito donde toca. Es un documento más honesto de lo que la mayoría en su puesto publicaría jamás.

El punto ciego: la cumbre y el valle

Aquí es donde la silla de la seguridad ve algo que la silla del CEO estructuralmente no puede.

Marcar el ritmo de la frontera es una política sobre la cumbre — el próximo modelo, más capaz, que aún no se ha entrenado. Es un control sobre el futuro. Y como control sobre el futuro, es razonable. Pero casi nada de lo que yo manejo vive en la cumbre. Mi trabajo está abajo, en el valle: las capacidades que ya se lanzaron, ya se filtraron, ya se difundieron por ahí y no se pueden des-lanzar. Y la verdad incómoda es que marcar el ritmo de la frontera no hace nada —literalmente nada— por el valle.

El propio informe de amenazas de Anthropic es la prueba, y el momento me da la razón sola. Ese informe no describía una futura superinteligencia. Describía a estudiantes universitarios en Changsha manejando enjambres de agentes, a un hacktivista en solitario construyendo una plataforma de doxing, a criminales de nivel medio decompilando 1,8 millones de apps en busca de secretos — todo usando la capacidad de hoy, la que ya está fuera. Eso no lo puedes frenar. Ya pasó. Un acuerdo de ritmo firmado mañana no vuelve atrás para des-enseñarle al modelo que ya corre en la GPU alquilada de alguien.

Y ese es el modelo del laboratorio puntero, el gobernado. El valle es mucho más ancho que eso. Las mismas capacidades se están difundiendo hacia modelos abiertos que ningún acuerdo de ritmo puede tocar, porque no hay nadie que lo firme ni nada que retirar. Puedes frenar a Anthropic. Puedes frenar a OpenAI. No puedes frenar un fichero de pesos que ya se ha descargado un millón de veces y afinado en un sótano. Un modelo abierto capaz, una vez que sus pesos están fuera, se replica y se reafina sin cuento en cuestión de semanas — no hay botón de retirada, ni nadie que firme una pausa aunque lo hubiera. Marcar el ritmo es un tratado entre la gente de la cumbre; el valle está lleno de gente que nunca estuvo en la mesa y nunca lo estará.

Así que sé preciso sobre lo que marcar el ritmo hace y no hace. Estrangula el flujo de entrada — la velocidad a la que la capacidad peligrosa nueva se derrama desde la cumbre hacia el valle — y eso es real, y vale la pena tenerlo. Lo que no puede hacer es vaciar el valle que ya está lleno. Esa es la totalidad de mi única aportación al argumento de Amodei: marcar el ritmo de la frontera es necesario y no es suficiente. Es una buena política para la capacidad que viene, y política ninguna para la capacidad que ya está aquí. Alguien tiene que defender el valle, y ese alguien no va a ser el equipo de evaluación de un laboratorio puntero. Va a ser el resto de nosotros.

Qué significa de verdad «defender el valle»

Si marcar el ritmo es el trabajo de la cumbre, este es el del valle — la agenda del profesional que el texto de Amodei, por su propia naturaleza, no cubre.

Asume que la capacidad peligrosa ya está fuera, porque lo está. Tu modelo de amenaza no debería esperar a que el próximo modelo puntero dé miedo. El actual, y la copia abierta del anterior, ya bastan. Planifica para el adversario que ya tiene un agente ofensivo autónomo, porque el informe de amenazas dice que lo tiene.

Trata los modelos abiertos como un insumo ingobernable. No hay ningún equipo de trust-and-safety detrás del modelo del sótano, ni evaluador integrado, ni informe de desactivación. Si tu defensa asume que el modelo del atacante está vigilado, se equivoca. Construye para el modelo que no responde ante nadie.

Instrumenta y contén en tu frontera, no en la suya. No puedes marcarle el ritmo al modelo del atacante, pero sí puedes controlar qué pasa cuando se encuentra con tus sistemas: telemetría en la capa de agentes, mínimo privilegio, control de salida, credenciales de IA custodiadas como secretos de producción. La cumbre se gobierna por tratado; el valle se gobierna con tus propios controles, o no se gobierna.

Deja de esperar permiso de la frontera. Las propuestas de Amodei necesitan gobiernos, coordinación y años. Tu incidente del próximo trimestre no. La defensa del valle no puede depender de un acuerdo global que quizá nunca llegue; tiene que funcionar bajo el supuesto de que el acuerdo fracasa.

Las dos capitales respondieron en cuarenta y ocho horas

El plan de Amodei tiene tres pasos, y los dos últimos —coordinación entre los laboratorios respaldada por gobiernos democráticos, y después un acuerdo global que alcance a los autoritarios— dependen por completo de que los gobiernos lo quieran. A los dos días de su texto, los dos gobiernos que más importan dieron su respuesta.

En Washington, Trump —hablando en Irlanda al día siguiente del texto, y de nuevo en redes— calificó las advertencias de exageradas, dijo que Estados Unidos no puede permitirse perder impulso frente a China, rechazó cualquier frenazo generalizado dejando margen para salvaguardas concretas, y comprimió toda la doctrina en cuatro palabras: «quien gana la IA, gana». Y ya no era a un solo CEO a quien despachaba. Altman, Musk y Hassabis se habían alineado todos detrás de la petición de marcar el ritmo. La frontera entera, en bloque, pidió frenar — y recibió un no de la Casa Blanca.

La respuesta de Pekín llegó el mismo día, y es la más instructiva de las dos porque llegó en estéreo. Oficialmente, el portavoz del Ministerio de Exteriores despachó toda la conversación: «el alarmismo, la confrontación y la competencia viciosa solo perturbarán el proceso de gobernanza global de la IA». Pero en la revista estatal China Cyberspace, el jefe del Ministerio de Seguridad del Estado, Chen Yixin, escribía lo contrario: que la IA es «una nueva arena de rivalidad estratégica entre grandes potencias», que habilita «una guerra de propaganda y una guerra cognitiva» que amenazan la «seguridad política, la seguridad institucional y la seguridad ideológica» del Partido, y que la próxima generación de modelos estadounidenses rebajará la barrera para los ciberataques. El jefe de los espías de China tiene miedo de exactamente lo mismo que Amodei. Los diplomáticos de China no van a frenar de todos modos.

Lee las dos respuestas juntas y tienes la carrera entera en miniatura: todos en la cumbre pueden ver el peligro, y ninguna capital va a ser la primera en frenar. No es un motivo para abandonar la coordinación — Amodei debería seguir empujando. Es el motivo por el que el valle no puede esperarla. La frase que escribí justo arriba, que la defensa del valle tiene que funcionar bajo el supuesto de que el acuerdo fracasa, dejó de ser una hipótesis unas cuarenta y ocho horas después de que él pulsara publicar.

Qué podría hacer de verdad la cumbre por el valle

Para ser justo con Amodei —y porque una crítica que solo quita es una crítica débil— la cumbre no está impotente para ayudar aquí abajo. Ya lo ha hecho, y debería decirlo más alto. El informe de amenazas de Anthropic es el mejor ejemplo que hay en la sala: un laboratorio puntero usando su posición única de observación sobre cómo se abusa de su propio modelo para entregar a los defensores inteligencia de verdad — técnicas, herramientas, indicadores. Eso es la cumbre lanzando una cuerda al valle, y para mí vale más que cualquier calendario de ritmo.

Así que esta es la enmienda que le atornillaría a la agenda del ritmo. Si los laboratorios van en serio, el paquete de gobernanza debería llevar compromisos de cara al defensor junto a los controles de capacidad: divulgación rutinaria del oficio del abuso —más de justo lo que hace el informe de amenazas—, detecciones e indicadores compartidos, y herramientas construidas para quienes defienden el presente difundido, no solo para quienes gobiernan el futuro vigilado. Marca el ritmo de la cumbre, por supuesto. Pero lanza más cuerda. El valle es donde tu modelo ya se está convirtiendo en un arma, y el laboratorio que ve eso ocurrir es el que está en mejor posición para ayudar al resto de nosotros a verlo también.

El incentivo que tengo que nombrar

Sería un mal profesional si me tragara la propuesta de gobernanza de un CEO de laboratorio del todo al pie de la letra, así que una nota honesta. Marcar el ritmo de la frontera, los evaluadores integrados, los requisitos de seguridad duros, restringir el cómputo a los rivales — todo es razonable por sus méritos, y además da la casualidad de que favorece a los titulares. Un régimen en el que solo unos pocos laboratorios bien financiados pueden permitirse cumplir el listón de seguridad es un régimen en el que solo unos pocos laboratorios bien financiados compiten. No creo que sea el motivo de Amodei; el texto se lee como sincero, y el incidente de HF es una razón real para alarmarse. Pero la sinceridad y el interés propio pueden apuntar en la misma dirección, y el lector debería tener ambos a la vista. Toma el argumento; mantén los ojos abiertos sobre a quién beneficia.

Nada de esto le resta valor al texto. Es una pieza seria e inusualmente franca escrita por alguien que tiene todo que perder al escribirla. Solo quiero que la comunidad de seguridad lo lea por lo que es: una política necesaria para lo alto de la montaña, publicada por alguien que vive allí — y que no lo confunda con un plan para el valle que el resto de nosotros defendemos de verdad.

En resumen

Marca el ritmo de la frontera. Lo digo en serio — frenar la capacidad que aún no se ha lanzado es una buena idea, y Amodei merece crédito por decirlo desde la silla en la que se sienta. Pero que la elegancia de una política de nivel-cumbre no te distraiga del trabajo poco glamuroso de aquí abajo. Las capacidades peligrosas ya están sueltas, ya se difunden, ya están en manos de gente a la que ningún tratado alcanzará. El CEO puede gobernar la cumbre. Defender el valle es nuestro trabajo, empieza hoy, y no puede esperar a un acuerdo global.

Con eso cierro un breve arco — la advertencia, los recibos y la réplica. Ahora vuelvo a bajar al valle, donde está el trabajo de verdad, y te sugeriría que hicieras lo mismo.

Mantente paranoico. Marca el ritmo de lo que puedas. Defiende lo que ya anda suelto.

Lecturas recomendadas:

¿Preguntas o comentarios? Contacta a través de:

Contacto: info@vulnex.com

Publicado en AI, Economia, IA, Privacidad, Seguridad, Tecnologia | Etiquetado , , , , , | Deja un comentario