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. 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 captura a nivel de kernel viene de un sensor Tetragon que despliegas tú; Olivares AI lee la exportación de Tetragon y no carga programas eBPF por sí mismo.
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 cuya fuente lleva una identidad por agente, como OpenTelemetry cooperativo con un id de agente o una traza de auditoría en la que el agente tiene su propio rol de base de datos, se marca como atribuida. Una arista inferida de telemetría parcial, y toda arista vista solo por el kernel, se marca como aproximada, porque las señales de kernel nombran un proceso, un cgroup o un contenedor, no un agente. 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 aproximada
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. El kernel confirma que la escritura ocurrió, pero nombra un proceso o un contenedor y no un agente, así que esa arista se marca como aproximada.
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. Olivares AI evalúa Cedar como una capa forbid sobre roles deny-by-default, de modo que una regla solo puede quitar acceso; esta deniega cualquier petición 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 de Business.
El descubrimiento pasivo encuentra la escritura no permitida, y el mapa de acceso la marca como deriva. 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 herramientas MCP y entre agentes. Una escritura que pasa por uno de ellos y que el rol del agente no permite se deniega antes de producirse y queda en el registro de auditoría firmado y a prueba de manipulación; una escritura directa en la base de datos se observa, no se bloquea. 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.