OpenClaw-Skills, Heartbeat-Autonomie und Freigabestufen

Sobald OpenClaw installiert und die Kanalidentität abgesichert ist (Einrichtung, Allowlists und Pairing), folgt die nächste Fähigkeitsebene: Skills, regelmäßige Heartbeat-Durchläufe, die Freigaberichtlinie für die Host-Shell und die Entscheidung, ob Browserautomatisierung innerhalb eines geprüften Workflows aktiviert wird.

Wichtige Dokumentation: Skills, Heartbeat, Sicherheit.

Heartbeat in Verbindung mit uneingeschränktem Host-exec oder Browserautomatisierung in einem wertvollen angemeldeten Konto ermöglicht unbeaufsichtigte Aktionen mit den Zugangsdaten und Berechtigungen, die über diese Oberfläche erreichbar sind. Aktivieren Sie regelmäßige Durchläufe erst, wenn die Toolrichtlinie zu Ihrem Bedrohungsmodell passt. Das gilt besonders, wenn nicht nur Sie selbst den Agenten über einen Kanal auslösen können.

Skills: Was sie sind

Skills sind Markdown-Anweisungspakete (SKILL.md mit YAML-Frontmatter und Inhalt), die dem Agenten vermitteln, wie und wann er Tools einsetzen soll. OpenClaw lädt mitgelieferte Skills und lokale Überschreibungen und filtert sie beim Laden anhand der Umgebung, der Konfiguration und der Verfügbarkeit erforderlicher Programme.

Vorrang (höchster zuerst), gemäß aktueller Dokumentation:

1. Workspace-Skills
2. Projekt-Agent-Skills
3. Persönliche Agent-Skills (~/.agents/skills im Standardzustand)
4. Verwaltete oder lokale Skills im OpenClaw-Zustandsverzeichnis
5. Mitgelieferte Skills
6. Zusätzliche Verzeichnisse oder Plugin-Skills

Wenn derselbe Skill-Name an mehreren Stellen vorkommt, hat die weiter oben stehende Quelle Vorrang. Behandeln Sie Skill-Ordner als vertrauenswürdigen Code: Wer sie ändern kann, kann auch das Verhalten des Agenten verändern.

Allowlists für sichtbare Skills

Speicherort und Vorrang sind von der Sichtbarkeit über eine Allowlist pro Agent getrennt. Die Dokumentation zeigt beispielsweise folgende Struktur:

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

Lassen Sie die Standardlisten für Skills nur weg, wenn Sie bewusst eine breite Oberfläche zulassen möchten. Beginnen Sie bei persönlichen Gateways mit einer engen Auswahl: Skills, die Sie gelesen haben, die zu den installierten Programmen passen und die Sie für tatsächlich ausgeführte Aufgaben benötigen.

Community-Skills und Plugins bilden eine Softwarelieferkette. Ihre Installation kann Code ausführen und den Toolumfang erweitern. Bevorzugen Sie offizielle Dokumentation und selbst geprüfte Skills; nutzen Sie security.installPolicy, wenn Sie vom Betreiber festgelegte Zulassungs- und Sperrentscheidungen auf dem Host durchsetzen.

Auf einem Knoten gehostete Skills erscheinen nur, solange der gekoppelte Knoten verbunden ist. Ihre Dateien, referenzierten Pfade und Programme verbleiben auf diesem Knoten; die Ausführung verwendet exec host=node node=<node-id>. Das anfängliche Pairing der Knotenrolle genehmigt die Veröffentlichung der Skills. Spätere Änderungen erfordern einen Neustart des Knotens, aber kein erneutes Pairing. Die Exec-Richtlinie des Agenten und die hostlokale Freigaberichtlinie des Knotens bestimmen weiterhin, was ausgeführt werden darf.

Heartbeat: Ein Puls, kein zweites Gehirn

Heartbeat führt regelmäßige Agentendurchläufe in der Hauptsitzung aus. So kann das Modell melden, was Aufmerksamkeit erfordert, ohne Sie mit Nachrichten zu überfluten. Es handelt sich um einen geplanten Durchlauf der Hauptsitzung, nicht um einen eigenständigen Hintergrundauftrag.

Voreinstellungen (für Ihre Version prüfen):

• Das Intervall beträgt häufig 30m (bei Anthropic-Einrichtungen mit OAuth oder Token kann der Standardwert höher liegen; die Dokumentation nennt in diesem Fall 1h)
• Setzen Sie agents.defaults.heartbeat.every (nutzen Sie 0m, um zu deaktivieren)
• Der Standard-Prompt weist den Agenten an, den Heartbeat-Monitor-Notizbereich zu beachten, keine wiederkehrenden Aufgaben aus alten Chats zu erfinden und mit HEARTBEAT_OK zu antworten, wenn nichts Aufmerksamkeit erfordert

Beispiel:

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

Praktische Hinweise:

• Behalten Sie target: "none" bei, solange keine Zustellung gewünscht ist; setzen Sie target: "last" nur, wenn Nachrichten an den letzten Kontakt akzeptabel sind.
• Nutzen Sie activeHours, damit nachts in Ihrer Zeitzone keine Meldungen eingehen.
• Legen Sie wiederkehrende Arbeiten in Automatisierungen oder Cron-Jobs ab, nicht in informellen Heartbeat-Notizen; die Heartbeat-Dokumentation betont diese Trennung.
• Geplante Heartbeats erfordern aktivierte Automatisierungen; ist Cron deaktiviert, werden sie nicht ausgeführt.

Antwortvertrag: HEARTBEAT_OK am Anfang oder Ende gilt als Bestätigung und wird unterdrückt, wenn der übrige Inhalt kurz ist. Warnmeldungen sollten HEARTBEAT_OK weglassen und nur den eigentlichen Meldungstext zurückgeben.

Heartbeat-Durchläufe können weiterhin alle Tools nutzen, auf die der Agent Zugriff hat. Auch eine „harmlose Routineprüfung“ mit erlaubtem exec bietet regelmäßig die Gelegenheit, dass durch Prompt-Injection manipulierter Inhalt im Gedächtnis oder auf abgerufenen Seiten Shell-Aktionen anfordert. Kombinieren Sie Heartbeat mit Toolrichtlinien, die Aktionen sperren oder eine Rückfrage verlangen.

Freigabestufen für Shell und Browser

Das Sicherheitsmodell von OpenClaw behandelt Exec-Freigaben als Schutz der vom Betreiber beabsichtigten Aktionen, nicht als Isolation gegenüber böswilligen Mandanten. Bei persönlichen Gateways entscheiden sie dennoch darüber, ob das System nachfragt oder einen Befehl einfach ausführt.

Exec

Die aktuelle Referenz zu Exec-Freigaben nennt folgende wichtige Einstellungen. Gleichen Sie sie mit dem Schema Ihrer installierten Version ab:

• tools.exec.mode ist die maßgebliche dauerhaft gespeicherte Richtlinie für Host-Ausführungen: deny, allowlist, ask, auto oder full.
• auto leitet nicht durch die Allowlist abgedeckte Freigaben zunächst an den integrierten OpenClaw-Prüfer und danach gegebenenfalls an einen Menschen weiter. Dieser Komfortweg beweist nicht, dass ein Befehl sicher ist.
• Bei Ausführungen auf Gateway oder Knoten wird zusätzlich das lokale Freigabedokument des ausführenden Hosts berücksichtigt. Wirksam ist jeweils die strengere Vorgabe aus Konfiguration und hostlokalem Dokument.
• askFallback greift, wenn eine Rückfrage nötig ist, aber keine Benutzeroberfläche erreichbar ist oder die Anfrage abläuft. Der Standardwert ist deny; behalten Sie ihn bei, damit ein Ausfall des Freigabewegs den Zugriff nicht erweitert.
• Allowlists gelten pro Agent. Verwenden Sie eng eingegrenzte Programmpfade und gegebenenfalls argPattern; strictInlineEval schafft eine zusätzliche Schutzebene, wenn Interpreter auf der Allowlist stehen.
• tools.exec.host: "auto" verwendet bei aktiver Sandbox die Sandbox, andernfalls das Gateway. Die Ausführung auf einem Knoten erfordert einen gekoppelten Knoten und dessen eigenen hostlokalen Freigabestatus.

Beginnen Sie mit tools.exec.mode: "deny" oder, wenn Rückfragen erforderlich sind, mit mode: "ask" und einem mindestens ebenso restriktiven hostlokalen Freigabedokument. Lassen Sie privilegierte Tools deaktiviert. Die Ausführung auf Gateway- und Knoten-Hosts verwendet andernfalls standardmäßig full, die Ausführung in einer Sandbox hingegen deny. Verschärfen Sie die Hostrichtlinie, bevor Kanäle, Skills oder Heartbeat den möglichen Schadensradius vergrößern.

Der Knotenbefehl system.run auf einem gekoppelten Mac ermöglicht entfernte Codeausführung auf diesem Mac. Pairing ist keine Freigabe für jeden einzelnen Befehl; die Knotenbefehlsrichtlinie des Gateways und die hostlokale Freigaberichtlinie des Knotens bilden gemeinsam die Ausführungsgrenze. Um die entfernte Shell-Ausführung zu deaktivieren, setzen Sie den angeforderten Exec-Modus auf deny und halten Sie die hostlokale Freigaberichtlinie des Knotens restriktiv. Entfernen Sie alternativ die Knotenrolle und das Pairing, wenn Sie beides nicht benötigen.

Browser

Die Browsersteuerung ist eine Oberfläche für Betreiber und kann navigieren, Seiten lesen und Inhalte auswerten. Behandeln Sie die entfernte Erreichbarkeit von Browser oder CDP wie einen Betreiberzugang: nur über Loopback oder einen bewusst geschützten privaten Pfad, niemals über einen öffentlichen CDP- oder Steuerendpunkt. Verwenden Sie das dedizierte Browserprofil openclaw, das von Ihrem alltäglichen Browserprofil getrennt ist, und lassen Sie Browser-Plugin und -Tool deaktiviert, bis eine geprüfte Aufgabe sie benötigt. Exec-Freigaben schaffen keine Freigabegrenze für einzelne Klicks. Verlangen Sie daher vor folgenreichen Übermittlungen, Käufen, Veröffentlichungen oder Kontoänderungen eine menschliche Bestätigung im Workflow.

Prompt-Injection über abgerufene Seiten ist ein wesentliches Risiko. Toolrichtlinien zum Zulassen oder Sperren, getrennte Browserprofile, ausdrückliche Bestätigung im Workflow und Sandboxing begrenzen den möglichen Schaden; Kanal-Allowlists bleiben dennoch erforderlich.

Privilegierte Tools

tools.elevated verlässt die Sandbox. Begrenzen Sie allowFrom eng. Aktivieren Sie den privilegierten Modus weder für Fremde noch für große Nutzergruppen in einem Kanal.

Eine sinnvolle Abstufung der Autonomie

Gehen Sie erst dann zur nächsten Stufe über, wenn Sie openclaw security audit ausgeführt und genügend Läufe aufbewahrt haben, um Normalbetrieb, Sperrpfade, ablaufende Freigaben und Wiederherstellung zu erproben. Eine feste Anzahl von Tagen beweist keine Sicherheit.

Einen kleinen internen Skill schreiben

Ein minimal nützlicher Skill ist ein Ordner mit SKILL.md:

---
name: disk-check
description: Prüft die Festplattennutzung auf dem Gateway-Host, wenn nach Festplatte oder Kapazität gefragt wird.
---

Wenn der Nutzer nach Festplattenspeicher auf diesem Host fragt:

1. Führen Sie nur den per Allowlist zugelassenen `df`-Aufruf aus, den Ihre Exec-Richtlinie erlaubt.
2. Fassen Sie die Dateisystemnutzung in drei Punkten zusammen.
3. Installieren Sie keine Pakete und löschen Sie keine Dateien.

Formulieren Sie die Beschreibung konkret, damit der Agent weiß, wann er den Skill einsetzen soll. Kombinieren Sie ihn mit einem eng begrenzten Exec-Modus, geprüften Befehls- und Argumentregeln pro Agent, strictInlineEval sowie einer Sandbox oder Isolation auf Betriebssystemebene. Diese Kontrollen verkleinern die Befehlsoberfläche; sie beweisen nicht, dass ein zugelassener Interpreter oder ein Hilfsprogramm keine destruktiven Aktionen ausführen kann. Bevorzugen Sie kontrollierte Workspace-Skills, statt jedes scheinbar praktische ClawHub-Paket zu übernehmen.

Was in die Heartbeat-Notizen gehört (und was nicht)

Nutzen Sie den Notizbereich des Heartbeat-Monitors (openclaw cron scratch <jobId> --set "...") als kurze Checkliste, nicht als zweite Aufgabendatenbank:

Gut: „Wenn Festplatte > 90 % auf dem Gateway-Host, benachrichtigen. Wenn nichts, HEARTBEAT_OK.“ Schlecht: „Denken Sie daran, die Q3-Roadmap fertigzustellen, Alice zu mailen, den Agenten zu refaktorieren und Wettbewerberpreise zu scrapen.“

Wiederkehrende Aufgaben gehören in Automatisierungen mit eigenen Zeitplänen. Wenn Heartbeat Aufgaben aus alten Chats neu ableitet, werden ruhige Installationen schnell laut und teuer.

Freigaben testen, bevor Sie ihnen vertrauen

1. Setzen Sie tools.exec.mode für einen Fail-closed-Test auf deny. Wenn Sie eine Rückfrage testen möchten, verwenden Sie ask zusammen mit einem mindestens ebenso restriktiven hostlokalen Freigabedokument.
2. Bitten Sie den Agenten in Ihrer per Allowlist zugelassenen Direktnachricht, uname oder einen vergleichbaren harmlosen Prüfbefehl auszuführen.
3. Prüfen Sie, ob der Befehl sauber abgelehnt oder eine Freigabe angefordert wird, statt unbemerkt erfolgreich zu sein.
4. Wenn Sie Rückfragen testen, lassen Sie eine Anfrage ablaufen oder machen Sie die Benutzeroberfläche unerreichbar. Prüfen Sie, ob askFallback: "deny" die Ausführung blockiert. Steht die wirksame Rückfragerichtlinie auf always, muss auch der nächste andere Befehl erneut nachfragen.
5. Ist ein Knoten gekoppelt, wiederholen Sie den Test mit dessen separat gespeicherter Freigaberichtlinie.
6. Vergewissern Sie sich mit einer nicht per Allowlist zugelassenen Identität, dass kein Toolpfad erreichbar ist.

Wenn Schritt 3 trotz der konfigurierten Freigabestufe gelingt, prüfen Sie sowohl den angeforderten Exec-Modus als auch das lokale Freigabedokument des ausführenden Hosts, bevor Sie Heartbeat aktivieren.

Mit n8n kombinieren, wenn die Aufgabe planbare Systemintegration ist

Heartbeat eignet sich für Routineprüfungen, die eine Bewertung durch den Agenten erfordern. Deterministische SaaS-Abfragen, Wiederholungslogik und menschliche Freigaben gehören häufig in n8n (Idempotenz und menschliche Freigaben, Übergabe an Hermes per API oder Webhook). Nutzen Sie OpenClaw, wenn Menschen per Chat interagieren; nutzen Sie n8n für die Integration von Systemen.

Checkliste für Betreiber

• Skill-Allowlists geprüft; ungenutzte Skills entfernt
• Keine nicht vertrauenswürdigen Skill-Verzeichnisse sind für andere beschreibbar
• Heartbeat-Intervall und aktive Zeiten bewusst festgelegt
• Heartbeat-Ziel überflutet keine Gruppenkanäle mit Nachrichten
• tools.exec.mode ist deny oder ask, und das lokale Freigabedokument des ausführenden Hosts ist ebenso restriktiv oder restriktiver
• Browser, Suche und Abruf deaktiviert, sofern nicht erforderlich
• Privilegierte Tools deaktiviert
• Freigabeweg mit einem harmlosen Befehl getestet
• Audit nach jeder Autonomie-Erhöhung erneut ausgeführt

Skills machen den Agenten kompetent. Heartbeat sorgt für zeitnahe Reaktionen. Restriktive Exec- und Browserrichtlinien, Sandboxing und Kontrollen der Kanalidentität verringern das Risiko, dass Kompetenz und regelmäßige Ausführung zu unbeaufsichtigten Aktionen auf dem Host führen. Erweitern Sie diese Fähigkeiten in genau dieser Reihenfolge und nur so weit, wie es Ihr Bedrohungsmodell rechtfertigt.