Seguridad en OpenClaw

Ejecutar un agente de IA con acceso a la shell de tu máquina es arriesgado. Estás conectando el comportamiento de modelos avanzados con herramientas reales y superficies de mensajería. No existe un setup “perfectamente seguro”, pero el objetivo es que seas deliberado con quién puede hablar con tu bot, dónde puede actuar y qué puede tocar.

Te recomiendo empezar con el acceso más pequeño que funcione y ampliarlo solo cuando ganes confianza.

Requisitos previos

• OpenClaw CLI instalado
• Archivos de configuración de Gateway o canales activos
• Credenciales configuradas en ~/.openclaw

Inicio rápido

Ejecuta el auditor de seguridad regularmente, especialmente después de cambiar la configuración o exponer servicios a la red. Te toma menos de 5 minutos:

# Análisis básico
openclaw security audit

# Análisis profundo con prueba de Gateway en vivo
openclaw security audit --deep

# Aplicar protecciones automáticas
openclaw security audit --fix

El comando --fix aplica estas protecciones seguras:

• Cambia groupPolicy="open" a groupPolicy="allowlist".
• Cambia logging.redactSensitive="off" a "tools".
• Ajusta permisos locales (ej. ~/.openclaw a 700, archivos de configuración a 600).

Qué revisa el audit

El auditor busca errores comunes que pueden comprometer tu sistema:

• Acceso entrante: Políticas de DMs y grupos para evitar que extraños activen el bot.
• Radio de impacto de herramientas: Controla si un prompt injection puede ejecutar comandos en la shell o acceder a archivos.
• Exposición de red: Revisa el bind del Gateway, tokens cortos o débiles y configuraciones de Tailscale.
• Control del browser: Detecta endpoints CDP remotos o puertos de relay expuestos.
• Higiene del disco local: Permisos de archivos, symlinks y rutas de carpetas sincronizadas.
• Plugins: Verifica que no haya extensiones cargadas sin una allowlist explícita.
• Higiene del modelo: Avisa si usas modelos antiguos que no siguen instrucciones de forma estricta.

Mapa de almacenamiento de credenciales

Usa estas rutas para auditar quién tiene acceso o para tus backups:

• WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Telegram: config/env o channels.telegram.tokenFile
• Discord: config/env (por ahora no soporta token file)
• Slack: config/env (channels.slack.*)
• Allowlists de emparejamiento: ~/.openclaw/credentials/<channel>-allowFrom.json
• Perfiles de auth de modelos: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json

Control UI sobre HTTP

La Control UI necesita un contexto seguro (HTTPS o localhost) para generar la identidad del dispositivo. Si activas gateway.controlUi.allowInsecureAuth, la interfaz usará solo autenticación por token y omitirá el emparejamiento de dispositivos.

Esto reduce la seguridad. Prefiere usar HTTPS a través de Tailscale Serve o abre la UI en 127.0.0.1. Solo usa gateway.controlUi.dangerouslyDisableDeviceAuth para emergencias de depuración y desactívalo rápido.

Reverse Proxy Configuration

Si usas el Gateway detrás de nginx, Caddy o Traefik, configura gateway.trustedProxies para detectar correctamente la IP del cliente.

gateway:
  trustedProxies:
    - "127.0.0.1" # si tu proxy corre en localhost
  auth:
    mode: password
    password: ${OPENCLAW_GATEWAY_PASSWORD}

Cuando configuras trustedProxies, el Gateway usa los encabezados X-Forwarded-For. Si detecta una conexión desde una IP que no está en esa lista, no la tratará como cliente local. Si la autenticación del Gateway está desactivada, esas conexiones se rechazan para evitar saltarse la seguridad.

Solución de problemas

Si el audit imprime hallazgos, soluciónalos en este orden de prioridad:

1. Cualquier cosa “open” con herramientas activadas: Bloquea DMs y grupos usando allowlists antes de cualquier otra cosa.
2. Exposición a red pública: Si tienes un bind de LAN o Funnel sin autenticación, corrígelo de inmediato.
3. Exposición remota del browser: Trata esto como acceso de operador; usa solo redes privadas (tailnet) y evita la exposición pública.
4. Permisos: Asegúrate de que tus credenciales y configuración no sean legibles por otros usuarios del sistema.

¿Necesitas ayuda para configurar estas reglas? Prueba el AI Setup Assistant.

Próximos pasos

• Formal Verification (Security Models)
• Configuración de Gateway

---
title: Seguridad y control de acceso en OpenClaw
description: Aprende a proteger tus logs de sesión, configurar permisos de ejecución y gestionar quién puede interactuar con tu asistente de IA.
---

Configurar un asistente de IA que tiene acceso real a tu sistema es increíble, pero también da un poco de vértigo. Si no tienes cuidado, un mensaje malintencionado de un tercero o un script mal configurado podrían exponer datos sensibles o ejecutar comandos que no quieres.

La seguridad en estos casos no se trata de esperar que el modelo de IA "se porte bien", sino de poner barreras claras antes de que el mensaje llegue siquiera a procesarse. Aquí te explico cómo blindar tu instancia de OpenClaw.

## Requisitos previos

- OpenClaw Gateway instalado y configurado.
- Acceso al sistema de archivos donde corre el Gateway.
- Un nodo macOS vinculado (opcional, para funciones de `system.run`).
- Credenciales de canales (Discord, Slack, WhatsApp, etc.) ya configuradas.

## Inicio rápido

1.  **Protege tus logs**: Ejecuta `chmod 700 ~/.openclaw` para asegurar que solo tu usuario pueda leer las transcripciones de las sesiones.
2.  **Activa el emparejamiento**: Asegúrate de que tu `dmPolicy` esté en `pairing` (es el valor por defecto) para que desconocidos no puedan ejecutar comandos.
3.  **Aísla sesiones**: Si permites que varias personas hablen con el bot, añade esto a tu configuración para evitar fugas de contexto:
    ```json
    {
      session: { dmScope: "per-channel-peer" },
    }

4. Verifica permisos: Si usas un nodo macOS, ve a Settings → Exec approvals en el nodo para controlar qué comandos puede ejecutar la IA.

Logs de sesión en disco

OpenClaw guarda las transcripciones de las sesiones en ~/.openclaw/agents/<agentId>/sessions/*.jsonl. Esto es necesario para la continuidad y la memoria de la sesión, pero significa que cualquier proceso o usuario con acceso al sistema de archivos puede leer esos logs.

Considera el acceso al disco como tu frontera de confianza. Si necesitas un aislamiento real entre agentes, ejecútalos bajo usuarios del sistema operativo distintos o en hosts separados.

Ejecución de nodos (system.run)

Si vinculas un nodo macOS, el Gateway puede invocar system.run. Esto es remote code execution en tu Mac y debes tratarlo con cuidado:

• Requiere vinculación previa (aprobación + token).
• Se controla en el Mac desde Settings → Exec approvals (puedes elegir seguridad máxima, preguntar siempre o usar una allowlist).
• Si quieres desactivar la ejecución remota, cambia la seguridad a deny y elimina el pairing de ese Mac.

Skills dinámicas

OpenClaw puede refrescar su lista de skills en mitad de una sesión:

• Skills watcher: Si cambias SKILL.md, el snapshot de skills se actualiza en el siguiente turno del agente.
• Remote nodes: Al conectar un nodo macOS, las skills exclusivas de macOS pasan a estar disponibles (tras un bin probing).

Trata las carpetas de skills como código confiable y limita quién puede editarlas.

El Modelo de Amenazas

Tu asistente de IA puede:

• Ejecutar comandos de shell arbitrarios.
• Leer y escribir archivos.
• Acceder a servicios de red.
• Enviar mensajes (si tiene acceso a canales como WhatsApp).

Cualquier persona que te envíe un mensaje puede:

• Intentar engañar a la IA para que realice acciones dañinas.
• Usar ingeniería social para acceder a tus datos.
• Sondear detalles de tu infraestructura.

Control de acceso antes que inteligencia

La mayoría de los fallos de seguridad no son exploits complejos, sino simplemente el bot haciendo lo que alguien le pidió por chat. La postura de OpenClaw es clara:

1. Identidad primero: Decide quién puede hablar con el bot (DM pairing, allowlists).
2. Alcance después: Decide dónde puede actuar el bot (allowlists de grupos, menciones obligatorias, sandboxing).
3. Modelo al final: Asume que el modelo puede ser manipulado y diseña el sistema para que el radio de impacto sea limitado.

Autorización de comandos

Los slash commands y las directivas solo funcionan para remitentes autorizados. Esto se gestiona mediante allowlists de canales y el parámetro commands.useAccessGroups.

El comando /exec es una utilidad de conveniencia solo para sesiones de operadores autorizados. No escribe configuración ni altera otras sesiones.

Plugins y extensiones

Los plugins corren in-process con el Gateway. Trátalos como código de total confianza:

• Instala solo plugins de fuentes fiables.
• Usa plugins.allow para definir allowlists explícitas.
• Revisa la configuración del plugin antes de habilitarlo.
• Si instalas desde npm (openclaw plugins install <npm-spec>), recuerda que los scripts de ciclo de vida de npm pueden ejecutar código. Prefiere versiones fijas como @scope/pkg@1.2.3 e inspecciona el código en ~/.openclaw/extensions/<pluginId>/ antes de activarlo.

Modelo de acceso por DM

Todos los canales de DM soportan una política que filtra los mensajes antes de ser procesados:

• pairing (por defecto): Los desconocidos reciben un código de emparejamiento y el bot los ignora hasta que los apruebes. Los códigos expiran en 1 hora.
• allowlist: Se bloquea a cualquier remitente que no esté en la lista (sin handshake).
• open: Permite que cualquiera escriba. Requiere que la allowlist incluya "*" explícitamente.
• disabled: Se ignoran todos los DMs.

Para aprobar a alguien desde la CLI:

openclaw pairing list \<channel\>
openclaw pairing approve \<channel\> <code>

Aislamiento de sesiones (multi-user mode)

Por defecto, OpenClaw dirige todos los DMs a una sesión principal. Si varias personas tienen acceso al bot, usa el secure DM mode:

{
  session: { dmScope: "per-channel-peer" },
}

Esto evita que el contexto y los datos se filtren entre diferentes usuarios. Si manejas varias cuentas en un mismo canal, usa per-account-channel-peer.

Allowlists y terminología

Hay dos capas de control:

• DM allowlist (allowFrom): Quién puede hablar con el bot en privado. Las aprobaciones se guardan en ~/.openclaw/credentials/<channel>-allowFrom.json.
• Group allowlist: Qué grupos o servidores acepta el bot.
  • En WhatsApp/Telegram/iMessage, configurar groups actúa como allowlist.
  • Usa groupPolicy="allowlist" + groupAllowFrom para restringir quién activa al bot dentro de un grupo.

Evita usar dmPolicy="open" o groupPolicy="open" a menos que confíes plenamente en todos los integrantes del canal.

Solución de problemas

• El bot no responde a mis mensajes: Comprueba si el remitente está autorizado. Usa openclaw pairing list <channel> para ver si hay solicitudes pendientes.
• Los cambios en SKILL.md no se ven: El watcher actualiza el snapshot en el “siguiente turno”. Asegúrate de que el archivo tenga el formato correcto.
• Error de permisos en logs: Si el Gateway no puede escribir en ~/.openclaw, fallará. Revisa que el usuario que ejecuta el proceso tenga permisos de escritura.

¿Necesitas ayuda configurando tus políticas de acceso? Prueba el AI Setup Assistant.

Próximos pasos

• Configuración detallada del Gateway
• Guía de Slash commands
• Gestión de Plugins
• Conceptos de Session Management

```mdx
---
title: "Prompt injection: qué es y cómo proteger tu bot"
description: "Aprende a identificar ataques de prompt injection y configura tu Gateway para mantener tus herramientas y archivos seguros."
---

Seguro que te ha pasado: diseñas un sistema genial, ajustas el system prompt con cuidado y, de repente, el bot empieza a ignorar tus reglas porque alguien le envió un mensaje ingenioso. Es frustrante ver cómo un simple texto puede saltarse las protecciones que configuraste.

El prompt injection ocurre cuando alguien envía un mensaje diseñado para manipular al modelo y obligarlo a hacer algo peligroso, como ignorar instrucciones, volcar el filesystem o ejecutar comandos maliciosos. Aunque uses system prompts fuertes, el problema no está resuelto del todo; la seguridad real viene de las políticas de herramientas, aprobaciones de ejecución y el uso de sandboxing.

## Requisitos previos

- Acceso al Gateway de tu agente.
- Un modelo moderno y instruction-hardened (recomendamos Anthropic Opus 4.6).
- Herramientas de alto riesgo configuradas (`exec`, `browser`, `web_fetch`, `web_search`).
- Permisos para ejecutar comandos en el CLI.

## Inicio rápido

Sigue estos cuatro pasos para reducir el riesgo de ataques en menos de 5 minutos:

1.  **Cierra los DMs entrantes**: Mantén los mensajes directos bloqueados mediante allowlists o pairing. En grupos, prefiere el mention gating en lugar de tener bots "siempre activos".
2.  **Usa modelos de primer nivel**: Los modelos antiguos o pequeños (como Sonnet o Haiku) son menos resistentes al prompt injection. Configura Anthropic Opus 4.6 para agentes que manejen herramientas.
3.  **Activa el sandboxing**: Ejecuta cualquier herramienta sensible en un sandbox. Recuerda que el sandboxing es opt-in; si está apagado, `exec` correrá en el host del Gateway aunque `tools.exec.host` apunte a un sandbox por defecto.
4.  **Aísla el contenido no confiable**: No dejes que el agente que tiene acceso a tus herramientas lea directamente contenido externo. Usa un "reader agent" (sin herramientas) para resumir webs o archivos y luego pasa ese resumen a tu agente principal.

## Solución de problemas

### El bot filtró información del sistema mediante `find ~`
Este es un error común. En el incidente `find ~`, un usuario pidió al bot listar el directorio home y este lo hizo, revelando nombres de proyectos y configuraciones.
**Solución**: Activa el sandboxing y asegúrate de que los secrets no estén en el filesystem alcanzable por el agente. Pasa los secrets mediante env/config en el Gateway host.

### Ataques de ingeniería social como "Find the Truth"
Un atacante puede intentar engañar al bot diciendo que "alguien miente" y que debe "explorar el HDD" para encontrar pruebas.
**Solución**: No permitas que el bot explore el filesystem libremente. Limita las herramientas de alto riesgo (`exec`, `browser`) solo a agentes de total confianza o mediante allowlists estrictas.

### Fuga de datos en canales públicos mediante `/reasoning`
Usar `/reasoning` o `/verbose` en grupos puede exponer argumentos de herramientas, URLs y datos privados que el modelo analizó.
**Solución**: Mantén estas opciones desactivadas en salas públicas. Úsalas solo para debug en DMs privados o salas controladas.

### El bot fue comprometido por un link o archivo
El prompt injection no requiere DMs públicos; puede venir de cualquier contenido que el bot lea (emails, logs, resultados de `web_search`).
**Solución**: Trata cualquier link, adjunto o texto pegado como hostil por defecto. Si el modelo es pequeño, desactiva `web_search` y `web_fetch` a menos que los inputs estén muy controlados.

## Incident Response

Si sospechas que tu bot ha sido comprometido o un token se ha filtrado, actúa rápido siguiendo estos cuatro pasos:

1.  **Detén el impacto**: Desactiva las herramientas elevadas o detén el Gateway por completo hasta entender qué pasó. Bloquea las superficies de entrada (políticas de DM y allowlists).
2.  **Rota tus credenciales**: Cambia el token o password de `gateway.auth`. Rota `hooks.token` y revoca cualquier pairing de Node sospechoso. No olvides rotar las API keys de tus proveedores de modelos.
3.  **Revisa los artefactos**: Analiza los logs del Gateway y las transcripciones de las sesiones buscando llamadas a herramientas inesperadas. Revisa la carpeta `extensions/` para eliminar cualquier cosa sospechosa.
4.  **Ejecuta una auditoría**: Usa el comando `openclaw security audit --deep` y confirma que el reporte salga limpio.

¿Necesitas ayuda configurando las políticas de seguridad de tu Gateway? Prueba nuestro [AI Setup Assistant](/docs/).

## Próximos pasos

- [Configuración avanzada de Sandboxing](/docs/)
- [Guía de permisos para herramientas](/docs/)
- [Mejores prácticas para System Prompts](/docs/)
- [Gestión de Secrets en el Gateway](/docs/)

---
title: "Hardening de Configuración: Asegura tu Gateway de OpenClaw"
description: "Guía práctica para proteger tu instancia de OpenClaw, desde permisos de archivos hasta autenticación WebSocket y seguridad en redes locales."
---

Configurar una herramienta nueva siempre es emocionante, pero dejarla abierta por accidente es un dolor de cabeza que nadie quiere. Es frustrante darte cuenta de que tus sesiones privadas o tus API keys podrían estar expuestas solo porque olvidaste revisar quién tiene acceso al puerto por defecto o qué archivos son legibles en tu sistema.

Asegurar tu entorno no tiene por qué ser una tarea eterna. Se trata de aplicar unas cuantas reglas básicas para que tú seas el único con las llaves de tu Gateway, evitando que cualquier curioso en tu red local o en internet pueda husmear en tus integraciones.

## Requisitos previos

- Tener OpenClaw instalado en tu sistema.
- Acceso a la CLI de `openclaw`.
- Un archivo de configuración `openclaw.json` activo.

## Inicio rápido

Sigue estos pasos para establecer una base segura en menos de 5 minutos:

1.  **Protege tus archivos**: Cambia los permisos de `~/.openclaw` a `700` y de `openclaw.json` a `600`.
2.  **Configura el bind**: Asegúrate de que `gateway.bind` esté en `"loopback"`.
3.  **Genera un token**: Ejecuta `openclaw doctor --generate-gateway-token` para activar la autenticación obligatoria.
4.  **Verifica**: Ejecuta `openclaw doctor` para confirmar que no hay vulnerabilidades obvias.

## Hardening de Archivos y Red

### Permisos de archivos
Mantén tu configuración y el estado de tus datos privados en el host del Gateway:

- `~/.openclaw/openclaw.json`: `600` (lectura/escritura solo para tu usuario).
- `~/.openclaw`: `700` (acceso exclusivo para tu usuario).

Puedes usar `openclaw doctor` para recibir advertencias y dejar que la herramienta ajuste estos permisos por ti.

### Exposición de red (bind, port y firewall)
El Gateway multiplexa **WebSocket + HTTP** en un solo puerto:

- Puerto por defecto: `18789`
- Configuración mediante: `gateway.port`, el flag `--port`, o la variable de entorno `OPENCLAW_GATEWAY_PORT`.

El modo de bind controla dónde escucha el Gateway:

- `gateway.bind: "loopback"` (por defecto): solo permite conexiones de clientes locales.
- Binds que no son loopback (`"lan"`, `"tailnet"`, `"custom"`): aumentan la superficie de ataque. Úsalos solo con un token/password configurado y un firewall real.

Recomendaciones directas:
- Prefiere **Tailscale Serve** antes que hacer un bind a la LAN. Con Serve, el Gateway se queda en loopback y Tailscale gestiona el acceso.
- Si necesitas bind a la LAN, usa un firewall para permitir solo IPs de origen específicas; evita el port-forwarding masivo.
- Nunca expongas el Gateway sin autenticación en `0.0.0.0`.

### Descubrimiento mDNS/Bonjour
El Gateway se anuncia vía mDNS (`_openclaw-gw._tcp` en el puerto 5353) para que otros dispositivos locales lo encuentren. En modo "full", esto incluye registros TXT que pueden revelar:

- `cliPath`: ruta completa al binario de la CLI (revela tu usuario y ruta de instalación).
- `sshPort`: indica si SSH está disponible en el host.
- `displayName`, `lanHost`: información del hostname.

Si quieres evitar que cualquiera en tu red local mapee tu infraestructura, usa el **modo minimal** (recomendado):

```json
{
  discovery: {
    mdns: { mode: "minimal" },
  },
}

O desactívalo por completo si no necesitas el descubrimiento de dispositivos:

{
  discovery: {
    mdns: { mode: "off" },
  },
}

También puedes usar la variable de entorno OPENCLAW_DISABLE_BONJOUR=1. En modo minimal, el Gateway solo anuncia lo básico para funcionar (role, gatewayPort, transport), omitiendo rutas de archivos y puertos SSH.

Autenticación del Gateway

La autenticación es obligatoria por defecto. Si no configuras un token o password, el Gateway rechazará las conexiones WebSocket.

Configurar un Token

Usa un token para que todos los clientes de WebSocket deban autenticarse:

{
  gateway: {
    auth: { mode: "token", token: "tu-token-seguro" },
  },
}

Usa openclaw doctor --generate-gateway-token para crear uno rápidamente. Ten en cuenta que gateway.remote.token es solo para llamadas de CLI remotas y no protege el acceso local de WebSocket.

Emparejamiento de dispositivos (Pairing)

• El emparejamiento se aprueba automáticamente para conexiones locales (loopback o la dirección tailnet del propio host).
• Otros nodos de la tailnet no se consideran locales; requieren aprobación de pairing.

Tailscale Serve e Identidad

Si gateway.auth.allowTailscale es true (valor por defecto), OpenClaw acepta los headers de identidad de Tailscale Serve (tailscale-user-login). OpenClaw verifica esto mediante tailscale whois contra la dirección x-forwarded-for.

Regla de seguridad: No reenvíes estos headers desde tu propio reverse proxy. Si usas un proxy delante del Gateway, desactiva gateway.auth.allowTailscale y usa token/password. Si terminas TLS frente al Gateway, añade tus IPs en gateway.trustedProxies.

Gestión de Secretos y Logs

Datos sensibles en disco

Asume que cualquier cosa en ~/.openclaw/ es privada. Esto incluye:

• openclaw.json: puede contener tokens y configuraciones de proveedores.
• credentials/**: credenciales de canales (como WhatsApp) y listas de pairing.
• agents/<agentId>/sessions/**: transcripciones de sesiones que contienen mensajes y outputs de herramientas.
• extensions/**: plugins instalados.

Consejos de seguridad:

• Usa cifrado de disco completo (Full-disk encryption) en el host.
• Usa una cuenta de usuario de OS dedicada para el Gateway.

Logs y Redacción

Los logs pueden filtrar información sensible. Te recomiendo:

• Mantener activada la redacción de herramientas: logging.redactSensitive: "tools".
• Usar logging.redactPatterns para añadir patrones personalizados (tokens internos, hostnames).
• Al compartir diagnósticos, usa openclaw status --all en lugar de logs crudos, ya que redacta secretos automáticamente.

Configuración de Canales y Agentes

WhatsApp y Grupos

Para mantener la privacidad, configura el pairing obligatorio en DMs y exige menciones en grupos:

{
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
  agents: {
    list: [
      {
        "id": "main",
        "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] }
      }
    ]
  }
}

Modo de Solo Lectura (Read-Only)

Puedes crear un perfil restringido combinando estas opciones:

• agents.defaults.sandbox.workspaceAccess: "ro"
• Listas de herramientas (allow/deny) que bloqueen write, edit, exec, o process.

Baseline de Configuración Segura

Aquí tienes un ejemplo de openclaw.json que mantiene todo privado y bajo control:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "tu-token-largo-y-aleatorio" },
  },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}

Solución de problemas

• El Gateway no conecta remotamente: Verifica que gateway.bind no esté en loopback si intentas acceder desde otra IP, o mejor aún, usa Tailscale.
• Error de autenticación en la CLI: Asegúrate de que el token generado con openclaw doctor coincida con el que tienes en tu archivo de configuración.

¿Necesitas ayuda para ajustar tu configuración específica? Prueba el AI Setup Assistant.

Próximos pasos

• Logging y Redacción
• Guía de Tailscale
• Web Overview
• Uso del Browser Tool

```mdx
---
title: Configura el Sandboxing en OpenClaw para proteger tu entorno
description: Guía para implementar aislamiento de agentes y herramientas mediante Docker y políticas de acceso.
---

Seguro que has sentido esa pequeña duda al darle a un agente acceso a tu terminal. ¿Y si borra algo que no debe o accede a archivos privados por error? No quieres limitar la utilidad del agente, pero tampoco quieres dejarle las llaves de tu casa sin supervisión.

Configurar un entorno seguro te permite experimentar sin miedo. Aquí te explico cómo aislar tus procesos y herramientas para que el Gateway funcione exactamente como tú decidas.

## Requisitos previos

- **Docker**: Necesario para el aislamiento de contenedores.
- **OpenClaw Gateway**: Instalado y configurado.
- **detect-secrets**: Si planeas realizar escaneos de seguridad en tu flujo de trabajo.

## Quick Start: Configuración en 5 minutos

Para empezar con el Sandboxing (altamente recomendado), tienes dos caminos que se complementan:

1.  **Gateway completo en Docker**: Ejecutas todo el Gateway dentro de un contenedor para crear una barrera total. Consulta la guía de [Docker](/docs/install/docker).
2.  **Sandbox de herramientas**: Mantienes el Gateway en el host pero aíslas las herramientas usando `agents.defaults.sandbox`.

Para evitar que los agentes accedan a datos de otros agentes, mantén `agents.defaults.sandbox.scope` en `"agent"` (valor por defecto). Si necesitas un aislamiento más estricto por cada sesión, usa `"session"`. La opción `scope: "shared"` utiliza un único contenedor o espacio de trabajo.

### Control de acceso al Workspace

Configura cómo el agente ve tus archivos mediante `agents.defaults.sandbox.workspaceAccess`:

-   `"none"` (por defecto): El agente no accede a su workspace; las herramientas corren en un espacio temporal en `~/.openclaw/sandboxes`.
-   `"ro"`: Monta el workspace del agente como solo lectura en `/agent`. Esto desactiva comandos como `write`, `edit` o `apply_patch`.
-   `"rw"`: Monta el workspace con permisos de lectura y escritura en `/workspace`.

**Nota importante**: `tools.elevated` es tu vía de escape global para ejecutar comandos directamente en el host. Mantén `tools.elevated.allowFrom` muy restringido. Puedes limitar esto por agente en `agents.list[].tools.elevated`. Revisa los detalles en [Elevated Mode](/docs/tools/elevated).

## Riesgos del control del Browser

Activar el control del Browser permite al modelo manejar un navegador real. Si ese perfil tiene sesiones iniciadas, el modelo podrá acceder a esas cuentas. Maneja los perfiles del navegador como **estado sensible**:

- Usa un perfil dedicado para el agente (el perfil `openclaw` que viene por defecto).
- No apuntes el agente a tu perfil personal de uso diario.
- Desactiva el control del navegador en el host para agentes en sandbox, a menos que confíes plenamente en ellos.
- Trata las descargas del navegador como archivos no confiables y usa un directorio de descargas aislado.
- Desactiva la sincronización y gestores de contraseñas en el perfil del agente.
- En Gateways remotos, asume que el control del navegador equivale a tener acceso de operador a todo lo que ese perfil alcance.
- Mantén el Gateway y los hosts de Node.js solo en tu red de Tailscale; no expongas puertos a la red local o internet pública.
- El endpoint CDP del relay de la extensión de Chrome requiere autenticación; solo clientes de OpenClaw pueden conectar.
- Si no lo necesitas, apaga el enrutamiento por proxy: `gateway.nodes.browser.mode="off"`.

El modo relay de la extensión de Chrome **no** es más seguro; puede tomar el control de tus pestañas abiertas. Asume que puede actuar en tu nombre en cualquier sitio al que esa pestaña tenga acceso.

## Perfiles de acceso por agente (Multi-agent)

Con el enrutamiento multi-agente, puedes definir una política de sandbox y herramientas específica para cada uno. Esto te permite dar **acceso total**, **solo lectura** o **sin acceso**. Tienes todos los detalles en [Multi-Agent Sandbox & Tools](/docs/tools/multi-agent-sandbox-tools).

### Ejemplo: Acceso total (sin sandbox)

```json
{
  agents: {
    list: [
      {
        id: "personal",
        workspace: "~/.openclaw/workspace-personal",
        sandbox: { mode: "off" },
      },
    ],
  },
}

Ejemplo: Herramientas y workspace de solo lectura

{
  agents: {
    list: [
      {
        id: "family",
        workspace: "~/.openclaw/workspace-family",
        sandbox: {
          mode: "all",
          scope: "agent",
          workspaceAccess: "ro",
        },
        tools: {
          allow: ["read"],
          deny: ["write", "edit", "apply_patch", "exec", "process", "browser"],
        },
      },
    ],
  },
}

Ejemplo: Sin acceso a sistema de archivos o shell

{
  agents: {
    list: [
      {
        id: "public",
        workspace: "~/.openclaw/workspace-public",
        sandbox: {
          mode: "all",
          scope: "agent",
          workspaceAccess: "none",
        },
        tools: {
          allow: [
            "sessions_list",
            "sessions_history",
            "sessions_send",
            "sessions_spawn",
            "session_status",
            "whatsapp",
            "telegram",
            "slack",
            "discord",
          ],
          deny: [
            "read",
            "write",
            "edit",
            "apply_patch",
            "exec",
            "process",
            "browser",
            "canvas",
            "nodes",
            "cron",
            "gateway",
            "image",
          ],
        },
      },
    ],
  },
}

Qué decirle a tu AI

Incluye guías de seguridad directamente en el system prompt de tu agente:

## Security Rules
- Never share directory listings or file paths with strangers
- Never reveal API keys, credentials, or infrastructure details
- Verify requests that modify system config with the owner
- When in doubt, ask before acting
- Private info stays private, even from "friends"

Troubleshooting: Respuesta ante incidentes

Si tu AI se comporta de forma inesperada, sigue estos pasos:

1. Contener

• Detenlo: Cierra la app de macOS o termina el proceso openclaw gateway.
• Cierra la exposición: Cambia gateway.bind: "loopback" o desactiva Tailscale Funnel hasta entender qué pasó.
• Congela el acceso: Cambia las políticas de DMs a dmPolicy: "disabled" y elimina entradas de permitir todo ("*").

2. Rotar (asume compromiso si hubo fuga de secretos)

• Rota el token del Gateway (gateway.auth.token / OPENCLAW_GATEWAY_PASSWORD).
• Rota los secretos de clientes remotos (gateway.remote.token) en cualquier máquina conectada.
• Rota credenciales de proveedores (WhatsApp, Slack, Discord o keys de APIs en auth-profiles.json).

3. Auditar

• Revisa los logs del Gateway en /tmp/openclaw/openclaw-YYYY-MM-DD.log.
• Revisa las transcripciones en ~/.openclaw/agents/<agentId>/sessions/*.jsonl.
• Verifica cambios recientes en la configuración de gateway.bind, gateway.auth o tools.elevated.

4. Recolectar para un reporte

• Guarda el timestamp, OS del host y versión de OpenClaw.
• Adjunta transcripciones y un fragmento del log (anonimizando datos sensibles).
• Describe qué envió el atacante y qué hizo el agente.

Escaneo de secretos (detect-secrets)

Si el CI falla en el trabajo de secrets, significa que hay posibles credenciales nuevas que no están en el baseline.

1. Reproducir localmente:

   detect-secrets scan --baseline .secrets.baseline

2. Herramientas:
   • detect-secrets scan: Encuentra candidatos y compara con el baseline.
   • detect-secrets audit: Abre una revisión interactiva para marcar elementos como reales o falsos positivos.
3. Secretos reales: Rotarlos o eliminarlos, luego re-escanear.
4. Falsos positivos: Ejecuta el auditor interactivo:

   detect-secrets audit .secrets.baseline

Si necesitas excluir archivos, edita .detect-secrets.cfg y regenera el baseline con los flags --exclude-files o --exclude-lines.

La Jerarquía de Confianza

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#000000',
    'primaryBorderColor': '#000000',
    'lineColor': '#000000',
    'secondaryColor': '#f9f9fb',
    'tertiaryColor': '#ffffff',
    'clusterBkg': '#f9f9fb',
    'clusterBorder': '#000000',
    'nodeBorder': '#000000',
    'mainBkg': '#ffffff',
    'edgeLabelBackground': '#ffffff'
  }
}}%%
flowchart TB
    A["Owner (Peter)"] -- Full trust --> B["AI (Clawd)"]
    B -- Trust but verify --> C["Friends in allowlist"]
    C -- Limited trust --> D["Strangers"]
    D -- No trust --> E["Mario asking for find ~"]
    E -- Definitely no trust 😏 --> F[" "]

     %% The transparent box is needed to show the bottom-most label correctly
     F:::Class_transparent_box
    classDef Class_transparent_box fill:transparent, stroke:transparent

Reportar problemas de seguridad

¿Has encontrado una vulnerabilidad en OpenClaw? Por favor, infórmanos de forma responsable:

1. Email: security@openclaw.ai
2. No lo publiques hasta que esté solucionado.
3. Te daremos crédito por el hallazgo (a menos que prefieras el anonimato).

---

¿Necesitas ayuda configurando tus contenedores? Prueba nuestro AI Setup Assistant.

What’s Next:

• Documentación de Sandboxing
• Guía de instalación con Docker
• Uso del Elevated Mode
• Configuración Multi-Agent