Agentjacking: errores falsos de Sentry secuestran agentes de código vía MCP
La investigación de Tenet Security (junio de 2026) muestra que un atacante puede inyectar un error falso de Sentry que los agentes de código leen por MCP y ejecutan, exfiltrando secretos con un 85 % de éxito en 2 388 organizaciones expuestas.
¿Qué es esto?
El 9 de junio de 2026, el Threat Labs de Tenet Security publicó una investigación que describe el «agentjacking»: una forma de secuestrar agentes de código de IA plantando un informe de error falso en un servicio en el que el agente confía. La Cloud Security Alliance emitió una nota corroborante el 12 de junio de 2026. El ataque encadena dos decisiones de diseño razonables por separado —la ingesta de eventos abierta y sin autenticación de Sentry y la confianza implícita que un agente de código deposita en la salida de una herramienta expuesta vía Model Context Protocol (MCP)— en un camino que va de «cualquiera en internet» a «código arbitrario en la máquina de un desarrollador». Tenet reporta una tasa de éxito del 85 % contra Claude Code, Cursor y Codex, e identificó al menos 2 388 organizaciones con credenciales inyectables, 71 de ellas en el top un millón de Tranco. Este artículo solo informa de los hallazgos publicados y las defensas; no contiene payloads ni pasos operativos.
Cómo funciona
Sentry es una plataforma de seguimiento de errores muy utilizada. Para recibir informes de fallos de navegadores y aplicaciones móviles, emite un DSN: una credencial pública de solo escritura que Sentry documenta deliberadamente como segura para incrustar en JavaScript del lado del cliente. Por diseño, el punto de ingesta no está autenticado: cualquiera que tenga un DSN puede hacer POST de un evento, que aterriza en la cola de incidencias del proyecto junto a los fallos reales.
El ataque aprovecha esa propiedad. Un atacante descubre un DSN (está en el código fuente de las páginas, en repositorios públicos de GitHub o en índices de escaneo) y luego hace POST de un evento elaborado cuyos campos están formateados en markdown: una falsa sección ## Resolution que, cuando el servidor MCP de Sentry la devuelve, se muestra idéntica a las plantillas de diagnóstico de Sentry. Cuando un desarrollador pide después a su agente «corregir los errores de Sentry sin resolver», el agente consulta Sentry vía MCP, recibe el evento inyectado y no puede distinguir el texto del atacante de un error real de la aplicación. Sigue la instrucción plantada —ejecutando un comando como npx [REDACTED-PACKAGE] --diagnose— con los privilegios del propio desarrollador. El paquete de demostración de Tenet era inofensivo y se identificaba como un escaneo de seguridad; uno real exfiltraría variables de entorno, claves de AWS, tokens de GitHub/GitLab, credenciales de npm y Docker, y tokens de Kubernetes.
El fallo de fondo es el que la inyección indirecta lleva años señalando: un modelo recibe datos e instrucciones en el mismo flujo de tokens y no tiene forma nativa de separarlos. Tenet señala que el payload se ejecutó incluso cuando se instruía explícitamente a los agentes, mediante prompts de sistema y skills, a ignorar datos no confiables; no es algo que se arregle desde el prompt.
Por qué importa
Lo novedoso aquí no es la primitiva de explotación, sino la escala y el punto ciego. El ataque eludió EDR, WAF, IAM, VPN y cortafuegos en las configuraciones probadas, porque cada paso está autorizado: un proceso de confianza (el agente) ejecuta un comando normal de gestor de paquetes con las credenciales del desarrollador. No se deja ningún binario, no se viola ninguna política, no se cruza ningún umbral de anomalía. Tenet lo llama la «Authorized Intent Chain», y los controles clásicos están diseñados para detectar comportamiento no autorizado, del cual aquí no hay ninguno.
El punto más importante es la generalización. Sentry no está especialmente roto: es un ejemplo. Cualquier fuente conectada vía MCP que exponga contenido controlable desde el exterior —gestores de incidencias, colas de soporte, comentarios de revisión de código, agregadores de logs— pertenece a la misma clase de inyección. Auditar los binarios de sus servidores MCP sin examinar los datos que exponen cubre solo parte de la superficie. Unit 42 y Elastic han documentado vectores MCP vecinos (abuso del sampling, invocación encubierta de herramientas, inyección de comandos en buena parte de los servidores probados) a lo largo de 2025-2026; el agentjacking es la confirmación empírica.
Defensas
Exija confirmación humana antes de ejecutar. Desactive los modos autónomos (auto-run) para todo agente conectado a un servidor MCP que exponga contenido externo, de modo que las instalaciones de paquetes y los comandos de shell requieran aprobación explícita. Acompáñelo de concienciación de los desarrolladores, ya que los eventos inyectados están diseñados para explotar la fatiga de confirmación.
Trate los datos MCP como entrada no confiable. Inventaríe a qué servidores MCP se conectan sus agentes y cuáles devuelven datos influenciables desde el exterior. Si la integración MCP de Sentry no es operativamente necesaria, desactívela; si lo es, limite lo que el agente puede hacer con su salida.
Reduzca el radio de exposición de los secretos. Ejecute los agentes en entornos aislados de mínimo privilegio, con acceso restringido a archivos, visibilidad limitada de variables de entorno y salida de red restringida, bloqueando explícitamente los endpoints de metadatos de la nube. Sustituya los tokens de larga duración en los entornos de desarrollo por secretos efímeros y de alcance acotado.
Corte el punto de entrada. Audite la exposición de DSN; rote los DSN encontrados en bundles públicos, repositorios o índices de escaneo; y considere canalizar el reporte del lado del cliente a través de un relay en el servidor para que el DSN nunca aparezca en el código del navegador.
Gobierne y haga red teaming. Aplique a la autorización de servidores MCP el rigor de una revisión de dependencias, y añada escenarios de tool poisoning e inyección entregada vía MCP a su red teaming agéntico, no solo los casos de binario de servidor comprometido.
Estado
Se trata de investigación publicada con enfoque defensivo, no de un CVE de producto. Tenet hizo la divulgación a Sentry el 3 de junio de 2026; Sentry acusó recibo el mismo día pero declinó una corrección de raíz, calificando la clase de «técnicamente indefendible» a nivel de plataforma, y desplegó en su lugar un filtro de contenido contra la cadena de payload específica. El comportamiento se validó contra Claude Code, Cursor y Codex; todas las pruebas usaron solo las API de ingesta públicas de Sentry, los payloads se identificaban como escaneos de Tenet, y los datos capturados se redactaron en origen y se eliminaron. Como el propietario de la plataforma considera inviables las correcciones de raíz, el punto de control práctico es el runtime del agente: el momento en que decide actuar. Fechas de publicación de las fuentes: Tenet Security, 9 de junio de 2026; CSA Labs, 12 de junio de 2026; cobertura de The Hacker News, junio de 2026.
Este artículo cubre investigación de seguridad publicada con enfoque defensivo. Si sus desarrolladores ejecutan agentes de código conectados a integraciones MCP, trate toda fuente de datos influenciable desde el exterior como una posible vía de inyección y exija aprobación humana antes de que el agente ejecute comandos.
Sources
- → https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/
- → https://labs.cloudsecurityalliance.org/research/csa-research-note-agentjacking-mcp-sentry-injection-20260612/
- → https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html
- → https://unit42.paloaltonetworks.com/model-context-protocol-attack-vectors/