RIP OpenClaw: montar un agente autónomo realmente seguro con Claude + n8n (vía MCP)

La “era de los agentes” tiene un problema incómodo: cuanto más útiles se vuelven (acceso a correo, ficheros, pagos, tickets, repos…), más peligrosa es la tentación de darles demasiado poder. La forma sensata de escalar es justo la contraria: construir capacidad a base de permisos mínimos, compartimentos estancos y confirmaciones explícitas.

Aquí encaja MCP (Model Context Protocol): un estándar open-source para conectar aplicaciones de IA con herramientas y fuentes de datos externas de forma modular, como si fuera un “USB-C” para agentes.

La receta que estás describiendo (Claude Opus + n8n + Desktop Commander + proxy + Cloudflare Tunnel) es, en esencia, un patrón de arquitectura: el agente se vuelve omnipresente (lo hablas por Telegram/Slack desde cualquier sitio), pero su acceso al mundo real queda encapsulado detrás de guardarraíles duros.


La idea en una imagen mental

Tu móvil (Telegram/Slack)
        |
        v
     n8n (VPS)  -----> Integraciones (Gmail/Drive/Notion/Stripe/...)
        |
        | (llamadas a herramientas via MCP)
        v
   mcp-proxy  -----> Desktop Commander (Docker en tu portátil)
        |
        v
Carpetas montadas / comandos permitidos / sandbox aislado
  • n8n (VPS): cerebro-orquestador y punto único donde viven las credenciales de SaaS.
  • Desktop Commander (en tu máquina): “manos locales”, pero solo sobre carpetas montadas y acciones permitidas.
  • mcp-proxy: capa intermedia para exponer el servidor MCP de forma más controlada.
  • Cloudflare Tunnel: exposición segura sin IP pública entrante (modelo outbound-only con cloudflared).
  • MCP: la “interfaz” común para que el agente use herramientas.

Paso 0: sobre “Claude Opus 4.6”

Veo referencias a “Claude Opus 4.6” en catálogos/benchmarks de modelos. En la práctica, qué versión exacta tengas disponible depende del proveedor/API y de tu cuenta, pero el patrón funciona igual con cualquier “Opus” o modelo equivalente que n8n pueda invocar.


Paso 1: instalar Desktop Commander (Docker) en tu portátil/PC

Desktop Commander se usa como servidor MCP local para exponer operaciones (por ejemplo, acceso a ficheros o ejecución de comandos) desde tu máquina, pero sin abrirle la puerta a todo el sistema.

Ejemplo (conceptual) de docker run con principio de mínimo privilegio:

docker run -d --name desktop-commander \
  --restart unless-stopped \
  -p 127.0.0.1:7777:7777 \
  -v /Users/tuusuario/Documentos/AGENT_SHARE:/share:ro \
  -v /Users/tuusuario/Descargas/AGENT_OUT:/out:rw \
  desktopcommander/desktop-commander:latest

Claves aquí:

  • Publicar solo en loopback (127.0.0.1) para que, por defecto, nadie en tu red pueda entrar.
  • Carpetas separadas:
    • AGENT_SHARE en solo lectura (el agente “consulta”).
    • AGENT_OUT en lectura/escritura (el agente “deposita resultados”).
  • Nada de montar / ni $HOME completo. Si lo montas, tarde o temprano lo lamentas.

Paso 2: permisos “duros” con carpetas montadas

Tu seguridad aquí no es “una policy bonita en prompt”, es Linux/OS + Docker:

  • Si el agente no ve una carpeta, no puede exfiltrarla.
  • Si el volumen está en :ro, el agente no puede modificar.
  • Si el contenedor no tiene privilegios extra, no “escala” alegremente.

Este es el punto donde setups tipo OpenClaw suelen fallar: se apoyan demasiado en la buena fe del prompt o en reglas blandas. (OpenClaw es/era un proyecto orientado a agentes; si tu post dice “RIP”, menciónalo como antecedente y céntrate en por qué ahora quieres guardarraíles reales).


Paso 3: conexión segura (mcp-proxy + Cloudflare Tunnel + dominio)

3.1. mcp-proxy delante de Desktop Commander

La función del proxy es intermediar: concentrar control, autenticación/encapsulado (según implementación) y darte un punto único para exponer tu MCP server.

3.2. Cloudflare Tunnel (sin IP pública y sin puertos entrantes)

Cloudflare Tunnel te permite publicar un servicio interno sin exponer una IP “ruteable” públicamente: cloudflared crea conexiones salientes hacia la red de Cloudflare y el tráfico vuelve por ese canal.

Conceptualmente:

# en tu portátil/miniPC donde vive Desktop Commander
cloudflared tunnel create agent-tunnel
cloudflared tunnel route dns agent-tunnel agent.tudominio.com

# configura el túnel para apuntar a tu proxy/MCP local
# (en cloudflared config)
# hostname: agent.tudominio.com
# service: http://127.0.0.1:PORT_PROXY

Con esto consigues:

  • Cero puertos entrantes (reduce superficie de ataque).
  • Un endpoint estable (agent.tudominio.com) para que tu n8n lo invoque.

Nota: si además aplicas políticas de Zero Trust/Access (MFA, allowlist, identidad), elevas mucho el listón, pero incluso el simple hecho de no exponer IP pública ya es un cambio grande de riesgo.


Paso 4: montar el agente en n8n (VPS) con Claude + herramientas

n8n es el “pegamento”: recibe un evento (Telegram/Slack), llama al LLM, decide herramientas, ejecuta acciones y guarda memoria/estado.

4.1. Trigger por Telegram

n8n tiene nodos para Telegram, incluyendo disparadores (trigger) para recibir mensajes y nodos para responder.

Flujo base:

  1. Telegram Trigger (mensaje entrante)
  2. Normalizar (extraer texto, usuario, contexto)
  3. LLM (Claude Opus): “planifica + decide herramientas”
  4. Herramientas:
    • Llamadas al endpoint MCP (tu Desktop Commander vía túnel)
    • Integraciones SaaS (Gmail, Drive, Notion, Stripe…)
  5. Respuesta por Telegram

4.2. Conectar herramientas vía MCP

n8n ya se está moviendo en el ecosistema MCP (servidores MCP, herramientas, etc.), lo que hace más natural tratar “Desktop Commander” como una herramienta más con contrato claro.

4.3. “Memoria”, subagentes y el “Ralph Wiggum loop”

Traducción práctica a ingeniería:

  • Memoria: guarda preferencias + contexto operativo + trazas en un datastore (PostgreSQL, Redis, Notion, fichero JSON versionado…).
  • Subagentes: divide tareas (por ejemplo: “investigación”, “ejecución local”, “redacción”, “verificación”).
  • Loop de verificación (lo que llamas “Ralph Wiggum loop”): antes de ejecutar acciones sensibles, el agente:
    1. resume el plan,
    2. muestra impactos,
    3. pide confirmación,
    4. ejecuta,
    5. registra lo hecho.

Guardarraíles: por qué este patrón aguanta mejor

1) El agente no toca tus API keys

Las credenciales viven en n8n (VPS) y/o en un gestor de secretos. Desktop Commander solo ve ficheros montados. Resultado: aunque comprometas el lado “local”, no te roban Stripe/Gmail por defecto.

2) El agente no puede cambiar su entorno

  • Contenedor sin privilegios
  • Carpetas acotadas
  • Sandbox aparte para “instalar cosas” (otro contenedor/otra VM)

3) El agente solo usa herramientas aprobadas

No le das un “shell root”. Le das capacidades:

  • “lee esta carpeta”
  • “escribe aquí”
  • “ejecuta este comando en sandbox”
  • “envía email SOLO si confirmo”

4) Confirmación humana para acciones irreversibles

Regla de oro:

  • Leer puede ser automático.
  • Escribir/enviar/pagar debe llevar confirmación (por Telegram, con botones si lo montas así).

Checklist rápido de seguridad (lo que yo pondría en el post como cierre práctico)

  • Desktop Commander escuchando solo en 127.0.0.1
  • Volúmenes montados mínimos (:ro cuando se pueda)
  • Separar “entrada” (solo lectura) de “salida” (escritura controlada)
  • Proxy delante del MCP server (punto único de exposición)
  • Cloudflare Tunnel (sin puertos entrantes, outbound-only)
  • n8n con secretos aislados y rotación periódica
  • Confirmación explícita para emails/pagos/borrados
  • Logs/auditoría: cada acción con quién la pidió, qué hizo, qué tocó
Scroll al inicio