Grego — Ciberseguridad
Durante años aseguramos el pipeline de desarrollo haciéndonos una sola pregunta: ¿quién está autorizado a hacer esto? Firewalls, EDR, IAM, WAF — todo el stack está construido para atrapar lo no autorizado. Una investigación nueva de Threat Labs, el equipo de Tenet Security, publicada el 9 de junio, demuestra una clase de ataque que pasa caminando a través de todo eso, precisamente porque cada paso está autorizado. La llaman agentjacking, y si tu equipo está corriendo Claude Code, Cursor o Codex contra integraciones MCP, vale la pena entender exactamente qué fue lo que probaron.
El mecanismo es casi insultantemente simple. Sentry — la plataforma de error monitoring — ingiere eventos a través de un DSN, una credencial write-only que Sentry documenta deliberadamente como segura para embeber en el JavaScript del frontend. Vive en el código fuente público de incontables sitios en producción, por diseño. Cualquiera que tenga ese DSN puede hacer un POST de un evento de error fabricado al endpoint de ingest de Sentry: sin autenticación más allá del DSN, sin breach, sin exploit en el sentido tradicional. El atacante controla el payload entero — message, tags, context keys, stack traces.
La trampa se dispara en el paso siguiente. Cuando un dev le pide a su agent que “arregle los errores sin resolver de Sentry”, el agent consulta a Sentry a través de su MCP server y recibe el evento inyectado como output confiable del sistema. El payload de Tenet embebe markdown en los campos del error que renderiza como una sección falsa ## Resolution — estructuralmente indistinguible de la propia guía de remediación de Sentry — que contiene un comando npx. El agent lee la instrucción del atacante como consejo de diagnóstico legítimo y la ejecuta, con los privilegios completos del dev, en la propia máquina del dev.
Esa es toda la cadena. Un bug report falso hasta remote code execution, y el dev ve solamente output de diagnóstico inofensivo mientras el agent entrega lo que el entorno exponga: AWS keys, GitHub tokens, credenciales de git, URLs de repos privados.
Qué midió Tenet realmente — y qué no
Acá es importante ser preciso, porque los números impactan y son fáciles de inflar. Esto fue investigación controlada, no una ola de ataques in-the-wild. Usando solo reconocimiento pasivo — indexación de Censys, code search, extracción de CDN loaders — Tenet identificó 2.388 organizaciones con DSNs inyectables válidos, 71 de ellas en el Tranco top-1M, al momento de su reconocimiento de junio. En oleadas de validación controlada registraron 100+ agents actuando sobre errores inyectados a través de Claude Code, Cursor y Codex, una tasa de éxito de explotación del 85% contra los agents más usados del mercado. Las ejecuciones confirmadas abarcaron desde una empresa Fortune 500 hasta devs independientes — y, de manera notable, un vendor de seguridad cloud estuvo entre los expuestos. No se retuvo ningún dato de las sondas; las organizaciones afectadas fueron notificadas.
Así que el encuadre honesto es: una proof-of-concept demostrada a escala, no evidencia de explotación activa. Esa distinción importa. Pero no suaviza demasiado la conclusión, porque la barrera para convertir la PoC en una campaña real es, según el propio relato de Tenet, mínima — las mismas condiciones existen en miles de proyectos, alcanzables con recursos triviales.
Por qué las defensas habituales no ven nada
Esta es la parte que debería retener la atención de un CIO. Tenet la llama la Authorized Intent Chain: cada acción del ataque es algo que el tooling del dev tiene permiso de hacer. El DSN es público por diseño. Postear un evento es normal. Que el agent consulte a Sentry es normal. Ejecutar un comando sugerido es el agent haciendo su trabajo. EDR, WAF, IAM, VPN, firewalls — ninguno se dispara, porque no hay nada no autorizado que atrapar.
Y las defensas a nivel de prompt también fallaron. Tenet reporta que los agents ejecutaron el payload incluso cuando los system prompts y skills les indicaban explícitamente ignorar datos no confiables. La debilidad está en cómo los modelos actuales procesan el output de las MCP tools — no pueden separar de manera confiable los datos que leen de una instrucción para actuar. Como lo dice Tenet, esto no se arregla con un mejor prompt.
Por eso también sería un error archivar esto como “un problema de Sentry”. Tenet es explícito en que no se explotó ninguna vulnerabilidad en Sentry mismo — el punto de entrada es una credencial que Sentry pretende que sea pública. Al ser notificado, Sentry reconoció el problema y desplegó un content filter para el string de payload específico, pero caracterizó la clase subyacente como técnicamente no defendible en la capa de ingest, señalando en cambio una mitigación del lado del modelo. Leída con justicia, esa es una posición defendible: el endpoint de ingest no puede saber si un agent aguas abajo va a tratar su output como una instrucción. Sentry es simplemente el punto de entrada demostrado. El patrón vulnerable — una MCP tool que devuelve datos influidos por terceros a un agent que confía en ellos — es compartido por todo el ecosistema.
La pregunta para tu equipo
El instinto va a ser preguntar “¿parchamos Sentry?”. Esa es la pregunta equivocada. La correcta es: ¿de qué MCP tools leen nuestros agents, y cuáles de ellas devuelven datos que alguien fuera de nuestra organización puede influir? Logs de errores, sistemas de ticketing, dashboards de monitoreo, issue trackers, contenido web scrapeado — cualquiera de ellos puede ser un vector de entrega para la misma clase de inyección. Cada nueva integración MCP ensancha la superficie.
El corolario incómodo es dónde tiene que vivir el control. Si las capas de red e identidad no pueden ver esto, y la capa de prompt no puede detenerlo, entonces el único lugar que queda para hacer cumplir una política es el runtime del agent — el momento en que decide actuar sobre lo que leyó. Esa es una brecha arquitectónica que la mayoría de los equipos que despliegan coding agents todavía no llenó, y los equipos de Iberoamérica que están adoptando estas herramientas a toda velocidad no son la excepción. Agentjacking es la primera prueba ampliamente documentada de que la brecha es explotable. No va a ser la última.
El cambio más profundo es el que vale la pena dejar reposar. Los ataques de supply chain solían requerir comprometer un paquete real o engañar a un humano. Con agents en el loop, un atacante no necesita ninguna de las dos cosas — solo datos en los que el agent confíe. La plataforma de observabilidad se convierte en el canal de comando, y el agent se convierte en el motor de ejecución. Pasamos una década aprendiendo a no confiar en el input del usuario. La próxima lección es que nuestros agents todavía no saben hacerlo.