Lo que tus agentes de IA pueden alcanzar de verdad: mapear el acceso de agentes en infraestructura real

Un agente de IA es, en términos operativos, un proceso que tiene credenciales. Alguien le aprovisiona una service account, una API key o un rol IAM para que haga su trabajo y, desde ese momento, puede alcanzar todo lo que esas credenciales alcanzan. La descripción de la tarea decía “exporta los datos de facturación cada noche”. La credencial decía “lee y escribe en la base de datos de producción, y en el object store, y en la cola”. Nadie reconcilió ambas cosas. Meses después, nadie en el equipo sabe responder a una pregunta que debería ser trivial: ¿qué puede alcanzar de verdad este agente, y qué toca realmente?

Esa brecha no es hipotética. Investigación independiente del sector (CSA/Token) halló que en torno al 82% de las organizaciones tienen agentes de IA en marcha que desconocen, mientras que solo alrededor del 21% mantienen un inventario en tiempo real de ellos. No puedes gobernar lo que no ves, y ahora mismo la mayoría de los entornos no ven a sus agentes en absoluto — y mucho menos las aristas que conectan cada agente con los recursos que puede alcanzar.

Tres preguntas distintas que se confunden de forma rutinaria

La razón por la que “qué puede alcanzar este agente” es difícil de responder es que colapsa tres preguntas separadas en una. Mantenerlas distintas es la clave de todo.

• Tiene — las credenciales que posee el agente. Un token, una key, un binding de rol. Es un hecho de identidad: a qué puertas tiene llaves el agente.
• Permitido — lo que esas credenciales están autorizadas a hacer, según la política: las concesiones IAM, los roles de base de datos, las reglas de red. Es un hecho de política, y casi siempre es más amplio de lo que nadie recuerda, porque las concesiones se acumulan y nadie las revoca.
• Observado — lo que se ha visto hacer al agente realmente: a qué recursos llegó y si cada acceso fue lectura o escritura. Es un hecho de comportamiento y, hasta que lo recopilas, sencillamente no existe en ninguna parte.

La mayoría del tooling de seguridad se detiene en lo permitido. Lee tu IAM y te dice que el agente podría escribir en el bucket de exports de facturación. Es necesario pero insuficiente, porque “podría” es un conjunto de miles de capacidades latentes, y una persona no puede triar miles de “quizás”. Lo que cambia la conversación es poner lo observado al lado de lo permitido y mirar la diferencia.

El mapa de acceso

Un mapa de acceso es el grafo de esas aristas: por cada agente descubierto, una arista hacia cada recurso que puede alcanzar, anotada con lo que se observó realmente a través de ella. La unidad que importa es la arista, y la anotación más importante sobre la arista es la distinción lectura/escritura.

R (lectura) significa que el agente recuperó datos sin cambiarlos: un SELECT, un GET, leer un fichero. RW (lectura/escritura) significa que mutó estado: un INSERT/UPDATE/DELETE, un PUT a almacenamiento de objetos, una migración de esquema. El radio de impacto de ambos no es comparable. Una arista de lectura sobre una tabla sensible es una cuestión de exposición. Una arista de escritura — sobre todo si es no intencionada — es una cuestión de integridad y de incidente. Tratarlas como el mismo “acceso” es como los equipos se pierden el hallazgo que importaba.

Así queda la fila de un único agente una vez construido el mapa:

Fíjate en la primera fila. El trabajo de export debía leer de prod-postgres y escribir el resultado en s3://billing-exports. Leer en origen, escribir en destino. Pero la credencial que se le entregó concede RW sobre la base de datos, y el colector lo observó escribiendo en prod-postgres — una mutación sobre el sistema de registro de producción que nadie revisó, pretendió ni sabe explicar ahora mismo. La columna de permitido decía en voz baja que esto estaba autorizado desde el principio. Esa es la semilla de un incidente, a plena vista, y sin la columna de observado no hay nada que marcar.

Permitido menos observado es igual a drift

La salida característica es el diff. El least-privilege drift es lo que obtienes al restar una columna de la otra, y corta en ambos sentidos:

• Permitido pero nunca observado — el agente puede alcanzar internal-metrics-api pero en toda la ventana de observación nunca lo hizo. Eso es scope muerto: una concesión que puedes proponer revocar con seguridad, reduciendo la superficie de ataque sin tocar el comportamiento.
• Observado más allá de lo revisado — la escritura en prod-postgres que nadie aprobó. Este es el hallazgo de alta señal: una acción ocurriendo que, de habérselo preguntado a alguien en el momento del aprovisionamiento, no habría aprobado.

La segunda categoría es el riesgo titular, y la versión honesta del producto nunca lo inventa. Cada arista observada lleva un nivel de confianza — atribuido cuando la acción está ligada a la identidad de un agente concreto con señal corroborante, aproximado cuando la evidencia es más débil. Muestras la diferencia en lugar de blanquear una suposición y convertirla en certeza. Un hallazgo que no puedes sostener es peor que ningún hallazgo.

Descubierto de forma pasiva, atribuido por agente

Dos decisiones de diseño hacen que esto sea fiable en lugar de un dashboard más.

Primera, el descubrimiento es pasivo. El colector observa — logs, trazas de OpenTelemetry, streams de auditoría de base de datos como pgAudit de PostgreSQL y eBPF en el kernel como backstop de ground truth — y no se sitúa en el data path del agente. No hay proxy obligatorio. Si el colector falla, el agente sigue funcionando; se degrada la observabilidad, no la producción. Para un sistema cuyo propósito es gobernar infraestructura crítica, esa asimetría es el diseño: poco que perder, mucha señal.

Segunda, cada acción se atribuye a la identidad de un agente concreto, no a una service account compartida. Esta es la diferencia entre un libro de auditoría que dice “el rol de export escribió en prod-postgres a las 02:14” y uno que dice qué agente lo hizo, bajo qué propiedad y contra qué scope pretendido. La identidad por agente es la precondición para que el least-privilege signifique algo — sin ella, una acción puede verse pero nunca rastrearse hasta un responsable.

Las aristas y los hechos de lectura/escritura son lo único que se almacena. El mapa registra relaciones — agente a recurso, R o RW — no payloads, no las filas que se leyeron, no secretos. Las entradas que puedan llevar secretos o PII se redactan y se escanean en busca de secretos antes de escribir nada. El grafo es sensible precisamente porque es un mapa de acceso, así que se construye para guardar el mínimo que hace posible el gobierno y nada más.

Las señales del propio ecosistema del agente ayudan pero no se confían por sí solas. Un servidor MCP puede anunciar que una herramienta es de solo lectura mediante anotaciones como readOnlyHint; según la especificación MCP esos hints son no confiables y deben corroborarse, nunca creerse a ciegas. La vista a nivel de kernel es la que pilla una herramienta que se declaró de solo lectura y escribió igualmente.

Una vez existe el mapa, el paso siguiente es la aplicación: fijar el trabajo de export a solo lectura sobre la base de datos, denegar la escritura y alertar en lugar de limitarse a registrar — política aplicada en el momento del acceso, no reconstruida tras el incidente.

agent "data-export-job" {
  resource "prod-postgres" {
    access = "read"        # scope pretendido: leer solo en origen
    deny   = ["write", "ddl"]
  }
  resource "s3://billing-exports" {
    access = "read-write"  # scope pretendido: escribir en destino
  }
  on_violation {
    action = "block"
    alert  = "secops"
  }
}

El mapa te dice la política que deberías haber escrito, porque te muestra el único acceso que el agente necesitaba de verdad y la docena que nunca usó. Esa es la diferencia entre suponer el least-privilege y derivarlo del ground truth.

Si esta es la pregunta que tu infraestructura no sabe responder hoy — qué puede alcanzar cada agente, y qué toca realmente — para eso es exactamente el mapa de acceso. La visión del producto recorre el descubrimiento y el diff de permitido frente a observado; la arquitectura cubre cómo encajan la colección pasiva, la identidad por agente y el libro de auditoría sin situarse jamás en el data path de tus agentes.