Skip to main content

openclaw policy

openclaw policy lo proporciona el Plugin Policy incluido. Es una capa de conformidad empresarial sobre la configuración existente de OpenClaw, no un segundo sistema de configuración. Los requisitos se definen en policy.jsonc; OpenClaw observa el espacio de trabajo activo como evidencia; Policy informa de las desviaciones mediante doctor --lint. Policy no impone llamadas a herramientas ni reescribe el comportamiento del entorno de ejecución en el momento de la solicitud, y tampoco certifica almacenes de credenciales por agente como auth-profiles.json. Policy comprueba los canales configurados, los servidores MCP, los proveedores de modelos, la postura de SSRF de la red, el acceso de entrada/canales, la exposición del Gateway y la postura de comandos de los nodos, las sondas de enrutamiento de mensajes definidas, el acceso al espacio de trabajo de los agentes, la postura del entorno aislado, la postura de tratamiento de datos, la postura de los proveedores de secretos/perfiles de autenticación y los metadatos de las herramientas gobernadas (TOOLS.md). Se utiliza cuando un espacio de trabajo necesita una declaración duradera y verificable, como «Telegram no debe estar habilitado» o «las herramientas gobernadas deben declarar metadatos de riesgo y propietario». Si solo se necesita comportamiento local sin certificación ni detección de desviaciones, basta con la configuración normal.

Inicio rápido

El Plugin permanece habilitado incluso cuando falta policy.jsonc, para que doctor pueda informar de la ausencia del artefacto en lugar de omitir silenciosamente las comprobaciones. policy.jsonc se define manualmente; no se genera a partir de la configuración actual. Cada sección de nivel superior es un espacio de nombres de reglas: una comprobación solo se ejecuta cuando contiene una regla concreta (las secciones o claves no compatibles generan policy/policy-jsonc-invalid en lugar de ignorarse silenciosamente). Ejemplo mínimo que abarca todas las secciones compatibles:
Notas transversales que no resultan evidentes en las tablas de reglas siguientes:
  • Omitir gateway.bind al denegar vinculaciones que no sean de bucle local significa que se acepta el valor predeterminado del entorno de ejecución; se debe establecer gateway.bind: "loopback" para una conformidad estricta.
  • Para un agente de solo lectura, se debe establecer mode del entorno aislado en all o non-main en los valores predeterminados o el agente correspondientes, y workspaceAccess en none o ro. Un modo de entorno aislado ausente o off no satisface una política de solo lectura.
  • agents.workspace.denyTools acepta exec, process, write, edit, apply_patch. Los grupos de denegación de herramientas de configuración group:fs (mutación de archivos) y group:runtime (shell/proceso) satisfacen la postura equivalente.
  • Las comprobaciones de aprobaciones de ejecución leen el artefacto activo exec-approvals.json solo cuando existe una regla execApprovals; un artefacto ausente o no válido constituye evidencia no observable, no una aprobación sintética.
  • La evidencia de secretos y perfiles de autenticación registra únicamente la postura del proveedor/origen y los metadatos de SecretRef, nunca valores sin procesar. Policy no lee ni certifica almacenes de credenciales por agente como auth-profiles.json.
  • La evidencia de tratamiento de datos solo representa la postura en el nivel de configuración (modo de ocultación, opción de captura de telemetría, modo de mantenimiento de sesiones y configuración de indexación de transcripciones). No inspecciona registros, exportaciones de telemetría, transcripciones ni archivos de memoria, y un resultado limpio no demuestra que no contengan datos personales ni secretos.
  • Las sondas de enrutamiento reutilizan el solucionador de vinculaciones del entorno de ejecución de OpenClaw. La evidencia de enrutamiento solo registra el identificador de la sonda, el agente resuelto, el tipo de coincidencia y los metadatos de vinculación ocultados. Nunca registra identificadores de interlocutores, cuentas, servidores, equipos ni roles. Añadir una sección de enrutamiento cambia deliberadamente los hashes de la política y la certificación; las políticas sin enrutamiento conservan la estructura de evidencia existente.

Referencia de reglas de Policy

Todas las reglas siguientes son opcionales; una comprobación solo se ejecuta cuando la regla está presente. El estado observado corresponde a la configuración o los metadatos del espacio de trabajo existentes de OpenClaw.

Superposiciones con ámbito

Se debe utilizar scopes.<scopeName> cuando agentes o canales concretos necesiten una política más estricta que la base de nivel superior. El nombre del ámbito es solo una etiqueta; la coincidencia utiliza el selector incluido en el ámbito. Las superposiciones son aditivas: la regla global sigue ejecutándose y la regla con ámbito puede añadir su propio hallazgo sobre la misma evidencia. Si no existe una entrada agentIds en agents.entries.*, OpenClaw evalúa la regla con ámbito respecto de la postura global/predeterminada heredada para ese identificador de agente del entorno de ejecución en lugar de omitirla.
El mismo agente puede aparecer en varios ámbitos si cada uno gobierna un campo diferente, como en el ejemplo anterior. Un campo con ámbito repetido para el mismo agente debe ser igual de restrictivo o más; las declaraciones duplicadas menos restrictivas se rechazan (las listas de permitidos son subconjuntos, las listas de denegados son superconjuntos y los valores booleanos obligatorios son fijos). Las reglas de postura de contenedores (sandbox.containers.*) solo se comprueban respecto de la evidencia que puede exponer el backend del entorno aislado del agente coincidente. Si un backend no puede observar una regla habilitada para él, Policy informa de policy/sandbox-container-posture-unobservable en lugar de aprobarla; las reglas de contenedores deben limitarse a los grupos de agentes que utilicen un backend capaz de exponerlas. ingress.session.requireDmScope de nivel superior sigue siendo global; session.dmScope no es evidencia atribuible a un canal, por lo que no se le puede aplicar un ámbito mediante channelIds. Todos los ámbitos presentes en policy.jsonc deben ser válidos y aplicables.

Canales

Servidores MCP

Proveedores de modelos

Red

Enrutamiento de mensajes

Los identificadores de sondeo deben ser únicos. Una ruta admite channel, accountId opcional, peer, parentPeer, guildId, teamId y memberRoleIds. Los tipos de par son direct, group y channel. matchedBy puede contener uno o más tipos de coincidencia en tiempo de ejecución, incluidos binding.peer, binding.account, binding.channel o default. Las comprobaciones de enrutamiento son únicamente comprobaciones de conformidad. No modifican el inicio, la entrega de mensajes, la precedencia de los enlaces ni el comportamiento de reserva. Los hallazgos requieren la revisión del operador, ya que modificar automáticamente un enlace podría redirigir mensajes privados.

Acceso de entrada y a canales

Gateway

gateway.nodes.denyCommands es una regla exacta y sensible a mayúsculas y minúsculas de superconjunto de denegación de políticas. Se utiliza cuando la política debe demostrar que los comandos privilegiados de Node están explícitamente denegados por la configuración de OpenClaw. Una implementación que permita intencionadamente un comando privilegiado de Node debe actualizar policy.jsonc después de la revisión, en lugar de depender únicamente de gateway.nodes.commands.allow.

Espacio de trabajo del agente

Postura del entorno aislado

La política trata la ausencia de sandbox.mode como su valor predeterminado implícito off, por lo que sandbox.requireMode indica que un entorno aislado nuevo o sin configurar está fuera de una lista de permitidos como ["all"].

Tratamiento de datos

Secretos

Aprobaciones de ejecución

Las comprobaciones de aprobaciones de ejecución leen el artefacto exec-approvals.json del entorno de ejecución: ~/.openclaw/exec-approvals.json de forma predeterminada, o $OPENCLAW_STATE_DIR/exec-approvals.json cuando se establece OPENCLAW_STATE_DIR. Las reglas de postura incluidas en execApprovals.defaults.* o execApprovals.agents.* requieren evidencia legible del artefacto; un artefacto ausente o no válido se notifica como evidencia no observable en lugar de considerarse aprobado mediante el mejor esfuerzo. Una vez que es legible, los campos omitidos heredan los valores predeterminados del entorno de ejecución: la ausencia de defaults.security equivale a full, y la ausencia de seguridad del agente hereda ese valor predeterminado. La evidencia incluye defaults, agents.*, agents.*.allowlist[].pattern, argPattern opcional, la postura efectiva de autoAllowSkills y el origen de la entrada; nunca la ruta o el token del socket, commandText, lastUsedCommand, las rutas resueltas ni las marcas de tiempo. Ejemplo: exigir el artefacto de aprobaciones, denegar los valores predeterminados permisivos y permitir solo una postura revisada de aprobación de ejecución para los agentes seleccionados.

Perfiles de autenticación

Metadatos de herramientas

Postura de las herramientas

Ejecutar comprobaciones

Ejecute comprobaciones exclusivamente de políticas durante la creación:
policy check ejecuta únicamente el conjunto de comprobaciones de políticas y emite pruebas, hallazgos y hashes de atestación. Los mismos hallazgos también aparecen en openclaw doctor --lint cuando el Plugin de políticas está habilitado. Compare un archivo de políticas del operador con una línea base creada:
policy compare comprueba la sintaxis de un archivo de políticas con respecto a la sintaxis de otro archivo de políticas; no inspecciona el estado del entorno de ejecución, las pruebas, las credenciales ni los secretos. Utiliza los mismos metadatos de reglas que rigen las superposiciones con ámbito: las listas de permitidos deben mantenerse iguales o ser más restrictivas, las listas de denegación deben mantenerse iguales o ser más amplias, los booleanos obligatorios deben conservar su valor, las cadenas ordenadas solo pueden avanzar hacia el extremo más estricto del orden configurado y las listas exactas deben coincidir. La línea base puede ser una política creada por la organización; la política comprobada puede añadir valores más estrictos o reglas adicionales. Una regla comprobada de nivel superior puede satisfacer una regla de línea base con ámbito cuando es igual o más restrictiva. Los nombres de los ámbitos no tienen que coincidir entre archivos; la comparación se determina por el selector (agentIds/channelIds) y el campo. En las pruebas de enrutamiento, cada identificador de prueba de la línea base debe conservar la misma ruta y el mismo agente esperado. Una política comprobada puede añadir pruebas o restringir matchedBy, pero eliminar una prueba, cambiar su ruta o agente, o ampliar los tipos de coincidencia que acepta es menos restrictivo. Comparación sin hallazgos (--json):
La salida sin hallazgos de policy check --json incluye hashes estables que un operador o supervisor puede registrar:

Configurar la política

La configuración de políticas se encuentra en plugins.entries.policy.config.
Establezca plugins.entries.policy.config.enabled en false para deshabilitar las comprobaciones de políticas de un espacio de trabajo y mantener instalado el Plugin.

Aceptar el estado de la política

Ejemplo de salida JSON:
attestation.policy.hash identifica el artefacto de reglas creado. evidence registra el estado observado de OpenClaw utilizado por las comprobaciones, y workspace.hash identifica esa carga útil de evidencia. findingsHash identifica el conjunto exacto de hallazgos. checkedAt registra cuándo se ejecutó la comprobación. attestationHash identifica la declaración estable (hash de la política, hash de la evidencia, hash de los hallazgos y estado limpio/con cambios) y excluye deliberadamente checkedAt, por lo que el mismo estado de la política siempre produce el mismo hash de atestación. En conjunto, estos cuatro valores forman la tupla de auditoría de una comprobación de política. Si un Gateway o supervisor utiliza la política para bloquear, aprobar o anotar una acción en tiempo de ejecución, debe registrar el hash de atestación de la última comprobación limpia. checkedAt permanece en la salida JSON para los registros de auditoría, pero no forma parte del hash estable. Ciclo de vida para aceptar el estado de la política:
  1. Cree o revise policy.jsonc.
  2. Ejecute openclaw policy check --json.
  3. Si está limpio, registre attestation.policy.hash como expectedHash.
  4. Registre attestation.attestationHash como expectedAttestationHash.
  5. Vuelva a ejecutar openclaw doctor --lint en la Pipeline de CI o en las puertas de lanzamiento.
Si las reglas de la política cambian intencionadamente, actualice ambos hashes aceptados a partir de una comprobación limpia. Si solo cambia la configuración del espacio de trabajo (la política permanece igual), normalmente solo cambia expectedAttestationHash. Habilitar o actualizar las reglas de agents.workspace añade evidencia de agentWorkspace al hash del espacio de trabajo y al hash de atestación; revise la nueva evidencia y actualice los hashes de atestación aceptados después de habilitarlas. Habilitar o actualizar las reglas de postura de las herramientas añade evidencia de toolPosture de la misma manera. openclaw policy watch vuelve a ejecutar la comprobación e informa cuando la evidencia actual ya no coincide con expectedAttestationHash:
Utilice --once en la CI o en scripts que necesiten una única evaluación de desviaciones. Sin --once, sondea cada dos segundos de forma predeterminada; utilice --interval-ms para cambiar el intervalo.

Hallazgos

Un hallazgo puede incluir tanto target (el elemento observado del espacio de trabajo que no cumple los requisitos) como requirement (la regla definida que hizo que se considerara un hallazgo). Actualmente, ambos son cadenas de dirección oc://, pero los nombres de los campos describen la función en la política y no el formato de la dirección. Ejemplos de hallazgos:

Reparación

doctor --lint y policy check son de solo lectura. doctor --fix solo modifica la configuración del espacio de trabajo gestionada por políticas cuando workspaceRepairs está habilitado explícitamente; de lo contrario, las comprobaciones indican lo que repararían y no modifican la configuración. En esta versión, la reparación puede deshabilitar los canales denegados por channels.denyRules y aplicar las reparaciones automáticas de restricción que se enumeran a continuación. Habilite workspaceRepairs solo después de revisar el archivo de políticas, porque una regla válida puede modificar la configuración del espacio de trabajo:
  • establecer tools.elevated.enabled=false cuando una política global prohíbe las herramientas con privilegios elevados
  • añadir los identificadores de herramientas de denegación obligatoria que falten a tools.deny o agents.entries.*.tools.deny cuando la política exija denegar esas herramientas
  • establecer en false los conmutadores gateway.controlUi.* que no sean seguros
  • establecer gateway.mode=local cuando la política deniegue el modo de Gateway remoto
  • establecer las rutas gateway.http.endpoints.*.enabled notificadas en false cuando la política deniegue los endpoints de la API HTTP del Gateway
  • establecer las rutas groupPolicy notificadas de entrada de canales en allowlist cuando la política deniegue la entrada abierta de grupos
  • establecer las rutas requireMention notificadas de entrada de canales en true cuando la política exija menciones de grupo
  • establecer logging.redactSensitive=tools cuando la política exija la censura de datos confidenciales en los registros
  • establecer diagnostics.otel.captureContent=false, o diagnostics.otel.captureContent.enabled=false para la configuración de captura de telemetría en formato de objeto, cuando la política deniegue la captura del contenido de telemetría
Las reparaciones de herramientas con privilegios elevados y ámbito limitado son solo de detección. Las reparaciones de tratamiento de datos con ámbito limitado también se omiten cuando el hallazgo notifica una configuración compartida de registros o telemetría, porque modificar la configuración compartida afectaría a más elementos que el objetivo de la política con ámbito limitado. Las reparaciones de denegación obligatoria con ámbito limitado se omiten cuando el hallazgo notifica la configuración raíz heredada tools.deny, porque añadir la herramienta obligatoria a la configuración raíz afectaría a más elementos que el objetivo de la política con ámbito limitado. Las reparaciones de denegación obligatoria locales del agente pueden actualizar la ruta agents.entries.*.tools.deny notificada. Las reparaciones de entrada de canales con ámbito limitado se omiten cuando el hallazgo notifica la configuración heredada channels.defaults.*, porque modificar el valor predeterminado compartido del canal afectaría a más elementos que el objetivo de la política con ámbito limitado. Los hallazgos de listas de permitidos para la obtención de URL mediante HTTP del Gateway siguen requiriendo intervención manual porque la reparación automática no puede elegir los valores correctos de la lista de permitidos de URL de endpoints. Los hallazgos relativos al enlace del Gateway y a los comandos de Node siguen requiriendo revisión. Cuando policy/gateway-non-loopback-bind o policy/gateway-node-command-denied pueden asignarse a una ruta de configuración, doctor --fix notifica el cambio propuesto de gateway.bind o gateway.nodes.commands.deny como orientación de vista previa omitida. No aplica el cambio y el hallazgo no se considera reparado hasta que un operador revise y actualice la configuración o la política.

Códigos de salida

Temas relacionados