Le pidió a su agente que corrigiera los errores. Uno de ellos lo había escrito un atacante.

Un desarrollador abre su agente de programación con IA y escribe la petición más corriente del mundo: «eche un vistazo a los errores de Sentry sin resolver y corríjalos». El agente obtiene la lista de errores a través de su conector de Sentry, lee la incidencia principal, sigue los pasos de remediación escritos ahí mismo en el informe y los ejecuta. Medio minuto después ha ejecutado código de un atacante en la máquina del desarrollador, con todos sus privilegios, y nadie ha hecho nada mal.

Eso es Agentjacking, divulgado este mes por Tenet Security, y funcionó en el 85 % de los casos contra los tres agentes de programación más populares del mercado: Claude Code, Cursor y Codex [1][2].

Qué ocurrió realmente

Ante todo, qué es Sentry: uno de los servicios de monitorización de errores más extendidos del mundo del software. Cuando su aplicación lanza un error o se cae, Sentry lo captura y archiva el informe que priorizan sus desarrolladores; está presente en una enorme proporción de las aplicaciones que usa a diario. Para enviarle esos informes, toda aplicación incorpora un DSN: una clave de lado cliente que se incluye deliberadamente en el código fuente de su sitio web, para que el navegador pueda comunicar los errores. Cualquiera puede leerla. Y cualquiera que la tenga puede enviar mediante POST un evento de error a su proyecto de Sentry.

Ahí está toda la clave del ataque. Tenet elaboró un evento de error falso cuyo campo de mensaje estaba formateado para parecerse exactamente a las propias recomendaciones de remediación de Sentry: markdown ordenado, una «corrección recomendada», un comando que ejecutar. Lo enviaron con el DSN público. Después esperaron a lo más natural que hace un desarrollador: pedir al agente que vacíe la cola de errores.

El agente consulta Sentry a través de su conector MCP. El conector le devuelve el error como salida de sistema de confianza. El agente no puede distinguir un informe real de Sentry de uno falsificado; son idénticos byte a byte. Así que hace lo que le dicen y ejecuta la «corrección», normalmente una llamada a npx hacia un paquete del atacante. A partir de ahí tiene todo lo que tiene el desarrollador: variables de entorno, credenciales de Git, URL de repositorios privados, las claves de la nube de ~/.aws/.

Tenet encontró 2.388 organizaciones con DSN inyectables, desde desarrolladores independientes hasta empresas de la Fortune 100. En sus pruebas controladas, los agentes llegaron a ejecutar las instrucciones inyectadas en empresas reales: entre ellas, según Tenet, una empresa tecnológica de la Fortune 100 valorada en 250.000 millones de dólares cuyo agente de IA leyó el informe de error falso y ejecutó el código de Tenet en dos de sus máquinas corporativas [1][3]. Notificado a Sentry el 3 de junio, la empresa lo reconoció ese mismo día y se negó a corregirlo de raíz, calificando el problema de «técnicamente indefendible». Publicó un filtro de contenido que bloquea una cadena de carga concreta [4].

Esto no es negligencia por parte de Sentry

Aquí viene la parte incómoda: nada de esa cadena era un error de software. El DSN debe ser público. El servidor MCP debe devolverle sus datos de errores. El agente debe actuar sobre los diagnósticos que usted le pidió corregir. Cada paso estaba autorizado, y por eso mismo ningún cortafuegos, ningún EDR y ninguna instrucción de sistema lo detectó.

La falla es estructural, y no es exclusiva de Sentry. Cualquier herramienta que alimente a un agente con texto que un tercero pueda influir —un rastreador de errores, una cola de incidencias, una página web indexada, un documento compartido— es un canal de inyección, y el agente trata todo ello como un único flujo indiferenciado de instrucciones. La inyección de indicaciones, dos años después del inicio de la era de los agentes, sigue sin resolverse: no es posible impedir de forma fiable que un texto hostil entre en el razonamiento de un modelo. Dé por hecho que no lo impedirá.

La inyección no es la catástrofe

Esta es la parte en la que conviene detenerse. La razón por la que Agentjacking es una alerta máxima no es que el agente haya sido engañado, sino a qué podía llegar el agente engañado. Se ejecutó con el acceso permanente completo del desarrollador: cada clave del entorno, cada fichero de credenciales en disco, todo el almacén de claves a un solo comando de distancia.

Ese radio de alcance no es una ley de la naturaleza: es una configuración. El agente tenía acceso permanente a todo ello porque así se almacenan hoy las credenciales: ambientales, en la máquina, legibles por cualquier cosa que se ejecute allí. Retire eso, y el mismo secuestro se estrella contra un muro.

Diseñado para esto, de forma deliberada

Una credencial de Clavitor nunca permanece en el entorno donde se ejecuta el agente. No hay ningún ~/.aws/credentials que leer ni ninguna clave de API en una variable de entorno que exfiltrar, porque el valor secreto nunca aterriza donde se ejecuta el código: el agente obtiene el resultado de usar una credencial, no la credencial en sí. Solo puede alcanzar aquello para lo que fue nombrada, de modo que no puede enumerar el almacén para averiguar qué más hay en él. Y la concesión está acotada y es revocable, por lo que una sesión que empiece a comportarse como un atacante puede cortarse en plena acción.

Este es el límite honesto: esto no detiene la inyección, ni impide que un agente secuestrado ejecute un comando. La inyección de indicaciones sigue sin resolverse y no pretendemos resolverla. Lo que cambia es la recompensa. El código del atacante se sigue ejecutando, y se encuentra un entorno sin nada permanente que merezca la pena robar. El secuestro tiene éxito y el robo fracasa.

Hemos anotado las reglas que un sistema de credenciales debe cumplir una vez que el propio agente puede volverse contra usted, empezando por que el secreto nunca viva donde se ejecuta el código y por que un agente solo alcance aquello para lo que fue nombrado. Someta las suyas a estas reglas: clavitor.ai/rules.

La lección no es «parchear Sentry»

Sentry no puede corregir esto, y así lo ha dicho. Y la próxima herramienta envenenada no será Sentry. Mientras sus agentes porten credenciales ambientales y permanentes, cada herramienta de confianza que lean es un arma cargada, y la inyección de indicaciones es el gatillo que no puede bloquear.

No va a conseguir que el texto malicioso no entre. Así que deje de mantener las credenciales al alcance del agente que lo lee.

Clavitor (@clavitorai) es la bóveda de credenciales construida para agentes de IA, y contra ellos. clavitor.ai

Fuentes

[1] Tenet Security — "Agentjacking: hijacking coding agents with fake Sentry errors" (85 % de éxito; 2.388 organizaciones; mecanismo): https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

[2] The Hacker News — "Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code": https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

[3] The New Stack — "A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex": https://thenewstack.io/agentjacking-sentry-mcp-attack/

[4] Infosecurity Magazine — "New 'Agentjacking' Attacks Could Hijack AI Coding Agents" (la respuesta de Sentry): https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/