Los agentes de programación con IA ya no son solo experimentos personales. Empiezan a vivir dentro de entornos corporativos, y por eso el repositorio ADR que Uber abrió al público resulta relevante. La idea no es mirar Claude Code, Cursor, OpenAI Codex CLI, Cline, Claude Desktop, Warp Terminal u opencode como simples editores con autocompletado. Son sistemas que leen prompts, observan repositorios, eligen herramientas, ejecutan shell, modifican archivos, hablan con servidores MCP y a veces se encuentran con material parecido a credenciales. Esa cadena no queda suficientemente clara si seguridad solo mira procesos y eventos de archivos.

Panel de seguridad que sigue acciones de agentes de programación con IA

Qué abrió Uber

ADR significa Agentic Detection and Response, no el acrónimo clásico de decisiones de arquitectura. El repositorio lo presenta como un sistema de seguridad empresarial para agentes de IA y afirma que fue desplegado en Uber. En el momento de publicación estaba bajo Apache-2.0, principalmente en Python, con unas 1.334 estrellas y 112 forks, y actualizado el 10 de agosto de 2026. Las cifras no son la tesis, pero muestran que el tema llegó en plena conversación sobre seguridad de agentes.

No es un escáner mágico. La arquitectura se divide en observabilidad, benchmark, detección y prevención. El lanzamiento abierto incluye sensor, ADR-Bench y detector. La capa de prevención y parte del explorador interno no forman parte del paquete público. Esa frontera es importante: el proyecto sirve como referencia, no como producto listo para instalar en producción sin trabajo adicional.

El artículo aceptado en MLSys 2026 Industry Track da más contexto. Su resumen habla de tres problemas persistentes: observabilidad limitada, robustez insuficiente y alto coste de detección. También afirma que el sistema funcionó en Uber durante más de diez meses, con más de 7.200 hosts únicos y más de 10.000 sesiones de agentes al día. Son datos reportados por Uber, no una promesa automática para cualquier empresa.

Por qué EDR y SIEM ven poco

Un EDR tradicional responde bien a preguntas de sistema operativo: qué proceso escribió un archivo, qué binario abrió una conexión, qué host tocó un dominio sospechoso. Eso sigue siendo necesario. El problema es que un agente introduce una capa entre la intención humana y el evento técnico. Un comando de shell puede parecer normal, pero ser peligroso si nació de una instrucción hostil dentro de un issue, un documento o una respuesta de MCP.

Para desarrollo con agentes, la pregunta útil es más amplia: qué pidió el usuario, qué contexto leyó el modelo, qué plan mostró, qué tool calls propuso, cuáles ejecutó, qué política aplicaba y cuál fue el resultado. Sin esa cadena de sesión, el SOC ve síntomas pero no causa.

Por eso importa el énfasis de ADR en sesiones. El Sensor README describe parsers para Claude Code, Cursor IDE, Cline, Claude Desktop, OpenAI Codex CLI, Warp Terminal y opencode, con diferencias entre macOS, Linux y Windows. Los eventos se normalizan con session ID, timestamp, chat history, tools, model, project path y session context. Ese es el vocabulario que normalmente falta en EDR.

El problema de herramientas y MCP

La fuerza real del agente aparece en la frontera de herramientas. Un coding agent se vuelve operativo cuando puede leer un repositorio, llamar a git, ejecutar pruebas, consultar documentación interna, tocar tickets, usar un helper de despliegue o comunicarse con un MCP server. Cada conector puede estar justificado; juntos forman un grafo de permisos difícil de auditar.

ADR trata ese grafo como superficie de detección. ADR-Bench se describe como cerca de trescientos escenarios; la documentación de Detection habla de 303 escenarios, 261 benignos y 42 maliciosos, con 17 técnicas de ataque y 133 servidores MCP. Lo importante no es el número exacto, sino el tipo de prueba: comportamiento de agentes dentro de flujos realistas con instrucciones maliciosas, credenciales sintéticas y servicios vulnerables.

Las notas de apertura advierten que el benchmark contiene material de ataque sintético y dependencias fijadas con CVE conocidos para reproducibilidad. Debe ejecutarse en un entorno aislado, no en producción. Para una empresa madura, es equipo de prueba de seguridad: útil, pero separado de sistemas reales.

Qué deben hacer las empresas

Para CTO, CISO y equipos de plataforma, el mensaje no es prohibir agentes ni copiar un repositorio. Es construir una capa operativa. Primero hay que inventariar qué herramientas están permitidas, dónde viven sus logs, qué sistemas operativos cubren, qué repositorios alcanzan y qué acciones pueden ejecutar sin revisión humana constante.

Después viene el principio de mínimo privilegio. Un agente no debería heredar por defecto todas las credenciales, permisos de shell y sesiones de navegador del desarrollador. Gateways de credenciales, tokens cortos, permisos por repositorio, cuentas de desarrollo dedicadas y reglas explícitas para MCP ya son higiene básica.

La tercera pieza es auditabilidad. Los registros deben mostrar la cadena desde prompt hasta tool call y resultado. Pero no conviene registrar todo sin filtro. La telemetría de agentes puede contener código, tickets internos, datos de clientes y cadenas parecidas a secretos. Un programa de tipo ADR necesita retención limitada, redacción, control de acceso y exportación cuidadosa a SIEM.

Qué cambia para seguridad

Una sesión sospechosa de agente puede no parecer malware. Puede ser una máquina de desarrollo normal, un editor normal y un terminal legítimo. La anomalía puede estar en una secuencia de herramientas, un patrón de prompt, una lectura repentina de ubicaciones de credenciales, un script generado que sale de la red esperada o un servidor MCP que convierte documentación en acción real.

Las reglas deben combinar contexto. La telemetría de procesos es superficial; escanear prompts es frágil; mirar solo la salida del modelo no prueba lo ejecutado. La unidad útil es la sesión: entradas, contexto, herramientas, efectos en archivos y red, y decisiones de política. Los equipos maduros querrán detecciones que expliquen el riesgo, no solo coincidencias de regex.

También cambiarán las exigencias a proveedores. IDEs, workspaces en la nube, terminales, frameworks de agentes y plataformas MCP tendrán que entregar logs estructurados y exportables. Si cada herramienta guarda un formato privado, la adopción empresarial y la respuesta a incidentes serán mucho más difíciles.

Por qué es una señal de mercado

El hilo directo de Hacker News sobre Uber ADR fue pequeño, pero las discusiones cercanas sobre agentes en la nube, gateways de credenciales y sandboxes fueron más activas. La pregunta común es dónde debe ejecutarse un agente, qué secretos puede ver, cuán aislado está el workspace y quién responde cuando la automatización cruza una frontera.

ADR no está solo. Aparece junto a sandboxes para agentes, brokers de credenciales, runtime monitoring para aplicaciones de IA y motores de políticas para desarrollo. La industria se aleja de “dejar que un modelo conduzca mi portátil” y se acerca a infraestructura gestionada de agentes. La monitorización de seguridad es una pieza obligatoria.

Plan práctico

Una empresa puede empezar con poco. Haga un mapa de herramientas aprobadas y rutas de datos. Separe asistentes de autocompletado de agentes que pueden modificar el sistema de archivos o llamar servicios externos. Revise perfiles de shell, .env locales, tokens de package managers, credenciales cloud y claves SSH. Mantenga secretos de producción fuera de sesiones generales.

Recoja los logs disponibles: editor, historial de shell, transcripciones de terminal, eventos de gateway MCP, commits, pull requests y CI. La correlación será imperfecta, pero mostrará huecos reales. Pruebe después en un repositorio aislado con secretos sintéticos. Si el equipo no puede saber cuándo un agente leyó un archivo sensible, siguió una instrucción hostil o modificó código fuera de alcance, ya tiene su primera tarea.

La advertencia final es que la observabilidad también puede ser riesgo. Las sesiones pueden incluir código, planes internos, notas de vulnerabilidad, datos de soporte y secretos pegados por error. El control debe tener su propio modelo de seguridad: mínimo contexto útil, redacción, cifrado, acceso limitado, retención por sensibilidad y explicación clara a los empleados.

Uber ADR importa porque nombra una brecha. Los agentes de programación no son simples editores ni empleados completos; son sistemas delegados que convierten prompts y contexto en uso de herramientas. El siguiente paso de la IA corporativa dependerá de hacer ese trabajo observable, limitado, revisable y recuperable.