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
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:
- Omitir
gateway.bindal denegar vinculaciones que no sean de bucle local significa que se acepta el valor predeterminado del entorno de ejecución; se debe establecergateway.bind: "loopback"para una conformidad estricta. - Para un agente de solo lectura, se debe establecer
modedel entorno aislado enallonon-mainen los valores predeterminados o el agente correspondientes, yworkspaceAccessennoneoro. Un modo de entorno aislado ausente ooffno satisface una política de solo lectura. agents.workspace.denyToolsaceptaexec,process,write,edit,apply_patch. Los grupos de denegación de herramientas de configuracióngroup:fs(mutación de archivos) ygroup:runtime(shell/proceso) satisfacen la postura equivalente.- Las comprobaciones de aprobaciones de ejecución leen el artefacto activo
exec-approvals.jsonsolo cuando existe una reglaexecApprovals; 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 utilizarscopes.<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.
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 artefactoexec-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):
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 enplugins.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:
- Cree o revise
policy.jsonc. - Ejecute
openclaw policy check --json. - Si está limpio, registre
attestation.policy.hashcomoexpectedHash. - Registre
attestation.attestationHashcomoexpectedAttestationHash. - Vuelva a ejecutar
openclaw doctor --linten la Pipeline de CI o en las puertas de lanzamiento.
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:
--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=falsecuando 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.denyoagents.entries.*.tools.denycuando la política exija denegar esas herramientas - establecer en
falselos conmutadoresgateway.controlUi.*que no sean seguros - establecer
gateway.mode=localcuando la política deniegue el modo de Gateway remoto - establecer las rutas
gateway.http.endpoints.*.enablednotificadas enfalsecuando la política deniegue los endpoints de la API HTTP del Gateway - establecer las rutas
groupPolicynotificadas de entrada de canales enallowlistcuando la política deniegue la entrada abierta de grupos - establecer las rutas
requireMentionnotificadas de entrada de canales entruecuando la política exija menciones de grupo - establecer
logging.redactSensitive=toolscuando la política exija la censura de datos confidenciales en los registros - establecer
diagnostics.otel.captureContent=false, odiagnostics.otel.captureContent.enabled=falsepara la configuración de captura de telemetría en formato de objeto, cuando la política deniegue la captura del contenido de telemetría
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.