El mínimo privilegio es una de las ideas más antiguas y fiables de la seguridad. Da a una identidad exactamente el acceso que necesita, nada más, y el radio de impacto de cualquier compromiso se mantiene pequeño. Para cuentas de personas y cuentas de servicio de larga vida el modelo aguanta razonablemente: los roles se revisan, las concesiones se acotan, las certificaciones de acceso se ejecutan con cadencia trimestral.
Los agentes de IA rompen este modelo en silencio. A un agente se le da una credencial, una herramienta, una conexión a un servidor MCP, y desde ese momento su comportamiento es dinámico. Decide en tiempo de ejecución qué recursos leer, cuáles escribir, qué herramienta invocar a continuación. La concesión que escribiste el primer día describe un techo, no lo que el agente hace. Y como los agentes son productivos, ese techo tiende a ser generoso: roles de base de datos amplios, acceso de escritura “por si acaso”, una cuenta de servicio compartida entre media docena de flujos. El resultado es un parque donde el acceso permitido y el acceso realmente usado se separan, en silencio, cada día.
La investigación independiente del sector capta el tamaño del punto ciego: en torno al 82% de las organizaciones declara tener agentes de IA en ejecución que desconocía (CSA/Token Security, n=418). No puedes aplicar mínimo privilegio sobre una infraestructura que no puedes ver.
Definir la deriva de mínimo privilegio
La deriva de mínimo privilegio es la brecha creciente entre el acceso que un agente tiene permitido y el acceso que se observa que usa. Tiene dos direcciones de fallo, y solo una de ellas es obvia.
La dirección obvia es el infrauso: un agente mantiene acceso de escritura a una tabla en la que nunca ha escrito. Eso es privilegio muerto, riesgo que cargas sin beneficio alguno. La dirección peligrosa es la señal inversa que implica: cuando el conjunto observado contiene algo que el conjunto permitido nunca concedió de forma deliberada, tienes una acción ocurriendo que nadie revisó. Un trabajo de exportación que de pronto escribe en un bucket del que solo leía. Un agente que la política acotó a un esquema alcanzando otro. No son casos exóticos; son la textura diaria de agentes cableados entre sí con concesiones de grano grueso.
La razón de que esto sea difícil, y de que sea específico de los agentes y no de las personas, es que el comportamiento se genera, no se configura. Una persona con demasiado acceso casi nunca lo ejerce. Un agente con demasiado acceso ejercerá lo que le ayude a completar la tarea que tiene delante, incluidas rutas que nadie anticipó. La revisión estática de política no puede seguir el ritmo de un comportamiento que cambia en cada ejecución.
Convertir la deriva en una señal revisable
La deriva solo es peligrosa mientras es invisible. El trabajo es convertirla en una señal que una persona pueda revisar, y eso requiere dos cosas trabajando juntas: observación continua de lo que los agentes tocan realmente, y un registro estable de lo que tenían permitido tocar.
La observación tiene que ser read-first. Un colector que observa desde logs, trazas de OpenTelemetry y señales de eBPF en el kernel se sitúa fuera de la ruta de datos del agente. No es un proxy, no controla las llamadas, y si falla, falla del lado seguro: el agente sigue funcionando, pierdes visibilidad y no disponibilidad. Esa asimetría importa: un control de seguridad capaz de tumbar producción es un control que los equipos desactivan en silencio. La capa de eBPF en particular actúa como verdad de base a nivel de kernel, la parte que un agente no puede esquivar (la captura del kernel procede de un sensor Tetragon que despliegas tú; Olivares AI lee la exportación de Tetragon y no carga programas eBPF por sí mismo), y por eso las pistas a nivel de protocolo como las anotaciones de herramienta de MCP (readOnlyHint, destructiveHint) se corroboran contra ella en lugar de confiar en ellas. La propia especificación MCP dice que esas anotaciones no son de confianza; las señales del kernel son lo que hace real la corroboración.
Lo que produce la observación es un mapa de acceso: para cada agente, qué recursos alcanzó y si leyó (R) o leyó/escribió (RW). El mapa almacena relaciones de acceso, no payloads, secretos ni PII. La parte interesante es el diff:
| Agente | Recurso | Permitido | Observado | Deriva |
|---|---|---|---|---|
| data-export-job | prod-postgres | R | R | ninguna |
| data-export-job | s3://billing-exports | R | RW | escritura no revisada |
| report-builder | analytics-db | R | (sin uso) | privilegio muerto |
La fila que importa es la del medio. La política concedió lectura sobre el bucket de exportación; el colector observó una escritura. Esa única línea es el riesgo titular que la deriva de mínimo privilegio busca aflorar: un privilegio ejercido que nadie revisó, atribuido a un agente concreto y no a una cuenta de servicio compartida, porque la identidad por agente es lo que hace posible la atribución y la auditoría en primer lugar.
Aplicar en tiempo de acceso, no solo registrarlo
La detección te dice que la deriva ocurrió. Para cerrar el bucle quieres que la escritura no revisada sea una ruta denegada, no una registrada. Ahí entra la política evaluada en tiempo de acceso.
Olivares AI evalúa Cedar como una capa de prohibiciones (forbid) sobre roles que deniegan por defecto, de modo que una regla solo puede quitar acceso; esta deniega cualquier solicitud que toque una credencial secreta, diga lo que diga el rol.
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };Escribir tus propias reglas Cedar requiere Business; Community aplica los roles integrados, la capa de denegación nativa y el kill switch; los roles personalizados y las concesiones acotadas son Business.
Recorre el antes y el después de forma concreta.
Antes. Un agente de código, con un rol amplio, llama a una herramienta MCP que escribe en s3://billing-exports. Nada lo detiene. La acción tiene éxito, se mezcla con el tráfico normal y aparece días después, si es que aparece, como una anomalía en el mapa de acceso. La brecha entre permitido y observado se ensanchó, y el único artefacto es una línea de log que nadie leyó.
Después. La misma llamada a la herramienta llega al punto de control MCP. El rol del agente no permite la escritura, así que el punto de control deniega la llamada antes de producirse (deny-closed) y registra la denegación en el registro de auditoría firmado, que permite detectar manipulaciones. La escritura no revisada nunca llega a ser un cambio no revisado. Olivares AI bloquea una acción solo en sus cuatro puntos de aplicación: dentro de Claude Code, en el proxy de modelos, en cada llamada a una herramienta MCP y entre agentes. Un trabajo que escribe directamente en S3, fuera de esos puntos, no se bloquea: el mapa de acceso registra la escritura y la señala como deriva para su revisión.
Dos propiedades mantienen esto honesto. Primera, cada vista privilegiada del mapa de acceso se audita a su vez, quién vio qué, porque el mapa es sensible y una herramienta de seguridad que no puede rendir cuentas de sus propios operadores no es de fiar. Segunda, la confianza se muestra sin adornos: un vínculo cuya fuente lleva una identidad por agente se marca attributed, mientras que uno visto solo por el kernel se marca approximate, porque las señales del kernel nombran un proceso, un cgroup o un contenedor, no un agente. Nunca se te pide actuar sobre una certeza fabricada.
La conclusión
El mínimo privilegio no falló para los agentes de IA; falló la cadencia de revisión. Las concesiones son de grano grueso, el comportamiento es dinámico, y las certificaciones trimestrales no pueden seguir una superficie de acceso que cambia en cada ejecución. La solución no es un proxy más pesado en la ruta crítica. Es observación continua y read-first que produce un diff permitido-versus-observado, más política como código que aplica la frontera corregida en tiempo de acceso, de modo que un agente sobre-privilegiado se detecta como señal revisable mucho antes de convertirse en incidente.
Si quieres ver cómo encajan el colector, el mapa de acceso y la aplicación en tiempo de acceso sin situarse en la ruta de datos de tus agentes, la página de arquitectura recorre el diseño, y el producto muestra cómo se ve la vista permitido-versus-observado sobre un parque real.