TL;DR

  • Risk level: High
  • Who is affected: Anyone running OpenClaw with heartbeat enabled and any skill or integration that pulls remote instructions
  • Main issue: The heartbeat prompt explicitly tells the agent to read HEARTBEAT.md and follow it strictly. If that file is populated from the internet, you’ve created a remote control loop.
  • Core problem: Domain compromise or skill updates can silently change what your agent does.
  • Mitigation: Keep heartbeat local, pin/verify instruction sources, require approval on changes, and isolate heartbeat agents from secrets.

What “Fetch-and-Follow” Means in OpenClaw

OpenClaw’s heartbeat is a scheduled agent run. By default it runs every 30 minutes and sends a heartbeat prompt verbatim as the user message, telling the agent to read HEARTBEAT.md and follow it strictly. In other words, the heartbeat is designed to execute instructions from a file on every cycle.

That’s safe when the file is local and controlled. It becomes risky when the file is fetched from a remote URL or updated by a skill without human review.

Typical pattern:

  1. Install a skill from a URL (SKILL.md) that sets up integration logic.
  2. The skill writes or refreshes HEARTBEAT.md from a remote endpoint.
  3. The heartbeat loop executes whatever the file says on every cycle.

This is the “fetch-and-follow” loop: fetch instructions from the internet -> follow them automatically -> repeat.

Why This Is Structurally Risky

1) Automatic execution

Heartbeat instructions are followed on a schedule, not on human approval. If the instruction source changes, your agent changes with it.

2) No integrity guarantees

Most setups don’t cryptographically sign instructions. A compromised domain or repo can silently ship malicious steps.

3) Persistent control surface

A periodic fetch means repeated opportunities for compromise. One successful change can trigger ongoing unwanted actions.

4) Privileged context

Heartbeat runs with the same tool access and credentials you granted the agent. If your agent can read files, execute commands, or message your team, so can the heartbeat.

Model Tier Reality Check (Why “Better Models” Don’t Fix This)

OpenClaw’s security guidance is explicit: prompt injection is unsolved, and system prompts are “soft” guidance. Hard enforcement comes from tool policy, approvals, sandboxing, and allowlists–not model choice.

The docs also warn that smaller/cheaper tiers are more susceptible to prompt injection. So model tier choice matters–but it does not fix the fetch-and-follow risk. The risk is architectural: a trusted loop that can be reprogrammed remotely.

Practical takeaway:

  • Use stronger tiers if you must run tool-enabled agents.
  • Treat model choice as a risk reducer, not a risk eliminator.

If you want a full token-window comparison by tier, that belongs in the model comparison hub (see /compare/models/*).

Real-World Signal: The Moltbook Heartbeat Loop

Moltbook’s onboarding flow popularized this pattern. Agents are instructed to check a remote heartbeat.md file every few hours and execute its contents. That’s fetch-and-follow in plain sight.

The broader lesson: if a platform can change the instructions your agent executes, platform compromise becomes agent compromise–no malware required.

Why This Matters Right Now

Security researchers at Wiz recently reported a Moltbook exposure that leaked platform data at scale, including API tokens and private messages. Even if your local OpenClaw instance is hardened, a platform breach can still become your agent’s breach when the platform controls the instructions your agent follows.

What Can Go Wrong (Concrete Scenarios)

  • Domain compromise: Attacker gains control of example.com/heartbeat.md -> agent starts exfiltrating files.
  • Supply-chain rug pull: Skill author updates instructions after you trust them -> agent behavior changes silently.
  • Credential spill: If your heartbeat has access to API keys or filesystem tools, those can be abused.

Mitigations That Actually Help

Keep heartbeat local

  • Use a static, locally stored HEARTBEAT.md that you edit manually.
  • Avoid “self-updating” heartbeat files unless you have integrity checks.

Pin and verify instructions

  • Pin to immutable versions (commit hashes, release tags).
  • Hash remote instruction files and compare before execution.

Require approval on changes

  • Block heartbeat runs when the file changes until a human reviews the diff.
  • Log heartbeat diffs and alert on unexpected updates.

Isolate heartbeat agents

  • Run heartbeat agents on separate machines/containers with no secrets.
  • Disable command execution and file access unless strictly needed.

Split roles

  • Use a reader agent to fetch and summarize updates.
  • Use a separate actor agent that only executes approved tasks.

Who Should Avoid Fetch-and-Follow

  • Teams with production credentials or sensitive data in the same environment
  • Organizations that require auditability and deterministic change control
  • Anyone without capacity to monitor and verify instruction updates

Evidence / Signals

SignalStatusSource
Heartbeat prompt instructs agent to read HEARTBEAT.md and follow itConfirmedOpenClaw heartbeat docs
Heartbeat runs on a schedule with configurable intervalConfirmedOpenClaw heartbeat docs
System prompts are soft guidance; hard controls are tool policies and approvalsConfirmedOpenClaw security docs
Smaller model tiers are more susceptible to prompt injectionConfirmedOpenClaw security docs
Moltbook instructs periodic remote heartbeat fetchingConfirmedSimon Willison analysis

What Would Change This Assessment

  • Cryptographically signed heartbeat instructions with mandatory verification
  • Built-in approval workflows for instruction changes
  • Immutable instruction endpoints (content-addressed, not mutable URLs)
  • Default isolation profiles for heartbeat-enabled agents

AIHackers Verdict

Fetch-and-follow is a powerful automation pattern–but it’s remote control by design. In OpenClaw, the heartbeat loop is a feature. The risk appears when that loop is fed by mutable remote instructions without integrity checks.

Bottom line: Treat fetch-and-follow as a privileged control plane. If you need it, lock it down. If you don’t, keep heartbeat local and static.

What to Do Next

Already using heartbeat? Secure your deployment – isolation and containment checklist.

Want a safer default? OpenClaw safe setup – baseline hardening guide.

Need the broader context? OpenClaw security reality check – full incident timeline.

Sources