Los scopes de operador de OpenClaw

Cada cliente WebSocket del gateway se conecta con un rol, operator o node, y después cada método de operador comprueba un scope. La página de scopes es el mapa de ese segundo control: qué significa cada scope, cómo los limitan los roles con nombre, cómo los obtiene una identidad verificada y por qué aprobar el acceso de otra persona nunca concede más de lo que tienes tú. También deja claro que nada de esto es aislamiento entre inquilinos.

Roles y niveles de scope

• operator es el rol de plano de control para la CLI, la interfaz de control, la automatización y los auxiliares de confianza, y node, el rol de host de capacidades para hosts macOS, iOS, Android y sin interfaz gráfica que exponen comandos mediante node.invoke; los métodos RPC de operador exigen el rol operator, y los métodos originados en un nodo, el rol node.
• operator.read cubre el estado, las listas, el catálogo, los registros, las lecturas de sesión y los diagnósticos de auditoría conservados; operator.write cubre el envío de mensajes, la invocación de herramientas, los ajustes de talk y de voz y la retransmisión de comandos a nodos, y también satisface read; operator.admin satisface todos los scopes de operador y es necesario para modificar la configuración, las actualizaciones, los hooks nativos, los espacios de nombres reservados y las aprobaciones de alto riesgo.
• operator.pairing gestiona el emparejamiento de dispositivos y nodos, operator.approvals, las API de aprobación de exec y de plugins, operator.questions, las preguntas interactivas, operator.talk crea, dirige y cierra sesiones de Talk sin acceso general de escritura (write también lo satisface) y operator.talk.secrets lee la configuración de Talk con sus secretos; los scopes futuros desconocidos requieren una coincidencia exacta, salvo que quien llama ya tenga admin.
• La gestión de la conexión personal de GitHub es la única excepción, limitada al propio usuario, al comportamiento de solo lectura: necesita operator.read más el perfil persistente autenticado exacto, de modo que una persona solo puede conectar, consultar o desconectar su propia cuenta, mientras que los cambios de GitHub del sistema y por agente siguen requiriendo admin, y la publicación, write más la autorización de sesión.

Los scopes de operador determinan lo que un cliente del Gateway puede hacer después de autenticarse.

Roles con nombre y concesiones por identidad

Los gateways de equipo vinculan perfiles persistentes autenticados a roles con nombre en gateway.roles, cada uno de los cuales combina cuatro políticas cerradas: el acceso a las sesiones de otras personas (none, view, suggest o write), los agentes disponibles para crear sesiones y ejecuciones (una lista, un asterisco o un array vacío), un conjunto máximo de scopes y si las sesiones nuevas requieren entorno aislado. users.setRole asigna un rol y cierra de inmediato las conexiones de ese perfil, gateway.roles.default es obligatorio en cuanto existen roles, y cuando hay roles configurados, los operadores autenticados por identidad dejan de recibir tokens de dispositivo o de arranque reutilizables, porque esos tokens no están vinculados a una persona. Un entorno aislado obligatorio se aísla por creador de sesión, reduce un espacio de trabajo de lectura y escritura a solo lectura con una advertencia, queda marcado de forma inmutable con el creador antes de la primera ejecución, lo heredan los hijos delegados, nunca recurre al gateway ni a un nodo y no se puede eludir con el modo elevado, las sobrescrituras de host de exec ni los destinos de host configurados. Después, gateway.auth.identityScopes concede scopes a identidades verificadas procedentes de la autenticación por proxy de confianza o de Tailscale WhoIs, con claves de correo que coinciden sin distinguir mayúsculas de minúsculas; las conexiones por token, por contraseña y sin autenticación no llevan identidad y no reciben ninguna concesión, y las conexiones de nodo nunca la reciben.

El control por método y lo que viene después

• Cada RPC tiene un scope de método de mínimo privilegio que se deriva antes del despacho: agent necesita write para los turnos ordinarios y admin para los comandos de ciclo de vida new o reset; node.invoke necesita write para la retransmisión ordinaria y admin cuando retransmite a un nodo el proxy del navegador, el listado de directorios o la subida por terminal; sessions.create necesita write para la creación ordinaria y admin para las sesiones de incógnito o cualquier execNode; el despacho y el traslado de sesiones derivan su scope del destino: write para dispositivos y admin para perfiles.
• Después, los controladores aplican comprobaciones más estrictas sobre el objeto concreto: device.pair.approve es accesible con pairing, pero aprobar un dispositivo de operador solo puede emitir o conservar scopes que quien llama ya tiene; node.pair.approve deriva scopes adicionales de los comandos declarados por el nodo pendiente (write para los comandos ordinarios, admin para system.run, el proxy del navegador, el listado de directorios o los comandos de aprobación de exec), y los comandos de chat config set y unset requieren admin además del envío de chat.
• La autoridad de la conexión se resuelve en este orden: primero, el encabezado x-openclaw-scopes limita las solicitudes de registro o de ampliación de dispositivos; se une una concesión por identidad del lado del servidor que coincida; luego, el encabezado limita la unión final (si falta, no hay límite; si está presente pero vacío, no hay scopes), y un rol con nombre efectivo intersecta el resultado con su techo; el resultado alimenta tanto hello.auth.scopes como la autorización de métodos.

El emparejamiento en OpenClaw es donde se registran estas aprobaciones, y los controles de seguridad del gateway de OpenClaw, el conjunto de controles más amplio al que pertenecen los scopes.

Lo que los scopes no son

La página repite un mismo límite en varios lugares: los scopes son una salvaguarda del plano de control dentro de un único dominio de operador de un gateway de confianza, no aislamiento entre inquilinos hostiles. Los roles con nombre organizan la colaboración dentro de ese dominio; los métodos de auditoría de diagnóstico siguen siendo superficies de lectura del dominio compartido que no se filtran por rol de sesión; operator.write sigue autorizando la invocación de herramientas y la retransmisión a nodos en todo el gateway; y la autenticación por token o contraseña de secreto compartido se trata como un acceso de operador de confianza que restaura el conjunto completo de scopes predeterminado en las superficies compatibles con OpenAI, la ruta de invocación de herramientas y los endpoints del historial de sesiones, incluso cuando quien llama declara scopes más restringidos. Para una separación fuerte entre personas, equipos o máquinas, la respuesta son gateways separados con usuarios del sistema operativo o hosts distintos. El entorno aislado de OpenClaw, explicado explica el entorno aislado por creador que un rol puede exigir, y la API HTTP compatible con OpenAI de OpenClaw, la superficie HTTP en la que se aplica la regla del secreto compartido.

En Diali

En Diali, cada cliente ejecuta su propio gateway, que es la separación que recomienda la documentación, con la configuración del motor generada desde el panel y sustituida en cada versión. OpenClaw alojado en Diali describe el asistente alojado, y la seguridad en Diali, el perímetro que rodea cada motor.

• Write implica read y talk; admin lo implica todo.
• Una aprobación nunca emite scopes que quien aprueba no tiene.
• Los scopes son una salvaguarda, no aislamiento entre inquilinos; los gateways separados sí lo son.