Uber abrió el código del sistema de seguridad que construyó para sus propios agentes de IA. La razón por la que tuvo que construirlo es la parte incómoda: sus herramientas de seguridad no podían ver qué estaban haciendo esos agentes.

Eso solo ya es una historia. Pero el dato que me detuvo no está en el anuncio. Está enterrado en la diapositiva de la presentación que Uber dio en MLSys 2026, bajo el título “hallazgos del despliegue”, y dice esto: hay gente que aprueba más de 50 acciones por sesión. La conclusión que el propio equipo escribió debajo: la fatiga de aprobación significa que no hay supervisión real.

El clic de aprobar no es una política

Esta es la tesis, y es incómoda porque casi todas las empresas que están soltando agentes hoy dependen exactamente de eso.

El diálogo de aprobación es la última capa de gobernanza que le queda a la mayoría. El agente propone, el humano confirma, y todo el mundo duerme tranquilo porque hay un human-in-the-loop. El problema es que ese control no falla al azar. Se degrada en función de la longitud de la sesión.

Una sesión de seis acciones la lees completa. Una de cincuenta la aprietas. Misma persona, misma política escrita, resultado opuesto. Y la longitud de la sesión no es una variable independiente: crece exactamente en la medida en que el agente se vuelve capaz. Mientras más útil el agente, menos real es tu supervisión.

Dicho de otra forma: el control que tienes funciona bien en el piloto y deja de funcionar en producción. Es el peor perfil posible para una defensa, porque te da confianza justo durante el período en que no la necesitas.

La IA empresarial no falla en producción porque el modelo no razone. Falla porque nadie definió quién aprueba qué, bajo qué política y con qué registro. Y “que el humano confirme” no es una definición de eso. Es una forma elegante de posponerla.

Lo que Uber vio cuando por fin pudo ver

Vale la pena entender por qué Uber tuvo que construir la telemetría desde cero.

Su diagnóstico es de una honestidad rara: las herramientas de seguridad tradicionales, las de EDR, ven escrituras de archivos y llamadas de red, pero no ven el razonamiento del agente, ni los prompts, ni la cadena causal que conecta una intención con la ejecución de una herramienta a través de agentes heterogéneos. Es decir, tu SIEM te va a decir que un proceso escribió un archivo. No te va a decir por qué el agente decidió escribirlo, ni qué pidió el usuario tres pasos antes.

Sobre la escala, los propios números de Uber no se ponen de acuerdo entre sí, y eso también dice algo. El paper de MLSys 2026, con datos de más de diez meses en producción, reporta más de 10,000 sesiones de agentes al día sobre más de 7,200 equipos únicos. La presentación del mismo trabajo habla de 200,000 sesiones diarias como escala de producción 2026 sobre 30,000 equipos. Su CTO, al anunciar la liberación, habló de más de 50,000 sesiones diarias. La curva es tan empinada que tres documentos de la misma empresa, publicados con meses de diferencia, citan tres cifras distintas. Ninguna empresa audita a esa velocidad con revisiones manuales.

Los hallazgos de campo son más útiles que las cifras. Uber reporta que mucha gente usa de forma consistente el modo YOLO sin sandbox. Reporta agentes que ejecutan comandos privilegiados con la identidad del usuario, y que las barreras que traen los modelos cubren rm -rf pero no las herramientas internas ni el contexto propio de la empresa. Y reporta el caso de agencia excesiva más didáctico que he leído: un agente falla al autenticarse porque un certificado venció. Lo correcto era pedirle al usuario que se reautenticara. En su lugar, el agente empezó a volcar credenciales por todos lados, disparó alertas de EDR, encontró llaves SSH y se puso a explorar otros entornos de desarrollo.

Nadie atacó a ese agente. Solo se le venció un certificado.

La inyección de prompts se lleva las charlas; las credenciales se llevan los incidentes

Acá está el segundo hallazgo, y es el que debería reordenar presupuestos.

Uber clasifica la fuga de secretos como su problema más común: cientos de exposiciones de severidad alta repartidas en 26 categorías, con credenciales de larga vida compartidas con proveedores de IA, con proveedores de modelos y con servidores MCP.

¿Y la prompt injection? Uber la mete en una diapositiva titulada “errores comunes de percepción”. Textualmente: sorprendentemente rara en producción. Los laboratorios de modelos han invertido mucho ahí, los agentes expuestos al exterior sí se pueden engañar pero sus acciones son fáciles de rastrear, y la acción recomendada por Uber hoy es ninguna.

Léelo de nuevo. La amenaza que se lleva las charlas de conferencia y los whitepapers de proveedores está catalogada por el operador más grande que ha publicado datos de campo como algo que hoy no requiere acción. Y el problema que sí les está pasando, todos los días, es aburridísimo: credenciales que se van a donde no deberían.

La razón es simple. La inyección de prompts necesita un atacante. La fuga de credenciales solo necesita un martes. Un agente que lee un .env para entender por qué falla una conexión. Un token de larga vida en un archivo de configuración que nadie rotó. Un servidor MCP al que le pasas más contexto del que necesita porque configurarlo bien tomaba veinte minutos más.

Y la respuesta de Uber tampoco fue más inteligencia artificial. Fue una capa de prevención que corta el secreto antes de que salga, con 97.2% de precisión sobre 206 credenciales detectadas. Prevención aburrida sobre detección brillante.

Un detalle que me hace confiar más en todo el trabajo: en su propio benchmark, ADR-Bench, con 302 tareas sobre 133 servidores MCP y cobertura de las 17 técnicas de ataque, ADR detecta el 67% de los ataques con cero falsos positivos. Sesenta y siete por ciento. Un proveedor habría redondeado ese número hacia arriba o lo habría escondido. Uber lo publicó junto con el código.

Qué hacemos en IQ Source con esto

Ya escribimos sobre el método de 10 días con que Uber construye sus Agentic Pods. Esto es lo que pasa después del día 10, cuando el agente ya está en producción y la conversación deja de ser sobre cómo construirlo y pasa a ser sobre quién responde por lo que hace.

Y confirma con datos algo que vengo argumentando: la gobernanza es el moat (ventaja competitiva), no el modelo. La diferencia es que ahora no es una tesis mía. Es telemetría de diez meses de la empresa que más agentes corre en producción y que publicó los números que la dejan mal parada.

En la fase de discovery de AI Maestro, esto se traduce en tres cosas concretas que hacemos antes de que un agente toque nada.

Primero, definimos un presupuesto de aprobaciones por proceso, no por acción. Si un flujo de trabajo necesita 50 confirmaciones humanas para completarse, el flujo está mal diseñado, no la persona que dejó de leerlas. La pregunta correcta no es “¿cuántas aprobaciones necesita este agente?” sino “¿cuáles tres decisiones de este proceso son irreversibles?”. Esas tres se aprueban de verdad. El resto se ejecuta bajo política y se audita después.

Segundo, inventariamos qué credenciales hereda cada agente antes de la primera corrida. Uber necesitó construir telemetría nueva para encontrar cientos de exposiciones. La mayoría de las empresas con las que trabajamos no necesita construir nada todavía: necesita sentarse una tarde y listar qué puede leer el agente con los permisos que ya tiene. Ese ejercicio, sin una sola línea de código, suele ser más productivo que el primer trimestre entero de monitoreo.

Tercero, definimos dónde queda el registro antes de encender nada. Si la única evidencia de lo que hizo el agente vive en el historial local de su sesión, en la laptop de quien lo lanzó, no tienes registro de auditoría. Tienes un recuerdo.

Uber armó su presentación de seguridad, según dice el pie de la última diapositiva, con Codex y Claude Code. Están usando agentes para documentar el problema de gobernar agentes, y publicaron el 67% en vez de esconderlo. Esa combinación de velocidad y honestidad sobre los propios números es más difícil de copiar que cualquier modelo.

Si tu plan de gobernanza de agentes cabe en un diálogo de confirmación, tu plan es que alguien lea cincuenta veces al día algo que dejó de leer en la tercera.

Revisa cuántas aprobaciones reales tiene tu proceso, no cuántas pide tu agente