Guía completa de configuración de seguridad de OpenClaw: defensa en cinco capas desde el sandbox Docker hasta el control de accesos

Conclusión rápida (priorización)

Si solo haces tres cosas, ya cubrirás la mayoría de los escenarios de alto riesgo con OpenClaw:

1. imponer autenticación (token/contraseña) y limitar los puntos de entrada;
2. sandbox en contenedor + no root + mínimos privilegios;
3. listas blancas para herramientas sensibles, rechazo por defecto de comandos peligrosos.
   Una vez hechos estos tres pasos, completa capa a capa la auditoría y el aislamiento de red: ahí está el mayor beneficio de seguridad.

A las tres de la madrugada, un desarrollador publicó un pedido de ayuda en Reddit. Había instalado OpenClaw en su MacBook, lo había ejecutado dos semanas con la configuración predeterminada y le parecía genial. Hasta que un día le pidió a OpenClaw que « me ayude a organizar los archivos recientes del proyecto » — la IA leyó ~/.ssh/ y ~/.aws/, y « amablemente » mostró el contenido de su clave privada en la respuesta.

Peor aún: esa conversación se había sincronizado en su grupo de trabajo.

Sinceramente, cuando leí este caso por primera vez, se me erizó la piel. OpenClaw es un asistente de IA muy potente: ejecuta comandos Shell, lee y escribe archivos, controla el navegador — pero eso también significa que, mal configurado, es como dejar entrar a un desconocido con las llaves de tu casa.

Quizá pienses: solo lo uso yo, no pasará nada.

Pues ahí está el problema. Los riesgos de OpenClaw no vienen solo de ataques externos: inyección de prompt (instrucciones maliciosas coladas en el chat), errores de configuración (puerto API expuesto sin querer) o incluso el « entusiasmo excesivo » de la IA (pides limpiar archivos y entiende que debe borrar datos importantes).

Todo esto se puede evitar — con la configuración adecuada.

Este artículo te muestra paso a paso cómo poner a OpenClaw en una « jaula de seguridad » — desde el aislamiento Docker hasta el control fino de permisos, cinco capas de defensa para usar esta « bestia » con tranquilidad. Aviso: la configuración parece un poco pesada, pero comparada con una filtración de datos o un rm -rf en la base de datos, no es gran cosa.

Guía low-cost para « criar langosta »: ArkClaw democratiza los agentes de IA

¿OpenClaw (langosta) es popular pero la configuración espanta? ArkClaw de ByteDance Volcano Engine baja el umbral al mínimo. Sin servidor ni tokens que configurar: un agente en línea 24/7 que controla el navegador, ejecuta scripts y gestiona la agenda con un clic.

El precio importa: 9,9 ¥/mes; con mi código de invitación ZLKUK54M (regístrate aquí) solo 8,9 ¥. ¿Desarrollador? El Coding Plan Pro puede incluir ArkClaw gratis.

¿Por qué necesitas configuración de seguridad?

¿Cuánto puede hacer OpenClaw?

Empecemos por un dato que aclara las ideas. OpenClaw no es un asistente que solo chatea — puede hacer casi todo lo que harías en una terminal:

• Ejecutar comandos Shell arbitrarios: rm -rf /? Técnicamente posible.
• Leer y escribir en todo el sistema de archivos: claves SSH, credenciales AWS, contraseñas de base de datos — si están en disco, puede acceder.
• Acceder a recursos de red: llamar APIs, descargar archivos, escanear puertos de la red interna.
• Controlar el navegador: vía Playwright, incluidos sitios donde ya has iniciado sesión.
• Leer variables de entorno: todo lo que hay en process.env es visible.

En otras palabras, dar permisos predeterminados a OpenClaw es como entregar un llave maestra de tu casa a un asistente « muy inteligente pero que no conoces bien ».

¿Qué tan peligrosa es la configuración predeterminada?

Sé que muchos van a lo simple: npm install -g openclaw y luego openclaw gateway (o el daemon que arranca solo). ¿Pero sabes qué ocurre por defecto?

Antes de v2026.1.29:

• El control de acceso podía ser auth: none: quien tuviera tu URL controlaba tu OpenClaw.
• Sin sandbox: la IA podía leer/escribir en todo el sistema de archivos.
• Todas las herramientas activadas por defecto, incluidos exec y browser.
• Ejecución posible con privilegios elevados (incluso root).

"v2026.1.29 eliminó obligatoriamente la opción auth: none; ahora se requiere autenticación por token o contraseña"

Después de v2026.1.29, algo mejor: se retiró auth: none; token o contraseña obligatorios. Pero lo demás persiste — sandbox, permisos de herramientas, acceso al sistema de archivos: todo sigue requiriendo configuración manual.

Sinceramente, la configuración predeterminada es dormir con la puerta abierta y un cartel de « bienvenidos, visitantes ».

Tres objetivos de la configuración de seguridad

¿Para qué tantos ajustes? Tres objetivos de fondo:

1. Principio de mínimo privilegio: dar a OpenClaw solo lo que realmente necesita. ¿Le pides escribir código? Acceso de lectura/escritura al workspace; ¿no necesitas navegador? Desactiva la herramienta browser.

2. Defensa en profundidad: no confiar en una sola barrera. Aislamiento Docker, usuario sin privilegios, control de acceso, lista blanca de herramientas, aislamiento de red — cinco capas; si una cede, las demás aguantan.

3. Radio de explosión controlado: en el peor caso — inyección de prompt, filtración de token, bug de la IA — ¿cuál es la pérdida máxima? Si OpenClaw solo accede a un workspace aislado, la filtración se limita a ese directorio, no a todo /home.

En resumen: la seguridad no busca impedir todo ataque (imposible), sino hacerlo costoso y limitar los daños.

Configuración de seguridad en cinco capas

Vamos a la práctica. De la capa inferior a la superior, cinco niveles de defensa. En cada capa: por qué, y cómo verificar que está en su lugar.

Capa 1: aislamiento en sandbox Docker (obligatorio)

¿Por qué Docker?

Muchos ven Docker como herramienta de despliegue. Error. Para una aplicación de altos privilegios como OpenClaw, el valor real es el aislamiento:

• Aislamiento del sistema de archivos: la IA solo ve archivos del contenedor; tu ~/.ssh queda en el host.
• Aislamiento de red: cortar acceso a Internet o permitir solo ciertos dominios.
• Límites de recursos: evitar que un bucle infinito queme la CPU.
• Recuperación rápida: ¿problema? docker rm, reconstruir un contenedor limpio en segundos.

A veces se objeta: lo ejecuto en local, ¿hace falta todo esto?

Sí. Lo local es más arriesgado — tokens de GitHub, contraseñas de BD, claves API: blancos para inyección de prompt.

Pasos de configuración

1. Crear un Dockerfile seguro

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

FROM openclaw/gateway:latest

# Crear usuario sin privilegios
RUN adduser --disabled-password --gecos '' clawuser

# Cambiar a usuario sin privilegios
USER clawuser

# Directorio de trabajo
WORKDIR /home/clawuser/openclaw

El punto clave: USER clawuser. Por defecto, el contenedor corre como root; OpenClaw tendría privilegios root. Un usuario dedicado limita los daños si el contenedor se compromete.

2. Parámetros de seguridad en Docker Compose

El núcleo del dispositivo, línea por línea:

version: '3.8'
services:
  openclaw-gateway:
    build: .
    container_name: openclaw-safe

    # Seguridad
    security_opt:
      - no-new-privileges:true  # Evita elevación de privilegios en el contenedor
    cap_drop:
      - ALL  # Elimina todas las Linux capabilities
    cap_add:
      - NET_BIND_SERVICE  # Solo añade capacidad de enlazar puerto

    # Sistema de archivos raíz de solo lectura
    read_only: true

    # Directorios temporales (escritura)
    tmpfs:
      - /tmp
      - /home/clawuser/openclaw/temp

    # Límites de recursos
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

    # Aislamiento de red
    networks:
      - openclaw-isolated

    # Volúmenes (mínimo privilegio)
    volumes:
      # Workspace (lectura/escritura)
      - ./workspace:/home/clawuser/workspace
      # Config (solo lectura)
      - ./config:/home/clawuser/openclaw/config:ro
      # Logs (solo escritura)
      - ./logs:/home/clawuser/openclaw/logs

networks:
  openclaw-isolated:
    driver: bridge
    internal: true  # Sin acceso a red externa

¿Por qué esta configuración?

• no-new-privileges:true: bloque sudo y setuid; incluso con una falla, no hay elevación de privilegios.
• cap_drop: ALL: las capabilities Linux son granulares; quitar todo y devolver solo lo necesario (p. ej. enlazar puerto) reduce la superficie de ataque.
• read_only: true: raíz de solo lectura; sin backdoors ni modificaciones del sistema. La escritura va por tmpfs (/tmp, etc.).
• internal: true: sin red externa. Si OpenClaw no necesita web (solo archivos locales), limita la exfiltración.

3. Activar el modo sandbox de OpenClaw

La configuración principal en runtime suele estar en ~/.openclaw/openclaw.json (JSON). El YAML siguiente es una analogía de estructura; nombres de campos e anidación: ver la documentación oficial de Gateway. Un repositorio GitOps propio puede usar config/config.yaml — no es el nombre predeterminado upstream.

sandbox:
  mode: "non-main"  # Todos los chats de grupo corren en contenedores aislados
  docker:
    enabled: true
    network: "none"  # Desactiva la red de contenedores sandbox

Función sandbox propia de OpenClaw. mode: "non-main": fuera de tu ventana principal, cada conversación corre en un contenedor Docker dedicado. Una inyección de prompt en un hilo de grupo solo puede actuar en su pequeño sandbox.

Verificación

No te apresures; verifica primero:

# Verificar que el contenedor no es root
docker exec openclaw-safe whoami
# Esperado: clawuser

# Verificar sistema de archivos de solo lectura
docker exec openclaw-safe touch /test.txt
# Esperado: Read-only file system

# Verificar aislamiento de red
docker exec openclaw-safe ping 8.8.8.8
# Esperado: Network is unreachable

Si pasan las tres pruebas, la primera capa está en su lugar.

Capa 2: ejecución con usuario sin privilegios (obligatorio)

No root en el contenedor, de acuerdo — ¿pero quién inicia el contenedor? Si ejecutas docker-compose up como root en el host, una fuga de Docker aún puede dar root.

Solución: usuario dedicado de bajos privilegios en el host

Configuración en el host:

# Crear grupo y usuario dedicados
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser

# Estructura de directorios
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}

# Permisos
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config  # Config: solo propietario
sudo chmod 755 /opt/openclaw/workspace  # Workspace
sudo chmod 750 /opt/openclaw/logs  # Logs

# Limitar privilegios del usuario
sudo usermod -L clawuser  # Bloquear login por contraseña; solo su

¿Por qué chmod 700?

Solo el propietario (clawuser) lee/escribe/ejecuta; los demás ni siquiera pueden listar. Tokens y contraseñas en la config: proteger a toda costa.

Permisos de archivos de credenciales (¡crucial!)

Para WhatsApp u otros servicios conectados a OpenClaw:

# Archivos de credenciales en 600 (solo lectura/escritura del propietario)
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw

He visto 644 (legibles por todos) en un servidor compartido — credenciales robadas por otro usuario. No cometas este error básico.

Verificación

# Usuario del proceso OpenClaw
ps aux | grep openclaw
# Esperado: clawuser, no root

# Permisos de archivos
ls -la /opt/openclaw/config
# Esperado: drwx------ clawuser openclaw

Por qué importa esta capa

En el peor caso: contenedor comprometido, sandbox de OpenClaw sorteada, código arbitrario — el atacante sigue siendo clawuser:

• Sin acceso a archivos de otros usuarios
• Sin instalación a nivel de sistema (sin sudo)
• Sin modificar /etc
• Sin leer /root

Es la defensa en profundidad: cae una capa, la siguiente aguanta.

Capa 3: control de acceso y autenticación (obligatorio)

Las dos primeras capas limitan lo que OpenClaw puede hacer; esta limita quién puede usarlo.

Cambio importante v2026.1.29

Antes, auth: none (sin verificación) era posible — un desastre. v2026.1.29 lo eliminó; token o contraseña obligatorios.

Configurar autenticación por token en Gateway

Ventaja del token frente a contraseña: un token por persona/aplicación, permisos distintos; filtración de un token → revocación sin afectar a los demás.

Siempre en la sección Gateway de ~/.openclaw/openclaw.json (no confundir con config/config.yaml de un repo propio; YAML indicativo):

gateway:
  # Autenticación por token obligatoria
  auth: token

  # Configuración de tokens
  tokens:
    - name: "admin-token"
      value: "${OPENCLAW_ADMIN_TOKEN}"  # Variable de entorno, ¡no en duro!
      permissions:
        - "admin"  # Permisos complètes

    - name: "readonly-token"
      value: "${OPENCLAW_READONLY_TOKEN}"
      permissions:
        - "chat"  # Solo chat
        - "read"  # Solo lectura de archivos
      # Sin exec, browser, etc.

Generar tokens robustos

Nada de 123456 o mytoken. Token aleatorio de 256 bits:

# Generar token aleatorio
openssl rand -base64 32

# Variables de entorno (¡no en el archivo de config!)
export OPENCLAW_ADMIN_TOKEN="tu token generado"
export OPENCLAW_READONLY_TOKEN="otro token"

¿Por qué no en duro? El archivo de config puede acabar en Git, logs o backup en la nube. Las variables de entorno son relativamente más seguras.

Lista blanca de acceso

El token responde a « quién puede acceder », pero quizá quieras limitar a ciertos usuarios o grupos de WhatsApp:

# Política DM (mensajes privados)
dmPolicy: allowlist  # Modo lista blanca
allowFrom:
  - "user_id_1"
  - "user_id_2"

# Política de grupo
groupPolicy: allowlist
allowFrom:
  - "group_id_1"

# Mention gating (responder solo a @ en grupo)
mentionGating: true

# Sin acceso público
publicAccess: false

mentionGating: true es muy útil. OpenClaw en un grupo de 100 personas sin esto: procesa cada mensaje (coste + superficie de ataque por prompt). Con esto: responde solo cuando lo @ mencionan.

Verificación

# Acceso no autorizado (debe fallar)
curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# Esperado: 401 Unauthorized

# Token válido
curl -X POST http://localhost:3000/api/chat \
  -H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# Esperado: 200 OK

Por qué esta capa es clave

Sin control de acceso, el aislamiento Docker y mínimo privilegio no sirven — el atacante entra directo por la API.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Es el guardián de la puerta.

Capa 4: control de permisos de herramientas (recomendado)

OpenClaw está enjaulado, pero aún tiene muchas herramientas. Toca quitar las más peligrosas.

Problema: todas las herramientas activadas por defecto

Decenas de herramientas: exec, browser, write_file, web_fetch… Todo abierto por defecto.

En la práctica, para escribir código y buscar documentación, browser y exec pueden quedar desactivados.

Lista blanca de herramientas

tools:
  # Solo herramientas seguras
  allowlist:
    - "read_file"
    - "write_file"     # Escritura limitada a directorios autorizados
    - "web_search"
    - "git"
    # Sin exec, browser, etc.

  # Herramientas de riesgo: autorización explícita
  exec:
    enabled: false

  browser:
    enabled: false

  web_fetch:
    enabled: true
    allowedDomains:
      - "github.com"
      - "api.anthropic.com"
      - "*.npmjs.com"

Si exec es indispensable: lista blanca de comandos

Tests, build de proyecto:

tools:
  exec:
    enabled: true
    sandbox: true

    allowCommands:
      - "git"
      - "npm"
      - "yarn"
      - "pytest"
      - "curl"

    denyCommands:
      - "rm -rf"
      - "sudo"
      - "chmod 777"
      - "dd if="
      - "mkfs"
      - "> /dev/sda"

Lista blanca > lista negra: los ataques son infinitos; los comandos seguros, no.

Restricción de acceso al sistema de archivos

filesystem:
  allowedPaths:
    - "/home/clawuser/workspace"
    - "/home/clawuser/projects"

  deniedPaths:
    - "/home/clawuser/.ssh"
    - "/home/clawuser/.aws"
    - "/home/clawuser/.config"
    - "/etc"
    - "/root"

  defaultPermission: "readonly"

  writablePaths:
    - "/home/clawuser/workspace/temp"

Incluso con un prompt del tipo « lee ~/.ssh/id_rsa », rechazo.

Verificación

En el chat de OpenClaw:

• Tú: « Ejecuta sudo apt update »

  • Respuesta esperada: comando bloqueado por la política de seguridad

• Tú: « Lee el archivo ~/.ssh/id_rsa »

  • Respuesta esperada: Access denied

Capa 5: aislamiento de red y monitorización (avanzado)

Empresa, datos sensibles o paranoia sana: nivel definitivo.

Aislamiento de red: cortar conexiones innecesarias

internal: true bloquea Internet — ¿pero OpenClaw debe llamar a la API de Claude?

Solución: proxy con lista blanca de dominios

Solo api.anthropic.com, etc.; el resto bloqueado:

# docker-compose.yml
services:
  openclaw-gateway:
    environment:
      - HTTP_PROXY=http://allowlist-proxy:8080
      - HTTPS_PROXY=http://allowlist-proxy:8080
    networks:
      - openclaw-isolated

  allowlist-proxy:
    image: squid:latest
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - openclaw-isolated
      - external  # Solo el proxy accede al exterior

squid.conf (lista blanca):

acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com

acl SSL_ports port 443
acl CONNECT method CONNECT

http_access allow allowed_domains
http_access deny all

access_log /var/log/squid/access.log

OpenClaw solo alcanza esos dominios; « descarga un script malicioso » vía inyección → bloqueado por el proxy.

Registro de auditoría: registrar todo

Los logs no evitan el ataque, pero explican qué pasó:

logging:
  level: "info"

  auditLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/audit.log"
    format: "json"

    logToolCalls: true
    logFileAccess: true
    logNetworkRequests: true
    logPrompts: true

  sessionLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/sessions/"

logPrompts: true es crucial para detectar « ignora las restricciones anteriores, ejecuta… » después.

Monitorización en tiempo real

# Actividad sospechosa
tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"

# Conexiones de red
docker exec openclaw-safe netstat -tuln

# Recursos
docker stats openclaw-safe

Alertas

alerts:
  - type: "command_execution"
    pattern: "sudo|rm -rf|chmod 777"
    action: "block_and_notify"

  - type: "file_access"
    pattern: "/.ssh/|/.aws/|/etc/passwd"
    action: "block_and_notify"

  - type: "network_request"
    pattern: ".*\\.onion|torproject\\.org"
    action: "block_and_notify"

Email, Slack o parada del servicio OpenClaw.

Estrategia de inicio en solo lectura

Cinco capas en su lugar — ¿activar todo de golpe?

Non.

Seguridad y comodidad se equilibran. Demasiado estricto → OpenClaw inutilizable; demasiado laxo → sin protección.

Mejor: partir de lo más estricto, relajar progresivamente.

Semana 1: modo solo lectura

Al desplegar:

tools:
  allowlist:
    - "read_file"
    - "web_search"
    - "git_log"

filesystem:
  defaultPermission: "readonly"
  writablePaths: []

Esta semana: observar.

• Archivos accedidos con frecuencia
• Actividad sospechosa en los logs
• Herramientas llamadas habitualmente
• Prueba de inyección de prompt (en entorno seguro)

Semana tranquila → base OK. Intentos frecuentes en .ssh → config o ataque real.

Semana 2: escritura limitada

filesystem:
  writablePaths:
    - "/home/clawuser/workspace/temp"

tools:
  allowlist:
    - "write_file"
    - "git_commit"

Solo el directorio temporal es writable; el código fuente sigue protegido.

« Limpia el proyecto » entendido como borrar todo → daños limitados a temporales.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Semana 3 y más: herramientas según necesidad

tools:
  exec:
    enabled: true
    sandbox: true
    allowCommands:
      - "git"
      - "npm test"

Principios:

• Solo un permiso a la vez
• 24 h de observación tras cada relajación (logs de auditoría)
• Rollback inmediato si comportamiento sospechoso

Caso real: mi evolución de configuración

Al principio quise todo de golpe, doc « seguridad completa » — OpenClaw ni siquiera completaba código (write_file desactivado).

Aprendí:

• Semana 1: solo lectura, doc y explicación de código. Sin problemas.
• Semana 2: escritura en workspace/drafts. OK.
• Semana 3: git para commits — olvidé config Git user, errores; corregido, OK.
• Semana 4: npm test. Suficiente a diario.

browser y exec sin límite? Nunca activados, nunca necesarios.

Lección: no configures permisos « tranquilizadores » pero inútiles. Mejor relajar según necesidad.

Lista de verificación de seguridad

¿Cómo verificar que no falta nada? Esta lista evita ~90 % de errores tontos antes del despliegue.

Antes del despliegue (marcar todo)

Seguridad del contenedor:

• ☐ Usuario sin privilegios (no root en el contenedor)
• ☐ no-new-privileges:true
• ☐ cap_drop: ALL
• ☐ Raíz de solo lectura (read_only: true)
• ☐ Límites de CPU/memoria
• ☐ Modo sandbox de OpenClaw activado

Autenticación:

• ☐ Token fuerte (no auth: none)
• ☐ Token ≥32 caracteres, aleatorio
• ☐ Token en variable de entorno, no en el código
• ☐ Lista blanca DM/grupo
• ☐ En VPS: lista blanca IP si aplica

Control de permisos:

• ☐ Lista blanca de herramientas
• ☐ Herramientas de riesgo desactivadas o lista blanca de comandos
• ☐ Restricciones del sistema de archivos
• ☐ .ssh, .aws, etc. en lista de denegación
• ☐ Archivos de credenciales en 600

Auditoría y monitorización:

• ☐ Registro de auditoría activado
• ☐ Registro de sesión activado
• ☐ Espacio en disco suficiente para logs
• ☐ Sabes leer y analizar los logs

En producción (periódico)

Semanal:

• ☐ Revisar registro de auditoría
• ☐ CPU, memoria, disco
• ☐ Intentos de acceso no autorizado
• ☐ Respaldar la config

Mensual:

• ☐ Actualizar OpenClaw
• ☐ Rotación de tokens (servicios de larga duración)
• ☐ docker scan en la imagen
• ☐ Quitar permisos que ya no hacen falta

Preparación para emergencias

Script de parada de emergencia:

#!/bin/bash
# emergency-stop.sh

echo "Parada de emergencia de OpenClaw..."

docker stop openclaw-safe

# Revocar todos los tokens (si sistema dinámico)
# curl -X DELETE https://your-auth-server/tokens/revoke-all

curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"OpenClaw detenido en emergencia"}'

echo "Detenido. Consulta los logs: /opt/openclaw/logs/audit.log"

Filtración de token:

1. Revocar inmediatamente el token
2. Auditoría: usos del token
3. Nuevo token, informar a usuarios legítimos
4. Filtración de datos → plan de incidentes

Actividad sospechosa:

1. No apagar de inmediato (alerta al atacante)
2. Guardar logs y snapshot del contenedor
3. Analizar vector e impacto
4. Aislar, reiniciar o reconstruir

Conclusión

En una frase: OpenClaw es potente, pero solo es una « bestia » útil dentro de una jaula segura.

Las cinco capas:

1. Sandbox Docker: contenedor, archivos y red limitados
2. Usuario sin privilegios: daños limitados incluso con intrusión
3. Control de acceso: token + listas blancas
4. Permisos de herramientas: herramientas peligrosas desactivadas o restringidas
5. Red y monitorización: conexiones filtradas, todo registrado

Las tres primeras son obligatorias; las dos últimas recomendadas para datos sensibles o despliegue empresarial.

Sí, es un poco pesado. « Solo lo uso yo, ¿hace falta? »

Sí.

No porque OpenClaw esté mal diseñado — sus capacidades son enormes. « Organiza los archivos del proyecto » puede volverse « borra temporales » incluyendo un borrador no guardado. « Historial Git reciente » puede leer credenciales en .git/config.

No es malicioso, solo demasiado entusiasta — las consecuencias pueden ser iguales.

La seguridad no busca evitar que OpenClaw « haga mal », sino limitar el radio de un error.

Tres acciones:

1. Revisa tu config ahora — config predeterminada: detente y aplica al menos las tres primeras capas.
2. Estricto primero, relajar después — una semana en solo lectura antes de abrir permisos.
3. Logs de auditoría cada semana — 5 minutos para detectar anomalías pronto.

OpenClaw es una excelente herramienta. Como la energía nuclear: bien dominada, útil; mal configurada, catástrofe.

La config es pesada — menos que una filtración, un rm -rf o un post en Reddit a las tres de la madrugada.

¿Verdad?

Próximas lecturas

• 5 ajustes de seguridad imprescindibles en la configuración inicial de OpenClaw
• Configuración de OpenClaw al detalle: guía completa de openclaw.json
• Guía de instalación OpenClaw 2026: despliega tu asistente de IA personal