OpenClaw skills, autonomi med heartbeat och godkännandekontroller

När OpenClaw är installerat och kanalidentiteten är låst (installation, tillåtelselistor och parning) är nästa lager agentens förmågor: skills, periodiska heartbeat-körningar, policy för godkännande av kommandokörning på värden och beslutet om webbläsarautomatisering ska aktiveras i ett granskat arbetsflöde.

Dokumentation: Skills, Heartbeat, Security.

Heartbeat tillsammans med obegränsad exec på värden, eller webbläsarautomatisering i en profil med värdefulla aktiva inloggningar, möjliggör oövervakade åtgärder med de autentiseringsuppgifter och den åtkomst som ytan exponerar. Aktivera periodiska körningar först när verktygspolicyn motsvarar hotmodellen, särskilt om någon annan än du kan utlösa agenten via en kanal.

Skills: vad de är

Skills är instruktionspaket i Markdown (SKILL.md med YAML-frontmatter och brödtext) som lär agenten hur och när den ska använda verktyg. OpenClaw läser in medföljande skills och lokala åsidosättningar och filtrerar dem utifrån miljö, konfiguration och tillgången till nödvändiga binärfiler.

Prioritetsordning, högst först, enligt den aktuella dokumentationen:

1. Workspace-skills
2. Projektagent-skills
3. Personliga agent-skills (~/.agents/skills i standardläge)
4. Hanterade eller lokala skills under OpenClaws tillståndskatalog
5. Medföljande skills
6. Extra kataloger / plugin-skills

När samma namn på en skill förekommer på flera ställen vinner källan med högst prioritet. Behandla skill-mappar som betrodd kod: den som kan ändra dem kan också ändra agentens beteende.

Tillåtelselistor för vilka skills en agent ser

Placering i prioritetsordningen och synlighet genom en tillåtelselista per agent är två skilda saker. Exempelstruktur från dokumentationen:

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

Utelämna bara listorna över standardskills när du medvetet vill ge agenten en bred verktygsyta. Börja snävt för personliga gateways: använd skills som du har läst, som motsvarar de binärfiler du installerar och som behövs för uppgifter du faktiskt kör.

Skills och insticksprogram från gemenskapen ingår i en leveranskedja. En installation kan köra kod och utöka verktygsytan. Föredra officiell dokumentation och skills som du har granskat. Använd security.installPolicy om operatören styr beslut om att tillåta eller blockera installationer på värden.

Skills som finns på en nod visas bara medan den parade noden är ansluten. Filerna, de refererade sökvägarna och binärfilerna stannar på noden, och körningen använder exec host=node node=<node-id>. Den första parningen av nodrollen godkänner att nodens skills publiceras. Senare ändringar av en skill kräver att noden startas om, inte att den paras på nytt. Agentens exec-policy och nodens lokala godkännandepolicy styr fortfarande körningen.

Heartbeat: en puls, inte en andra hjärna

Heartbeat kör periodiska agentkörningar i huvudsessionen så att modellen kan uppmärksamma dig på sådant som behöver hanteras utan att skicka onödigt många meddelanden. Det är en schemalagd körning i huvudsessionen, inte en separat bakgrundsuppgift.

Standardvärden (verifiera på din version):

• Intervallet är ofta 30m (konfigurationer med Anthropic OAuth eller token kan få ett högre standardvärde när inget anges; dokumentationen anger 1h i det fallet)
• Sätt agents.defaults.heartbeat.every (använd 0m för att inaktivera)
• Standardprompten säger åt agenten att följa heartbeat-monitorns tillfälliga anteckning, inte hitta på återkommande arbete utifrån gamla chattar, och svara HEARTBEAT_OK när inget behöver uppmärksamhet

Exempel:

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

Praktisk vägledning:

• Behåll target: "none" tills du vill ha leveranser; sätt target: "last" endast när du accepterar pingar till senaste kontakten.
• Använd activeHours så att nattliga pulser hålls tysta i din tidszon.
• Lägg återkommande arbete i automatiseringar eller cron-jobb, inte i inofficiella anteckningar för heartbeat. Heartbeat-dokumentationen betonar den uppdelningen.
• Schemalagda heartbeats kräver att automatiseringar är aktiverade; om cron är inaktiverat körs inte schemalagda heartbeats.

Svarskontrakt: HEARTBEAT_OK i början eller slutet behandlas som en kvittens och döljs när resten av innehållet är kort. Aviseringar ska utelämna HEARTBEAT_OK och bara returnera aviseringstexten.

Heartbeat-körningar använder fortfarande alla verktyg som agenten kan nå. En ”harmlös kontroll” med tillåten exec ger fortfarande promptinjicerat innehåll i minnet eller på hämtade sidor en schemalagd möjlighet att begära skalåtgärder. Kombinera heartbeat med en verktygspolicy som nekar eller begär godkännande.

Godkännandekontroller för skal och webbläsare

OpenClaws säkerhetsmodell behandlar exec-godkännanden som skydd för operatörens avsikt, inte som isolering mellan sinsemellan fientliga användare. För personliga gateways utgör de ändå skillnaden mellan ”fråga mig” och ”kör direkt”.

Exec

Relevanta kontroller från den aktuella referensen för exec-godkännanden; bekräfta dem i schemat som följer med din installerade version:

• tools.exec.mode är den beständiga, auktoritativa policyn för exec på värden: deny, allowlist, ask, auto eller full.
• auto skickar kommandon som inte matchar godkännandepolicyn genom OpenClaws inbyggda granskare innan de vid behov går vidare till en människa. Det är en bekvämlighetsfunktion, inte ett bevis på att kommandot är säkert.
• Körning på gateway och nod använder även det lokala godkännandedokumentet på värden där kommandot körs. Den effektiva policyn är den striktare av konfigurationen och det lokala dokumentet.
• askFallback gäller när en bekräftelse krävs men inget gränssnitt kan nås eller tidsgränsen löper ut. Standardvärdet är deny. Behåll det så att en otillgänglig godkännandeväg inte utökar åtkomsten.
• Tillåtelselistor gäller per agent. Använd snävt avgränsade sökvägar till körbara filer och argPattern där det passar. strictInlineEval ger ytterligare försvar på djupet när tolkprogram finns i tillåtelselistan.
• tools.exec.host: "auto" väljer sandlådan när en sådan är aktiv och gatewayen annars. Körning på en nod kräver en parad nod och dess eget lokala godkännandetillstånd.

Börja med tools.exec.mode: "deny", eller med mode: "ask" och ett minst lika restriktivt lokalt godkännandedokument på värden när du behöver bekräftelsefrågor. Håll förhöjda verktyg avstängda. Exec på gateway- och nodvärdar använder annars full som standard, medan exec i sandlådan nekas som standard. Skärp värdpolicyn innan kanaler, skills eller heartbeat ökar skadeområdet.

Node system.run på en parad Mac är fjärrkörning av kod på den Macen. Parning är inte ett godkännande per kommando. Gatewayens policy för nodkommandon och nodens egna exec-godkännanden bildar körningsgränsen. Inaktivera fjärrkörning i skalet genom att sätta begärt exec-läge till deny och hålla nodens lokala godkännandepolicy restriktiv, eller ta bort nodrollen och parningen om du inte behöver dem.

Webbläsare

Webbläsarstyrning är en yta på operatörsnivå som kan navigera, läsa sidor och köra uttryck. Behandla exponering av en fjärrwebbläsare eller CDP som operatörsåtkomst: använd loopback eller en avsiktligt skyddad privat väg och publicera ingen CDP- eller kontrollslutpunkt. Använd den särskilda webbläsarprofilen openclaw, som är isolerad från din vanliga profil, och håll webbläsarinsticksprogrammet eller verktyget avstängt tills en granskad uppgift behöver det. Exec-godkännanden skapar inte en godkännandegräns för varje klick i webbläsaren. Kräv mänsklig bekräftelse i arbetsflödet före betydelsefulla formulärinskick, köp, publiceringar eller kontoändringar.

Promptinjektion via hämtade sidor är en central risk. Verktygens policy för att tillåta eller neka, isolering av webbläsarprofilen, uttrycklig bekräftelse i arbetsflödet och sandlådan minskar skadeområdet, men tar inte bort behovet av kanaltillåtelselistor.

Förhöjda verktyg

tools.elevated kör utanför sandlådan. Håll allowFrom strikt. Aktivera inte det förhöjda läget för främlingar eller stora grupper av kanalanvändare.

En sund autonomistege

Flytta upp ett steg först efter openclaw security audit och tillräckligt många sparade körningar för att täcka normalt arbete, nekade vägar, timeout för godkännande och återställning. Ett fast antal dagar är inget bevis på säkerhet.

Skriva en liten intern skill

En minsta användbar skill är en mapp med SKILL.md:

---
name: disk-check
description: Kontrollera diskutrymmet på gateway-värden när användaren frågar om diskutrymme eller kapacitet.
---

När användaren frågar om diskutrymme på den här värden:

1. Kör endast det tillåtelselistade `df`-anrop som din exec-policy medger.
2. Sammanfatta filsystemens utrymmesanvändning i tre punkter.
3. Installera inga paket och radera inga filer.

Håll beskrivningen konkret så att agenten vet när den ska användas. Kombinera skillen med ett snävt exec-läge, granskade kommando- och argumentregler per agent, strictInlineEval samt en sandlåda eller OS-isolering. Kontrollerna minskar kommandoytan men bevisar inte att ett tillåtet tolkprogram eller en hjälpprocess saknar förmåga att utföra destruktivt arbete. Föredra workspace-skills som du kontrollerar framför att installera varje bekvämt ClawHub-paket.

Vad som ska finnas i heartbeat-anteckningen, och vad som inte ska finnas där

Använd heartbeat-monitorns tillfälliga anteckning (openclaw cron scratch <jobId> --set "...") som en kort checklista, inte som en andra uppgiftsdatabas:

Bra: “Om disk > 90 % på gateway-hosten, meddela. Om inget, HEARTBEAT_OK.” Dåligt: “Kom ihåg att slutföra färdplanen för Q3, mejla Alice, omstrukturera agenten och hämta konkurrenternas priser.”

Återkommande arbete hör hemma i automatiseringar med egna scheman. Om heartbeat försöker härleda uppgifter på nytt ur gamla chattar blir en stillsam installation lätt både störande och dyr.

Testa godkännanden innan du litar på dem

1. Sätt tools.exec.mode till deny för ett test som fallerar stängt, eller till ask med ett lokalt godkännandedokument på värden som är minst lika restriktivt när du vill ha en bekräftelsefråga.
2. Be agenten köra uname, eller en motsvarande harmlös kontroll, från din identitet som finns i DM-tillåtelselistan.
3. Bekräfta att du får ett tydligt avslag eller en godkännandefråga, inte att kommandot lyckas utan meddelande.
4. Om du testar bekräftelsefrågor låter du en begäran löpa ut eller gör gränssnittet otillgängligt och bekräftar att askFallback: "deny" blockerar den. När den effektiva ask-policyn är always bekräftar du att nästa separata kommando frågar igen.
5. Om en nod är parad upprepar du testet mot nodens separat lagrade godkännandepolicy.
6. Från en icke-tillåtelselistad identitet bekräftar du att ingen verktygsväg finns.

Om steg 3 lyckas utan den konfigurerade kontrollpunkten granskar du både begärt exec-läge och det lokala godkännandedokumentet på värden där kommandot kördes innan du aktiverar heartbeat.

Kombinera med n8n för schemalagda integrationsflöden

Heartbeat är till för kontroller som kräver agentens bedömning. Deterministisk avläsning av SaaS-tjänster, omförsök och mänskliga kontrollpunkter hör ofta hemma i n8n (idempotens och mänskliga kontrollpunkter, överlämning till Hermes API eller webhook). Använd OpenClaw när gränssnittet är en chatt och n8n när gränssnittet är andra system.

Operatörschecklista

• Skill-tillåtelselistor granskade; oanvända skills borttagna
• Inga obetrodda skill-kataloger kan skrivas av andra
• Heartbeat-intervall och aktiva timmar har angetts medvetet
• Heartbeat-målet skickar inte onödigt många meddelanden till gruppkanaler
• tools.exec.mode är deny eller ask, och det lokala godkännandedokumentet på värden där kommandot körs är lika eller mer restriktivt
• Webbläsare, sökning och hämtning är avstängda om de inte behövs
• Förhöjda verktyg är avstängda
• Godkännandeväg testad med ett harmlöst kommando
• Säkerhetsgranskningen körs om efter varje ökning av autonomin

Skills ger agenten förmåga. Heartbeat gör att den agerar i rätt tid. En restriktiv exec-policy, webbläsarpolicy, sandlåda och kontroll av kanalidentitet minskar risken att förmåga och tidpunkt leder till oövervakade åtgärder på värden. Utöka dem i den ordningen och bara så långt hotmodellen motiverar.