Pilot Heartbeat Monitor
Security checks across static analysis, malware telemetry, and agentic risk
Overview
The skill appears to do what it says—monitor Pilot agents with shell commands—but it can run ongoing heartbeat loops and affect swarm failover, so use it only in a trusted, supervised Pilot environment.
Install this only if you already use Pilot Protocol and trust the local pilotctl setup. Before running the examples, verify the registry host, swarm name, agent ID, timeout values, and how to stop any background loops. Avoid enabling automatic failover or re-election in production until you have tested the behavior and confirmed peer identity/trust settings.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If run with the wrong registry, swarm name, or agent variables, the commands could publish or query heartbeat state in the wrong Pilot environment.
The skill authorizes Bash examples that interact with the Pilot network through pilotctl. This is expected for heartbeat monitoring, but it is still command/tool authority that users should run in the intended swarm only.
allowed-tools:\n - Bash\n...\npilotctl --json publish ...\npilotctl --json inbox ...\npilotctl --json ping "$AGENT_ADDR"
Review REGISTRY_HOST, SWARM_NAME, AGENT_ID, and peer settings before running; avoid letting an agent automate disruptive failover steps without testing.
A misconfigured heartbeat timeout could cause unnecessary failover, duplicated work, or leadership churn in a swarm.
The stated purpose includes automatic redistribution or leader re-election based on failure detection. That is purpose-aligned, but false positives or overly aggressive timeouts could affect multiple agents or tasks.
Detect agent failures and trigger automatic task redistribution or re-election.
Test heartbeat intervals and timeouts in a safe environment, and consider confirmation or additional checks before production redistribution or re-election.
If copied as-is, the process may keep sending heartbeats or monitoring in the background after the immediate task is over.
The workflow example starts a background heartbeat sender and a continuous monitoring loop. This is disclosed and aligned with monitoring, but it can continue running until explicitly stopped.
(\n while true; do\n pilotctl --json publish "$REGISTRY_HOST" "heartbeat:$SWARM_NAME" ...\n sleep $HEARTBEAT_INTERVAL\n done\n) &\n\n# Monitor peer heartbeats\nwhile true; do
Run it under a supervisor, terminal session, or service you control, and document how to stop the background process.
Untrusted or misconfigured peer messaging could make health status unreliable and influence failover decisions.
The skill relies on registry/inbox heartbeat messages between agents. The artifact does not describe identity validation, so users should ensure Pilot registry and peer trust are configured appropriately.
pilotctl --json publish "$REGISTRY_HOST" "heartbeat:$SWARM_NAME" --data "{\"agent\":\"$AGENT_ID\",\"timestamp\":...}"\n...\npilotctl --json inbox | jq ... select(.topic == "heartbeat:$SWARM_NAME")Use trusted Pilot registries and peers, and verify what authentication or identity guarantees pilotctl provides before relying on automatic recovery.
The skill may fail or behave differently if those dependencies are missing, outdated, or installed from an untrusted source.
The registry requirements list pilotctl, while SKILL.md also references jq, bc, and the pilot-protocol skill. This is not suspicious by itself, but users must obtain and trust those external dependencies.
Requires pilot-protocol skill, jq, and bc.
Install pilotctl, jq, bc, and any Pilot Protocol components from trusted sources and verify their versions.