T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:75- Finding
Unpinned Remote Installer Is Downloaded and Executed Directly
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is purpose-aligned for agent networking, but it needs review because it installs a persistent network daemon through an unverified remote script and includes automation that can blindly trust peers and run incoming tasks.
Review this skill before installing. Do not run the curl | sh installer unless you trust the publisher and delivery endpoint; prefer a verified, versioned download. Avoid adding the provided heartbeat script as written, and require manual or policy-based review before approving peers, accepting tasks, executing tasks, processing received files, or sending results. Use gateway and webhook features only with deliberate scoping, avoid sudo unless absolutely necessary, and monitor the persistent ~/.pilot service, config, inbox, received files, tasks, and webhook settings.
SKILL.md:75Unpinned Remote Installer Is Downloaded and Executed Directly
SKILL.md:95Unaudited Installer Establishes Cross-Session Daemon Persistence
SKILL.md:287Persistent Heartbeat Automatically Trusts Peers and Accepts Remote Tasks
Piping a remote script directly into the shell executes unreviewed network-fetched code immediately, creating a strong supply-chain and remote-code-execution risk. In this skill, the installer also modifies PATH, writes config, and sets up services, so compromise of the distribution endpoint or transit path would have significant local impact.
No sudo required. Binaries are installed to ~/.pilot/bin/.
curl -fsSL https://pilotprotocol.network/install.sh | sh
Sets a hostname during install:
The command chain combines remote content retrieval with immediate shell execution, removing any pause for inspection or integrity verification. This pattern is especially risky in an agent skill because it teaches automation-friendly execution of arbitrary downloaded code, which can be repurposed or silently compromised.
No sudo required. Binaries are installed to ~/.pilot/bin/.
curl -fsSL https://pilotprotocol.network/install.sh | sh
Sets a hostname during install:
The heartbeat guidance recommends approving trust requests and accepting/executing incoming tasks automatically without prominent warnings about the security consequences. In a peer-to-peer agent skill, this omission is especially dangerous because it encourages autonomous trust expansion and remote-triggered work execution as routine maintenance.
The instructions and sample automation normalize accepting inbound tasks immediately, and the script auto-accepts all NEW tasks before executing queued work. That enables unsolicited remote work execution from peers, which can drive the agent to process attacker-controlled task content or perform actions beyond the user's intent.
These instructions operationalize unsafe defaults by treating blind trust approval and automatic task acceptance/execution as normal maintenance behavior. Because the skill is specifically designed for inter-agent networking and task exchange, this creates a direct path for malicious or untrusted peers to gain influence over the local agent's workflow.
The heartbeat sample script automatically approves every pending trust request, which collapses the protocol's trust boundary and lets any requester become trusted without review. In this skill's context, trust gates discovery, messaging, file exchange, and tasking, so blind approval can expose the agent to unsolicited communications and follow-on abuse from arbitrary peers.
The auto-approval behavior is especially risky because it normalizes trust establishment through reciprocal handshakes without emphasizing that this can create trust automatically. In the context of an overlay network for inter-agent communication, an attacker could induce or socially engineer a mutual handshake and obtain trusted status with less operator scrutiny than a manual approval flow.
The installation and usage guidance sets up a networked daemon, registry connectivity, messaging, file receipt, and optional task execution, yet it lacks a clear warning that data will be transmitted to external peers and that a background service and local mailbox directories will be created. Users may enable broad network capabilities and persistent services without understanding privacy, exposure, or system-modification implications.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
No sudo required. Binaries are installed to ~/.pilot/bin/.
curl -fsSL https://pilotprotocol.network/install.sh | sh
The skill states that the installer sets up a system service and that gateway operation may require sudo for ports below 1024, which implies possible privileged system changes without much detail on scope or safeguards. While not inherently malicious, the combination of background service installation and optional root-requiring network bridging increases the blast radius if misused or misunderstood.
clawhub install pilot-protocol
The installer detects your platform, downloads pre-built binaries (or builds from source if no release is available), writes `~/.pilot/config.json`, adds `~/.pilot/bin` to your PATH, and sets up a system service (systemd on Linux, launchd on macOS). Only the gateway requires sudo — and only for ports below 1024.
## Self-Discovery
The send-file documentation explicitly states that the receiving daemon saves the transferred file to ~/.pilot/received/, but it does not warn users that invoking this command causes a write on the remote host. In an agent-to-agent communication skill, that omission is risky because users or downstream agents may treat it as a harmless message operation and unintentionally deliver untrusted or sensitive files to another system where they will be persisted.
The send-message command description notes that the target saves messages to ~/.pilot/inbox/, but it lacks a prominent warning that submitted content is persisted on the remote host. In this skill's context, where agents may automate task submission and inter-agent messaging, failing to highlight persistence increases the chance of accidental data leakage, storage of malicious payloads, or unintended retention of sensitive instructions on peer systems.
This markdown documents pilotctl disconnect <conn_id>, which actively terminates an existing connection, but provides no warning that the action is disruptive or may interrupt active traffic. For markdown files, destructive or system-impacting behavior should be disclosed so users understand the operational impact before invoking it.
The documentation instructs users to start an IP bridge that opens TCP proxy listeners and may require root for privileged ports, but it does not prominently warn that this exposes local listening services and expands the attack surface. In the context of an agent-to-agent gateway, unclear documentation can lead operators to enable broad port exposure or run with elevated privileges without understanding the security implications.
The example normalizes use of sudo to start the gateway, which can encourage operators to run the service with full privileges even when only a specific capability or higher unprivileged port would suffice. Because this gateway bridges network traffic from remote agents into local TCP listeners, running it as root increases the consequences of misconfiguration or any implementation flaw.
# Map a remote agent and proxy port 3000
sudo pilotctl gateway start --ports 3000 0:0000.0000.0001
# mapped 10.4.0.1 -> 0:0000.0000.0001
# Now use standard tools
This second example again promotes starting the gateway with sudo, and additionally demonstrates exposing multiple ports at once, which compounds the risk of unnecessary privilege use and network exposure. In a skill specifically designed to bridge IP traffic between agents, broad multi-port root-run examples make unsafe deployment patterns more likely.
sudo pilotctl gateway start --ports 80,3000,8080 0:0000.0000.0007 curl http://10.4.0.1/status curl http://10.4.0.1:3000/api/data
The documentation presents approve and untrust as routine operations without warning that approving a peer grants that remote agent access to agent-to-agent communication capabilities and that revocation affects an established trust boundary. In a trust-management skill, omission of these security consequences can cause users or downstream agents to approve unverified peers too casually, enabling unauthorized data exchange or task submission.
The documented automatic trust decision is a form of autonomous security-relevant decision making: the system changes a trust state based on matching handshake behavior, without an explicit manual authorization at the time trust is granted. In this skill's context, where trust unlocks communication between agents, such automation increases the risk of unintended trust relationships and subsequent data exposure or remote task abuse.
## Auto-approval
Trust is auto-approved when both agents independently request a handshake with each other (mutual handshake).
## Trust workflow example
The example concludes that agents can 'communicate freely' once trusted, but does not warn that trust may permit broad data sharing, file transfer, task exchange, or other sensitive interactions. This wording can lead users to treat trust as low-risk convenience rather than a significant security boundary, increasing the chance of over-trusting peers in production environments.
The documentation instructs users to send real-time daemon events to an HTTP endpoint without warning that these events may contain sensitive operational metadata such as node identifiers, peer activity, trust-handshake details, and received-message/file notifications. In the context of an agent-to-agent networking daemon, this omission can lead users to expose internal telemetry to insecure or unintended destinations, especially if plain HTTP is used.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
| `handshake.pending` | Handshake queued for approval |
| `handshake.approved` | Handshake approved |
| `handshake.rejected` | Handshake rejected |
| `handshake.auto_approved` | Mutual handshake auto-approved |
| `trust.revoked` | Trust revoked locally |
| `trust.revoked_by_peer` | Trust revoked by remote peer |
| `message.received` | Typed message received via data exchange |
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
| `handshake.pending` | Handshake queued for approval |
| `handshake.approved` | Handshake approved |
| `handshake.rejected` | Handshake rejected |
| `handshake.auto_approved` | Mutual handshake auto-approved |
| `trust.revoked` | Trust revoked locally |
| `trust.revoked_by_peer` | Trust revoked by remote peer |
| `message.received` | Typed message received via data exchange |
The runtime command documentation notes that the webhook URL persists to user config and applies immediately, but it does not clearly warn that this instantly alters daemon behavior and creates a durable exfiltration path for future events. In a security-sensitive networking skill, lack of emphasis on immediate and persistent side effects increases the chance of accidental misconfiguration or unnoticed redirection of telemetry.
No suspicious patterns detected.