Hubble: observabilidad de red en eBPF, estado del arte 2026 y la nueva frontera con los agentes IA

TL;DR

Hubble es la observabilidad de red nativa de Cilium, construida sobre los mismos programas eBPF que Cilium usa para enforcement. No duplica datapath ni instrumenta el kernel a su manera: escucha los hooks que Cilium ya tiene y produce flow logs estructurados con contexto Kubernetes incluido —pod, namespace, labels, service, verdict de policy, payload L7 cuando aplica—. Es lo que pasa cuando alguien decide que tcpdump con grep no escala a 10 000 pods y construye un sistema distribuido propio (Hubble server por nodo + Hubble Relay como agregador + CLI + UI) con overhead prácticamente cero porque la captura ya estaba ocurriendo. En 2026 está en versión 1.19.3 (abril 2026), con Cilium 1.19 marcando el décimo aniversario del proyecto; ha llegado el tracing por IP options, el filtrado por estado de cifrado, el drop event taggeado con la NetworkPolicy exacta que lo causó (atribución directa), el field mask API estabilizado, y la primera oleada de anomaly detection con ML aplicado a flows para predictive security en clusters IoT/5G. Y, lo más interesante para 2026: aparece una frontera nueva donde el mismo eBPF observa agentes de IA —Claude Code, Gemini CLI, agentes MCP— interceptando SSL/TLS y stdio sin instrumentar el código, lo que convierte el stack Cilium + Hubble + Tetragon + AgentSight en una pila completa para entender qué hace un sistema agentic dentro de un cluster.

Este artículo es la parte 3 de la serie sobre eBPF. Parte 1: eBPF de cero a Cilium: cómo el kernel aprendió a saltarse su propia pila TCP/IP. Parte 2: Tetragon: el primo de seguridad de Cilium que ve cada syscall en el kernel. Aquí completamos el cuadrante de observabilidad: red con Hubble, proceso con Tetragon, agente IA con AgentSight.

La analogía: tcpdump que habla Kubernetes

Si has administrado redes los últimos veinte años, tcpdump y Wireshark han sido el pan nuestro de cada día. Capturan paquetes en una interfaz, los parsean, te dejan filtrar con tcp.port == 443 and host 10.0.0.5. Funcionan, llevan funcionando desde los 90, y son lo primero que abres cuando algo huele raro.

Ahora pega tcpdump a un cluster Kubernetes de 10 000 pods. Los problemas saltan en orden:

1. Una sesión tcpdump por nodo. Querías “ver el tráfico entre el frontend y la API”; necesitas SSH a cada nodo, tcpdump por cada NIC, sincronizar timestamps, agregar a mano.
2. No hay contexto K8s. Ves un paquete de 10.244.5.7 a 10.244.8.42. ¿Qué pod era? ¿Qué namespace? ¿Qué label? Te toca correlar con kubectl get pod -A -o wide cada vez.
3. Sin entender L7. Ves un POST a HTTPS, no puedes saber qué método y path porque está cifrado en el cable. Si hay mTLS entre pods, peor.
4. Coste alto: captura completa de paquetes con copia a userspace ralentiza el datapath. En tráfico denso, lo notas.

Hubble es tcpdump rediseñado para todo eso. Reutiliza los programas eBPF que ya están procesando cada paquete (Cilium los pone ahí para enforcement) y, mientras toman su decisión de allow/deny, emiten un evento de flow con todo el contexto: identidad del pod origen y destino, namespace, labels, protocolo, verdict, y —si Cilium ha hecho parsing L7 vía Envoy— método HTTP, path, status code, DNS query, Kafka topic. Ese evento viaja por un ringbuffer a userspace, lo recibe el Hubble server que vive dentro del agent Cilium del nodo, y lo expone vía gRPC. Un servicio aparte, Hubble Relay, agrega los streams de todos los nodos y te da una única API cluster-wide. Por encima de eso: una CLI (hubble) y una UI web con grafo de servicios en tiempo real.

Cero copia adicional. Cero parsing duplicado. Y el resultado lo entiende cualquiera que sepa qué es un Pod.

Arquitectura: cuatro piezas que se ven desde fuera

Hubble se compone de cuatro componentes lógicos, todos opcionales según lo que quieras hacer:

1. Hubble Server (embedded en cada agent Cilium)

Vive dentro del proceso del agent Cilium (no es un binario aparte). Cada nodo expone localmente un endpoint gRPC en el socket Unix /var/run/cilium/hubble.sock. El server escucha los eventos que los programas eBPF emiten al ringbuffer, los enriquece con metadata Kubernetes (que el agent ya tiene en memoria), y los pone disponibles para consumidores.

Activación: --set hubble.enabled=true en el chart Helm de Cilium. Por defecto, el server solo es accesible localmente; si quieres consumirlo desde otro nodo, hace falta exponerlo (lo que hace Hubble Relay).

2. Hubble Relay (agregador)

Es un Deployment aparte (típicamente 1 réplica, escalable) que se conecta a todos los Hubble servers del cluster y agrega sus streams en una única API. Cuando tu CLI o UI pide “los últimos 1000 flows del cluster”, la Relay los recoge en paralelo de todos los nodos y devuelve la unión.

Activación: --set hubble.relay.enabled=true. Sin la Relay, solo ves el tráfico del nodo donde estás conectado, lo que es útil para debug local pero no para visión cluster-wide.

3. Hubble CLI (hubble)

Un binario en Go que habla gRPC con la Relay (o con un Hubble server local). Soporta dos modos principales:

• hubble observe: stream de flows en tiempo real, con filtros muy expresivos (por namespace, pod, port, verdict, protocolo, label).
• hubble status: estado del cluster Hubble (cuántos nodos conectados, lag, flow rate).

Y el equivalente a tcpdump’s pcap dump: hubble observe --output jsonpb > flows.json para procesar a posteriori con jq u otras herramientas.

4. Hubble UI

Frontend web que se conecta a Hubble Relay y muestra:

• Grafo de servicios en tiempo real (qué Pod habla con qué Service, qué protocolos usa, qué verdict).
• Lista de flows filtrable.
• Detalles L7 cuando los hay (HTTP method/path/status, DNS query/response).

Activación: --set hubble.ui.enabled=true. Útil para presentaciones a equipos no-CLI; no sustituye a la CLI para debug serio.

Qué se ve: el flow log de Hubble por dentro

Un flow de Hubble en formato JSON tiene aproximadamente esta forma (simplificado):

{
  "time": "2026-05-19T03:12:45.182Z",
  "verdict": "FORWARDED",
  "source": {
    "ID": 5482,
    "identity": 24871,
    "namespace": "prod-api",
    "labels": ["app=checkout", "team=payments"],
    "pod_name": "checkout-7c9f-x8j2",
    "workloads": [{"name": "checkout", "kind": "Deployment"}]
  },
  "destination": {
    "ID": 12041,
    "identity": 18356,
    "namespace": "prod-db",
    "labels": ["app=postgres", "tier=primary"],
    "pod_name": "postgres-0"
  },
  "Type": "L3_L4",
  "l4": {
    "TCP": {
      "source_port": 41982,
      "destination_port": 5432,
      "flags": {"SYN": true}
    }
  },
  "node_name": "rke2-worker-03",
  "Summary": "TCP Flags: SYN"
}

Cuando hay parsing L7 activo (vía Envoy embebido o el parser ligero de Hubble), el mismo flujo añade:

"l7": {
  "type": "REQUEST",
  "http": {
    "code": 200,
    "method": "GET",
    "url": "/api/v1/cart/items",
    "protocol": "HTTP/1.1",
    "headers": [{"key": "user-agent", "value": "checkout/1.4.2"}]
  }
}

Los protocolos soportados nativamente para parsing L7:

• HTTP/1.1 y HTTP/2 (incluyendo gRPC sobre HTTP/2).
• DNS (queries y responses, con domains, tipos, response codes).
• Kafka (topics, API keys).
• TLS handshake (SNI, no el payload cifrado por defecto).
• MySQL, Cassandra (con módulos opcionales).

Para HTTP y gRPC, Cilium puede activar el proxy Envoy embebido para los flujos que quieras inspeccionar (no todos; selectivo via CiliumNetworkPolicy con reglas L7). Sin Envoy hay parsing ligero pero menos detallado.

Verdict y atribución de drops

Cada flow tiene un verdict: FORWARDED, DROPPED, ERROR, AUDIT, REDIRECTED, TRACED, TRANSLATED. Para el caso DROPPED, Hubble incluye una razón estructurada (drop_reason) y, desde Cilium 1.19, la NetworkPolicy exacta que lo causó.

Esto último cambia la operativa. Antes, cuando un pod no podía hablar con otro, el flujo de debug era:

1. Ver el flow dropeado en Hubble.
2. Mirar todas las CiliumNetworkPolicy del namespace.
3. Razonar a mano cuál de ellas, con cuáles labels, lo está bloqueando.

Con la atribución de Cilium 1.19, el campo policy_match_info te dice directamente “lo dropeó la policy frontend-egress, regla 3”. Pasas de “Sherlock Holmes durante 20 minutos” a “kubectl get -o yaml de esa policy concreta”.

Métricas Prometheus y dashboards Grafana

Hubble también expone métricas agregadas en formato Prometheus, separadas del stream gRPC de flows. Activación: --set hubble.metrics.enabled=true (Helm) y enumeración del set que quieres exportar.

Los grupos de métricas habituales:

• flow: total flows por verdict, source/dest, protocolo.
• http: requests por método, código de respuesta, latencia (histograma).
• dns: queries, response codes, dominios top-N.
• tcp: handshakes, retransmisiones, ventana congestion.
• drop: drops por razón, con NetworkPolicy attribution.
• port-distribution: histograma de ports activos.
• policy: hits por policy y verdict.

Estas métricas tienen labels K8s ricos (source_workload, destination_workload, namespace, etc.) que las hacen pivotables en Grafana. Hay dashboards prebuilt en Grafana Labs que cubren los casos comunes; importar uno y tener visión inmediata cuesta cinco minutos.

Coste: las métricas con muchos labels K8s pueden explotar la cardinalidad en Prometheus. Para clusters grandes (>1 000 pods), conviene revisar qué set exportas y usar drop rules en Prometheus para limitar.

Despliegue: Helm en una pantalla

Instalación canónica de Cilium con Hubble completo:

# values.yaml
hubble:
  enabled: true
  metrics:
    enabled:
    - dns:query;ignoreAAAA
    - drop
    - tcp
    - flow
    - port-distribution
    - icmp
    - httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction
    serviceMonitor:
      enabled: true                # auto-discover por kube-prometheus-stack
  relay:
    enabled: true
    rollOutPods: true
  ui:
    enabled: true
    rollOutPods: true
    ingress:
      enabled: true
      className: cilium
      hosts:
      - hubble.example.local

Y la instalación:

helm upgrade --install cilium cilium/cilium -n kube-system -f values.yaml

Tras la instalación, valida con cilium status (CLI de Cilium) que la sección Hubble muestra OK, y prueba el primer flow con:

cilium hubble observe --namespace prod-api --pod checkout-7c9f-x8j2

Estado del arte en 2026

Cilium 1.19 se publicó en febrero de 2026 marcando el décimo aniversario del proyecto. Hubble alcanzó la versión 1.19.3 el 22 de abril de 2026. Las novedades relevantes:

Atribución directa de drops a NetworkPolicy

Ya cubierta arriba; es probablemente el cambio operacional más valioso del release. Cualquier flow dropeado lleva el nombre, namespace y regla específica de la policy responsable. Aplicable también vía métricas Prometheus, lo que permite alertas tipo “policy X está dropping >N peticiones/segundo”.

Tracing con IP options

Hubble puede ahora trazar paquetes individuales con IP options activado. Es un mecanismo similar al traceroute pero a nivel L3: pones una marca en el paquete y Cilium la reporta cada vez que el paquete atraviesa un nodo o una decisión de eBPF. Útil para debug de paths multi-cluster, fabric mesh, o NetworkPolicy que se aplican en distintas capas.

Filtrado por estado de cifrado

Nuevo flag en CLI: hubble observe --encryption-status=encrypted (o unencrypted). Útil para validar despliegues con WireGuard o IPsec activado pod-a-pod: confirmas que el tráfico que debería estar cifrado lo está, y detectas regresiones rápidamente.

Hubble field mask API estabilizado

El field_mask permite pedir solo las partes del flow que te interesan, reduciendo enormemente el ancho de banda y el procesamiento cuando solo necesitas, por ejemplo, source/dest y verdict. Antes era experimental, ahora está estable y es default-on en la CLI.

AI-driven anomaly detection (predictive security)

Esta es la incorporación más comentada de 2026. Cilium 1.19 añade hooks para que un consumer externo —típicamente un sistema ML— procese los flows en streaming y detecte anomalías estadísticas: pods que de pronto hablan con destinos nuevos, picos de latencia en una API, secuencias raras de DNS. La parte de detección ocurre fuera del agent Cilium (no se quiere ML pesado en el datapath), pero Cilium expone los flows con las features pre-calculadas que el modelo necesita. Los casos de uso publicados se enfocan en IoT y 5G donde el tráfico es alto en volumen y bajo en variedad, condiciones ideales para anomaly detection.

Escala a 10 000+ pods

Cilium 1.19 ha hecho trabajo serio en escalabilidad: Hubble Relay puede ahora agregar streams de cientos de nodos sin saturar; el field_mask por defecto reduce el ancho de banda inter-nodo; y los flows pueden samplearse en alta carga si tu uso es análisis estadístico (no debug forense).

Cilium 1.20 en desarrollo

Cilium 1.20 está en branch de desarrollo. Lo más relevante para Hubble:

• Unificación de preferIpv6: el flag hubble.preferIpv6 se deprecó en favor del global preferIpv6 aplicable a todos los componentes Cilium.
• tetragon-python SDK: aunque es de Tetragon, no de Hubble, marca tendencia: políticas eBPF escritas en Python en lugar de YAML. Probablemente Hubble seguirá camino similar.

La nueva frontera: eBPF y los agentes de IA

Hasta aquí el contenido clásico de Hubble. Pero hay un giro 2026 que merece la pena cubrir porque cierra el círculo con la otra serie de este blog.

Cuando un cluster Kubernetes empieza a ejecutar agentes de IA —Claude Code, Gemini CLI, agentes basados en LangGraph que llaman APIs y MCP servers—, el problema de observabilidad cambia de forma. Ya no basta con saber “qué pod habló con qué pod” (eso es Hubble) ni “qué proceso ejecutó qué” (eso es Tetragon). Necesitas saber:

• A qué APIs externas está llamando el agente y con qué prompts.
• Qué herramientas MCP está invocando, con qué argumentos.
• Cuántos tokens consume, qué modelo elige, cuánto cuesta.
• Si el agente se desvía del comportamiento esperado (out-of-policy queries, intentos de jailbreak, leakage de secretos).

Las soluciones tradicionales —instrumentar el código del agente con OpenTelemetry, parsear logs estructurados— no funcionan bien cuando el agente es un binario de terceros (Claude Code de Anthropic, Gemini CLI de Google) o cuando los MCP servers viven en otros lenguajes con stdio como transport.

AgentSight: zero-instrumentation para agentes LLM

AgentSight (proyecto del grupo eunomia-bpf, mismo ecosistema de varios runtimes eBPF de alto perfil) ataca este problema con la misma filosofía que Hubble: no instrumentes; escucha. Pone hooks eBPF en dos puntos críticos:

1. uprobes en bibliotecas SSL/TLS (libssl, boringssl, rustls). Captura el plaintext antes del cifrado en send y después del descifrado en recv. Para una llamada HTTP a https://api.anthropic.com/v1/messages, AgentSight ve el JSON completo del prompt y la respuesta sin descifrar nada en transit, simplemente porque ha llegado al nivel del syscall antes de que la TLS layer haga su trabajo.

2. stdiocap BPF: captura read, write, dup sobre los file descriptors de stdin/stdout/stderr de un proceso. Esto es lo que permite observar MCP servers que hablan stdio con su cliente —el patrón habitual de los servers MCP locales—. Capturas el JSON-RPC que va y viene sin que ni el cliente ni el server lo sepan.

Sobrecarga reportada: <3% CPU, comparable a Hubble en su régimen.

Cómo encaja con Hubble y Tetragon

Los tres se complementan limpiamente:

• Hubble te dice: “el pod del agente abrió conexión TCP a api.anthropic.com:443 con verdict ALLOW”.
• Tetragon te dice: “el proceso claude-code con PID 1843 hizo connect() a esa IP” (más el binario, los argumentos, el namespace de pod).
• AgentSight te dice: “el contenido HTTPS de esa conexión era un prompt messages=[{role:'user', content:'analyze this repo and modify the firewall config'}] y la respuesta incluyó una tool call a read_file con argument /etc/passwd”.

Es la diferencia entre flujo, proceso y semántica. Para un equipo de seguridad que quiera vigilar agentes de IA en producción, los tres son necesarios. Para alguien que quiera entender el coste, los tres son útiles (Hubble para latencia de red, Tetragon para uso de recursos, AgentSight para tokens y modelo elegido).

Casos de uso emergentes

Los patrones que se están consolidando en 2026:

• Audit trail de agentes: registrar cada llamada a LLM y cada tool call para compliance (sobre todo en sectores regulados).
• Detección de jailbreak y prompt injection: aplicar reglas sobre los prompts capturados por AgentSight (similar a las TracingPolicy de Tetragon, pero sobre contenido semántico).
• Cost accountability: ver qué team/agente consume qué tokens, sin instrumentar.
• Replay y debug: reproducir el reasoning de un agente en producción sin pedirle que vuelva a ejecutar (que es no-determinístico).

Es un campo joven —AgentSight tiene meses, no años— pero el patrón “eBPF como observabilidad zero-instrumentation” está clarísimamente extendiéndose más allá de red y proceso. El próximo año va a ver consolidación y, probablemente, integración nativa con Hubble.

Casos de uso habituales de Hubble

Volviendo a Hubble propiamente, los casos en los que cualquier organización lo despliega:

1. Debug de NetworkPolicy

El uso clásico: “este pod no llega a este Service”. Sin Hubble, tocaba SSH, tcpdump, comparar reglas. Con Hubble:

hubble observe --from-pod prod-api/checkout --to-pod prod-db/postgres --verdict DROPPED

Si hay drops, ves la policy responsable (Cilium 1.19+). Si no hay drops, el problema no es policy: es DNS, routing o el target service.

2. Audit de comunicación inter-namespace

Para compliance: validar que namespaces aislados no están comunicándose contra lo declarado.

hubble observe --from-namespace prod-payments --to-namespace 'NOT prod-db' --output json

3. Detección de exfiltración

Tráfico saliente a destinos públicos sospechosos. Hubble los detecta por IP/SNI, no por payload (que está cifrado):

hubble observe --to-fqdn 'NOT *.example.com' --to-fqdn 'NOT *.internal' --protocol tcp

Combinado con métricas Prometheus y alertas en Grafana, esto da un radar de exfiltración a coste cero.

4. SLO de servicio en tiempo real

Métricas hubble:http:response_time_seconds con labels source_workload, destination_workload, method, status_code permiten dashboards SLO sin necesidad de instrumentar las apps. El SRE ve la latencia p95 de checkout → catalog directamente.

5. Performance debugging

hubble:tcp:retransmissions_total y hubble:tcp:flags_total{flag="RST"} son señales tempranas de problemas de red. Una subida correlada con regresión de latencia te apunta a algo en infraestructura (NIC, switch, MTU) antes de bajar a investigar la app.

6. Forensics post-incidente

Configurar Hubble para exportar flows a almacenamiento persistente (vía OTLP a Tempo/Loki, o hubble observe --output jsonpb a S3) te da capacidad forense: si en T+30 días detectas que algo iba mal en T, puedes reconstruir el tráfico.

Hubble y el resto del stack de observabilidad

Hubble no reemplaza Prometheus, Loki, Tempo ni Jaeger; los complementa:

• Prometheus: recibe las métricas agregadas de Hubble. Hubble exporta endpoint Prometheus nativo.
• Loki: recibe los flow logs estructurados si los exportas como logs. Hubble no tiene exporter nativo a Loki, pero un Fluent Bit con plugin OTLP o uno custom hace el puente fácilmente.
• Tempo / Jaeger: el Cilium Operator tiene exportador OTLP de flows en formato traces (cada flujo HTTP/gRPC es un span). Integra con Tempo o cualquier otro tracing backend OTLP.
• Grafana: ya hay dashboards públicos de Hubble. Combinados con Prometheus, Loki y Tempo, te dan un panel unificado: métricas, logs, traces, todo correlado por labels K8s.

La pila full-stack que se ve en producción 2026 (descrita en Building a Production eBPF Observability & Security Stack for Kubernetes in 2026):

• Datos: Cilium + Hubble (red), Tetragon (proceso), AgentSight (agente IA).
• Pipeline: OTLP Collector como router único.
• Almacenamiento: Prometheus (métricas), Loki (logs), Tempo (traces).
• UI: Grafana con dashboards específicos por dominio.
• Alerting: AlertManager con reglas sobre las métricas Hubble + Tetragon.

Comparativa con alternativas

Si tu CNI es Cilium, Hubble es el punto de entrada natural y no compite con los demás: complementa. Para clusters Calico, Whisker es el equivalente. Para profiling, Parca. Para agentes IA, AgentSight. La era del “una herramienta para todo” está pasando: la pila moderna combina varias piezas especializadas, todas basadas en eBPF, expuestas vía OTLP.

Trampas operativas

Cardinalidad en Prometheus

Las métricas Hubble con todos los labels K8s pueden explotar Prometheus. Mide la cardinalidad antes de exportar todo. Las métricas más prolíficas son flow y httpV2; empieza por drop y port-distribution y añade el resto incrementalmente.

L7 visibility cuesta CPU

Activar parsing L7 vía Envoy embebido añade carga al agent (no al datapath base, pero sí al envoy proxy del nodo). Para tráfico HTTP intenso, mide. Para flujos donde solo necesitas L4, deja Envoy desactivado.

Hubble Relay sin HA

Una sola réplica de Relay es un single point of failure para CLI y UI (no para el agent local, que sigue funcionando). Para producción, deploy con replicas: 2+ y topologySpreadConstraints para que no caigan ambas.

Encryption status reporting depende de Cilium config

El nuevo filtro --encryption-status solo da datos reales si Cilium tiene encryption activado (WireGuard o IPsec). Sin esto, todo es unencrypted y el filtro no aporta.

UI expuesta sin auth

Hubble UI no tiene auth nativa. Si la expones por Ingress, delante tiene que haber autenticación: OIDC vía oauth2-proxy, mTLS, IP allowlist. No es opcional.

Storage no escalado

Si guardas flows durante días para forensics, el volumen es serio. Para un cluster de 100 pods activos, fácilmente 1-10 GB/día de flow logs. Plantea el ciclo de vida (compactación, retención, cold storage) antes de habilitarlo.

Lo que no hemos cubierto

• Mesh / multi-cluster Hubble: agregar flows de varios clusters Cilium en una sola Relay. Caso de uso: visión cross-cluster, debug de service mesh distribuido.
• hubble export: persistencia local en disco del agent para forensics con baja retención.
• Anomaly detection con modelos propios: cómo conectar el stream gRPC a un consumer ML personalizado.
• AgentSight en profundidad: el proyecto merece su propio artículo. Próxima entrega.
• eBPF para profiling de LLM serving: cómo medir TTFT, TPOT y throughput de vLLM sin instrumentar, usando uprobes en libcudart.

Referencias

Hubble y Cilium:

• Hubble GitHub — repo principal.
• Hubble — Network Observability (Cilium docs) — referencia oficial.
• Cilium 1.19 release notes (InfoQ, feb 2026) — décimo aniversario y novedades 1.19.
• Cilium releases — todos los releases.
• Hubble L7 HTTP Metrics — Grafana dashboard 19423 — listo para importar.
• End‑to‑end L7 Visibility with Cilium Hubble (cloud-cod.com, mar 2026).
• Cilium Hubble Observability Platform Internal Analysis (Young-ju).
• CiliumNetworkPolicy Python Hubble: L7 Visibility 2026 — uno de los hilos del SDK Python.

Estado del arte 2026 y stack completo:

• Building a Production eBPF Observability & Security Stack for Kubernetes in 2026 (DEV).
• eBPF-Based Network Observability: Exploring Cilium Hubble and Alternatives (CloudRaft).

eBPF + agentes IA:

• AgentSight (GitHub eunomia-bpf) — el proyecto referenciado.
• Harnessing eBPF for High‑Performance LLM Workloads (Klizo Solutions).

Cross-references:

• Parte 1: eBPF de cero a Cilium.
• Parte 2: Tetragon: el primo de seguridad de Cilium.
• Serie de inferencia LLM: KV cache, vLLM en K8s, PagedAttention, Operators LLM K8s — donde el tráfico que Hubble observa lleva los prompts que AgentSight inspecciona.