Pilot Swarm Config
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This skill’s purpose is legitimate, but its example workflow can automatically accept and spread swarm configuration changes from a registry without showing sender/authentication checks or human approval.
Review this skill carefully before use in any real swarm. Only run it against a trusted Pilot registry, restrict who can publish to config channels, require signed/authenticated config updates, and add validation plus staged approval before agents automatically apply changes.
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.
A bad or unauthorized config update could be adopted by many agents and change their behavior at once.
The documented workflow can continuously propagate and apply configuration changes across many agents, but it does not show staged rollout, approval, containment, or safeguards before applying the update.
Use this skill when: ... You need to push config updates to all swarm members ... while true; do ... if [ "$LATEST_VERSION" -gt "$CURRENT_VERSION" ]; then ... echo "$CONFIG_DATA" > /tmp/swarm-config.json
Use only on trusted registries and channels, require signed or authenticated updates, add strong schema/range validation, and prefer staged rollout with rollback and human approval for high-impact changes.
If an untrusted party can publish to the channel or registry, they may influence agent configuration or observe status messages.
The subscriber trusts messages based on channel, type, and version, with no documented check of message origin, publisher identity, signature, or channel permissions before applying the config.
pilotctl --json subscribe "$REGISTRY_HOST" "$CONFIG_CHANNEL"
LATEST=$(pilotctl --json inbox \
| jq '[.messages[] | select(.topic == "'$CONFIG_CHANNEL'" and .payload.type == "config_update")] | sort_by(.payload.version) | last')Document and enforce publisher authentication, channel access controls, message signing, and trusted registry selection before agents subscribe or apply updates.
Running the example as-is creates a continuing background-style process that may keep changing local config over time.
The workflow example is an indefinite polling loop. This is expected for a config subscriber, but it means the process keeps operating and applying changes until explicitly stopped.
while true; do LATEST=$(pilotctl --json inbox ...) ... sleep 5 done
Run the subscriber only under explicit supervision, add stop conditions or service controls, and log each applied update for auditability.
The skill may fail or behave differently depending on the installed pilotctl, pilot-protocol daemon, and jq versions.
The skill relies on external tools and a daemon, and SKILL.md names dependencies beyond the registry-declared pilotctl requirement. This is not malicious, but users need to verify the external components.
Requires `pilot-protocol` skill, `pilotctl` binary, running daemon, and `jq` for JSON parsing.
Install dependencies from trusted sources, verify versions and daemon configuration, and consider declaring all required dependencies in metadata.