Ciencia y Tecnología
Han secuestrado agentes de Anthropic, Google y Microsoft por el bien de la ciencia. Las tres empresas acabaron pagando
<p>
 <img src="https://i.blogs.es/82d438/hacker-portada/1024_2000.jpeg" alt="Han secuestrado agentes de Anthropic, Google y Microsoft por el bien de la ciencia. Las tres empresas acabaron pagando ">
 </p>
<p>En algunos equipos de desarrollo ya se está volviendo habitual apoyarse en <a class="text-outboundlink" href="https://www.xataka.com/basics/ai-agents-agentes-ia-que-componentes-que-tipos-existen-inteligencia-artificial" data-vars-post-title="AI Agents o Agentes de IA: qué son, componentes y qué tipos existen en la inteligencia artificial" data-vars-post-url="https://www.xataka.com/basics/ai-agents-agentes-ia-que-componentes-que-tipos-existen-inteligencia-artificial">agentes de inteligencia artificial</a> para revisar incidencias, analizar cambios en el código y moverse por tareas que antes quedaban en manos humanas. El problema aparece cuando esos sistemas no solo leen información que puede venir de fuera, sino que además operan en espacios donde conviven <strong>claves, tokens y permisos sensibles</strong>. Eso es lo que pone sobre la mesa una investigación reciente: no estamos simplemente ante una herramienta útil que puede equivocarse, sino ante una arquitectura que también puede volverse peligrosa si se despliega sin límites muy claros.</p>
<p><!-- BREAK 1 --></p>
<p>La alarma la ha encendido <a rel="noopener, noreferrer" href="https://oddguan.com/">Aonan Guan</a> y los investigadores de Johns Hopkins Zhengyu Liu y Gavin Zhong tras demostrar ataques contra tres agentes desplegados en la mencionada plataforma: Claude Code Security Review, de Anthropic, Gemini CLI Action, de Google, y GitHub Copilot Agent, una herramienta de GitHub bajo Microsoft. <a rel="noopener, noreferrer" href="https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/">Según su documentación,</a> los fallos fueron comunicados de forma coordinada y acabaron en recompensas económicas pagadas por las compañías, pero lo relevante es que apuntan a un problema más amplio.</p>
<h2>Así lograron torcer a los agentes desde dentro</h2>
<p>El nombre que Guan le pone al hallazgo ayuda bastante a entender de qué va todo esto: “Comment and Control”. La idea es sencilla de explicar, aunque el fondo no lo sea tanto. En vez de montar una infraestructura externa para dirigir el ataque, el propio GitHub hace de canal de entrada y de salida: el atacante <strong>deja la instrucción en un título</strong>, una incidencia o un comentario, el agente la procesa como si formara parte del trabajo normal y el resultado termina reapareciendo dentro de ese mismo entorno. Todo queda en casa, y precisamente ahí está la clave del problema.</p>
<p><!-- BREAK 2 --></p>
<div class="article-asset-video article-asset-normal">
<div class="asset-content">
<div class="base-asset-video">
<div class="js-dailymotion"></div>
</p></div>
</p></div>
</div>
<p>Y ese “todo queda en casa” no es un detalle menor, sino la base de lo que describe la investigación. Los tres agentes comparten una lógica muy parecida: leen contenido normal de GitHub, lo incorporan como contexto de trabajo y, a partir de ahí, ejecutan acciones dentro de flujos automatizados. El choque aparece porque ese mismo espacio no solo contiene texto enviado por terceros, sino también herramientas, permisos y secretos que el agente necesita para operar.</p>
<p><!-- BREAK 3 --></p>
<p>El primer caso que detalla Guan afecta a Claude Code Security Review, una acción de GitHub de Anthropic pensada para revisar cambios de código y buscar posibles fallos de seguridad. Hasta aquí, todo entra dentro de lo esperable. El problema, según explica el investigador, es que bastaba con introducir instrucciones maliciosas en el título de una <em>pull request</em>, que es la solicitud que alguien envía para proponer cambios en un proyecto, para que <strong>el agente ejecutara comandos</strong> y devolviera el resultado como si formara parte de su revisión. Después, el equipo logró ir un paso más allá y demostrar que también podía extraer credenciales del entorno.</p>
<p>Lo interesante es que el mismo esquema también apareció en los otros dos servicios, aunque con matices. En Google, Gemini CLI Action podía ser empujado a revelar la GEMINI_API_KEY a partir de instrucciones coladas en una incidencia y en sus comentarios; en GitHub Copilot Agent, la variante era todavía más preocupante, porque el ataque se escondía en un comentario HTML que una persona no veía en pantalla, pero el agente sí procesaba cuando otra persona lo asignaba al caso. En ambos escenarios, el fondo volvía a ser el mismo: contenido aparentemente normal que acababa torciendo el comportamiento del sistema hasta exponer credenciales o información sensible dentro del propio GitHub.</p>
<p><!-- BREAK 4 --></p>
<div class="article-asset-image article-asset-normal article-asset-center">
<div class="asset-content">
<p> <img alt="Claude Code Api Key Leak" class="centro_sinmarco" src="https://i.blogs.es/1e1f8b/claude-code-api-key-leak/450_1000.png"></p></div>
</div>
<p>Guan asegura que el patrón permitió filtrar claves de API, tokens de GitHub y otros secretos expuestos en el entorno donde corría el agente, es decir, justo las credenciales que luego pueden abrir la puerta a acciones bastante más delicadas. ¿A quién afecta esto? Sobre todo a repositorios que ejecutan agentes en <strong>GitHub Actions</strong> sobre contenido enviado por colaboradores no fiables y, además, les dan acceso a secretos o herramientas potentes. El propio investigador matiza que el riesgo depende mucho de la configuración: por defecto GitHub no expone secretos a las <em>pull requests</em> desde <em>forks</em>, pero sí existen despliegues que abren esa puerta.</p>
<p><!-- BREAK 5 --></p>
<p>Y aquí aparece otra capa del asunto, menos técnica pero igual de importante. <a rel="noopener, noreferrer" href="https://www.theregister.com/2026/04/15/claude_gemini_copilot_agents_hijacked/">Según publicó The Register</a>, Anthropic, Google y GitHub acabaron pagando recompensas por los hallazgos, pero ninguna de las tres había publicado avisos públicos ni asignado <a rel="noopener, noreferrer" href="https://www.redhat.com/en/topics/security/what-is-cve">CVE</a> en el momento de esa información. Guan fue bastante claro al respecto: dijo saber “con certeza” que algunos usuarios seguían anclados a versiones vulnerables y advirtió de que, sin una comunicación visible, muchos podían no enterarse nunca de que estaban expuestos o incluso siendo atacados. Así que aunque hubo mitigaciones y cambios en documentación o en el tratamiento interno de los reportes, no existó un aviso público equivalente para todos los posibles afectados.</p>
<ul>
<li>Anthropic resolvió el caso el 25 de noviembre de 2025 y pagó 100 dólares</li>
<li>Google recompensó el hallazgo el 20 de enero de 2026 con 1.337 dólares</li>
<li>GitHub cerró el caso el 9 de marzo de 2026 con un pago de 500 dólares</li>
</ul>
<p>Lo que vuelve este caso especialmente delicado es que GitHub no parece el final del camino, sino más bien el primer escaparate visible. Guan sostiene que el mismo patrón probablemente puede reproducirse en otros agentes que trabajan con herramientas y secretos dentro de flujos automáticos, y ahí menciona <strong>desde bots conectados a Slack hasta agentes de Jira</strong>, correo o automatización de despliegues. La lógica vuelve a ser la misma: si el sistema tiene que leer contenido externo para hacer su trabajo y, además, cuenta con acceso suficiente para actuar, el terreno queda abonado para que alguien intente torcerlo desde dentro.</p>
<p><!-- BREAK 6 --></p>
<div class="article-asset article-asset-normal article-asset-center">
<div class="desvio-container">
<div class="desvio">
<div class="desvio-figure js-desvio-figure">
 <a href="https://www.xataka.com/seguridad/cada-cuanto-debemos-cambiar-todas-nuestras-contrasenas-tres-expertos-ciberseguridad" class="pivot-outboundlink" data-vars-post-title="Cada cuánto debemos cambiar TODAS nuestras contraseñas según tres expertos en ciberseguridad"><br />
 <img alt="Cada cuánto debemos cambiar TODAS nuestras contraseñas según tres expertos en ciberseguridad" width="375" height="142" src="https://i.blogs.es/c6d2d1/contrasena-portada1/375_142.jpeg"><br />
 </a>
 </div>
<div class="desvio-summary">
<div class="desvio-taxonomy js-desvio-taxonomy">
 <a href="https://www.xataka.com/seguridad/cada-cuanto-debemos-cambiar-todas-nuestras-contrasenas-tres-expertos-ciberseguridad" class="desvio-taxonomy-anchor pivot-outboundlink" data-vars-post-title="Cada cuánto debemos cambiar TODAS nuestras contraseñas según tres expertos en ciberseguridad">En Xataka</a>
 </div>
<p> <a href="https://www.xataka.com/seguridad/cada-cuanto-debemos-cambiar-todas-nuestras-contrasenas-tres-expertos-ciberseguridad" class="desvio-title js-desvio-title pivot-outboundlink" data-vars-post-title="Cada cuánto debemos cambiar TODAS nuestras contraseñas según tres expertos en ciberseguridad">Cada cuánto debemos cambiar TODAS nuestras contraseñas según tres expertos en ciberseguridad</a>
 </div>
</p></div>
</p></div>
</div>
<p>La conclusión a la que llega Guan no pasa por vender una solución mágica, sino por volver a una idea bastante clásica en seguridad: dar a cada sistema solo lo imprescindible para hacer su trabajo. Si un agente revisa código, no debería tener acceso a herramientas o secretos que no necesita; si se limita a resumir incidencias, tampoco tendría sentido que pudiera escribir en GitHub o tocar credenciales sensibles. Por eso insiste en pensar estos despliegues con lógica de mínimo privilegio y listas de permisos muy cerradas.</p>
<p><!-- BREAK 7 --></p>
<p>Imágenes | DC Studio | Aonan Guan</p>
<p>En Xataka | <a class="text-outboundlink" href="https://www.xataka.com/robotica-e-ia/eeuu-ha-nombrado-tenientes-coroneles-a-directivos-meta-palantir-openai-tenemos-muchas-preguntas" data-vars-post-title="La IA es crucial para el ejército de EEUU. Así que está nombrando tenientes generales a líderes de OpenAI y Palantir" data-vars-post-url="https://www.xataka.com/robotica-e-ia/eeuu-ha-nombrado-tenientes-coroneles-a-directivos-meta-palantir-openai-tenemos-muchas-preguntas">La IA es crucial para el ejército de EEUU. Así que está nombrando tenientes generales a líderes de OpenAI y Palantir</a></p>
<p> &#8211; <br /> La noticia<br />
 <a href="https://www.xataka.com/seguridad/han-secuestrado-agentes-anthropic-google-microsoft-bien-ciencia-tres-empresas-acabaron-pagando?utm_source=feedburner&;utm_medium=feed&;utm_campaign=17_Apr_2026"><br />
 <em> Han secuestrado agentes de Anthropic, Google y Microsoft por el bien de la ciencia. Las tres empresas acabaron pagando </em><br />
 </a><br />
 fue publicada originalmente en<br />
 <a href="https://www.xataka.com/?utm_source=feedburner&;utm_medium=feed&;utm_campaign=17_Apr_2026"><br />
 <strong> Xataka </strong><br />
 </a><br />
 por <a href="https://www.xataka.com/autor/javier-marquez?utm_source=feedburner&;utm_medium=feed&;utm_campaign=17_Apr_2026"><br />
 Javier Marquez<br />
 </a><br />
 . </p>
<p> En algunos equipos de desarrollo ya se está volviendo habitual apoyarse en agentes de inteligencia artificial para revisar incidencias, analizar cambios en el código y moverse por tareas que antes quedaban en manos humanas. El problema aparece cuando esos sistemas no solo leen información que puede venir de fuera, sino que además operan en espacios donde conviven claves, tokens y permisos sensibles. Eso es lo que pone sobre la mesa una investigación reciente: no estamos simplemente ante una herramienta útil que puede equivocarse, sino ante una arquitectura que también puede volverse peligrosa si se despliega sin límites muy claros.<br />
La alarma la ha encendido Aonan Guan y los investigadores de Johns Hopkins Zhengyu Liu y Gavin Zhong tras demostrar ataques contra tres agentes desplegados en la mencionada plataforma: Claude Code Security Review, de Anthropic, Gemini CLI Action, de Google, y GitHub Copilot Agent, una herramienta de GitHub bajo Microsoft. Según su documentación, los fallos fueron comunicados de forma coordinada y acabaron en recompensas económicas pagadas por las compañías, pero lo relevante es que apuntan a un problema más amplio.<br />
Así lograron torcer a los agentes desde dentro<br />
El nombre que Guan le pone al hallazgo ayuda bastante a entender de qué va todo esto: “Comment and Control”. La idea es sencilla de explicar, aunque el fondo no lo sea tanto. En vez de montar una infraestructura externa para dirigir el ataque, el propio GitHub hace de canal de entrada y de salida: el atacante deja la instrucción en un título, una incidencia o un comentario, el agente la procesa como si formara parte del trabajo normal y el resultado termina reapareciendo dentro de ese mismo entorno. Todo queda en casa, y precisamente ahí está la clave del problema.</p>
<p>Y ese “todo queda en casa” no es un detalle menor, sino la base de lo que describe la investigación. Los tres agentes comparten una lógica muy parecida: leen contenido normal de GitHub, lo incorporan como contexto de trabajo y, a partir de ahí, ejecutan acciones dentro de flujos automatizados. El choque aparece porque ese mismo espacio no solo contiene texto enviado por terceros, sino también herramientas, permisos y secretos que el agente necesita para operar.<br />
El primer caso que detalla Guan afecta a Claude Code Security Review, una acción de GitHub de Anthropic pensada para revisar cambios de código y buscar posibles fallos de seguridad. Hasta aquí, todo entra dentro de lo esperable. El problema, según explica el investigador, es que bastaba con introducir instrucciones maliciosas en el título de una pull request, que es la solicitud que alguien envía para proponer cambios en un proyecto, para que el agente ejecutara comandos y devolviera el resultado como si formara parte de su revisión. Después, el equipo logró ir un paso más allá y demostrar que también podía extraer credenciales del entorno.<br />
Lo interesante es que el mismo esquema también apareció en los otros dos servicios, aunque con matices. En Google, Gemini CLI Action podía ser empujado a revelar la GEMINI_API_KEY a partir de instrucciones coladas en una incidencia y en sus comentarios; en GitHub Copilot Agent, la variante era todavía más preocupante, porque el ataque se escondía en un comentario HTML que una persona no veía en pantalla, pero el agente sí procesaba cuando otra persona lo asignaba al caso. En ambos escenarios, el fondo volvía a ser el mismo: contenido aparentemente normal que acababa torciendo el comportamiento del sistema hasta exponer credenciales o información sensible dentro del propio GitHub.</p>
<p>Guan asegura que el patrón permitió filtrar claves de API, tokens de GitHub y otros secretos expuestos en el entorno donde corría el agente, es decir, justo las credenciales que luego pueden abrir la puerta a acciones bastante más delicadas. ¿A quién afecta esto? Sobre todo a repositorios que ejecutan agentes en GitHub Actions sobre contenido enviado por colaboradores no fiables y, además, les dan acceso a secretos o herramientas potentes. El propio investigador matiza que el riesgo depende mucho de la configuración: por defecto GitHub no expone secretos a las pull requests desde forks, pero sí existen despliegues que abren esa puerta.<br />
Y aquí aparece otra capa del asunto, menos técnica pero igual de importante. Según publicó The Register, Anthropic, Google y GitHub acabaron pagando recompensas por los hallazgos, pero ninguna de las tres había publicado avisos públicos ni asignado CVE en el momento de esa información. Guan fue bastante claro al respecto: dijo saber “con certeza” que algunos usuarios seguían anclados a versiones vulnerables y advirtió de que, sin una comunicación visible, muchos podían no enterarse nunca de que estaban expuestos o incluso siendo atacados. Así que aunque hubo mitigaciones y cambios en documentación o en el tratamiento interno de los reportes, no existó un aviso público equivalente para todos los posibles afectados.<br />
Anthropic resolvió el caso el 25 de noviembre de 2025 y pagó 100 dólaresGoogle recompensó el hallazgo el 20 de enero de 2026 con 1.337 dólaresGitHub cerró el caso el 9 de marzo de 2026 con un pago de 500 dólares<br />
Lo que vuelve este caso especialmente delicado es que GitHub no parece el final del camino, sino más bien el primer escaparate visible. Guan sostiene que el mismo patrón probablemente puede reproducirse en otros agentes que trabajan con herramientas y secretos dentro de flujos automáticos, y ahí menciona desde bots conectados a Slack hasta agentes de Jira, correo o automatización de despliegues. La lógica vuelve a ser la misma: si el sistema tiene que leer contenido externo para hacer su trabajo y, además, cuenta con acceso suficiente para actuar, el terreno queda abonado para que alguien intente torcerlo desde dentro.</p>
<p> En Xataka</p>
<p> Cada cuánto debemos cambiar TODAS nuestras contraseñas según tres expertos en ciberseguridad</p>
<p>La conclusión a la que llega Guan no pasa por vender una solución mágica, sino por volver a una idea bastante clásica en seguridad: dar a cada sistema solo lo imprescindible para hacer su trabajo. Si un agente revisa código, no debería tener acceso a herramientas o secretos que no necesita; si se limita a resumir incidencias, tampoco tendría sentido que pudiera escribir en GitHub o tocar credenciales sensibles. Por eso insiste en pensar estos despliegues con lógica de mínimo privilegio y listas de permisos muy cerradas.<br />
Imágenes | DC Studio | Aonan Guan<br />
En Xataka | La IA es crucial para el ejército de EEUU. Así que está nombrando tenientes generales a líderes de OpenAI y Palantir</p>
<p> &#8211; La noticia</p>
<p> Han secuestrado agentes de Anthropic, Google y Microsoft por el bien de la ciencia. Las tres empresas acabaron pagando </p>
<p> fue publicada originalmente en</p>
<p> Xataka </p>
<p> por<br />
 Javier Marquez</p>
<p> . </p>