La mayoría de los equipos descubren el mismo hecho incómodo en el mismo orden. Primero se dan cuenta de que ya hay agentes de IA corriendo por todo su parque, llamando a modelos, abriendo servidores MCP, metiéndose en bases de datos y almacenes de objetos. Después intentan inventariarlos y descubren que no existe ninguna lista. La investigación independiente del sector (CSA/Token, n=418) pone cifras a la brecha: alrededor del 82% de las organizaciones tiene agentes corriendo que desconoce, y solo en torno al 21% mantiene un inventario en tiempo real. Antes de poder gobernar nada de esto, hay que verlo. La pregunta es cómo conseguir esa visibilidad sin empeorar las cosas.
Hay dos respuestas honestas, y están en extremos opuestos de un espectro de riesgo.
Dos formas de ver un agente
La primera es un proxy en línea. Enrutas el tráfico del agente a través de un componente que controlas y, como cada petición y respuesta pasa por él, puedes ver, moldear y bloquear en tiempo real. Es un diseño legítimo y potente. Así se aplica hoy buena parte del filtrado de salida, el brokering de secretos y la política a nivel de petición.
La segunda es el descubrimiento pasivo. En vez de plantarte en el flujo, lo observas desde un lado: el OpenTelemetry que un agente ya emite, los registros de auditoría nativos de los sistemas que toca (PostgreSQL pgAudit, registros de auditoría de nube como AWS CloudTrail, la auditoría de Kubernetes) y señales a nivel de kernel vía eBPF como backstop de verdad. Nunca terminas la conexión. Observas lo que pasó y reconstruyes quién tocó qué.
La diferencia que importa no es cuánto puede ver cada uno en el mejor caso. Es qué ocurre cuando la propia capa de visibilidad falla.
El radio de impacto es el verdadero eje
Un proxy en línea está, por construcción, en el data-path. Eso compra control en tiempo real, y te cuesta un modo de fallo compartido. Si el proxy va lento, tus agentes van lentos. Si se cae, el comportamiento seguro suele ser fail closed, es decir, tus agentes se paran, o fail open, es decir, tu control desaparece en silencio en el peor momento. En cualquier caso, el componente de visibilidad comparte ahora radio de impacto con producción. Además añade un salto de latencia a cada llamada y una superficie de despliegue que alguien tiene que operar, escalar y parchear en la ruta crítica.
El descubrimiento pasivo tiene el perfil opuesto. El colector está fuera de banda y es read-first: lee telemetría, registros de auditoría y eventos de kernel; no reenvía ni reescribe el tráfico del agente. Si se degrada o muere, nada cambia en la ruta de las peticiones. Pierdes visibilidad fresca hasta que se recupere, no throughput, no disponibilidad. Esto es lo que significa en la práctica read-first y de riesgo asimétricamente bajo: no hay riesgo al alza sobre producción desde la cosa cuyo único trabajo es observar.
| Proxy en línea | Descubrimiento pasivo | |
|---|---|---|
| Posición | En el data-path | Fuera de banda, al lado |
| Bloqueo en tiempo real | Nativo | Necesita enforcement en el punto de acceso |
| Latencia añadida | Sí, en cada llamada | Ninguna |
| Si falla | Los agentes se atascan o el control se esfuma | La visibilidad se queda obsoleta; los agentes no se enteran |
| Cobertura de rutas silenciosas | Alta (termina el flujo) | Depende de las señales emitidas + backstop eBPF |
Por eso la postura del producto es sin proxy obligatorio, no “los proxies no sirven”. Hay rutas donde un componente en línea es la decisión correcta, y se componen. Pero el descubrimiento, la parte a la que nunca debería permitírsele tirar abajo aquello que está inventariando, es el trabajo equivocado para atornillarlo a la ruta crítica.
El tradeoff, dicho con honestidad
El descubrimiento pasivo tiene una debilidad real, y fingir lo contrario sería la clase de strawman que hace que un diseño pierda la confianza en silencio. Un proxy que termina un flujo ve cada byte de él. Un colector pasivo solo ve lo que el agente, su runtime o el recurso decidieron emitir. En una ruta plenamente no cooperativa, una que registra poco y no emite telemetría útil, el descubrimiento a nivel de aplicación se adelgaza. Puedes inferir que algo pasó, pero la atribución se complica.
Dos cosas mantienen eso honesto en vez de fatal.
La primera es el backstop eBPF a nivel de kernel. Los logs de aplicación pueden estar incompletos, llegar tarde o, en un caso adversario, suprimirse a propósito. Al kernel no se le puede pedir con buenas maneras que olvide una syscall. Un agente que abre un socket a una base de datos o escribe un fichero deja rastro en el límite de la syscall, al margen de lo que su logging decidiera registrar. Eso convierte a eBPF en la verdad anti-evasión: cuando las señales de más alto nivel discrepan o se callan, la vista del kernel es la capa que corrobora. Es también la razón por la que las anotaciones de herramientas MCP como readOnlyHint y destructiveHint, útiles como pistas, se tratan como no confiables según la spec de MCP. Una herramienta que dice ser de solo lectura y se observa escribiendo es justo la discrepancia que merece la pena destacar, y solo la pillas si corroboras la afirmación contra lo que de verdad ocurrió.
La segunda son los niveles de confianza honestos. No toda observación merece el mismo peso, así que el mapa de acceso no finge que sí. Una arista respaldada por una señal de kernel y una entrada de auditoría que cuadra se marca como atribuida; una arista inferida de telemetría parcial se marca como aproximada. El producto nunca convierte una conjetura en un hecho. Quien revisa debe poder ver, de un vistazo, cuánto fiarse de cada línea.
De la observación al diff que importa
El descubrimiento es solo la entrada. La salida es la comparación entre PERMITIDO, lo que la política autoriza, y OBSERVADO, lo que el colector vio de verdad. Ese diff es la deriva de mínimo privilegio, y el caso principal es una escritura observada que la política nunca concedió y que nadie revisó.
Unas pocas líneas de un feed de acceso lo hacen concreto. Las lecturas son rutina; la escritura marcada es la historia:
agente accion recurso resultado confianza
data-export-job READ s3://billing-exports allowed atribuida
data-export-job READ prod-postgres allowed atribuida
data-export-job WRITE prod-postgres flagged atribuida
support-rag READ internal-wiki-mcp allowed aproximadaUn job de exportación leyendo una base de datos de producción no llama la atención. El mismo job escribiendo en ella, cuando la política solo concedió lectura, es la clase de arista que nunca debería pasar sin revisar. Como la escritura está corroborada en el límite del kernel, se marca como atribuida, no como una reserva.
Ver la deriva es la mitad del trabajo; cerrarla es la otra mitad. El enforcement va en el punto de acceso, expresado como policy-as-code, para que la regla sea revisable y se actúe sobre la violación, no solo se registre:
policy "data-export-readonly" {
agent = "data-export-job"
resource = "prod-postgres"
allow = ["read"]
deny = ["write"]
on_violation = "block + alert"
}El descubrimiento pasivo encuentra la escritura no permitida; la política devuelve al agente a mínimo privilegio y bloquea la siguiente. Visibilidad y control siguen siendo asuntos separados, que es exactamente por lo que la capa de descubrimiento puede permitirse ser read-first.
Para llevarse
La visibilidad sobre los agentes de IA es una decisión de riesgo antes que una decisión de feature. Un proxy en línea te da control en tiempo real a cambio de compartir radio de impacto con producción. El descubrimiento pasivo cede algo de alcance en rutas silenciosas a cambio de no poder tirar nunca producción abajo, y luego recupera casi todo ese alcance con un backstop eBPF de verdad y niveles de confianza que siguen siendo honestos sobre lo que de verdad se vio. Para un inventario, la capa cuyo único trabajo es observar, esa asimetría es el valor por defecto correcto.
Si quieres el cuadro completo de cómo encajan los colectores, el mapa de acceso y el registro de auditoría, la visión de arquitectura lo recorre de principio a fin.