Un reporte de bug falso secuestró al agente de código

Aquí tienes un ataque que debería cambiar cómo piensas sobre los agentes. Investigadores de Tenet Security revelaron «Agentjacking» — y The Hacker News lo cubrió este mes. El montaje es casi demasiado simple: un atacante envía un reporte de error falso al Sentry de una empresa (la herramienta de seguimiento de errores), usando solo una clave pública que es fácil de encontrar. El error falso contiene «pasos de resolución». Cuando el agente de código con IA del equipo lee el error para ayudar a arreglarlo, ejecuta esos pasos — que en realidad son los comandos del atacante — en la máquina del desarrollador, con los propios privilegios del desarrollador.

En las pruebas, Claude Code, Cursor y Codex lo hicieron todos. No supieron distinguir un error real de uno plantado. El botín para el atacante: variables de entorno, claves de AWS, tokens de npm, credenciales de git, URLs de repos privados. Tenet encontró 2,388 organizaciones con claves expuestas e inyectables.

Tus guardrails no lo atraparon

La parte aterradora es lo que no lo detuvo. Según la investigación, EDR, WAF, IAM, VPN, Cloudflare — e incluso una instrucción explícita en el system prompt diciéndole al agente que desconfiara de los datos externos — todo falló en bloquearlo. Y Sentry, cuando le pidieron arreglarlo a nivel de plataforma, llamó al problema «técnicamente indefendible».

Decirle al modelo «no confíes en los datos externos» no es un control de seguridad. Es una sugerencia que el modelo es libre de ignorar.

Esa es la verdad incómoda que este ataque expone: no puedes llegar a la seguridad a base de prompt. Si el agente puede leer texto controlado por el atacante y ejecutar comandos, las instrucciones del prompt que hay en medio no son un muro.

La lección real: cada entrada es una superficie de inyección

Es tentador archivar esto bajo «un bug de Sentry». No lo es. El rastreador de errores es solo la puerta. El patrón es general: cualquier cosa que tu agente lee y sobre la que alguien de fuera puede influir es un lugar para inyectar comandos — logs de errores, tickets de soporte, comentarios en issues, páginas web que navega, la salida de otra herramienta, la descripción de un servidor MCP. He escrito sobre esto desde otros ángulos — una página web puede darle órdenes a tu agente — y Agentjacking es la misma lección con una puerta nueva.

Lo que de verdad te protege

Esto no se arregla con un mejor prompt. Se arregla con arquitectura:

• Separa leer de hacer. La parte del agente que ingiere texto no confiable no debería ser la parte que puede ejecutar comandos. Pon una frontera real entre ellas.
• Aísla la ejecución en un sandbox. Corre los comandos del agente en un entorno aislado sin acceso a credenciales reales, claves de nube o los secretos de tu repo. Si lo secuestran, no consigue nada.
• Mínimo privilegio, siempre. El agente solo debería alcanzar lo que la tarea necesita. La mayor parte del botín en este ataque eran credenciales que el agente no necesitaba ver.
• Aprobación humana para cualquier cosa que ejecute o envíe. Leer es barato; ejecutar y exfiltrar es donde pones la puerta.

En resumen

Agentjacking no va realmente sobre Sentry. Es una demostración limpia de que un agente que lee texto no confiable y ejecuta comandos está a un mensaje bien armado de trabajar para el atacante.

Trata cada entrada que tu agente lee como hostil, separa «leer» de «ejecutar», y aísla en sandbox lo que ejecuta — porque no puedes salir de la inyección a base de prompt. La puerta seguirá cambiando. El arreglo es la frontera que pones detrás de ella.