← Volver al Blog
Arquitectura 30 de julio de 2026 · 7 min de lectura

Cómo los agentes de IA acceden a infraestructura privada de forma segura

Servidores MCP, agentes Docker y bots de CI/CD necesitan acceder a bases de datos y APIs privadas. wzctl les proporciona un túnel WebSocket efímero — sin cliente VPN, sin NET_ADMIN.

El problema

Los agentes de IA van más allá del chat. Los servidores MCP de Claude consultan tu base de datos de producción para responder preguntas. Los agentes de GitHub Copilot ejecutan migraciones contra staging. Bots personalizados extraen métricas de APIs internas. Estos agentes necesitan acceso de red a infraestructura privada — bases de datos, APIs REST, clústeres de Kubernetes — que está detrás de firewalls sin endpoint público.

El reto: estos agentes se ejecutan en contenedores efímeros sobre infraestructura compartida. No tienen configuración de red persistente. Se levantan, hacen su trabajo y desaparecen.

Por qué los enfoques tradicionales fallan

  • Las VPN requieren NET_ADMIN — los runtimes de contenedores (Docker, pods de Kubernetes, sandboxes en la nube) no conceden esta capacidad. No puedes crear una interfaz WireGuard u OpenVPN dentro de un contenedor estándar.
  • Las credenciales se filtran — incrustar cadenas de conexión a bases de datos en las configuraciones del agente significa que persisten en logs, memoria, y potencialmente en la ventana de contexto del LLM.
  • Sin limitación temporal — una configuración VPN o clave SSH otorga acceso permanente. Si un agente se ve comprometido, el atacante tiene un túnel persistente a tu red.
  • Sin granularidad de auditoría — no puedes saber qué sesión de agente accedió a qué recurso, ni revocar una sesión individual sin rotar credenciales compartidas.

La solución: wzctl

wzctl es un binario en espacio de usuario que crea un túnel WebSocket cifrado hacia el broker de WireZTNA. Sin interfaz de kernel, sin NET_ADMIN, sin dispositivo TUN. Expone un puerto TCP local que reenvía a un host:puerto específico en la red privada.

El flujo:

  • Regístrate con wzctl register (self-service, sin portal)
  • Genera un token de publisher con wzctl token --cidrs
  • Enrolla el publisher en el servidor privado
  • El agente ejecuta wzctl connect --daemon para abrir un puerto local
  • Cuando el TTL expira, el túnel se cierra — sin acceso residual

Paso 1: Setup (una vez)

Regístrate y genera un token de publisher:

# Registro (free tier)
wzctl register --broker https://freetier.wireztna.com --email tu@ejemplo.com --save

# Generar token de publisher
wzctl token --broker https://freetier.wireztna.com --cidrs "10.0.2.0/24" --name mi-db-server

# En el servidor privado: enrollar publisher
sudo ./wireztna-publisher install --token "<url_de_wzctl_token>"
sudo systemctl start wireztna-publisher

Paso 2: Conectar desde el agente

Dentro del contenedor del agente, ejecuta wzctl connect en modo daemon:

# Conectar — abre localhost:5432 tunelizado a 10.0.2.30:5432
wzctl connect --broker https://freetier.wireztna.com \
  --publisher <publisher_id> \
  --target 10.0.2.30 --port 5432 \
  --ttl 30m --local-port 5432 --daemon &

Ahora el agente puede conectarse a localhost:5432 como si la base de datos fuera local:

# Desde la perspectiva del agente, es simplemente un PostgreSQL local
psql -h localhost -p 5432 -U readonly -d analytics

Paso 3: Uso en CI/Docker

Para agentes en contenedores o CI runners:

# En un step de GitHub Actions
- name: Conectar a BD privada
  run: |
    curl -fsSL https://wireztna.com/dl/wzctl-linux-amd64 -o wzctl
    chmod +x wzctl
    ./wzctl connect --broker "$WIREZTNA_BROKER" \
      --publisher "$PUBLISHER_ID" \
      --target 10.0.2.30 --port 5432 \
      --ttl 10m --local-port 5432 --daemon &
    sleep 2
    psql -h localhost -p 5432 -U readonly -d analytics

Sin --privileged, sin --cap-add NET_ADMIN, sin host networking. Se ejecuta completamente en espacio de usuario.

Modelo de seguridad

  • Tiempo limitado — los pases expiran después del TTL configurado (por defecto: 1 hora). El túnel se termina automáticamente.
  • Alcance host:puerto — un pase otorga acceso a exactamente un destino. El agente no puede pivotar a otros hosts en la red privada.
  • Revocación automática — si el orquestador detecta un problema, puede revocar el pase vía API. El túnel se cierra inmediatamente.
  • Auditoría completa — cada conexión se registra con el ID del pase, etiqueta del agente, IP de origen, bytes transferidos y duración. Sabes exactamente qué sesión de agente tocó tu base de datos.
  • Sin credenciales almacenadas — el token del pase es efímero. No es una contraseña ni una clave — es una autorización de un solo uso con alcance definido que no puede reutilizarse tras la expiración.

Patrones del mundo real

Servidor MCP de Claude consultando una base de datos

Tu servidor MCP se inicia, solicita un pase de acceso para la BD de analytics, se conecta vía wzctl y sirve consultas a Claude. Cuando la sesión termina, el pase expira y el túnel se cierra.

GitHub Actions desplegando en un clúster privado

Un paso del workflow genera un pase para el servidor API de K8s (puerto 6443), se conecta vía wzctl, ejecuta kubectl apply, y el pase se auto-revoca al completarse el job.

Cron job extrayendo métricas

Un agente programado solicita un pase de 5 minutos a la API de Prometheus, extrae los datos que necesita y se desconecta. Sin acceso residual entre ejecuciones.

Resumen

Los agentes de IA necesitan acceso de red a infraestructura privada, pero se ejecutan en entornos donde las VPN no funcionan. wzctl resuelve esto con túneles efímeros, con alcance definido y auditables que no requieren privilegios de kernel. Tus agentes obtienen exactamente el acceso que necesitan, durante exactamente el tiempo que lo necesitan — y nada más.

Más información sobre wzctl →