Así es como lograron hackear a Claude, Gemini y Copilot

Un investigador manipula agentes de IA de Anthropic, Google y GitHub para robar credenciales y destapa un silencio incómodo dentro del sector

Los agentes de IA de Anthropic, Google y GitHub —la pieza de Microsoft en esta historia— pudieron ser manipulados con una técnica de prompt injection incrustada en contenido corriente de GitHub: un título de pull request, el cuerpo de una issue, un comentario y, en el caso más fino, hasta una nota HTML invisible para el ojo humano. El resultado no fue una travesura académica ni una demo de escaparate. El investigador Aonan Guan documentó cómo esos agentes acababan publicando claves API, tokens de GitHub y otros secretos del entorno donde estaban ejecutándose. Y sí: hubo recompensas por reporte, pero no CVE ni aviso público a la altura de la gravedad del hallazgo.

La parte importante, la que explica de verdad lo que ocurrió, es esta: no estamos ante un “hackeo” clásico que fuerce servidores desde fuera, sino ante agentes que obedecen mal porque leen como contexto confiable datos que no lo son. Eso permite convertir a GitHub en el propio canal del robo. El atacante escribe algo; el agente lo interpreta como parte de su trabajo; ejecuta acciones con herramientas y credenciales reales; y la fuga vuelve a GitHub en forma de comentario, log, commit o archivo. Todo dentro de casa. Sin infraestructura externa. Sin la caricatura del atacante con capucha en un sótano húmedo. Más simple. Más incómodo.

Un ataque que usa GitHub contra sí mismo

Guan bautizó el patrón como Comment and Control, un nombre que no está nada mal porque resume la jugada con bastante mala leche: el atacante no necesita montar un canal de mando aparte, le basta con usar las propias piezas del flujo de desarrollo. El bot lee datos de GitHub porque para eso está ahí. Revisa pull requests, analiza issues, responde comentarios, crea commits. Ese tráfico cotidiano, que parecía inocente, se convierte en superficie de ataque. La trampa no entra por una puerta trasera; entra por la principal, con pase VIP y cara de empleado del mes.

Aquí conviene detenerse un segundo, porque hay un matiz técnico que cambia bastante el cuadro. La prompt injection indirecta tradicional suele ser reactiva: alguien planta instrucciones en una web o en un documento y espera a que una persona pida al modelo que lo lea o lo resuma. En este caso, el mecanismo es más agresivo porque es proactivo. Los flujos de GitHub Actions se disparan solos sobre eventos como pull_request, issues o issue_comment. Basta con abrir una incidencia o lanzar una pull request para activar al agente en determinados entornos. La máquina no cae porque “decida” leer algo raro; cae porque leer eso forma parte exacta del trabajo que le hemos ordenado hacer.

Ese detalle parece pequeño, pero no lo es. Cambia el mapa del riesgo. Ya no hablamos de un usuario despistado que arrastra un documento venenoso al chat y a ver qué sale. Hablamos de automatizaciones empresariales, integradas en repositorios reales, con permisos reales y con secretos reales al alcance del proceso. En otras palabras: la comodidad de la automatización empieza a parecerse demasiado a una cadena de montaje donde cualquiera puede colar una instrucción falsificada y dejar que la máquina haga el resto.

Tres pruebas, un mismo agujero mental

Claude Code y el título que no debía leerse como orden

En Anthropic, el caso afectó a Claude Code Security Review. Según la investigación, el título de la pull request se interpolaba en el prompt sin un saneado suficiente. Ese detalle, que en un workflow serio debería levantar más cejas de las que levantó, permitió que instrucciones maliciosas acabaran ejecutándose con herramientas del agente. Guan mostró que podían extraerse ANTHROPIC_API_KEY y GITHUB_TOKEN del entorno del proceso y devolverlos en un comentario del bot o dejarlos en los logs de Actions, una vía todavía más discreta.

Lo notable no es solo que el modelo “entendiera” la orden, sino que el proceso heredara variables sensibles del entorno y las tratara como material disponible. Ahí está la grieta. El agente no se limita a leer texto; actúa dentro de un ecosistema con permisos, herramientas, variables y capacidad de escritura. Y cuando mezclas lenguaje natural, automatización y credenciales, la frontera entre contexto y orden empieza a desdibujarse con una facilidad alarmante.

Gemini y la falsa zona segura

En Google, el objetivo fue Gemini CLI Action. El patrón cambiaba un poco el decorado, no el fondo. El agente incorporaba al contexto el título, el cuerpo y los comentarios de una issue. El investigador inyectó una falsa sección de “contenido confiable” después del bloque legítimo de contexto adicional y consiguió que Gemini publicara la GEMINI_API_KEY como comentario visible en la propia incidencia. Traducido al castellano de la calle: el bot fue persuadido para creer que revelar la llave era una acción permitida dentro de un entorno supuestamente seguro, cuando de seguro había bastante poco.

La escena tiene algo casi ridículo, y por eso mismo da miedo. El sistema se presenta como una ayuda avanzada para desarrolladores y termina comportándose como ese empleado nuevo que enseña la caja fuerte porque alguien se lo pidió con tono convincente. No hay que romper el cristal. Basta con hablarle a la máquina de la forma adecuada, en el lugar adecuado, usando el canal que ya estaba abierto.

Copilot y el truco invisible

El caso de GitHub Copilot Agent, quizá el más inquietante de los tres, sube un peldaño porque mezcla invisibilidad y falsa sensación de control. Aquí el payload se escondía dentro de un comentario HTML en el cuerpo de una issue, de modo que el humano veía un texto inocente mientras el agente leía también las instrucciones ocultas. Después, cuando una víctima asignaba esa incidencia a Copilot, el sistema ejecutaba órdenes como ps auxeww | base64, generaba un archivo, lo subía a una rama y abría una pull request. De ese archivo codificado podían extraerse GITHUB_TOKEN, GITHUB_COPILOT_API_TOKEN, GITHUB_PERSONAL_ACCESS_TOKEN y COPILOT_JOB_NONCE.

Ese punto es especialmente delicado porque GitHub ya había introducido capas de protección en tiempo de ejecución: filtrado de entorno, escaneo de secretos, restricciones de red. Sobre el papel suena razonable. En la práctica, la investigación mostró cómo esas defensas podían esquivarse usando el propio canal permitido, GitHub, como vía de exfiltración. No hace falta abrir una conexión rara a un servidor externo si la propia plataforma sirve como mensajero del botín.

El detalle que cambia la gravedad del caso

Hay noticias técnicas que parecen enormes y luego se quedan en una demo de laboratorio, bonita, muy compartible, bastante inofensiva. Esta no juega en esa liga. Lo que se extrae aquí no son frases comprometedoras del prompt del sistema ni un trozo pintoresco de configuración; son secretos operativos del repositorio o del entorno del runner. Eso incluye claves de proveedor, tokens con capacidad de escritura y credenciales que pueden tocar código, comentar, abrir cambios o, en el peor de los casos, moverse lateralmente por la cadena de herramientas.

Cuando se habla de “robar credenciales”, en este caso no se está exagerando para animar el titular. Se está describiendo una posibilidad técnica con consecuencias muy concretas. Una clave API expuesta puede generar costes, abrir puertas a otros sistemas o alimentar ataques posteriores. Un token de GitHub puede cambiar archivos, manipular flujos, abrir puertas a automatizaciones encadenadas. El efecto no es solo el robo; es lo que ese robo permite después.

También hay que evitar el titular tramposo de “todo GitHub está roto”. No es eso. Por defecto, GitHub Actions no expone secretos a las fork pull requests. El riesgo aparece cuando un repositorio ejecuta agentes sobre entradas de colaboradores no confiables y, además, les concede acceso a secretos o capacidades de escritura donde no debería. Ahí entran configuraciones como pull_request_target, permisos demasiado generosos o automatismos pensados para ahorrar tiempo que acaban convirtiendo el repositorio en una oficina abierta a las tres de la mañana.

Bug bounty, sí; aviso claro, no

La cronología explica bastante bien por qué este asunto ha irritado tanto a parte del sector. El informe sobre Claude se reportó en octubre de 2025 y se resolvió en noviembre con una recompensa de 100 dólares. El de Gemini se notificó ese mismo mes y Google lo premió en enero de 2026 con 1.337 dólares. El de Copilot llegó en febrero de 2026, GitHub lo cerró primero como “informativo”, luego se reabrió y terminó resuelto en marzo con 500 dólares. El blog técnico que reunió el conjunto de hallazgos se publicó a mediados de abril de 2026. Es decir, no hablamos de un susto descubierto ayer por la tarde, sino de meses de comunicaciones privadas entre investigador y plataformas.

Aquí entra una cuestión menos vistosa, pero decisiva. No hubo CVE ni advisory público claro. Y eso no es una manía de burócrata con pasión por las siglas. Sirve para que equipos de seguridad, responsables de compliance, administradores de plataformas y terceros que dependen de versiones concretas sepan que existe un problema, lo rastreen y lo documenten. Sin esa señal pública, muchos usuarios siguen viendo un repositorio que “funciona”, una acción que “pasa” o un bot que “ayuda”, y no activan ninguna revisión seria.

Anthropic, según el investigador, llegó a valorar el caso con una severidad alta. GitHub, por su parte, lo trató en parte como una limitación arquitectónica. Ese lenguaje importa. Cuando un proveedor llama “limitación arquitectónica” a un vector que termina sacando tokens del proceso, está diciendo, en el fondo, que el fallo no cabe del todo en la caja de herramientas clásica. Y ahí aparece el gran atasco de esta etapa de la IA: se despliegan agentes con poder operativo antes de que la industria haya decidido cómo clasifica, comunica y asume sus fracasos.

No es un fallo aislado: es arquitectura

Lo más duro de esta historia no es que tres grandes nombres hayan tropezado a la vez. Lo duro es que los tres tropezaron con el mismo tipo de problema. El patrón común es casi ofensivamente sencillo: entrada no confiable de GitHub, agente que la procesa como contexto útil, herramientas con capacidad de ejecución y secretos accesibles en el mismo entorno. Ahí nace la contradicción. El agente necesita leer lo que llega desde fuera para hacer su trabajo. Y necesita credenciales para actuar. Juntar ambas cosas en el mismo espacio operativo equivale a sentar al becario nuevo en la caja fuerte y pedirle que abra todos los sobres sospechosos.

Por eso varios especialistas llevan tiempo insistiendo en una idea incómoda: la analogía correcta no es tanto SQL injection como una especie de phishing para máquinas. No se trata de romper un parser con un carácter raro, sino de persuadir al sistema para que obedezca instrucciones envueltas como si fueran contexto legítimo. La diferencia parece filosófica, pero no lo es. Si el problema fuera solo un bug de implementación, bastaría con parchear una línea y dormir tranquilos. Si el problema es que el agente debe leer datos hostiles para trabajar, el frente se mueve a otro sitio: mínimo privilegio, segmentación de secretos, herramientas limitadas, controles humanos y bastante menos fe ciega en la palabra “autonomía”.

La documentación empieza a admitir lo obvio

Uno de los aspectos más reveladores del caso es que la propia documentación de algunas herramientas ya empieza a reconocer el problema, aunque sea con tono casi administrativo. En el caso de Anthropic, la acción de revisión de seguridad advierte que no está endurecida frente a prompt injection y que conviene usarla solo sobre pull requests de confianza o con aprobación previa para colaboradores externos. Eso, leído deprisa, parece una nota técnica. Leído con calma, suena a rectificación cultural.

Hace nada estos agentes se vendían como asistentes sofisticados para acelerar tareas delicadas. Ahora su propia documentación te viene a decir: cuidado, no los sueltes alegremente sobre entradas hostiles porque podrían tragarse el cebo. La tecnología sigue prometiendo velocidad; la letra menos brillante empieza a recordar que no confundas velocidad con control.

La fiebre del agente y la resaca de seguridad

La carrera por meter agentes en cada esquina del desarrollo —revisión de código, triaje de incidencias, automatización rutinaria, despliegues, respuesta a incidentes— tiene una lógica comercial evidente: menos fricción, menos tiempo muerto, más sensación de que el software se mueve solo. El problema aparece cuando el relato de producto va dos pasos por delante del modelo de amenazas. El caso de Guan no demuestra que los agentes sean inútiles. Demuestra algo más incómodo: que un agente con demasiado acceso y demasiado contexto es un multiplicador de errores.

Donde antes había un comentario venenoso, ahora puede haber ejecución, escritura y fuga de credenciales con sello corporativo. Donde antes un descuido generaba ruido, ahora puede generar un incidente. Ese salto es el que muchas empresas todavía no están terminando de asumir. Y, mientras tanto, la tentación sigue ahí: automatizar más, delegar más, abrir más permisos porque todo va más deprisa. Hasta que deja de ir.

Google, como otros proveedores, acompaña estas herramientas con recomendaciones generales de buenas prácticas: proteger ramas, gestionar secretos con cuidado, fijar versiones, revisar logs, endurecer autenticación. Todo eso está bien. Nadie discute la higiene básica. Pero una guía general no sustituye a un aviso específico cuando ya se ha demostrado un patrón de ataque concreto con botín real. Ahí está, quizá, la grieta más reveladora de todo el episodio: la industria de la IA ya ha aprendido a pagar bug bounties por hallazgos incómodos, pero todavía no ha decidido del todo cómo contarlos cuando la vulnerabilidad no encaja limpiamente en las casillas heredadas del software clásico.

Lo que queda al descubierto

Lo ocurrido con Claude Code Security Review, Gemini CLI Action y GitHub Copilot Agent deja una conclusión bastante seca. El riesgo central de los agentes no está solo en el modelo, ni solo en el prompt, ni solo en los permisos. Está en la mezcla. En cuanto un sistema que interpreta lenguaje natural recibe instrucciones desde usuarios o entornos no confiables y, al mismo tiempo, dispone de herramientas con capacidad real y secretos a mano, el margen para convertir “contexto” en “orden” se vuelve peligrosamente estrecho.

Ese es el corazón de la noticia. No una anécdota para especialistas. No un susto de laboratorio sobredimensionado para rascar clics. Una advertencia seria sobre cómo se están desplegando los agentes de IA justo ahora, en empresas reales, sobre repositorios reales, con flujos reales y con una confianza quizá demasiado optimista en que el sistema entenderá por sí solo dónde acaba el texto y dónde empieza el engaño.

Y hay una segunda conclusión, menos técnica y más industrial. Si una vulnerabilidad se reconoce en privado, se recompensa, se mitiga a medias o se rodea con recomendaciones, pero no se comunica con la claridad que exige su impacto, el usuario queda convertido en figurante de un experimento del que no conoce ni el guion. Ese es el verdadero golpe de esta historia: no solo que se pudiera secuestrar a tres agentes relevantes con prompt injection, sino que la conversación pública sobre ese riesgo siga yendo por detrás de la realidad técnica. La IA agéntica promete manos. De momento, lo que está enseñando son, sobre todo, sus muñecas.