Límites de red para agentes de IA con NGINX y OpenTelemetry en Kubernetes

Introducción

En un taller de Kubernetes Community Days (KCD) 2026, un operador mencionó que su equipo no implementaría agentes de IA en su red porque «no saben qué hace realmente esa cosa». La preocupación es válida: los agentes autónomos pueden automatizar tareas críticas, pero su autonomía introduce riesgos operativos y de seguridad difíciles de cuantificar. Por ejemplo, un agente que ejecute comandos curl o acceda a APIs internas sin supervisión puede filtrar datos sensibles, consumir recursos no autorizados o incluso ejecutar acciones maliciosas si es comprometido.

La solución no requiere infraestructura nueva, sino combinar dos componentes maduros y omnipresentes en entornos cloud-native: NGINX como plano de control de tráfico y OpenTelemetry como plano de auditoría. Este diseño crea un perímetro de red observable donde se aplican reglas de traffic shaping granulares, sin depender de la buena voluntad del agente. En este artículo, desglosamos cómo implementarlo en Kubernetes, qué métricas recopilar y cómo integrarlo con herramientas como Jaeger, Grafana o un SIEM.

Qué ocurrió

El autor del proyecto OpenClaw —un framework para agentes de IA autónomos— observó que, aunque existen guardrails para controlar la intención de los agentes, no hay patrones estandarizados para auditar y limitar su tráfico de red egress. La mayoría de las arquitecturas actuales asumen que el agente respetará las políticas de red, pero esto suele fallar en entornos productivos.

La propuesta presentada en el KCD Japan 2026 es usar NGINX como gateway doble:

1. Inbound: Actúa como reverse proxy, termina TLS y redirige solicitudes al agente.
2. Outbound: Funciona como forward proxy, obligando a todo el tráfico egress del agente a pasar por él.

Combinado con iptables, se bloquea cualquier otro tráfico de salida del pod, convirtiendo el perímetro en una propiedad arquitectónica, no en una política. La magia está en el módulo nativo de OpenTelemetry de NGINX, que emite un span por cada petición. Estos spans se envían a un OpenTelemetry Collector, que los persiste en un audit log o los reenvía a herramientas como Jaeger, Grafana o un SIEM.

El prototipo se desplegó en un cluster Kubernetes de un solo nodo con:

• NGINX (con el módulo OTEL)
• Ollama (servidor de modelos de lenguaje)
• OpenClaw (framework de agentes)
• OpenTelemetry Collector

El patrón es independiente de la infraestructura: funciona en edge devices, servidores enterprise o incluso en un Raspberry Pi con Kubernetes.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

• Reducción de superficie de ataque: Los agentes de IA suelen ejecutarse con permisos elevados (ej. pods con securityContext.runAsUser: 0 en Kubernetes). Un perímetro como este minimiza el riesgo de exfiltración de datos al limitar los destinos a los que puede acceder el agente. Por ejemplo, en el prototipo, solo se permitió tráfico a nginx.org y duckduckgo.com (ver configmap.yaml).

• Escalabilidad: NGINX es capaz de manejar hasta 500,000 solicitudes por segundo en hardware commodity (según benchmarks de F5 en 2025). En el caso de uso con agentes, el tráfico es esporádico pero crítico, por lo que el proxy no se convierte en un cuello de botella.

• Integración con herramientas existentes: NGINX Ingress Controller (NIC) y NGINX Gateway Fabric (NGF) heredan funcionalidades del NGINX core. Por ejemplo, la versión 1.15.0 de NIC (publicada en mayo 2026) incluye soporte experimental para forward proxy en modo egress. Esto significa que podés implementar este patrón sin cambiar tu infraestructura actual, solo actualizando los componentes.

Para equipos de Cloud y Seguridad

• Auditoría centralizada: OpenTelemetry emite spans en formato estándar (W3C Trace Context), compatibles con Jaeger, Grafana Loki o Splunk. En el prototipo, se midió que cada petición del agente generaba 3.2 MB de logs auditables por día (para un agente que realizaba 1,000 consultas diarias a APIs externas).

• Detección de anomalías: Los spans incluyen metadata como:

– http.target: URL destino.

– net.peer.name: IP o hostname remoto.

– user_agent.original: Identificador del agente (ej. OpenClaw/1.0.0).

Con esta información, podés construir reglas en Grafana o un SIEM para alertar si un agente:

– Accede a dominios no autorizados.

– Realiza más de X solicitudes por minuto a un mismo endpoint.

– Usa métodos HTTP no permitidos (ej. PUT en un endpoint de solo lectura).

• Compliance: Este diseño cumple con requisitos como PCI DSS 4.0 (sección 1.3.4: «Limitar el tráfico de red a sistemas críticos») o NIST SP 800-53 (CM-7: «Configuración mínima de servicios»). La documentación generada por OpenTelemetry sirve como evidence para auditorías.

Riesgos residuales

• Proxy como punto único de falla: Si NGINX cae, el agente no podrá acceder a recursos externos. Solución: Implementar NGINX en alta disponibilidad (ej. con un Deployment en Kubernetes y un PodDisruptionBudget que garantice al menos 2 réplicas).

• Latencia añadida: El tráfico pasa por dos capas de proxy (inbound y outbound). En pruebas con modelos de lenguaje locales (ej. Mistral 7B), el overhead fue de 12-18 ms por petición, medido con kubectl port-forward y curl --write-out. Para agentes que requieren baja latencia (ej. trading algorítmico), considerá usar un service mesh como Istio con egress gateways.

Detalles técnicos

Arquitectura del prototipo

[Agente OpenClaw] → [NGINX Reverse Proxy] → [Modelo Ollama]
      ↑                                      ↓
[OpenTelemetry Collector] ← [NGINX Forward Proxy]
      ↓
[Jaeger/Grafana/SIEM]

Componentes clave:

1. NGINX:

– Configuración base:

     # Forward proxy: solo permite tráfico a dominios autorizados
     server {
         listen 8080;
         location / {
             proxy_pass $upstream;
             proxy_set_header Host $host;
             allow nginx.org;
             allow duckduckgo.com;
             deny all;
         }
     }
     

– Para TLS, usa certificados gestionados por cert-manager (versión 1.14.4) con ACME (Let’s Encrypt).

1. OpenTelemetry Collector:

– Pipeline de procesamiento:

     # otel-collector-config.yaml
     receivers:
       otlp:
         protocols:
           grpc:
           http:
     processors:
       batch:
     exporters:
       jaeger:
         endpoint: "jaeger:14250"
       logging:
         loglevel: debug
     service:
       pipelines:
         traces:
           receivers: [otlp]
           processors: [batch]
           exporters: [jaeger, logging]
     

1. Kubernetes:

– NetworkPolicy aplicada al namespace openclaw:

     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: agent-egress-control
     spec:
       podSelector:
         matchLabels:
           app: openclaw-agent
       policyTypes:
       - Egress
       egress:
       - to:
         - podSelector:
             matchLabels:
               app: nginx
         ports:
         - protocol: TCP
           port: 8080
     

Vectores de ataque mitigados

1. Tasa de errores en egress:

   sum(rate(nginx_upstream_response_time_count{upstream=~".*"}[5m]))
   by (http_status, upstream)
   

– Umbral de alerta: >1% de errores 5xx en 5 minutos.

1. Latencia por dominio destino:

   # Grafana dashboard (promql)
   sum(rate(nginx_upstream_response_time_sum{upstream=~".*"}[5m]))
   by (upstream)
   /
   sum(rate(nginx_upstream_response_time_count{upstream=~".*"}[5m]))
   by (upstream)
   

1. Tráfico por agente:

     -- Consulta en Grafana con Loki
     {job="openclaw-agent"}
     | json
     | line_format "{{.http.target}}"
     

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Actualizar NGINX y compilar el módulo OpenTelemetry

1. Instalar NGINX 1.27.0 (o superior) con el módulo OTEL:

   # Instalar dependencias en Ubuntu 24.04 LTS
   sudo apt update && sudo apt install -y build-essential libssl-dev zlib1g-dev
   wget https://nginx.org/download/nginx-1.27.0.tar.gz
   tar -xzvf nginx-1.27.0.tar.gz
   cd nginx-1.27.0

   # Clonar y compilar el módulo
   git clone https://github.com/nginxinc/nginx-otel-module.git
   ./configure --add-module=nginx-otel-module
   make && sudo make install
   

1. Verificar la instalación:

   nginx -V 2>&1 | grep -o 'otel_module'
   # Debería imprimir: --add-module=nginx-otel-module
   

Paso 2: Configurar NGINX como reverse y forward proxy

1. Reverse proxy (inbound):

   # /etc/nginx/nginx.conf
   server {
       listen 443 ssl;
       server_name agent.company.com;
       ssl_certificate /etc/letsencrypt/live/agent.company.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/agent.company.com/privkey.pem;

       location / {
           proxy_pass http://openclaw:8000; # Destino del agente
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       }
   }
   

1. Forward proxy (outbound):

   # /etc/nginx/nginx-egress.conf
   server {
       listen 8080;
       resolver 8.8.8.8;

       location / {
           set $upstream $request_uri;
           proxy_pass $upstream;
           allow nginx.org;
           allow duckduckgo.com;
           deny all;
       }
   }
   

1. Habilitar el módulo OpenTelemetry:

   load_module modules/ngx_http_opentelemetry_module.so;

   http {
       opentelemetry_service_name "nginx-ai-agent";
       opentelemetry_collector "otel-collector.openclaw.svc.cluster.local:4317";
   }
   

Paso 3: Desplegar en Kubernetes

1. Crear un ConfigMap con las reglas de egress:

   # k8s/nginx-configmap.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: nginx-egress-rules
   data:
     nginx.conf: |
       # ... (configuración anterior)
   

1. Desplegar NGINX con Helm:

   helm repo add nginx-stable https://helm.nginx.com/stable
   helm install nginx-ai-agent nginx-stable/nginx \
     --namespace openclaw \
     --set controller.config.name=nginx-egress-rules \
     --set controller.extraContainers[0].name=otel-collector \
     --set controller.extraContainers[0].image=otel/opentelemetry-collector-contrib:v0.96.0
   

1. Aplicar NetworkPolicy para bloquear tráfico no autorizado:

   kubectl apply -f network-policy-egress.yaml
   

Paso 4: Configurar el pipeline de observabilidad

1. Desplegar Jaeger para trazas:

   helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
   helm install jaeger jaegertracing/jaeger \
     --namespace openclaw \
     --set collector.service.type=ClusterIP
   

1. Configurar OpenTelemetry Collector para exportar a Jaeger:

   # otel-collector-config.yaml
   exporters:
     jaeger:
       endpoint: "jaeger-collector.openclaw.svc.cluster.local:14250"
       tls:
         insecure: true  # Solo para entornos de prueba (usar cert-manager en prod)
   

1. Visualizar en Grafana:

– Configurar el origen de datos como Jaeger o Prometheus (para métricas de NGINX).

Paso 5: Validar y ajustar políticas

1. Probar el perímetro:

   # Ejecutar un agente de prueba que intente acceder a un dominio bloqueado
   kubectl exec -it openclaw-agent -- curl -v http://evil.site
   

– Debería devolver 403 Forbidden.

1. Ajustar reglas dinámicamente:

     # policy-egress.yaml
     apiVersion: kyverno.io/v1
     kind: ClusterPolicy
     metadata:
       name: restrict-agent-egress
     spec:
       validationFailureAction: enforce
       rules:
       - name: check-allowed-domains
         match:
           resources:
             kinds:
             - Pod
         validate:
           message: "El dominio {{request.object.spec.containers[0].env[?(@.name=='AGENT_EGRESS_ALLOWLIST')].value}} no está permitido."
           pattern:
             spec:
               containers:
               - env:
                 - name: AGENT_EGRESS_ALLOWLIST
                   value: "nginx.org,duckduckgo.com"
     

1. Monitorear con alertas:

     sum(rate(nginx_access_logs_total{status=~"403|404"}[1m])) by (http_host)
     > 0
     

Conclusión

Implementar un perímetro de red observable para agentes de IA no requiere herramientas exóticas, sino aprovechar lo que ya tenés en tu stack cloud-native: NGINX como puerta de enlace doble (inbound/outbound) y OpenTelemetry como sistema de auditoría. Este enfoque reduce el riesgo de exfiltración de datos, centraliza la observabilidad y se integra con herramientas como Jaeger, Grafana o SIEM, todo sin añadir complejidad innecesaria.

El patrón es replicable en cualquier entorno Kubernetes, desde un edge device hasta un cluster enterprise. Eso sí: recordá que esto es una capa más de defensa (defense-in-depth), complementaria a guardrails de aplicación, autenticación robusta y políticas de runtime security como Falco o Aqua Security.

Para empezar, revisá el repositorio openclaw-network-boundary, que incluye manifests de Kubernetes listos para desplegar. Si ya usás NGINX Ingress Controller o NGINX Gateway Fabric, actualizá a las últimas versiones (NIC 1.15.0+ o NGF 1.2.0+), ya que incluyen soporte nativo para el módulo OpenTelemetry.

FIN