Agentjacking: el secuestro de agentes de IA vía Sentry MCP

Le pide a su agente de IA: "corrige los errores de Sentry". Consulta Sentry vía MCP, lee un error falso con una sección "Resolution" que contiene un comando npx, y lo ejecuta con sus privilegios totales de sistema. Sin breach. Sin exploit. Sin acceso no autorizado. Todo legítimo. Todo devastador. Eso es Agentjacking, y según Tenet Security, el 85% de los agentes probados ejecutaron el payload.

Qué es Agentjacking

Agentjacking es una clase de ataque que secuestra agentes de IA de codificación para ejecutar comandos maliciosos con los privilegios totales del desarrollador. El término fue acuñado por Tenet Security, startup que salió del stealth el 17 de junio de 2026 con una ronda seed de US$ 6 millones, fundada por exintegrantes de Cisco AI Defense y alumni de la Unit 8200 (CEO Barak Sternberg, CTO Nevo Poran).

El concepto central es la Cadena de Intenciones Autorizadas: cada paso del ataque es legítimo y autorizado. El agente consulta una herramienta MCP, lee datos, interpreta instrucciones y ejecuta acciones, exactamente lo que fue diseñado para hacer. El problema es que los datos leídos pueden contener instrucciones maliciosas inyectadas por un atacante, y el agente no logra distinguir una instrucción legítima de un payload.

Según la investigación de Tenet Security, se secuestraron 4+ familias de agentes: Claude Code, Cursor, Codex y otros. La tasa de éxito del 85% entre agentes que actuaron sobre errores inyectados muestra que el problema no es puntual, es sistémico.

La cadena de ataque vía Sentry MCP

Según Tenet Security, el ataque contra Sentry sigue 5 etapas:

1. Descubrimiento de la DSN: el atacante encuentra la DSN (Data Source Name) pública de Sentry en el JavaScript del sitio. La DSN es una clave write-only, sin autenticación, cualquier persona puede publicar eventos en ella.

2. Inyección del evento forjado: el atacante hace un POST a ingest.sentry.io con un evento fabricado. El servidor devuelve HTTP 200 y procesa el evento como cualquier error real.

3. Inyección de markdown: el evento forjado contiene markdown que hace que el error parezca idéntico a la plantilla del propio Sentry, incluyendo una sección "Resolution" con un comando npx malicioso.

4. Lectura por el agente: el agente de IA consulta Sentry vía MCP, lee el evento forjado y no logra distinguirlo de una instrucción legítima del propio Sentry.

5. Ejecución con privilegios totales: el agente ejecuta el comando npx con los privilegios totales del desarrollador. Qué se exfiltra: claves AWS, tokens de GitHub, credenciales de Kubernetes, tokens de npm y Docker, secrets de CI/CD, acceso al SSH agent, tokens de autenticación del propio Sentry.

Los números son alarmantes: 2.388 organizaciones con DSN expuestas e inyectables. 71 de ellas en el top-1M del ranking Tranco. Más de 100 organizaciones en el conjunto validado controlado. La superficie de ataque es real y medible.

Por qué nada detecta

Según Tenet Security, cada paso del ataque es autorizado. El EDR no alerta porque no hay ejecución de código no autorizada. El WAF no bloquea porque el POST a Sentry es legítimo. El IAM no detecta porque el agente opera con las credenciales del propio desarrollador. La VPN no ayuda porque el tráfico es normal. Nada es no autorizado, y es exactamente eso lo que vuelve invisible el ataque.

Es una Cadena de Intenciones Autorizadas. Las defensas en la capa de prompt también fallaron: los agentes ejecutaron el payload incluso cuando se les indicó explícitamente ignorar datos no confiables. La confianza semántica entre agente y herramienta está rota, y las herramientas de seguridad tradicionales no operan en esa capa.

Sentry es solo el comienzo

Según Tenet Security, cualquier servicio conectado vía MCP donde terceros aportan contenido tiene la misma vulnerabilidad. La superficie de ataque va mucho más allá de Sentry:

• Issue trackers (Jira, Linear, GitHub Issues): cualquier usuario puede crear issues con markdown que el agente lee e interpreta como instrucciones.
• Sistemas de ticketing: los tickets de soporte al cliente pueden contener instrucciones maliciosas que el agente ejecuta al intentar "resolver" el ticket.
• Plataformas de code review: los comentarios en pull requests pueden contener payloads que el agente ejecuta al intentar "implementar" el feedback.
• Agregación de logs: los logs inyectados pueden contener instrucciones que el agente interpreta como guía de debugging.

El patrón es el mismo: un canal donde datos no confiables fluyen hacia un sistema que el agente de IA consulta vía MCP. El agente no distingue datos de instrucciones, y el atacante explora exactamente esa ambigüedad.

La respuesta de Sentry

Según Tenet Security, Sentry reconoció el problema el 3 de junio. Rechazó una corrección de causa raíz, argumentando que la vulnerabilidad es "indefendible por naturaleza". Añadió un filtro de contenido para un string específico de payload.

El filtro se puede evadir de forma trivial: basta modificar el payload para que no contenga el string bloqueado. Es como bloquear una URL específica de phishing mientras miles de otras permanecen accesibles. La respuesta de Sentry no resuelve el problema de fondo, y no es razonable esperar que lo resolviera solo. La vulnerabilidad está en la arquitectura de confianza entre agente y herramienta, no en Sentry en sí.

Mitigación disponible

Según Tenet Security, la mitigación open source está disponible en github.com/tenet-security/agent-jackstop, configuraciones drop-in para Cursor y Claude Code que bloquean la ejecución automática de comandos originados en datos no confiables.

Pero la protección real requiere un cambio de modelo mental: el perímetro de seguridad se movió hacia la confianza semántica entre agente y herramienta. Eso significa:

• Fronteras de confianza en MCP: los agentes nunca deben ejecutar comandos de shell originados en datos leídos vía MCP sin confirmación explícita del desarrollador.
• Privilegio mínimo: los agentes deben tener acceso solo a las herramientas MCP estrictamente necesarias, con el menor alcance de permisos posible.
• Auditoría de permisos: revisar regularmente a qué herramientas MCP puede acceder cada agente y qué acciones puede ejecutar cada herramienta.

En Tech86, vemos el Agentjacking como el primer ejemplo concreto de una nueva clase de amenazas que crecerá exponencialmente a medida que más servicios se conecten vía MCP. El modelo de seguridad de agentes de IA necesita evolucionar, y rápido. Si su equipo usa agentes de IA para codificar, necesita entender el Agentjacking hoy. Podemos ayudar a evaluar y mitigar esta superficie de ataque.