Arquitectura de Red para Despliegues de Agentes de IA: Segmentación, Rendimiento y Conectividad Zero-Trust

Todo agente de IA en producción es, en esencia, un sistema conectado en red. El agente envía prompts a un LLM, consulta una base de datos vectorial, llama a APIs externas y devuelve resultados a un usuario — cada paso cruzando un límite de red. Sin embargo, las redes son la capa más subestimada en la infraestructura de agentes. Los equipos pasan semanas perfeccionando prompts y definiciones de herramientas, para luego desplegar en configuraciones VPC predeterminadas con timeouts estándar de balanceadores de carga y sin segmentación, preguntándose por qué los agentes se cuelgan, expiran o filtran datos.

La arquitectura de red para agentes de IA es distinta de la red tradicional de aplicaciones web. Los agentes mantienen sesiones de larga duración, generan patrones de tráfico explosivos e impredecibles, se comunican con docenas de endpoints externos y manejan datos con niveles de sensibilidad variables — todo dentro de un solo flujo de trabajo. La red debe soportar simultáneamente confiabilidad, rendimiento, seguridad y observabilidad, y las configuraciones predeterminadas diseñadas para servicios HTTP stateless fallarán en cada dimensión.

Esta guía cubre los patrones de arquitectura de red que requieren los despliegues de agentes en producción: modelos de segmentación para seguridad y cumplimiento normativo, optimización de latencia para tráfico de inferencia, gestión de egreso para agentes multi-API, integración de service mesh para comunicación multi-agente y los runbooks operativos para mantener redes de agentes saludables a escala.

Por Qué las Redes de Agentes Son Diferentes

Antes de sumergirnos en la arquitectura, es esencial entender cómo el tráfico de los agentes de IA difiere de las cargas de trabajo para las que fueron diseñados los diseños de red tradicionales.

Requisitos de persistencia de sesión. Un servidor web puede perder una conexión, y el cliente reintenta sin consecuencias duraderas. Un agente que pierde su conexión con un LLM a mitad de la inferencia pierde todo el contexto de razonamiento. El agente debe reiniciar la tarea desde cero, desperdiciando tokens y tiempo. Las conexiones de red de los agentes deben ser resilientes — no solo disponibles en el momento de la conexión, sino estables durante la duración de sesiones potencialmente largas que pueden durar minutos u horas.

Tráfico explosivo multidestino. El tráfico de red de un agente no sigue el patrón constante de solicitud-respuesta de un servidor API. Un agente puede estar en silencio durante 30 segundos mientras razona internamente, y luego emitir cinco llamadas API concurrentes — dos inferencias LLM, una búsqueda vectorial, una obtención web y una consulta a base de datos — todo en dos segundos. La red debe manejar estos estallidos sin demoras de encolamiento ni pérdida de paquetes, y debe hacerlo para cientos de agentes concurrentes.

Sensibilidad variable de datos. Durante una sola sesión, un agente puede procesar datos públicos, información interna propietaria y PII (información de identificación personal) de clientes. La red debe imponer límites de clasificación de datos en tiempo real — evitando que PII llegue a una API externa no aprobada mientras permite que el mismo agente acceda a un recurso web público. Esto no es un problema que resuelva la segmentación tradicional basada en IP.

Asimetría de egreso. Las aplicaciones web son predominantemente intensivas en ingreso — los clientes se conectan a los servidores. Los agentes son intensivos en egreso — se conectan hacia afuera a APIs LLM, bases de datos vectoriales y endpoints de herramientas. El ancho de banda de egreso puede exceder al de ingreso en una proporción de 10:1. Las redes diseñadas para tráfico intensivo en ingreso (con uplinks delgados y NAT gateways dimensionados para tráfico de clientes) se convertirán en un cuello de botella bajo cargas de trabajo de agentes.

La red es el sistema operativo del despliegue de agentes. Cada modo de fallo — timeout, fuga de datos, pico de costos, caída de sesión — se manifiesta primero como un problema de red antes de ser visible en cualquier otro lugar.

Segmentación de Red para Despliegues de Agentes

El Modelo de Tres Zonas

Los despliegues de agentes en producción se benefician de un modelo de segmentación de red de tres zonas que separa los planos de cómputo, inferencia y datos:

1. Zona de Ejecución de Agentes — Donde residen los runtimes de agentes, orquestadores y brokers de mensajes. Esta zona tiene egreso controlado hacia la zona de inferencia y hacia APIs externas aprobadas, pero sin ingreso directo desde internet. Los agentes en esta zona inician todas las conexiones.
2. Zona de Inferencia — Nodos GPU que ejecutan infraestructura de servidores de modelos (vLLM, TGI, Ollama). Esta zona no tiene acceso directo a internet y solo acepta conexiones entrantes desde la zona de ejecución de agentes. Los servidores de inferencia se conectan a registros internos de artefactos para descargas de modelos, pero no alcanzan redes externas.
3. Zona de Datos — Bases de datos vectoriales, bases de datos relacionales, almacenes de conocimiento y registros de conversación. Esta zona no tiene egreso directo a internet y principalmente responde a consultas desde la zona de agentes. El tráfico saliente solo se permite para dependencias internas explícitas como peers de bases de datos en la misma zona, DNS, endpoints de backup o replicación y servicios de gestión; cada destino debe nombrarse en la política en lugar de permitir egreso amplio a subredes.

Este modelo de tres zonas aplica el principio de mínimo privilegio a nivel de red. Un agente comprometido mediante un ataque de inyección de prompts no puede alcanzar las claves API de la zona de inferencia, no puede exfiltrar datos de la base de datos vectorial directamente, y solo puede comunicarse con servicios externos aprobados a través de un gateway de egreso supervisado.

NetworkPolicies de Kubernetes para Microsegmentación de Agentes

Dentro de cada zona, las NetworkPolicies de Kubernetes proporcionan segmentación a nivel de pod. Una política de ejemplo para aislar pods de agentes:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-isolation
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: agent-runtime
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: agent-orchestrator
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: agent-inference
    ports:
    - protocol: TCP
      port: 8000
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: agent-data
    ports:
    - protocol: TCP
      port: 6333
    - protocol: TCP
      port: 5432
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: agent-egress
      podSelector:
        matchLabels:
          app.kubernetes.io/name: egress-proxy
    ports:
    - protocol: TCP
      port: 3128
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

El detalle crítico: los pods de agentes no tienen acceso de egreso general. Un ipBlock amplio de rango privado no fuerza el uso de un proxy; simplemente permite esas IPs de destino. Las reglas de egreso de NetworkPolicy de Kubernetes son reglas de permiso L3/L4, por lo que la política debe permitir solo los servicios internos requeridos, los pods del proxy de egreso y DNS. La lista blanca de dominios y la inspección de prevención de pérdida de datos (DLP) ocurren luego en el proxy, extensión CNI o capa de service mesh antes de que el tráfico llegue a internet.

Service Mesh para Comunicación Agente-a-Agente

En arquitecturas multi-agente, los agentes se comunican entre sí, con orquestadores y con sistemas de evaluación. Un service mesh o dataplane consciente de identidad puede proporcionar identidad criptográfica de workloads y gestión de tráfico, pero las implementaciones difieren: Istio y Linkerd suelen usar sidecars o dataplanes de mesh, mientras Cilium usa un datapath eBPF y Envoy para funciones L7 configuradas, no un modelo de sidecar por pod.

• mTLS entre todos los servicios de agentes — Cada workload de agente seleccionado recibe una identidad criptográfica. La comunicación se autentica y cifra según la configuración del mesh o dataplane, sin gestión de certificados en el código de aplicación.
• División de tráfico para versionado de agentes — Despliega nuevas versiones de agentes en canary enrutando el 5% de las llamadas entre agentes a la nueva versión mientras se mantiene el 95% en la versión estable.
• Circuit breaking para fallos en cascada — Si el agente de evaluación es lento, el sidecar, punto de enforcement del dataplane, gateway o proxy de aplicación configurado falla rápidamente en lugar de permitir colas sin límite y presión de memoria.
• Control de acceso a nivel de mesh — Políticas como "solo el orquestador puede llamar al agente de evaluación" se aplican en el sidecar o punto de enforcement del dataplane, según el mesh. Cilium aplica controles mediante su datapath eBPF y Envoy integrado o por nodo cuando está configurado, no mediante un sidecar por pod.

Optimización de Latencia para Redes de Inferencia

Las Tres Fases de la Latencia de Inferencia

La red de inferencia LLM tiene tres fases distintas, cada una con diferente sensibilidad a las condiciones de la red:

Fase 1: Tiempo hasta el Primer Token (TTFT). El prompt debe transmitirse desde el agente al servidor de inferencia antes de que pueda comenzar la generación, pero la carga del prompt debe calcularse en bytes en la red, no en tokens de modelo por milisegundo. Si los logs del proxy muestran un cuerpo de solicitud serializado de 64 KB, la serialización a velocidad de línea en un enlace de 40 Gbps es de aproximadamente 13 microsegundos antes de RTT, congestión, framing TLS, colas, tokenización, prefill del modelo y delay del scheduler. La distancia de red sigue importando porque cada RTT, handshake y retransmisión se suma al TTFT visible para el usuario, pero un prompt de texto medido en kilobytes no debe modelarse como segundos de tiempo de transmisión del enlace.

Fase 2: Latencia entre Tokens (ITL). Una vez que comienza la generación, los tokens se transmiten de forma incremental. La ejecución del modelo normalmente domina la ITL, mientras que el jitter de red, la pérdida de paquetes o el buffering del proxy pueden crear pausas visibles en el flujo de salida. Mide esto como distribución de intervalos del stream en el cliente y en el proxy de egreso o ingreso, no solo como tiempo de tokens del servidor de modelos.

Fase 3: Entrega Total de la Respuesta. Después del último token, la respuesta completa debe entregarse al consumidor upstream del agente. Esta fase involucra la menor cantidad de datos (típicamente solo la finalización) y rara vez está limitada por la red.

Estrategias de Ubicación para Endpoints de Inferencia

Para inferencia auto-alojada, colocar servidores GPU cerca de los runtimes de agentes reduce RTT evitable, tránsito entre zonas y contención de fabric compartido. Trata la topología siguiente como un orden de preferencia de red y valídala con pruebas de carga para tu servidor de modelos, batch size, longitud de contexto y comportamiento de streaming:

• Mismo rack, mismo switch ToR — Menor distancia de red y menor contención entre racks. Práctico cuando la huella GPU cabe dentro de un dominio de fallo a nivel de rack.
• Mismo clúster, diferentes racks — Aceptable para muchas cargas si los uplinks de racks GPU se diseñan separados del tráfico general del clúster y de la replicación de almacenamiento.
• Misma región, diferentes AZs — Útil para aislamiento de fallos, pero añade latencia entre zonas y costos de transferencia de datos en la nube. Úsalo solo cuando los requisitos de disponibilidad justifiquen el intercambio.

Para inferencia basada en API, la estrategia es diferente ya que no se puede controlar la ubicación del servidor de inferencia. Las palancas clave son:

• Endpoints documentados por el proveedor — Para APIs públicas directas, usa los endpoints documentados por el proveedor, como https://api.openai.com/v1/... mostrado en la referencia de API de OpenAI y https://api.anthropic.com en la base documentada de Anthropic. No inventes hostnames regionales a menos que el proveedor los documente para ese producto. Si se requiere ubicación regional o residencia de datos, usa ofertas regionales soportadas como endpoints de recursos de Azure OpenAI, endpoints runtime regionales de Amazon Bedrock o ubicaciones de Google Cloud/Vertex AI.
• Multiplexación HTTP/2 — Una sola conexión TCP maneja múltiples solicitudes de inferencia concurrentes, eliminando la sobrecarga de establecimiento de conexión para cada llamada. Esencial para agentes que realizan llamadas de inferencia en paralelo.
• Ajuste de keepalive — Configura los timeouts de inactividad de conexiones API por encima del intervalo medido entre llamadas de inferencia en tu carga. El tráfico de agentes suele alternar entre períodos silenciosos de razonamiento y ráfagas de llamadas API, por lo que keepalives cortos en proxies o clientes pueden causar churn innecesario de TLS y TCP.

Planificación de Ancho de Banda para Tráfico de Inferencia

El ancho de banda de inferencia debe dimensionarse a partir de bytes serializados de solicitud y respuesta, no del número de parámetros del modelo. Un modelo de 70B parámetros afecta la memoria y el cómputo del servidor; los pesos del modelo no cruzan la red en cada llamada API. Para una llamada API solo de texto, calcula:

bytes de red por llamada = bytes del cuerpo de solicitud + bytes del cuerpo de respuesta + framing HTTP/TLS + headers

bytes por hora = cantidad de agentes × llamadas por tarea × tareas por hora × p95 de bytes de red por llamada

Si tu telemetría de proxy muestra un payload p95 de 64 KB por llamada de inferencia, entonces 100 agentes × 3 llamadas × 10 tareas × 64 KB = 192,000 KB/hora, o aproximadamente 0.43 Mbps sostenidos antes de margen para ráfagas. La misma carga puede crecer por órdenes de magnitud cuando los agentes adjuntan documentos, imágenes, salidas de herramientas, contexto de recuperación o logs verbosos, así que la planificación de capacidad debe usar bytes p95/p99 observados por endpoint y separar capacidad de ráfaga de throughput sostenido.

Para clústeres GPU, dedica capacidad de red de inferencia solo cuando las mediciones muestren contención con almacenamiento, carga de checkpoints, envío de logs o tráfico de gestión. La cantidad y velocidad correctas de NICs dependen de la ubicación del servidor de modelos, paralelismo tensorial o de pipeline, volumen de streaming y sesiones concurrentes; evita fijar una regla de NIC por GPU sin un benchmark de tu propio fabric.

Arquitectura de Egreso para Agentes Multi-API

Proxies de Egreso con Lista Blanca

El control de seguridad de red más crítico para los agentes de IA es el proxy de egreso. Sin él, cada agente tiene acceso de salida a internet sin restricciones — una vulnerabilidad de inyección de prompts se convierte en una autopista de exfiltración de datos.

El proxy de egreso se sitúa entre la zona de ejecución de agentes e internet, aplicando tres capas de filtrado:

1. Lista blanca de dominios — Solo se pueden alcanzar los dominios pre-aprobados. La lista blanca incluye endpoints de API LLM, endpoints SaaS de bases de datos vectoriales, APIs de herramientas aprobadas y registros internos de artefactos. Todo lo demás está denegado por defecto.
2. Inspección de contenido — Inspección del cuerpo HTTP en busca de patrones de datos sensibles (PII, claves API, credenciales). Si un agente intenta enviar datos sensibles a un endpoint externo, el proxy bloquea la solicitud y alerta al equipo de operaciones.
3. Limitación de ancho de banda por endpoint — Limitar la velocidad de egreso a cada proveedor de API según el nivel del agente. Un agente de producción puede tener permitidas 100 solicitudes por minuto a la API LLM, mientras que un agente de desarrollo recibe 10. Esto evita que agentes descontrolados agoten los presupuestos de API.

El error más común en la arquitectura de egreso de agentes es tratar todo el tráfico de API externa como equivalente. Un agente que llama a una API LLM, una API meteorológica y una API para compartir archivos representa tres perfiles de riesgo fundamentalmente diferentes que requieren diferentes políticas de inspección y limitación de velocidad.

Arquitectura de NAT Gateway para Escala de Agentes

Los clústeres Kubernetes que usan SNAT (Source Network Address Translation) para el egreso de agentes enfrentan un desafío bien conocido: agotamiento de puertos. Cada conexión saliente consume capacidad de puertos de origen, pero el límite es específico del proveedor y a menudo específico del destino. AWS NAT Gateway documenta 55,000 conexiones simultáneas por dirección IPv4 hacia cada tupla de destino única. Azure NAT Gateway documenta 64,512 puertos SNAT por dirección IP pública y escalado hasta 16 direcciones IP. Una carga con muchos agentes y muchas conexiones concurrentes es más riesgosa cuando esos flujos se concentran en el mismo destino de API, permanecen abiertos mucho tiempo o rotan más rápido de lo que permiten los temporizadores de reutilización de puertos.

Las soluciones de producción incluyen:

• Múltiples IPs NAT — Añadir IPs privadas secundarias, Elastic IPs, IPs públicas o prefijos de IP pública según el modelo de cuotas del proveedor, y monitorear métricas del proveedor para errores de asignación de puertos y paquetes descartados.
• Cilium Egress Gateway — Evita un NAT gateway de nube compartido para tráfico seleccionado de pods, pero sigue usando SNAT/masquerade en un nodo gateway de Cilium con una IP de egreso configurada, como describe la documentación de Cilium Egress Gateway. La capacidad está limitada por conntrack del nodo, disponibilidad de puertos de origen, concentración de destinos y diseño de dominios de fallo, así que pruébalo bajo el patrón de conexiones que tus agentes realmente generan.
• Nodos de egreso dedicados — Enrutar todo el egreso de agentes a través de nodos proxy dedicados con tablas NAT grandes y seguimiento de conexiones optimizado para sesiones de larga duración de agentes.

El problema de agotamiento de puertos es invisible durante el desarrollo y se convierte en el primer incidente de producción que enfrentan la mayoría de los despliegues de agentes. Planifícalo antes de salir a producción.

Observabilidad para Redes de Agentes

Qué Medir

La observabilidad de red estándar — rendimiento, pérdida de paquetes, latencia — es necesaria pero insuficiente para cargas de trabajo de agentes. Métricas adicionales son críticas:

• Distribución de duración de conexiones — Las conexiones de red de agentes pueden durar minutos. Rastrear la duración de conexiones P50/P95/P99 para detectar conexiones que están atascadas o con fugas.
• Cardinalidad de destinos de egreso — ¿Cuántos endpoints externos únicos contacta cada agente por sesión? Un aumento repentino puede indicar un agente comprometido que está probando sistemas externos.
• Taxas de reintento y timeout por destino — Rastrear timeouts por endpoint de API. Una base de datos vectorial que comienza a tener timeouts hará que todos los agentes que la usan fallen — esta es la alerta temprana de la red para la degradación de servicios downstream.
• Volumen de datos por agente por sesión — Un pico en los datos de egreso de un solo agente puede indicar exfiltración de datos o un agente descontrolado realizando miles de llamadas de inferencia.

Observabilidad Basada en eBPF

Las métricas tradicionales de SNMP o APIs de proveedores de nube carecen de la granularidad por-pod y por-conexión que necesitan las cargas de trabajo de agentes. Las herramientas de observabilidad basadas en eBPF (Cilium Hubble, Pixie, Parca) proporcionan:

• Tablas de conexión por pod — Ver cada conexión abierta desde cada pod de agente en tiempo real
• Visibilidad de tráfico a nivel DNS — Cada consulta DNS que realiza un agente se registra, revelando intentos de endpoints no autorizados
• Taxas de retransmisión TCP por agente — Detectar congestión de red que afecta a agentes específicos antes de que expiren
• Fallos de handshake TLS — Errores de certificado a nivel de agente que pueden indicar MITM o certificados vencidos en la ruta de egreso

La función de mapa de servicios de Hubble es particularmente valiosa para despliegues de agentes — descubre automáticamente con qué servicios se comunica cada agente, haciendo inmediatamente visible cuando un agente comienza a hablar con un nuevo endpoint que no estaba en su diseño.

Runbooks Operativos para Redes de Agentes

Agotamiento del Pool de Conexiones

Síntoma: Los agentes reportan "connection refused" o "cannot connect to LLM API" a pesar de que la API está saludable. Causa raíz: El gateway de egreso ha agotado su tabla de seguimiento de conexiones, típicamente porque los agentes abren demasiadas conexiones concurrentes. Solución: Aumentar el tamaño de la tabla de seguimiento de conexiones en el nodo de egreso: sysctl -w net.netfilter.nf_conntrack_max=2097152. Luego implementar pool de conexiones en el runtime del agente — reutilizar conexiones HTTP en lugar de abrir nuevas para cada llamada de inferencia.

Picos de Latencia de Inferencia

Síntoma: El TTFT aumenta de 2 segundos a 15 segundos para modelos auto-alojados. Causa raíz: Congestión de red en la VLAN de inferencia — típicamente por tráfico de envío de registros o respaldos que comparten el mismo segmento de red. Solución: Implementar QoS en los switches ToR, priorizando el tráfico de inferencia (DSCP AF41) sobre el tráfico de almacenamiento y gestión (DSCP AF11). Alternativamente, dedicar una NIC física separada en cada nodo GPU solo para tráfico de inferencia.

Alerta de Exfiltración de Datos

Síntoma: El proxy DLP detecta que un agente está enviando direcciones de correo electrónico de clientes a un endpoint no aprobado. Causa raíz: Un ataque de inyección de prompts engañó al agente para extraer datos de la base de conocimiento y reenviarlos a un servidor controlado por el atacante. Solución: Bloquea inmediatamente el dominio de destino en el proxy de egreso y detén o pon en cuarentena la sesión de agente afectada. Rota credenciales si pudieron exponerse secretos o datos de clientes. Revisa los registros históricos de conversación, herramientas y egreso que ya fueron capturados para determinar el alcance. Añade controles deterministas antes de reanudar tráfico: allowlists de destinos, wrappers de herramientas que rechacen envíos externos no aprobados, inspección DLP sobre egreso futuro y pruebas de política para la ruta de bypass. Actualiza el prompt del agente solo como capa conductual secundaria, no como mecanismo de enforcement.

Fallos de Resolución DNS para Endpoints de API

Síntoma: Errores intermitentes de "no such host" para dominios de API LLM, afectando al 10-20% de las llamadas de agentes. Causa raíz: El almacenamiento en caché DNS en el servicio DNS del clúster (CoreDNS) es demasiado agresivo, y el proveedor de API rota IPs más rápido que el TTL de la caché. Solución: Reducir el TTL de caché de CoreDNS para dominios externos: configurar CoreDNS con un TTL del plugin cache de 30 segundos para zonas externas, o usar un resolver DNS externo dedicado (ej., 8.8.8.8 o Cloudflare 1.1.1.1) mediante una política de reenvío.

La Red como Fundamento de la Infraestructura de Agentes

La arquitectura de red no es una preocupación secundaria en los despliegues de agentes — es el fundamento que determina si los agentes funcionan de manera confiable, se comunican de forma segura y escalan de manera predecible. El modelo de segmentación de tres zonas proporciona el límite de seguridad. La planificación de ubicación y ancho de banda garantiza el rendimiento de inferencia. La arquitectura de egreso con proxies de lista blanca previene la exfiltración de datos. Y la observabilidad basada en eBPF proporciona la visibilidad en tiempo real que requieren las operaciones de agentes.

Los despliegues de agentes más exitosos que hemos observado comparten una característica: el equipo de redes estuvo involucrado antes de que se desplegara el primer pod de agente. Para cuando los agentes estaban funcionando en producción, la red ya estaba configurada para patrones de tráfico específicos de agentes — no adaptada de configuraciones predeterminadas de aplicaciones web.

Comienza con segmentación, invierte en controles de egreso, planifica el agotamiento de puertos e instrumenta cada conexión. Tus agentes funcionarán más rápido, fallarán con menos frecuencia y operarán dentro de límites de seguridad que hacen de la inyección de prompts un riesgo manejable en lugar de una vulnerabilidad catastrófica.

En la era de los agentes de IA autónomos, la red no es solo plomería — es el punto de aplicación de la seguridad, el punto de medición del rendimiento y el primer indicador de problemas operativos. Diséñala en consecuencia.

Conclusión

La arquitectura de red para agentes de IA requiere un cambio fundamental en cómo pensamos sobre la conectividad. La red tradicional de aplicaciones web — centrada en ingreso, stateless, a nivel HTTP — es insuficiente para agentes que mantienen sesiones largas, generan tráfico explosivo multidestino y manejan datos de sensibilidad variable dentro de un solo flujo de trabajo.

Los tres principios que guían el diseño de redes de agentes en producción son: segmentar agresivamente (zonas de inferencia, ejecución y datos sin conectividad innecesaria), controlar el egreso estrictamente (proxies de lista blanca con inspección de contenido y limitación de velocidad), y observar todo (visibilidad de conexiones por-pod basada en eBPF como línea base mínima).

Los despliegues que siguen estos principios reportan consistentemente menos incidentes de producción, tiempos de resolución más rápidos y mayor confianza al desplegar agentes que interactúan con sistemas externos. La red es la heroína no reconocida de la infraestructura de agentes en producción — préstale la atención que merece.