Si usas Claude Code, Cursor o Codex con Sentry conectado por MCP, lee esto antes de pedirle al agente que «arregle los errores pendientes». Tenet Security ha documentado una clase de ataque llamada Agentjacking que convierte tu asistente de IA en un ejecutor de comandos ajenos. Sin phishing, sin malware clásico, sin explotar un CVE en tu stack. Solo un POST a la API pública de Sentry y un desarrollador que confía en que la herramienta sabe lo que hace.
La cifra que más me ha hecho pensar: en pruebas controladas, consiguieron un 85% de éxito frente a los agentes más usados del mercado. Identificaron 2.388 organizaciones con DSN de Sentry inyectables. Y lo peor: el ataque pasa por delante del EDR, del WAF y de las políticas IAM porque cada paso es legítimo. El agente hace exactamente lo que le pediste.
¿Te suena exagerado? Yo también lo pensé hasta que leí el informe completo. El vector no es un bug de Sentry en el sentido tradicional. Es un fallo de arquitectura en la intersección entre la ingesta abierta de eventos de Sentry y la confianza ciega que los agentes de IA depositan en lo que devuelven las integraciones MCP.
Cómo funciona (y por qué es tan incómodo)
El DSN de Sentry es público por diseño: va en el JavaScript del frontend, en repos de GitHub, en documentación interna filtrada. Cualquiera puede enviar un evento de error con un payload arbitrario. Hasta aquí, eso ya lo sabíamos y asumíamos que lo peor que podía pasar era ensuciar el panel de errores.
Lo que cambia con los agentes de codificación es el paso siguiente. Cuando le dices «revisa los errores sin resolver en Sentry», el agente consulta Sentry vía MCP, recibe el evento inyectado y lo interpreta como instrucciones de remediación legítimas. En el escenario de Tenet, el payload incluía un comando npx que descargaba un paquete de npm controlado por el atacante. El agente lo ejecutaba con los privilegios completos del desarrollador: variables de entorno, credenciales AWS en ~/.aws/config, tokens npm, configuración Docker. Todo.
Infosecurity Magazine lo resume bien: a diferencia de un desarrollador humano, el agente no puede verificar si el error lo generó una aplicación real o un atacante externo. La confianza en las respuestas MCP crea un camino directo desde datos inyectados hasta ejecución de código.
Lo que Sentry ha dicho (y lo que no te cuentan)
Tenet hizo la divulgación responsable el 3 de junio. Sentry reconoció el problema e implementó un filtro de contenido para el string concreto del payload de prueba. Pero, según recogen Cybersecurity News y el propio informe, la empresa calificó la clase de ataque como «técnicamente no defendible» a nivel de plataforma y apuntó a mitigaciones del lado del modelo.
Perdona, pero eso me suena a pasar la patata caliente. Si tu producto alimenta datos no verificados a un agente con acceso a terminal, no puedes lavarte las manos diciendo que el filtro de strings es suficiente. Mañana el atacante cambia el payload y vuelves a empezar. Es la misma lógica de parchear síntomas que llevamos años criticando en WordPress con plugins de seguridad que bloquean firmas conocidas.
Y aquí está mi principal crítica al ecosistema, no solo a Sentry: estamos desplegando agentes con permisos de shell sin haber resuelto la confianza en las fuentes de datos externas. OWASP ya avisaba de que desplegamos agentes más rápido de lo que podemos protegerlos. Agentjacking es la demostración práctica de ese titular.
¿Afecta a tu agencia o a tu pyme?
Sí, si cumples tres condiciones: usas un agente de codificación con MCP, tienes Sentry (u otra integración similar que devuelva contenido externo sin validar) y le das al agente autonomía para ejecutar comandos. En hosting y desarrollo web esto ya no es nicho. Lo veo en equipos de tres personas que montan tiendas WooCommerce con Cursor, en consultoras que automatizan despliegues con Claude Code, en freelancers que conectan todo «para ir más rápido».
Lo incómodo es que las recomendaciones de mitigación son sensatas pero poco sexy: desactiva la integración Sentry-MCP si no la necesitas, exige aprobación humana antes de cualquier npx o instalación de paquetes disparada por datos de herramientas externas, audita sesiones MCP, trata la salida de herramientas como datos no confiables. Nada de «activa el modo seguro y listo».
En mi experiencia, la mayoría de equipos no van a hacer nada hasta que alguien del departamento de seguridad (si existe) lea el informe. Y las pymes directamente no tienen departamento de seguridad. Seguirán conectando Sentry al agente porque acelera el debugging y porque nadie les ha explicado que un DSN público más un agente obediente es una puerta trasera silenciosa.
El elefante en la habitación: MCP como nueva superficie de ataque
Agentjacking no es un problema exclusivo de Sentry. Es un patrón: integración MCP que devuelve contenido controlable por terceros + agente que ejecuta acciones basándose en ese contenido. Mañana puede ser otra herramienta de monitorización, un ticket de Jira envenenado, un log de CloudWatch manipulado. El modelo de confianza es el mismo y el agujero también.
Los medios en inglés lo están tratando como novedad de ciberseguridad, y técnicamente lo es. Pero para quien monta webs y gestiona hosting, el mensaje es más simple: has conectado un becario digital con acceso root a servicios que aceptan input anónimo. No me extraña el 85% de éxito.
Lo irónico es que muchos de los mismos equipos que exigen doble factor en el panel de Plesk le dan a un agente de IA permiso para ejecutar lo que lea en un evento de error. Prioridades al reves, como siempre.
Agentjacking llega la misma semana en que Anthropic apagó Fable 5 por controles de exportación de EE.UU. Dos caras de la misma moneda: por un lado el gobierno estadounidense tira del freno de emergencia porque los modelos son demasiado capaces; por otro, los modelos ya son lo bastante obedientes como para ejecutar malware disfrazado de diagnóstico. El sector quiere velocidad en ambas direcciones y nadie quiere asumir la responsabilidad del medio.
Si tu flujo de trabajo incluye «agente, arregla lo que diga Sentry», no esperes a que Sentry lo solucione solo. Toca revisar permisos, límites de ejecución y, sobre todo, dejar de tratar la salida de MCP como verdad del sistema. Porque un error falso con buena caligrafía técnica vale más que mil intentos de phishing.
Si mañana tu agente de IA te propusiera ejecutar un paquete npm para «corregir» un error de Sentry que tú no recuerdas haber visto en producción, ¿lo dejarías correr sin mirar el comando línea por línea?