Prompt injection en Claude, Gemini y Copilot: así roban credenciales reales usando GitHub como canal de ataque
Un investigador de seguridad demostró que los agentes de IA de Anthropic, Google y GitHub pueden ser manipulados para filtrar claves de API y tokens reales mediante instrucciones inyectadas en pull requests, issues y comentarios de GitHub. No es un hackeo clásico: el sistema funciona exactamente como fue diseñado.
Un investigador de seguridad ha documentado un patrón de ataque que afecta simultáneamente a los agentes de IA de tres de las empresas más importantes del sector: Anthropic, Google y GitHub/Microsoft. La técnica, denominada "Comment & Control", demuestra que estos agentes pueden ser manipulados para filtrar credenciales reales sin necesidad de explotar ninguna vulnerabilidad técnica en el sentido tradicional.
El sistema no fue hackeado. Funcionó exactamente como fue diseñado. Y eso es precisamente el problema.
El vector "Comment & Control": cómo funciona
El patrón es elegante en su simplicidad y efectivo por la misma razón que hace útiles a los agentes de IA: su capacidad para interpretar lenguaje natural como instrucciones ejecutables.
$ANTHROPIC_API_KEY, $GITHUB_TOKEN), los procesa y los prepara para exfiltración.
En un ataque tradicional, hay una exploit, un payload malicioso y una anomalía detectable. Aquí, el agente lee contenido de GitHub (comportamiento normal), interpreta instrucciones en lenguaje natural (su función principal) y publica resultados en GitHub (exactamente lo que se espera que haga). No hay tráfico anómalo. No hay payload binario. No hay firma de malware. Todo parece actividad legítima del agente porque técnicamente lo es.
Los tres casos documentados: Claude, Gemini y Copilot
El investigador documentó el ataque con pruebas de concepto funcionales contra tres productos distintos, cada uno con sus características específicas de fallo.
El agente procesa el título del pull request como parte del contexto de revisión de seguridad. Al no sanitizar ese input, cualquier instrucción incluida en el título se ejecuta con los permisos del agente.
El modelo fue persuadido mediante una instrucción que declaraba falsamente que revelar la clave de API era parte de un proceso de verificación legítimo. El agente no pudo distinguir la instrucción legítima de la inyectada.
La técnica más avanzada del conjunto: instrucciones maliciosas ocultas en HTML que no se renderiza visualmente pero que el agente procesa. Se creó un nuevo PR con un archivo que contenía las credenciales exfiltradas.
La respuesta de la industria: insuficiente para el riesgo real: Las tres empresas abonaron recompensas de entre 100 y 1.337 dólares por los hallazgos. No se emitieron CVEs claros ni advisories públicos de amplio alcance. Eso significa que la mayoría de equipos que usan estos agentes en sus flujos de trabajo de desarrollo siguen sin conocer el riesgo real al que están expuestos.
Por qué ocurre: arquitectura, no bug
El error conceptual más frecuente al analizar este tipo de incidentes es buscar el bug puntual que hay que parchear. No existe un bug de ese tipo aquí. El problema es arquitectónico: emerge de la combinación de cuatro condiciones que suelen darse juntas en implementaciones de agentes de IA sobre código.
Cuando estas cuatro condiciones se dan simultáneamente, el resultado es predecible: cualquier actor que pueda contribuir contenido a GitHub (incluso en un fork público) puede intentar manipular el comportamiento del agente. El sistema no fue comprometido: fue usado exactamente como fue diseñado, pero con input que sus diseñadores no contemplaron como hostil.
Cómo mitigar si usas agentes en desarrollo
La mitigación no requiere abandonar los agentes de IA en los flujos de trabajo de desarrollo. Requiere separar las condiciones que, combinadas, crean el vector. Estas medidas atacan cada una de las cuatro condiciones raíz.
- Aislar inputs no confiables antes de que lleguen al agente No procesar automáticamente PRs o issues de usuarios externos sin revisión previa. Cualquier contenido que venga de un fork público o de un usuario sin permisos de escritura debe pasar por aprobación humana antes de ser procesado por el agente.
- Aplicar mínimo privilegio en todos los tokens Los tokens que usa el agente deben tener solo los permisos estrictamente necesarios para su tarea. Un agente de revisión de código no necesita permisos de escritura en el repositorio. Un agente de CI no necesita acceso a secretos de producción.
- Separar el proceso de interpretación del acceso a secretos El proceso que interpreta el texto externo nunca debe tener acceso directo a las credenciales de producción. Las credenciales deben inyectarse solo en el momento de la acción específica que las requiere, no estar disponibles en todo el contexto del agente.
- Desactivar triggers automáticos en contenido público Evitar que el agente se active automáticamente ante cualquier PR o issue de usuarios externos. Preferir triggers manuales o restringidos a colaboradores con permisos verificados.
- Monitorizar los outputs del agente activamente Revisar los comentarios que genera el agente, los PRs que crea y los logs de ejecución. Un agente que publica contenido inusual (datos codificados en base64, claves con formato de API) en sus outputs es una señal de compromiso.
Conclusión: Nadie hackeó Claude, Gemini o Copilot en el sentido clásico. Lo que el investigador demostró es algo más importante y más difícil de resolver: un agente de IA con acceso a herramientas reales y contexto abierto es un vector de ataque si el input que procesa no está adecuadamente aislado. Este patrón es repetible en cualquier implementación que combine lenguaje natural, permisos y automatización sobre repositorios públicos. La mayoría de equipos que usan estos agentes hoy lo hacen sin conocer este riesgo. Y la industria, con recompensas de bug bounty de tres dígitos y sin advisories públicos claros, no está haciendo lo suficiente para cambiar eso.
