Listas de permitidos, emparejamiento y seguridad de menciones en grupos de OpenClaw

Las funciones útiles de OpenClaw son exactamente la razón por la que importa el modelo de seguridad. El Gateway puede conectar canales de mensajería a un agente capaz de ejecutar comandos de shell, leer y escribir archivos, manejar un navegador y enviar mensajes. Una vía de fallo básica pero de gran impacto es que un remitente no fiable o comprometido alcance a un agente con demasiados privilegios; los controles de abajo reducen esa exposición junto a la seguridad convencional de host, dependencias, credenciales y red.

El orden propio de OpenClaw es el correcto (docs de seguridad):

1. Identidad primero — quién puede hablar con el bot (emparejamiento DM / listas de permitidos / open explícito).
2. Alcance después — dónde puede actuar (grupos, herramientas, sandbox, permisos de dispositivo).
3. Modelo al final — asume que el modelo puede manipularse; limita el radio de impacto.

Este artículo asume que ya has instalado el gateway (configuración del gateway personal).

dmPolicy="open" y groupPolicy="open" son ajustes de último recurso. Prefiere emparejamiento y listas de permitidos salvo que confíes plenamente en cada participante que puede alcanzar el bot. Los DM abiertos con herramientas son una superficie de control remoto pública.

Cada remitente aprobado puede convertirse en un camino hacia lo que el agente puede leer: correo, archivos, sesiones de navegador, datos de clientes en herramientas. Aprueba personas como aprobarías claves SSH — con moderación, de forma revocable y dejando constancia del motivo.

Modelo de confianza en un párrafo

OpenClaw documenta un modelo de confianza de asistente personal: un límite de operador de confianza por gateway. No es un límite multiinquilino hostil. Si usuarios que no confían entre sí pueden escribir a un mismo agente con herramientas, comparten la autoridad delegada de ese agente. Divide gateways (e idealmente usuarios u hosts de SO) cuando los límites de confianza difieran.

El acceso autenticado al Gateway es a nivel de operador. sessionKey es un selector de enrutamiento, no un token de autorización. No te inventes una falsa sensación de aislamiento por usuario en un gateway personal compartido.

Acceso DM: emparejamiento, lista de permitidos, open, disabled

Cada canal con capacidad DM admite una política DM (los nombres varían ligeramente por canal; consulta docs actuales):

Aprueba deliberadamente:

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

Detalles: pairing.

Regla práctica para uso personal: mantén pairing o allowlist estricta. Aprueba solo tus propias cuentas y, como mucho, un conjunto mínimo de operadores adicionales que compartan el límite de confianza.

Dos capas de lista de permitidos

1. Lista de permitidos DM (allowFrom / equivalentes por canal)

Quién puede enviar DM al bot. OpenClaw guarda actualmente las filas de remitentes pendientes y aprobados en ~/.openclaw/state/openclaw.sqlite, indexadas por canal y cuenta. Los antiguos archivos JSON de credenciales son entradas heredadas de migración, no la fuente de autorización actual (documentación del estado de emparejamiento). Trata ese archivo SQLite como estado de autorización sensible y respáldalo de forma coherente con el estado del gateway.

2. Lista de permitidos de grupo

Qué grupos/canales/guilds acepta el bot — además de quién puede activarlo dentro de un grupo (groupPolicy="allowlist" + groupAllowFrom en canales admitidos).

El orden de comprobación importa: política/listas de permitidos de grupo primero, luego activación por mención/respuesta. Responder a un mensaje del bot no elude groupAllowFrom.

Estructura de ejemplo (adapta los IDs estables de remitente y los nombres de agente al esquema actual del canal):

{
  channels: {
    whatsapp: {
      dmPolicy: 'allowlist',
      allowFrom: ['+15555550123'],
      groupPolicy: 'allowlist',
      groupAllowFrom: ['+15555550123'],
      groups: { '<approved-group-id>': { requireMention: true } },
    },
  },
  agents: {
    list: [{ id: 'main', groupChat: { mentionPatterns: ['@openclaw'] } }],
  },
}

Personaliza los patrones de mención para que requireMention coincida con tus nombres de bot, y no con una cadena genérica que cualquiera teclea sin querer.

Las menciones en grupo son un control de seguridad

En los grupos con mucha actividad, un agente que está siempre a la escucha:

• Quema tokens en ruido
• Actúa a partir de inyecciones de prompt enterradas en bromas, logs pegados o páginas enlazadas
• Filtra contexto entre personas que comparten sala pero no un límite de confianza

Exige mención (o activación equivalente) salvo que la sala sea un canal dedicado al agente con una lista de miembros cerrada.

Incluso exigiendo mención, el contenido no fiable que el bot obtiene (páginas web, adjuntos, correos) puede contener instrucciones. La inyección de prompt no se resuelve con prompts del sistema. Los controles duros son la política de herramientas, las aprobaciones, el sandbox y quién puede llegar a hablar con el bot.

La inyección de prompt no requiere DM públicos. Si solo tú puedes escribir al bot, pero el bot lee la web abierta o bandejas compartidas, el texto adversarial puede llegar igualmente dentro de los resultados de las herramientas.

Aislamiento de sesión para DM con varias personas

El comportamiento por defecto puede enrutar DM a una sesión principal por continuidad. Si más de una persona puede enviar DM al bot, aísla sesiones:

{ session: { dmScope: 'per-channel-peer' } }

Sin aislamiento, el contexto de una persona puede filtrarse al turno de otra. Eso es tanto un bug de privacidad como un amplificador de inyección de prompt.

Exposición de red

Antes de celebrar el chat remoto:

• Prefiere gateway.bind: "loopback" para instalaciones personales
• Exige tokens de auth del gateway para cualquier acceso no loopback
• Trata Tailscale Serve/Funnel y proxies inversos como eventos de exposición — recorre el runbook de exposición si usas uno
• Nunca publiques la UI de control (:18789) ni los puertos del modelo en la Internet pública sin auth

Ejecuta:

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix   # narrow safe remediations only

Orden de triaje de la documentación: bloquea primero los DM y grupos abiertos con herramientas, luego la exposición de red pública, luego los accesos remotos de control del navegador, luego los permisos de archivo y, por último, los plugins.

Línea base endurecida (punto de partida)

OpenClaw publica un ejemplo compacto endurecido: bind local, auth por token, perfil de herramientas orientado a mensajería, listas de denegación para grupos automation/runtime/fs, exec denegado con ask: "always", herramientas elevadas desactivadas, emparejamiento estilo WhatsApp + requisitos de mención. Copia la intención en tu config desde la página de seguridad en vivo en lugar de congelar para siempre una copia pegada y obsoleta — y vuelve a auditar.

Los valores por defecto de operador único de confianza pueden permitir exec en host sin prompts (security="full", ask="off"). Es una UX intencionada para un asistente personal, no una prueba de que debas dejarlo así cuando los canales se amplíen. Endurece la configuración cuando tu modelo de amenazas incluya los mensajes de cualquier otra persona.

Preguntas de revisión trimestral

Cada trimestre (o tras cualquier ampliación de canal):

1. ¿Quién está en cada lista de permitidos, y por qué?
2. ¿Qué grupos siguen teniendo el bot, y siguen exigiendo mención?
3. ¿Alguien habilitó política DM/grupo open «temporalmente»?
4. ¿Las herramientas exec/navegador son más amplias que el modelo de amenazas del trimestre pasado?
5. ¿Se ejecutó openclaw security audit desde el último cambio de config?

Escribe las respuestas. La postura de seguridad que solo existe en la cabeza de alguien falla en cuanto llegan las primeras vacaciones.

Notas sobre Discord / Slack / Teams (los mismos principios)

Las UI de canal difieren; las preguntas de seguridad no:

• ¿Qué guilds/workspaces/teams están en la lista de permitidos?
• ¿Qué usuarios pueden enviar DM?
• ¿Debe @mencionarse el bot en canales?
• ¿Los tokens del bot se guardan solo en el host del Gateway?

Para Discord y Slack, OpenClaw documenta listas de permitidos por superficie (guilds, channels y claves relacionadas — confirma esquema actual). Aplica la misma postura «cerrado por defecto» que los ejemplos de WhatsApp/Telegram. Un workspace de Slack público con un agente abierto y herramientas exec es un incidente a la espera de un compañero curioso.

El chat de trabajo suele contener datos personales de empleados y clientes. Conectar OpenClaw a Slack/Teams es una actividad de tratamiento: conoce la base legal, quién puede invocar el bot y qué salidas de herramientas se conservan en ~/.openclaw.

Historias de fallo concretas (patrones, no folclore)

Estas son las formas que toman los incidentes:

Política DM open olvidada

Un token de bot se filtra a un repo público o un amigo comparte el alias. Desconocidos envían DM con prompts del estilo «resume mi ~/Documents». Con las herramientas activadas, el modelo puede intentarlo.

Grupo sin mención

El bot reacciona a cada hilo. Alguien pega un README malicioso. El agente lo obtiene y lo sigue.

WhatsApp familiar compartido

Adolescentes y contratistas comparten un grupo que puede mencionar al bot. La continuidad de sesión mezcla contextos. Una broma se convierte en una petición de comando de shell.

UI remota sin auth

:18789 enlazado en la LAN «para que el móvil pueda acceder». Los usuarios de la Wi-Fi de invitados obtienen un plano de control.

Cada historia se previene con emparejamiento/listas de permitidos, reglas de mención, aislamiento de sesión y bind/auth — no con un prompt del sistema más severo.

Revocación y offboarding

Construye un runbook mínimo:

1. Quita la identidad de allowFrom o revoca su entrada de emparejamiento con la CLI/UI actual; verifica que la fila de autorización canónica en SQLite ha desaparecido usando las herramientas admitidas, no editando la base de datos directamente.
2. Rota los tokens de bot del canal si la persona llegó a verlos.
3. Revisa las sesiones de ~/.openclaw en busca de restos sensibles.
4. Vuelve a ejecutar openclaw security audit.
5. Si la persona tenía emparejamiento de nodo, desempareja el dispositivo.

Trátalo como recuperar una clave SSH, no como dejar de seguir a un bot.

Checklist de operador

• La política DM es pairing o allowlist estricta
• allowFrom contiene solo identidades de confianza
• Los grupos exigen mención; listas de permitidos de grupo fijadas
• dmScope aislado si existen varios remitentes DM
• Gateway en loopback (o solo acceso remoto autenticado)
• openclaw security audit lo bastante limpio como para dormir tranquilo
• Herramientas de alto riesgo desactivadas hasta que la identidad esté bloqueada
• Los permisos del directorio de estado no permiten la lectura a cualquier usuario
• Pasos de offboarding documentados para tus canales

Revoca el emparejamiento y las entradas de la lista de permitidos cuando un número de teléfono, un usuario de Slack o la colaboración con un contratista dejen de estar activos. Las filas olvidadas de una lista de permitidos son invitaciones permanentes. Exporta o borra el historial de sesión que contenga datos personales de otras personas cuando termine la base legal.

Las listas de permitidos y el emparejamiento no son burocracia. Son la diferencia entre un gateway personal y una API de agente sin autenticación unida a tu shell. Configúralas antes de skills, heartbeat y automatizaciones de comodidad — cubiertas a continuación en skills, heartbeat y aprobaciones.