ADR: detección y respuesta para agentes MCP, probado a escala de Uber

¿Qué es esto?

El 17 de mayo de 2026, un equipo de Uber publicó ADR: An Agentic Detection System for Enterprise Agentic AI Security (arXiv:2605.17380, póster de MLSys 2026). El artículo describe lo que los autores presentan como el primer marco probado en producción, a gran escala, para vigilar agentes de IA que operan mediante el Model Context Protocol (MCP): el montaje hoy habitual en el que un host como Cursor, Cline o Claude Code dialoga con servidores MCP remotos que exponen lectura/escritura de archivos, llamadas a API y acceso a bases de datos.

La motivación es un punto ciego que muchos equipos reconocerán. Las herramientas EDR clásicas ven los resultados —se escribió un archivo, se llamó a una API— pero no los prompts del agente, su razonamiento ni la cadena causal que vincula una instrucción con una acción. Así resulta imposible distinguir una exfiltración maliciosa de un guardado de configuración inocuo. La tesis de ADR: la seguridad de los agentes exige telemetría pensada para agentes y una detección lo bastante económica para escalar. El código y el benchmark están publicados como código abierto en GitHub.

Cómo funciona

ADR consta de tres componentes, cada uno calcado de un rol conocido del SOC:

Componente      Rol (analogía SOC)        Función
--------------  ------------------------  --------------------------------------
ADR Sensor      Visibilidad / agente EDR  Analiza las cachés locales de las
                                          herramientas agénticas (bases SQLite /
                                          JSONL de Cursor, Cline, Claude Code)
                                          para reconstruir la sesión completa:
                                          prompts, razonamiento, llamadas a
                                          herramientas MCP, contexto de ejecución
ADR Detector    Triaje por niveles + analista  Tier 1: triaje LLM económico de
                                          alta sensibilidad («ante la duda, se
                                          escala»); Tier 2: razonamiento profundo
                                          con contexto de empresa + threat intel
ADR Explorer    Red team interno          Motor offline que genera y prueba
                                          variantes de ataque antes del
                                          despliegue, realimentadas al Tier 2

El principio rector es la telemetría causal, no solo los resultados: el Sensor registra por qué ocurrió algo (prompt → razonamiento → ejecución de herramienta), cerrando el punto ciego de observabilidad. El Detector de dos niveles existe porque ejecutar un LLM sobre cada evento al volumen de producción (más de 10.000 sesiones/día) sería prohibitivamente caro: el Tier 1 cortocircuita la actividad claramente benigna y solo escala los eventos sospechosos al Tier 2, más costoso. El Explorer offline descubre de forma continua «casos difíciles» y los registra en un repositorio de threat intelligence, de modo que la detección mejora antes de que los ataques lleguen a producción, no después.

Aquí no se reproduce ningún exploit, y no hace falta para entender la arquitectura; la referencia canónica es el artículo y su repositorio.

Por qué importa

Lo distintivo es que no se trata de un prototipo de laboratorio. ADR lleva más de diez meses en Uber, alcanzando más de 7.200 hosts únicos y procesando más de 10.000 sesiones de agentes al día. En producción sacó a la luz cientos de exposiciones de credenciales en 26 categorías, compartidas fuera de la red corporativa, y alimentó una capa de prevención «shift-left» que reporta una precisión del 97,2 % (206 detectadas sobre 212 credenciales únicas, de cientos de miles de sesiones).

En el benchmark publicado ADR-Bench (302 tareas —42 maliciosas, 260 benignas— en 133 servidores MCP y 17 técnicas de ataque), ADR reporta cero falsos positivos detectando el 67 % de los ataques, superando a tres referencias (ALRPHFS, GuardAgent, LlamaFirewall) por 2–4× en F1. Los autores optimizan deliberadamente la precisión: los métodos de referencia producían hasta 40 falsos positivos sobre 260 tareas benignas, es decir, en una empresa, 40 activaciones costosas e inútiles de respuesta a incidentes. Ese equilibrio —detectar dos tercios de los ataques sin falsas alarmas, en lugar de detectar más ahogando al SOC— es la lección práctica para quien despliegue vigilancia de agentes.

Defensas

ADR es en sí mismo la defensa, así que las conclusiones tratan de cómo instrumentar y evaluar la vigilancia de agentes.

1. Capture la cadena causal, no solo los resultados. Los registros de escritura de archivos y de llamadas a API no distinguen una exfiltración de un guardado de configuración. Reconstruya prompt → razonamiento → llamada a herramienta para que el comportamiento sea interpretable. El Sensor lo logra analizando las cachés locales de la herramienta agéntica.
2. Estratifique la detección para controlar el coste. Ejecutar un LLM de razonamiento sobre cada evento no escala. Triaje primero con un modelo económico de alta sensibilidad y reserve el análisis contextual costoso para los eventos señalados.
3. Haga red teaming offline, de forma continua. Genere variantes de ataque difíciles antes del despliegue y realiméntelas a la lógica de detección, en vez de esperar a que aparezcan nuevos ataques en producción.
4. Trate la exfiltración de credenciales como una señal de primer orden. El mayor hallazgo de campo fueron credenciales saliendo de la red; vigílelo explícitamente, en muchos formatos.
5. Optimice la precisión para producción. Una barrera que inunda al SOC de falsos positivos no sobrevivirá al contacto con las operaciones. Reporte su punto de operación (sensibilidad y falsos positivos), no solo una tasa de detección llamativa.

Estado

Elemento	Referencia	Fecha	Notas
Sistema ADR	arXiv:2605.17380	2026-05-17	Sensor + Detector de dos niveles + Explorer offline
Despliegue en producción	Uber	~10 meses	7.200+ hosts, 10.000+ sesiones/día, 97,2 % de precisión
ADR-Bench + código	github.com/uber/ADR	2026-05	302 tareas, 133 servidores MCP, 17 técnicas
Resultado reportado	ADR-Bench	2026-05	0 falsos positivos, 67 % de detección, 2–4× F1 vs referencias

Conviene recordar que se trata de un despliegue interno de un proveedor, con cifras autoinformadas, presentado como póster de MLSys y no como una evaluación independiente. El punto duradero y transferible es arquitectónico: los agentes MCP crean un punto ciego de observabilidad que el EDR clásico no cubre, y cerrarlo exige telemetría nativa de agentes, detección estratificada y consciente del coste, y un bucle de retroalimentación que haga red teaming al detector antes que los atacantes.