Saltar al contenido

mínimo privilegio

Deriva de mínimo privilegio: detectar agentes de IA sobre-privilegiados antes del incidente

Por Olivares AI 7 min de lectura

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, mientras que solo cerca del 21% mantiene un inventario en tiempo real de ellos (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

Pongámosle nombre con precisión. 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, 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:

AgenteRecursoPermitidoObservadoDeriva
data-export-jobprod-postgresRRninguna
data-export-jobs3://billing-exportsRRWescritura no revisada
report-builderanalytics-dbR(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 como código evaluada en tiempo de acceso. El mismo diff que marcó la deriva se convierte en la regla que la previene.

Considera fijar el trabajo de exportación a solo-lectura sobre la base de datos de producción y denegar las escrituras de plano, con una violación que bloquee y alerte en lugar de pasar en silencio:

agent "data-export-job" {
  # Solo lectura sobre la base de datos operacional. Sin escrituras, nunca.
  access "prod-postgres" {
    mode  = "read"
    deny  = ["write", "delete", "ddl"]
  }

  # El destino de exportación que el trabajo *debe* usar.
  access "s3://billing-exports" {
    mode = "read"
  }

  on_violation {
    action = "block"        # denegar la llamada en tiempo de acceso
    alert  = "security-oncall"
    audit  = "append"       # escribir en el ledger a prueba de manipulación
  }
}

Recorre el antes y el después de forma concreta.

Antes. El trabajo de exportación, con un rol amplio, emite una escritura a 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. Llega la misma escritura. La política se evalúa en tiempo de acceso, ve write sobre un recurso acotado a read y devuelve una denegación antes de que la operación aterrice. La violación bloquea la llamada, eleva una alerta a la rotación de guardia y añade una entrada al ledger de auditoría append-only y hash-encadenado. La escritura no revisada nunca llega a ser un cambio no revisado. La deriva se convierte, en el momento, de nuevo en una ruta de mínimo privilegio.

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: una acción atribuida a un agente por evidencia a nivel de kernel se marca distinto de una inferida de forma aproximada. 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.

Preguntas frecuentes

¿Qué es la deriva de mínimo privilegio en un agente de IA?

Es la brecha creciente entre lo que un agente tiene permitido hacer y lo que se observa que hace realmente. Con concesiones de grano grueso y comportamiento dinámico, un agente puede empezar a tocar recursos que nadie aprobó mucho antes de que alguien lo note. La deriva es la acumulación silenciosa de esa brecha, y solo es revisable si comparas de forma continua el conjunto permitido con el observado.

¿Cómo detectas un agente sobre-privilegiado sin romper producción?

Observa en vez de interceptar. Un colector read-first lee de logs, OpenTelemetry y señales de eBPF en el kernel en lugar de situarse en la ruta de datos del agente, de modo que un fallo del colector nunca bloquea al agente. Esa observación alimenta un diff permitido-vs-observado. La aplicación vive luego en política como código evaluada en tiempo de acceso, donde una escritura no revisada se convierte en una ruta denegada con alerta.

Mira a qué pueden llegar tus agentes

Olivares AI es la plataforma abierta y self-hosted para tu parque de IA. Despliégalo en tu propia infraestructura y obtén el mapa de acceso que tus equipos de seguridad y plataforma llevan pidiendo.