Skills, heartbeat y puertas de aprobación en OpenClaw

Una vez instalado OpenClaw y bloqueada la identidad de los canales (configuración, listas de permitidos y emparejamiento), la siguiente capa son las capacidades: skills, turnos periódicos del heartbeat, política de aprobación del shell del host y activación de la automatización del navegador dentro de un workflow revisado.

Anclas de documentación: Skills, Heartbeat, Security.

El heartbeat combinado con exec sin restricciones en el host, o con la automatización de un navegador que contenga sesiones valiosas ya iniciadas, permite actuar sin supervisión mediante las credenciales y los accesos expuestos en esa interfaz. Habilita los turnos periódicos solo cuando la política de herramientas se ajuste a tu modelo de amenazas, sobre todo si algún canal distinto del tuyo puede activar el agente.

Skills: qué son

Las skills son paquetes de instrucciones en markdown (SKILL.md con frontmatter YAML + cuerpo) que enseñan al agente cómo y cuándo usar herramientas. OpenClaw carga las skills incluidas de serie más los overrides locales, y las filtra en el momento de la carga según el entorno, la configuración y la existencia de los binarios requeridos.

Precedencia (mayor primero), según docs actuales:

1. Skills del espacio de trabajo
2. Skills de agente del proyecto
3. Skills de agente personales (~/.agents/skills en el estado por defecto)
4. Skills gestionadas / locales bajo el directorio de estado de OpenClaw
5. Skills incluidas de serie
6. Directorios adicionales / skills de plugins

Cuando el mismo nombre de skill aparece en varios sitios, gana la fuente superior. Trata las carpetas de skill como código de confianza: quien pueda modificarlas puede cambiar el comportamiento del agente.

Listas de permitidos para las skills que ve un agente

La ubicación (precedencia) y la visibilidad (lista de permitidos por agente) son cosas distintas. Estructura de ejemplo tomada de la documentación:

{
  agents: {
    defaults: {
      skills: ['github', 'weather'],
    },
    list: [
      { id: 'writer' },
      { id: 'docs', skills: ['docs-search'] },
      { id: 'locked-down', skills: [] },
    ],
  },
}

Omite las listas de skills por defecto solo cuando quieras de forma deliberada una superficie amplia. Para gateways personales, empieza con un conjunto reducido: skills que hayas leído, que correspondan a binarios que tú instalas y que sirvan para trabajos que realmente ejecutas.

Las skills y los plugins de la comunidad forman una cadena de suministro. Instalarlos puede ejecutar código y ampliar las herramientas. Prefiere la documentación oficial y las skills que hayas revisado; utiliza security.installPolicy si aplicas decisiones de autorización o bloqueo en el host que sean responsabilidad del operador.

Las skills alojadas en un nodo solo aparecen mientras el nodo emparejado está conectado. Sus archivos, las rutas a las que hacen referencia y sus binarios permanecen en ese nodo, y la ejecución utiliza exec host=node node=<node-id>. El emparejamiento inicial con el rol de nodo autoriza la publicación de skills; los cambios posteriores en las skills requieren reiniciar el nodo, no volver a emparejarlo. La política exec del agente y la política de aprobación local del host en el nodo siguen gobernando la ejecución.

Heartbeat: un pulso, no un segundo cerebro

Heartbeat ejecuta turnos periódicos del agente en la sesión principal para que el modelo pueda señalar lo que necesita atención sin spamearte. Es un turno programado de la sesión principal, no un registro de tareas en segundo plano.

Valores por defecto (verifica en tu versión):

• El intervalo suele ser 30m (las configuraciones OAuth o con token de Anthropic pueden adoptar un valor predeterminado mayor cuando no se ha definido; la documentación indica 1h en ese caso)
• Configura agents.defaults.heartbeat.every (usa 0m para deshabilitar)
• El prompt por defecto indica al agente que siga el scratch del monitor de heartbeat, que no invente trabajo recurrente a partir de chats antiguos y que responda HEARTBEAT_OK cuando nada requiera atención

Ejemplo:

{
  agents: {
    defaults: {
      heartbeat: {
        every: '30m',
        target: 'none',
        lightContext: true,
        isolatedSession: true,
        // activeHours: { start: "08:00", end: "22:00" },
      },
    },
  },
}

Orientación práctica:

• Mantén target: "none" hasta que quieras entregas; configura target: "last" solo cuando aceptes pings al último contacto.
• Usa activeHours para que los pulsos nocturnos guarden silencio en tu zona horaria.
• Coloca el trabajo recurrente en automatizaciones o tareas cron, no en el folclore del scratch del heartbeat; la documentación del heartbeat subraya esta separación.
• Los heartbeats programados requieren que las automatizaciones estén habilitadas; si cron está deshabilitado, los heartbeats programados no se ejecutan.

Contrato de respuesta: HEARTBEAT_OK (al inicio/fin) se trata como ack y se suprime cuando el contenido restante es corto. Las alertas deben omitir HEARTBEAT_OK y devolver solo el texto de alerta.

Los turnos heartbeat siguen usando las herramientas a las que puede acceder el agente. Un «check-in inofensivo» con exec permitido sigue siendo una oportunidad programada para que contenido inyectado por prompt en memoria o páginas obtenidas pida acciones de shell. Combina el heartbeat con políticas deny/ask para las herramientas.

Puertas de aprobación para shell y navegador

El modelo de seguridad de OpenClaw trata las aprobaciones exec como medidas de protección de la intención del operador, no como aislamiento multiinquilino hostil. Aun así, para gateways personales son la diferencia entre «pregúntame» y «ejecútalo».

Exec

Controles relevantes de la referencia actual de aprobaciones exec; confírmalos en el esquema incluido con la versión instalada:

• tools.exec.mode es la política persistente canónica de ejecución en el host: deny, allowlist, ask, auto o full.
• auto envía las solicitudes que no coinciden con la lista de permitidos al revisor nativo de OpenClaw antes de recurrir a una persona. Es una vía cómoda, no una prueba de que un comando sea seguro.
• La ejecución en la Gateway y en los nodos también consulta el documento local de aprobaciones del host de ejecución. La política efectiva es la más restrictiva entre la configuración y ese documento local.
• askFallback se aplica cuando se necesita una confirmación, pero no hay ninguna interfaz disponible o se agota el tiempo. Su valor predeterminado es deny; consérvalo para que la pérdida de la ruta de aprobación no amplíe el acceso.
• Las listas de permitidos son específicas de cada agente. Utiliza rutas de ejecutables limitadas y argPattern cuando corresponda; strictInlineEval añade defensa en profundidad cuando se permiten intérpretes.
• tools.exec.host: "auto" elige el sandbox cuando está activo y la Gateway en caso contrario. La ejecución en un nodo exige que esté emparejado y que tenga su propio estado local de aprobaciones en el host.

Empieza con tools.exec.mode: "deny", o con mode: "ask" y un documento local de aprobaciones del host igual de restrictivo cuando necesites confirmaciones, y mantén desactivadas las herramientas elevadas. De lo contrario, la ejecución en el host de la Gateway y de los nodos utiliza full por defecto, mientras que la ejecución en el host del sandbox se deniega por defecto. Refuerza la política del host antes de que los canales, las skills o el heartbeat amplíen el radio de impacto.

El system.run de un nodo en un Mac emparejado constituye ejecución remota de código en ese Mac. El emparejamiento no es una aprobación por comando; la política de comandos del nodo en la Gateway y las propias aprobaciones exec del nodo forman el límite de ejecución. Para desactivar la ejecución remota del shell, establece el modo exec solicitado en deny y mantén restrictiva la política local de aprobaciones del host del nodo, o elimina el rol y el emparejamiento del nodo si no los necesitas.

Navegador

El control de navegador es una superficie de grado operador (navegar, leer páginas, evaluar). Trata la exposición remota de navegador/CDP como acceso de operador: loopback o una ruta privada protegida deliberadamente, sin endpoint público de CDP o de control. Usa el perfil de navegador openclaw dedicado, que está aislado de tu perfil de navegador diario, y mantén el plugin o la herramienta de navegador desactivados hasta que una tarea revisada los necesite. Las aprobaciones de exec no crean un límite de aprobación por clic en el navegador; exige confirmación humana en el flujo antes de envíos, compras, publicaciones o cambios de cuenta con consecuencias.

La inyección de prompt mediante páginas recuperadas es un riesgo de primer orden. La política de autorización o denegación de herramientas, el aislamiento del perfil del navegador, la confirmación explícita en el workflow y el sandboxing reducen el radio de impacto; no eliminan la necesidad de listas de permitidos para los canales.

Herramientas elevadas

tools.elevated escapa del sandbox. Mantén allowFrom estricto. No habilites el modo elevado para desconocidos ni para poblaciones amplias de canales.

Una escalera de autonomía sensata

Sube de etapa solo tras openclaw security audit y suficientes ejecuciones conservadas como para ejercitar el trabajo normal, las rutas de denegación, el agotamiento del tiempo de aprobación y la recuperación. Un número fijo de días no demuestra que sea seguro.

Escribir una skill interna pequeña

Una skill mínima útil es una carpeta con SKILL.md:

---
name: disk-check
description: Check disk usage on the gateway host when asked about disk or capacity.
---

When the user asks about disk space on this host:

1. Run only the allowlisted `df` invocation your exec policy permits.
2. Summarise filesystem use in three bullets.
3. Do not install packages or delete files.

Mantén la descripción concreta para que el agente sepa cuándo utilizarla. Combina la skill con un modo exec limitado, reglas revisadas para los comandos y argumentos de cada agente, strictInlineEval y aislamiento mediante un sandbox o el sistema operativo. Estos controles reducen la superficie de comandos, pero no demuestran que un intérprete o una utilidad permitidos no puedan ejecutar acciones destructivas. Prefiere las skills del espacio de trabajo que controlas a instalar cualquier paquete de ClawHub que parezca útil.

Qué poner en el scratch heartbeat (y qué no)

Utiliza el scratch del monitor de heartbeat (openclaw cron scratch <jobId> --set "...") como una lista de comprobación breve, no como una segunda base de datos de tareas:

Bueno: «Si disco > 90 % en host gateway, notificar. Si nada, HEARTBEAT_OK.» Malo: «Recuerda terminar la hoja de ruta Q3, escribir a Alice, refactorizar el agente y scrapear precios de competidores.»

El trabajo recurrente pertenece a automatizaciones con sus propios horarios. Un heartbeat que vuelve a inferir tareas a partir de chats antiguos es la vía por la que una instalación silenciosa se vuelve ruidosa y cara.

Probar aprobaciones antes de confiar en ellas

1. Establece tools.exec.mode en deny para una prueba que deniegue por defecto, o en ask con un documento local de aprobaciones del host al menos igual de restrictivo si deseas una confirmación.
2. Desde tus mensajes privados incluidos en la lista de permitidos, pide al agente que ejecute uname, o una prueba inofensiva equivalente.
3. Confirma que obtienes una denegación clara o una solicitud de aprobación, no una ejecución silenciosa.
4. Si pruebas las solicitudes, deja que una caduque o haz que la interfaz no esté disponible y confirma que askFallback: "deny" la bloquea. Cuando la política efectiva de solicitud sea always, confirma que el siguiente comando distinto vuelve a pedir aprobación.
5. Si hay un nodo emparejado, repite la prueba con la política de aprobación que se guarda por separado en ese nodo.
6. Desde una identidad que no esté en la lista de permitidos, confirma que no existe ninguna ruta hacia las herramientas.

Si el paso 3 tiene éxito sin el control configurado, examina tanto el modo exec solicitado como el documento local de aprobaciones del host de ejecución antes de activar el heartbeat.

Combinar con n8n cuando el trabajo es fontanería programada

El heartbeat sirve para comprobaciones periódicas que requieren el contexto del agente. Las consultas SaaS deterministas, los reintentos y las validaciones humanas suelen corresponder a n8n (idempotencia y validaciones humanas, transferencia por API o webhook de Hermes). Utiliza OpenClaw cuando la interfaz sea un chat; utiliza n8n cuando la interfaz conecte sistemas.

Checklist de operador

• Listas de permitidos de skills revisadas; skills no usadas eliminadas
• Ningún directorio de skill no confiable escribible por otros
• Intervalo del heartbeat y horas activas configurados con intención
• El target del heartbeat no spamea canales de grupo
• tools.exec.mode está configurado como deny o ask, y el documento local de aprobaciones del host de ejecución es igual de restrictivo o más
• Browser/search/fetch desactivados salvo que sean necesarios
• Herramientas elevadas desactivadas
• Ruta de aprobación probada con un comando inofensivo
• Auditoría reejecutada tras cada aumento de autonomía

Las skills hacen competente al agente. El heartbeat le permite actuar a tiempo. Una política exec restrictiva, una política del navegador, el sandboxing y los controles de identidad de los canales reducen la probabilidad de que esa competencia y puntualidad se conviertan en acciones desatendidas sobre el host. Ajusta esos controles en ese orden y solo hasta donde lo justifique tu modelo de amenazas.