Friendly Fire y GhostApproval: así secuestran tu agente de código IA

Friendly Fire y GhostApproval son los nombres que usamos en Blurtek para dos patrones de ataque reales contra agentes de código IA (Claude Code, Cursor, Copilot): inyección de instrucciones ocultas en ficheros de reglas, comentarios de PR o issues que el agente lee como contexto de confianza, logrando que apruebe, mergee o ejecute código malicioso sin que el revisor humano lo detecte.

Ni Friendly Fire ni GhostApproval son CVEs oficiales ni firmas de un fabricante concreto: son la forma en que en Blurtek describimos un patrón de ataque que ya tiene base técnica documentada por investigadores de seguridad en 2025, cuando Pillar Security publicó el llamado 'Rules File Backdoor', una técnica que aprovecha ficheros de configuración como .cursorrules o los prompts de sistema de Copilot para inyectar instrucciones invisibles al ojo humano. La idea central no es nueva: es prompt injection indirecta, la misma familia de ataque que ya afecta a asistentes de IA que leen documentos, correos o páginas web no confiables. Lo que cambia con los agentes de código es el nivel de permisos: un asistente de chat que se deja engañar responde mal; un agente de código que se deja engañar puede escribir, commitear, abrir PRs y, en configuraciones agresivas, mergear directamente sobre el repositorio de producción. Esa diferencia de alcance del daño es la que justifica tratar esto como un problema de seguridad de la cadena de desarrollo, no como una curiosidad de investigación. Cuanta más autonomía das al agente sobre tu repositorio, más se parece este vector a un problema de control de acceso mal diseñado que a un bug puntual.

Friendly Fire: el agente se vuelve el vector

Llamamos Friendly Fire al patrón en el que el propio agente de código, actuando con las credenciales y permisos legítimos del desarrollador o de un bot de CI, se convierte en el vector de ataque contra el mismo repositorio que se supone protege. El payload no llega desde fuera del pipeline: llega desde dentro, escondido en un fichero de reglas, en un README que el agente indexa como contexto, o en un commit anterior que nadie relacionó con un problema de seguridad. Cuando el agente procesa ese contexto como instrucción de sistema en lugar de como dato no confiable, ejecuta exactamente lo que le pide el atacante, con la misma autoridad que tendría una orden legítima de un CTO o de cualquier desarrollador senior del equipo. El resultado es que el propio agente termina disparando contra su bando: abre PRs con dependencias maliciosas, modifica pipelines de CI, o inserta puertas traseras en código que después otro desarrollador revisa confiando en que 'ya lo revisó la IA'. Es fuego amigo porque el arma y la autorización eran legítimas; solo la orden estaba envenenada.

GhostApproval: la aprobación que nadie dio

GhostApproval describe el segundo momento del mismo ataque: cuando el agente, tras ser manipulado, emite una aprobación o un resumen de revisión que nunca debería haber existido. En equipos que han configurado sus agentes en modo de auto-aceptación o con revisión asistida por IA como filtro previo al humano, esa aprobación queda registrada como si fuera una revisión real, con el mismo peso que si un ingeniero senior hubiera dado el visto bueno. El problema no es solo que el agente se equivoque, es que deja rastro de una autoridad que nunca ejerció criterio real: el historial de git muestra una aprobación, pero detrás no hubo comprensión, hubo obediencia a una instrucción oculta. En una PYME donde el equipo de desarrollo es pequeño y la presión por entregar rápido empuja a confiar ciegamente en el visto bueno del asistente, esa aprobación fantasma puede ser la única barrera que existía antes de producción.

La pieza que casi ningún artículo sobre este tema explica es que el diff que ve un humano y el contexto que procesa el agente no son necesariamente la misma superficie de datos. GitHub, VS Code y la mayoría de terminales normalizan o colapsan ciertos caracteres de control al renderizar texto, mientras que el modelo de lenguaje que interpreta ese mismo fichero lo recibe carácter por carácter, sin ese filtro visual. Esto significa que un revisor puede dar el visto bueno a un PR que, a nivel de bytes, contiene instrucciones que el agente sí ejecuta y el humano jamás llegó a ver. No hace falta una vulnerabilidad de software clásica para que esto ocurra: basta con que el flujo de trabajo confíe en que 'si el humano lo aprobó, está limpio' cuando en realidad el humano y el agente aprobaron cosas distintas. Este desajuste entre lo que se muestra y lo que se procesa es, en la práctica, el verdadero fallo de diseño detrás de Friendly Fire y GhostApproval, más que cualquier bug puntual de una herramienta concreta.

• Ficheros de reglas del agente: .cursorrules, .github/copilot-instructions.md, CLAUDE.md y equivalentes, tratados como contexto de máxima confianza
• Comentarios y descripciones de Pull Request, especialmente los que provienen de colaboradores externos o forks
• Contenido de issues y su histórico, cuando el agente los usa como contexto para generar o revisar código
• Mensajes de commit anteriores en el historial, si el agente resume o razona sobre el log de git
• Documentación de dependencias de terceros (README, docstrings) que el agente lee al analizar o actualizar el proyecto

La tentación de activar el modo de auto-aprobación en un agente de código no es un error de novato: es una decisión racional cuando el objetivo es entregar rápido y el equipo es pequeño. El problema es que esa misma configuración es la que convierte a Friendly Fire y GhostApproval en un riesgo real en lugar de una curiosidad académica, porque elimina exactamente el punto de fricción humana que detectaría la manipulación. Cuantos más pasos del ciclo de revisión delegas al agente sin punto de control humano, mayor es la superficie donde una instrucción envenenada puede convertirse en una acción real sobre el repositorio. No se trata de prohibir la autonomía de los agentes de código, que es precisamente lo que los hace útiles, sino de decidir de forma consciente qué acciones pueden ejecutar sin supervisión y cuáles no, en función del alcance real de cada una.

En la mayoría de auditorías que hacemos en Blurtek, el problema no es que falte una herramienta de seguridad: es que nadie se sentó a decidir qué puede hacer el agente sin pedir permiso y qué no. Esa conversación de veinte minutos evita más incidentes que cualquier escáner.

• Audita los ficheros de reglas de tus agentes (.cursorrules, CLAUDE.md, copilot-instructions.md) igual que auditarías código de producción, incluyendo revisión de caracteres no imprimibles
• Desactiva el auto-merge y el auto-commit de agentes sobre ramas protegidas; exige un punto de control humano antes de cualquier acción irreversible
• Trata cualquier PR de un colaborador externo o fork como contenido no confiable para el agente, no solo para el humano
• Revisa el historial de aprobaciones automáticas: si un bot o agente aparece como aprobador, verifica qué política de permisos tenía activada
• Limita qué herramientas puede invocar el agente durante una revisión: ejecución de comandos, acceso a secretos, permisos de red
• Forma al equipo en que 'lo revisó la IA' no es sinónimo de 'está revisado': sigue siendo responsabilidad del humano que aprueba

Hay que ser honestos: si tu equipo usa agentes de código solo para autocompletado o sugerencias puntuales, sin permisos de commit, merge o ejecución autónoma sobre el repositorio, este vector de ataque no es tu prioridad de seguridad hoy. La mayoría de incidentes documentados hasta ahora son pruebas de concepto de investigadores, no explotación masiva en producción contra PYMEs españolas, y no tiene sentido que una empresa de veinte personas monte un programa de threat modeling específico para esto antes de tener controles básicos como revisión de dependencias, gestión de secretos o segmentación de accesos. Lo que sí recomendamos es que, si ya has dado a un agente permisos de escritura o merge sobre tu repositorio, la revisión de esta superficie entre en la misma conversación que ya deberías tener sobre gestión de secretos y control de acceso, no como un proyecto aparte.