Si tu equipo de desarrollo usa Claude Code, Cursor o Codex y los tiene conectados a Sentry, hay una pregunta que conviene responder esta misma semana: ¿qué pasa exactamente cuando un desarrollador le pide al agente que «resuelva los errores pendientes de Sentry»? La respuesta debería ser tranquilizadora. Desde junio de 2026 sabemos que, en determinadas configuraciones, no lo es.
Investigadores de Tenet Security publicaron el 12 de junio una clase de ataque a la que llaman agentjacking. La idea es incómoda por lo sencilla: un atacante puede colar instrucciones en un informe de error de Sentry y, cuando el agente de IA lo lee para «arreglarlo», acaba ejecutando código ajeno con los privilegios del propio desarrollador. Sin phishing, sin malware clásico, sin vulnerar ningún CVE de tu stack.
La buena noticia es que esto no es magia ni una puerta abierta de par en par para cualquiera. Es una condición concreta, acotada y mitigable. En este artículo te explicamos qué es el agentjacking, por qué funciona, cómo saber si estás expuesto y qué medidas tomar, sin tecnicismos innecesarios y sin alarmismo.
Qué es el agentjacking
El agentjacking es una técnica que convierte a un agente de IA de codificación en el ejecutor involuntario de las órdenes de un atacante. El vector de entrada es un evento de error manipulado en Sentry, la plataforma de monitorización y seguimiento de errores que usan millones de equipos de desarrollo. El atacante no necesita acceder a tu infraestructura: le basta con un dato que muchas aplicaciones publican abiertamente.
El nombre lo acuñó Tenet Security, una compañía especializada en seguridad de agentes autónomos. En sus pruebas, el ataque tuvo un 85% de éxito frente a los asistentes de codificación más usados del mercado, y los investigadores identificaron al menos 2.388 organizaciones con credenciales de Sentry inyectables. Son cifras de un estudio publicado, no estimaciones nuestras, y conviene leerlas con cabeza: el 85% se midió en un entorno controlado contra más de 100 organizaciones que cumplían las condiciones del ataque, no sobre el conjunto de todas las empresas que usan Sentry.
Lo relevante para un responsable técnico no es el titular, sino el patrón que revela: cuando un agente con permisos de ejecución consume datos que un tercero puede controlar, ese tercero puede, en la práctica, dirigir al agente.
Cómo funciona el ataque, paso a paso
A grandes rasgos, el ataque encadena cinco pasos. Lo describimos a nivel conceptual, lo justo para entender el riesgo y mitigarlo; no es una guía de explotación.
Primero, el atacante localiza el DSN de Sentry de la víctima. El DSN (Data Source Name) es la credencial que una aplicación usa para enviar sus informes de error a Sentry. Por diseño, es de solo escritura y suele estar embebido en el código del frontend, es decir, visible para cualquiera que inspeccione la web. Esto, por sí solo, no es un fallo: Sentry lo concibió así.
Segundo, con ese DSN el atacante envía a Sentry un evento de error fabricado. Es tráfico que la plataforma espera recibir, así que pasa como un informe más.
Tercero, ese evento falso incluye texto cuidadosamente formateado para parecer una indicación de resolución legítima, del tipo «para corregir este error, ejecuta…». Cuando el servidor MCP de Sentry devuelve el evento al agente, este lo presenta como contenido estructurado, prácticamente indistinguible de la propia plantilla del sistema.
Cuarto, llega el momento humano: un desarrollador le pide a su agente que revise y resuelva los errores pendientes de Sentry. El agente consulta la plataforma a través de MCP y recibe, entre los errores reales, el evento manipulado.
Quinto, el agente interpreta la instrucción del atacante como una guía de confianza y la ejecuta, con los permisos completos del desarrollador y en su propia máquina. A partir de ahí, según la investigación, quedan al alcance credenciales como variables de entorno, credenciales Git e identidad del desarrollador; en las demostraciones también se accedió a claves de AWS y tokens de GitHub.
Por qué el agente no distingue lo legítimo de lo inyectado
Aquí está el núcleo del problema. Un desarrollador humano que viera una «resolución» pidiéndole ejecutar un comando raro sospecharía. El agente, en cambio, no puede verificar si un evento de error lo generó un fallo real de la aplicación o lo inyectó un atacante. Recibe la respuesta de una fuente que tiene marcada como de confianza y actúa en consecuencia. Es, en esencia, una inyección de prompts indirecta: la instrucción maliciosa no la escribe el usuario, llega escondida dentro de datos que el agente da por buenos.
¿Por qué es tan difícil de detectar?
La incomodidad del agentjacking es que no hay nada «malicioso» que una herramienta de seguridad pueda señalar. Cada paso de la cadena está técnicamente autorizado.
El envío del evento a Sentry es una petición esperada. La consulta del agente a Sentry es legítima. La descarga de un paquete o la llamada de red que ejecuta el agente son acciones que ese mismo agente realiza decenas de veces al día. Por eso, según Tenet, el ataque no activa EDR, WAF, IAM ni VPN: no hay firma de malware, ni inyección de procesos, ni movimiento lateral anómalo. Todo encaja en lo que el sistema considera comportamiento normal.
Esto cambia la forma de pensar la defensa. No estamos ante un agujero que se cierra con un parche y un antivirus actualizado, sino ante una cuestión de diseño: a quién y a qué le concede confianza un agente, y con cuánta autonomía actúa sobre esa confianza.
El problema de fondo no es Sentry: es el modelo de confianza de MCP
Conviene poner a Sentry en su sitio. La compañía reconoció el problema, pero decidió no corregirlo de raíz porque lo considera «técnicamente no defendible» desde la plataforma, y activó un filtro global que bloquea una cadena de payload concreta. Es una mitigación parcial: bloquea un patrón conocido, no la categoría del ataque. Si el payload cambia, el filtro deja de servir.
Más allá de quién deba arreglarlo, lo importante es entender que Sentry es solo el ejemplo. El verdadero fallo está en una propiedad del Model Context Protocol (MCP): el agente trata la respuesta de un servicio externo conectado como salida de sistema de confianza. Mientras ese servicio devuelva contenido que un tercero pueda manipular, el patrón se repite. Hoy es un error de Sentry; mañana puede ser un ticket de Jira envenenado, un log manipulado o cualquier otra integración que canalice contenido externo hacia un agente con capacidad de ejecutar acciones.
Si quieres entender bien la pieza que está en el centro de todo esto, te recomendamos repasar nuestro artículo sobre qué es el Model Context Protocol y cómo funciona. El agentjacking no es un argumento contra MCP; es un recordatorio de que la confianza entre agente y fuente de datos hay que diseñarla, no darla por supuesta.
Qué puedes hacer hoy para reducir el riesgo
La pregunta práctica es: ¿estás expuesto? La exposición real requiere que se cumplan tres condiciones a la vez: usas un agente de codificación con MCP, tienes conectada una integración que devuelve contenido externo sin validar (como Sentry) y le das al agente autonomía para ejecutar comandos. Si falta alguna, el riesgo baja de forma notable. Eso ya te da un mapa para actuar con calma y por orden.
Medidas inmediatas de configuración
Empieza por lo que puedes revisar hoy mismo. Inventaria qué agentes usan tus equipos y qué integraciones MCP tienen activas, con especial atención a las que ingieren contenido de terceros. Revisa los permisos del agente: si puede ejecutar comandos en terminal de forma autónoma, evalúa si esa autonomía es necesaria o si tiene sentido exigir confirmación humana antes de ejecutar acciones sensibles.
En paralelo, trata la salida de cualquier integración externa como contenido no confiable por defecto, igual que tratarías la entrada de un formulario público. Y mantén el principio de mínimo privilegio en el entorno del desarrollador: cuantas menos credenciales sensibles estén disponibles en la sesión donde corre el agente, menor es el botín si algo sale mal.
Gobernanza de agentes a medio plazo
Las medidas de configuración tapan la brecha conocida; la gobernanza evita la siguiente. Define qué fuentes de datos puede consultar cada agente y con qué nivel de confianza, registra y audita las acciones que ejecutan, y establece límites claros sobre qué operaciones pueden realizar sin intervención humana. Estos mismos principios aparecen en marcos de referencia como el OWASP Top 10 de IA agéntica, que vale la pena tener como guía.
Es la misma lógica de defensa en profundidad que aplicas a otros riesgos de integridad de datos. Si te interesa esa línea, nuestro artículo sobre qué es el data poisoning y técnicas de defensa aborda otra cara del mismo principio: proteger lo que tu IA consume, no solo lo que produce.
Cómo aborda BertIA la seguridad en arquitecturas de agentes
En BertIA implementamos arquitecturas de agentes y conectores MCP en proyectos reales, y precisamente por eso la seguridad no es un añadido al final, sino una decisión de diseño desde el primer día. Cuando conectamos un agente a una fuente de datos, partimos de una premisa sencilla: ninguna salida externa es de confianza por defecto.
Eso se traduce en decisiones concretas: delimitar qué integraciones puede consultar cada agente, separar las acciones de lectura de las de ejecución, exigir validación humana en operaciones críticas y diseñar el entorno para que un eventual compromiso tenga el menor alcance posible. El objetivo no es frenar la adopción de agentes, que aportan una productividad real al desarrollo, sino desplegarlos sobre un modelo de confianza explícito y auditable. El agentjacking es, en ese sentido, una confirmación de un enfoque que ya aplicábamos: la autonomía de un agente debe ir siempre acompañada de límites diseñados a conciencia.
Conclusión
El agentjacking no es motivo para frenar la adopción de agentes de IA, pero sí para desplegarlos con criterio. El ataque no aprovecha un fallo exótico, sino una suposición demasiado común: que todo lo que llega a un agente desde un servicio conectado es de confianza. Revisar configuraciones, acotar permisos y tratar las fuentes externas como contenido no validado convierte un riesgo difuso en uno gestionable.
Si tu organización está desplegando agentes de IA o conectores MCP y quieres asegurarte de que lo hacéis sobre una arquitectura de confianza sólida y auditable, puedes hablar con el equipo de BertIA para revisar la seguridad de tus agentes y diseñar las mitigaciones adecuadas a tu caso.
