El riesgo más incómodo de los agentes autónomos no es que escriban mal código. Eso ya lo saben los equipos. El problema serio aparece cuando un agente lee texto no confiable y lo convierte en una acción local.

Agente de IA detrás de una frontera de confianza

Friendly Fire, publicado por AI Now Institute el 8 de julio, muestra ese punto. Los investigadores Boyan Milanov y Heidy Khlaaf describieron una vía de ejecución de código contra Anthropic Claude Code CLI y OpenAI Codex CLI cuando se usan para revisar la seguridad de una biblioteca de terceros.

No es un ataque masivo contra cualquier usuario. Requiere un agente capaz de ejecutar comandos, una base de código no confiable y un modo autónomo: auto-mode en Claude Code o auto-review en Codex, según AI Now y The Hacker News. En ese flujo, el agente revisa un repositorio, lee textos normales del proyecto y puede decidir ejecutar una orden sin pedir confirmación humana.

Ese detalle importa para la adopción empresarial. Las compañías ya usan agentes en code review, triage de vulnerabilidades, Sentry, generación de parches, limpieza de dependencias y asistencia en CI. Cuanto más útil es el agente, más herramientas recibe: shell, filesystem, package manager, repositorios y a veces secretos.

En ese momento deja de ser un chatbot. Es automatización privilegiada.

Qué muestra Friendly Fire

AI Now describe una copia modificada de la biblioteca Python geopy. Los investigadores añadieron texto en README, un script, un archivo señuelo y un binario precompilado. El repositorio público indica que el binario publicado fue limpiado de código malicioso.

La lección no es el payload. La lección es la frontera rota: el agente puede pasar de “analiza este proyecto” a “ejecuta este comando sugerido por el propio proyecto”.

AI Now cita pruebas con Claude Code CLI 2.1.116, 2.1.196, 2.1.198 y 2.1.199, usando Claude Sonnet 4.6, Sonnet 5 y Opus 4.8, además de OpenAI Codex CLI 0.142.4 con GPT-5.5. Los autores lo presentan como un problema de diseño del workflow, no como una versión concreta que se parchea y desaparece.

Por qué basta un README

Un README está hecho para guiar al lector. Le dice cómo compilar, probar y revisar un proyecto. Un humano puede parar y preguntarse si tiene sentido ejecutar un binario desconocido.

Un agente está diseñado para completar la tarea. Si su política permite aprobar algunos comandos, el texto de un repositorio puede convertirse en una ruta desde datos no confiables hasta ejecución local.

Es la misma familia de fallos que prompt injection en tickets, issues, logs, páginas web o salida de herramientas. El input no parece “código”, pero influye en el siguiente paso del agente.

No es un caso aislado

Friendly Fire llega después de Agentjacking de Tenet Security, donde errores falsos de Sentry llegaban a agentes por MCP. Tenet habló de 2.388 organizaciones expuestas y 85% de éxito en pruebas controladas; son cifras de ese estudio, no una tasa universal.

Sophos X-Ops publicó otra señal: agentes de coding en Windows pueden activar reglas de EDR parecidas a comportamiento de atacante, con PowerShell, acceso a credenciales, descargas estilo LOLBin y acciones similares a persistencia.

Son informes distintos. Pero comparten una pregunta operativa: ¿qué puede hacer el agente cuando la entrada es hostil?

Qué deberían cambiar los equipos

Separar trabajos confiables y no confiables. Limpiar un repo interno no debe tener la misma política que revisar una dependencia descargada.

Desactivar aprobación automática de comandos en repositorios externos, logs, Sentry events e issues no confiables.

Usar identidades separadas para agentes. No deberían heredar todo el acceso de GitHub, cloud y producción de un desarrollador.

Quitar secretos del entorno: variables, SSH keys, cookies del navegador, password managers y credenciales cloud locales. Un sandbox con secretos reales no es una frontera.

Tratar scripts, installs, binarios, browser automation y red como acciones de alto riesgo. En contextos no confiables deben requerir aprobación humana o estar bloqueadas.

Registrar input source, tool calls, comandos aprobados, process tree, destino de red y escrituras de archivos. Sin eso, la investigación termina en “la IA hizo algo”.

Qué deben ofrecer los vendors

Los agentes necesitan fronteras de confianza dentro del producto. El contenido no confiable debería conservar una etiqueta: texto de repo, comentarios, logs, Sentry events, web pages, salida MCP. La política de herramientas debe poder decir: esto puede informar el análisis, pero no autoriza ejecución.

“Autonomous” es demasiado vago. Las empresas necesitan saber si el agente puede ejecutar shell, instalar paquetes, correr binarios, abrir red, leer archivos ocultos, usar MCP o escribir fuera del workspace.

También necesitan controles centrales: managed settings, audit export, allowlists, deny rules y defaults seguros para security review.

Los agentes serán parte normal del desarrollo. Pero normal no significa inofensivo. CI runners y build systems también son normales, y aun así se aíslan. La regla práctica es simple: no preguntes si confías en el agente; define qué puede hacer cuando no confías en la entrada.