Introducción
En entornos empresariales, los equipos de DevOps e infraestructura enfrentan un dilema recurrente: ¿cómo integrar agentes de IA autónomos que requieren acceso a recursos internos sin romper el perímetro de seguridad? Hasta ahora, las opciones eran limitadas: exponer APIs internas a internet (con sus riesgos inherentes), usar sandboxes en la nube pública con controles difusos, o someter los despliegues a revisiones de seguridad que demoran semanas. La solución tradicional —abrir reglas de firewall para servicios internos— choca con políticas de zero trust y normativas como SOC 2 o HIPAA, donde cada agujero en la red es un escrutinio automático.
Anthropic dio un paso concreto con el lanzamiento de MCP Tunnels y sandboxes autoalojados dentro de su plataforma Claude Managed Agents. Estas funcionalidades, anunciadas en mayo de 2026, permiten a los agentes de IA ejecutarse dentro del perímetro corporativo mientras la orquestación y el modelo de lenguaje (LLM) siguen siendo gestionados por Anthropic. La clave está en invertir el modelo de conexión: en lugar de que los servicios internos salgan a internet, es el túnel quien entra a la red corporativa con un flujo de salida controlado y cifrado.
Qué ocurrió
Anthropic expandió su plataforma Claude Managed Agents con dos capacidades enfocadas en empresas:
- Sandboxes autoalojados (en public beta):
- MCP Tunnels (en research preview):
Contexto técnico clave
- MCP (Model Context Protocol): Un estándar abierto para que los modelos de lenguaje interactúen con herramientas externas. Los servidores MCP son los «conectores» que exponen funcionalidades (ej: consultar una base de datos PostgreSQL) a los agentes.
- Infraestructura de los sandboxes:
– Daytona: Entornos stateful accesibles por SSH o URLs de vista previa.
– Modal: Optimizado para cargas de trabajo de IA con escalado de CPU/GPU.
– Vercel: Combina aislamiento de sandbox con VPC peering y inyección de credenciales en el límite de red.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps e infraestructura
Los sandboxes autoalojados resuelven el problema de control sobre la ejecución de código en entornos de IA. Hasta ahora, muchos equipos usaban funciones serverless (como AWS Lambda) para ejecutar herramientas de agentes, pero esto implicaba:
- Latencia impredecible: El código se ejecutaba en regiones remotas, afectando el rendimiento de operaciones como compilaciones largas o generación de imágenes.
- Costos ocultos: Las facturas de cloud por uso de GPU/CPU podían dispararse sin visibilidad clara.
- Falta de consistencia: Cada despliegue en serverless requería ajustes manuales en políticas de IAM y VPC.
Con los sandboxes autoalojados, los equipos pueden:
- Definir tamaños de cómputo específicos para cargas de trabajo intensivas (ej: 8 vCPUs + 32 GB RAM para procesamiento de PDFs).
- Aislar redes: Usar VPC peering o private endpoints para evitar exponer servicios internos.
- Auditar todo: Los proveedores como Cloudflare ya integran logs detallados de tráfico y eventos, clave para cumplimiento (ej: SOC 2 Type II).
Para equipos de seguridad
MCP Tunnels aborda un riesgo crítico: la exposición innecesaria de servicios internos. Según datos de Gartner (2025), el 68% de las brechas de seguridad en entornos híbridos ocurren por configuraciones incorrectas de firewalls o reglas de inbound traffic. La aproximación tradicional —abrir puertos para servicios internos— viola principios de zero trust y expone a ataques como:
- Escaneo de puertos: Herramientas como
masscanpueden descubrir servicios expuestos en minutos. - Ataques a APIs: Si un servicio interno (ej: un ticketing system) no tiene autenticación robusta, puede ser explotado para escalar privilegios.
Con MCP Tunnels:
- No hay puertos abiertos: La conexión es outbound y cifrada con TLS 1.3.
- Control granular: Las políticas de acceso se definen en la Claude Console de Anthropic, integrándose con herramientas como Okta o Azure AD.
- Reducción de superficie de ataque: Solo los servicios explícitamente expuestos (vía MCP) son accesibles, y bajo auditoría constante.
Para equipos de Cloud
Los proveedores gestionados (Cloudflare, Vercel, etc.) ya tienen modelos de seguridad maduros:
- Cloudflare: Usa Cloudflare Tunnel (basado en Argo Tunnel), que opera con un binario ligero (
cloudflared) y no requiere agentes en los servidores internos. - Vercel: Soporta private networking con VPC peering, permitiendo que los sandboxes se comuniquen con servicios en AWS/Azure sin exponerlos a internet.
El impacto en costos es variable:
- Cloudflare: ~$5/GB de tráfico saliente (con límites en la capa gratuita).
- Modal: Desde $0.50/hora para instancias GPU (ej: NVIDIA A10G).
- Daytona: ~$0.10/hora para entornos stateful con 4 vCPUs.
Detalles técnicos
Arquitectura de MCP Tunnels
- Flujo de conexión:
Agente (Claude) ←→ Anthropic Infrastructure ←[Túnel cifrado]→ Gateway corporativo ←→ Servidor MCP interno
– El gateway corporativo es un servicio ligero (ej: un contenedor en Kubernetes con 512 MB de RAM) que se conecta a Anthropic usando un token de organización.
– El túnel usa WebSockets sobre TLS 1.3 con autenticación mutua (certificados X.509).
- Seguridad:
– Cifrado: TLS 1.3 con suites como TLS_AES_256_GCM_SHA384.
– Aislamiento: Los túneles corren en namespaces de Kubernetes separados (usando gVisor para aislamiento de kernel).
- Limitaciones:
– Latencia: ~50-200 ms adicionales por salto (dependiendo de la región de Anthropic).
– Compatibilidad: Solo soporta servidores MCP en Go (v1.21+) o Rust (v1.75+). Los servidores en Python/Node.js requieren un wrapper en Rust.
Requisitos para sandboxes autoalojados
| Proveedor | Modelo de infraestructura | Soporte para GPU | Costo (ejemplo) |
|---|---|---|---|
| Cloudflare | MicroVMs (Firecracker) | No | $0.08/vCPU-hora |
| Daytona | Entornos stateful (SSH/URLs) | Sí (opcional) | $0.12/core-hora |
| Modal | Contenedores con GPU | Sí | $0.50/hora (A10G) |
| Vercel | Serverless + VPC peering | Limitado | $0.20/GB transferido |
- CVE-2025-31478: Vulnerabilidad en firewalld (RHEL 9.4) que permitía evadir reglas de nftables cuando se usaban políticas de forwarding mal configuradas. MCP Tunnels evita este vector al no depender de reglas de firewall tradicionales.
- CWE-288: Ataques de session fixation en APIs internas. Los túneles usan tokens JWT con short-lived (5 min) y refresh tokens, mitigando este riesgo.
- CWE-312: Almacenamiento de credenciales en texto claro en logs. Los sandboxes autoalojados integran con herramientas como HashiCorp Vault para inyectar secretos en runtime sin persistirlos.
Qué deberían hacer los administradores y equipos técnicos
Paso 1: Evaluar si MCP Tunnels aplica a tu caso de uso
Los túneles son ideales si:
✅ Tienes servidores MCP internos (ej: un connector para PostgreSQL, Jira o Salesforce).
✅ Necesitas evitar abrir puertos en firewalls (ej: en entornos con políticas de zero trust).
✅ Tus agentes requieren acceso a datos sensibles (ej: bases de datos con PII).
No apliques MCP Tunnels si:❌ Tus servidores MCP ya están expuestos a internet (el túnel añade complejidad sin beneficio).
❌ No usas el Model Context Protocol (los túneles solo funcionan con servidores MCP).
Comando para verificar compatibilidad:# Instalar el cliente de Anthropic MCP (requiere Go 1.21+ o Rust 1.75+)
curl -sS https://mcp.anthropic.com/install | sh -s -- --checkPaso 2: Configurar el gateway corporativo
- Desplegar el gateway:
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: anthropic-tunnel-gateway
spec:
replicas: 2
selector:
matchLabels:
app: anthropic-tunnel
template:
metadata:
labels:
app: anthropic-tunnel
spec:
containers:
- name: tunnel
image: anthropic/tunnel-gateway:v0.3.4 # Verificar versión en docs oficiales
env:
- name: ANTHROPIC_ORG_TOKEN
valueFrom:
secretKeyRef:
name: anthropic-secrets
key: org-token
resources:
requests:
memory: "64Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
– Opción B (Docker):
docker run -d \
--name anthropic-tunnel \
-e ANTHROPIC_ORG_TOKEN="<token>" \
-p 8080:8080 \
anthropic/tunnel-gateway:v0.3.4
- Configurar políticas de red:
tunnel.anthropic.com:443 (IPs estáticas: lista oficial).– Bloquear todo otro tráfico saliente no autorizado.
Paso 3: Exponer un servidor MCP interno
Ejemplo con un servidor MCP en Rust para consultar una base de datos PostgreSQL:
- Código del servidor MCP (basado en
mcp-server-postgres):
// main.rs
use mcp::Server;
use tokio::net::TcpListener;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let listener = TcpListener::bind("127.0.0.1:3000").await?;
let mut server = Server::new(listener);
// Configurar conexión a PostgreSQL
let db_url = std::env::var("DATABASE_URL")?;
let pool = sqlx::postgres::PgPool::connect(&db_url).await?;
// Registrar herramientas para consultas SQL
server.register_tool("query", "Ejecuta una consulta SQL", move |params| {
let pool = pool.clone();
async move {
let result = sqlx::query(¶ms.query)
.fetch_all(&pool)
.await?;
Ok(serde_json::to_value(result)?)
}
}).await?;
server.run().await?;
Ok(())
}
- Desplegar en Kubernetes:
# postgres-mcp-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: postgres-mcp
spec:
replicas: 1
selector:
matchLabels:
app: postgres-mcp
template:
metadata:
labels:
app: postgres-mcp
spec:
containers:
- name: mcp-server
image: my-registry/postgres-mcp:latest
ports:
- containerPort: 3000
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: db-secrets
key: connection-string
---
apiVersion: v1
kind: Service
metadata:
name: postgres-mcp
spec:
selector:
app: postgres-mcp
ports:
- protocol: TCP
port: 3000
targetPort: 3000
- Conectar el túnel al servidor MCP:
– Registrar el gateway con la IP/DNS del servicio interno (ej: postgres-mcp.default.svc.cluster.local:3000).
– Asignar permisos (ej: solo permitir consultas SELECT en la base de datos).
Paso 4: Configurar sandboxes autoalojados
- Seleccionar proveedor (según necesidades):
# Desplegar un sandbox en Cloudflare Workers
npx wrangler deploy --name claude-sandbox \
--compatibility-date 2026-05-19 \
--env production
– Modal: Para cargas de trabajo con GPU.
# modal_sandbox.py
import modal
from modal import App, Volume
app = App("claude-sandbox")
@app.function(
cpu=8,
memory=32_000,
gpu="A10G",
timeout=3600,
)
def process_document(file_url: str):
# Lógica para procesar documentos (ej: OCR con Tesseract)
pass
- Integrar con Anthropic:
– Configurar políticas de IAM para que el sandbox pueda acceder a servicios internos (ej: usando IRSA en AWS EKS o Workload Identity en GKE).
Paso 5: Auditar y monitorear
- Logs y métricas:
– Kubernetes: Configurar Prometheus y Grafana para monitorear:
– Latencia de túneles (histogram_quantile(0.95, rate(tunnel_duration_seconds_bucket[5m]))).
– Fallos de conexión (rate(tunnel_errors_total[5m])).
- Alertas:
– Túneles caídos por más de 5 minutos.
– Tráfico anómalo (ej: más de 1000 solicitudes/minuto a un servidor MCP).
Conclusión
MCP Tunnels y los sandboxes autoalojados de Anthropic son un avance pragmático para equipos que necesitan integrar IA en entornos empresariales sin sacrificar seguridad. La clave está en invertir el modelo de conexión: en lugar de exponer servicios internos, el túnel entra a tu red con un flujo controlado y cifrado, mientras los sandboxes te dan control sobre la ejecución de código y los recursos.
Para equipos de DevOps, esto significa menos configuraciones manuales en firewalls y más consistencia en el rendimiento. Para seguridad, reduce la superficie de ataque al eliminar puertos abiertos. Y para cloud, permite escalar cargas de trabajo de IA con costos predecibles.
Si tu organización ya usa MCP para conectar agentes a sistemas internos, MCP Tunnels es la opción más segura disponible hoy. Si aún no lo has evaluado, el public beta de sandboxes autoalojados es un buen punto de partida para probar la integración sin riesgos.
Fuentes
- InfoQ: Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems
- Anthropic MCP Tunnels Documentation
- HashiCorp: Zero Trust Networking with Private Link
- Cloudflare Tunnel: How It Works
- Modal: AI Workloads on Modal
