T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:77- Finding
Unverified Remote Installer Is Executed Directly by the Shell
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill has a coherent networking purpose, but it asks users to run an unverified remote installer and includes automation that can trust peers and accept remote tasks without review.
Install only after reviewing or replacing the remote installer with a pinned, verifiable package. Do not use the provided heartbeat auto-approval script as written; require explicit review for each new peer, incoming task, received file, webhook destination, and gateway mapping.
SKILL.md:77Unverified Remote Installer Is Executed Directly by the Shell
SKILL.md:95Unaudited Remote Installer Establishes a Persistent System Service
SKILL.md:287Heartbeat Automatically Trusts Remote Peers and Accepts Their Tasks Without Validation
The installation instructions fetch and execute a remote shell script directly from the network, which gives the remote server complete control over code executed on the user's system at install time. In a security-sensitive networking skill that installs binaries, modifies configuration, and sets up services, this substantially increases supply-chain and compromise risk if the server, DNS, TLS trust chain, or distribution process is attacked.
No sudo required. Binaries are installed to ~/.pilot/bin/.
curl -fsSL https://pilotprotocol.network/install.sh | sh
Sets a hostname during install:
Piping a network response straight into sh is a classic dangerous chaining pattern because it removes any opportunity to inspect or verify the downloaded content before execution. If an attacker can influence the remote content or redirect the request, arbitrary shell commands run immediately in the user's environment, potentially persisting via PATH changes, config writes, or service installation described by the skill.
No sudo required. Binaries are installed to ~/.pilot/bin/.
curl -fsSL https://pilotprotocol.network/install.sh | sh
Sets a hostname during install:
The heartbeat section normalizes unattended processing of remote-originated trust requests and tasks, including accepting tasks quickly and executing queued work, which reduces or removes human review for untrusted network actions. In a networking skill that explicitly handles incoming messages, files, and tasks from other agents, this creates a strong pathway for remote abuse, coercing the agent into processing malicious content or instructions.
The heartbeat instructions tell the operator to approve or reject incoming trust requests as part of routine automation, but they do not highlight that granting trust changes the attack surface and may permit remote interaction from untrusted agents. In this skill, trust is a gating control for discovery and communications, so normalizing rapid approval without warning makes unsafe trust expansion more likely.
The script auto-approves all pending trust requests and provides no warning that doing so can expose the agent to hostile or spoofed peers. Since trust is the mechanism that opens communication and task pathways in this protocol, the sample directly operationalizes unsafe behavior rather than merely omitting a caution.
The skill encourages sending messages, files, tasks, and webhook data to other agents and endpoints but does not prominently warn that these operations may disclose sensitive data outside the local trust boundary. Because this is an agent-to-agent networking skill, users may forward credentials, local file contents, or internal task data without adequate caution, creating confidentiality and privacy risk.
The sample heartbeat script automatically approves every pending trust request, which eliminates any trust decision boundary and grants network access to arbitrary peers. In this skill's context, trust enables messaging, file transfer, task submission, and other remote interactions, so blanket approval materially increases exposure to malicious agents and follow-on task abuse.
The documentation explicitly encourages sending files and typed messages to remote agents and notes that the recipient daemon persists them to disk, but it provides no warning about sensitivity, trust boundaries, or the fact that remote persistence may be outside the sender's control. In a skill specifically designed for agent-to-agent communication and file exchange, this omission increases the risk of inadvertent data exfiltration, disclosure of secrets, or unsafe sharing with untrusted peers.
The documentation describes starting an IP bridge that opens local TCP proxy listeners and notes root is required for privileged ports, but it does not clearly warn users about the security implications of exposing local listeners that forward traffic to remote agents. In the context of an agent-to-agent networking skill, this omission can cause users to unintentionally create a bridge into remote services or run privileged networking commands without understanding the attack surface.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# 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
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# 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
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# 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
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# 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 markdown file documents pilotctl deregister, which removes the current node from the registry, but it provides no warning that the action is destructive or may disrupt routing/availability. Under the markdown-specific warning criterion, users should be explicitly alerted when an operation can affect system integrity or connectivity.
The auto-approval behavior allows trust to be created automatically when both sides initiate a handshake, reducing human review at the point where a sensitive relationship is established. In an agent-to-agent networking skill, this can be exploited through social engineering, misbinding, or unintended reciprocal requests, resulting in autonomous establishment of a trusted channel with a potentially unsafe peer.
## Auto-approval
Trust is auto-approved when both agents independently request a handshake with each other (mutual handshake).
## Trust workflow example
The document describes approving trust and a mutual auto-approval path without clearly warning that trust permits broad, ongoing agent-to-agent communication. In this skill’s context, granting trust is effectively a security boundary change, so understating its consequences can lead operators or upstream agents to establish links with unvetted peers and expose tasks, files, or network access.
The documentation instructs users to configure a webhook that will POST real-time daemon events to an HTTP endpoint, but it does not warn that those events may contain sensitive operational metadata such as node identifiers, peer activity, trust-handshake information, and message/file receipt notifications. In the context of an agent-to-agent networking skill, this omission can lead users to expose telemetry to insecure or unintended endpoints, especially when using plain HTTP as shown in the example.
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 subscription and listening commands document potentially unbounded inbound streams ('streams NDJSON indefinitely' and wildcard topic subscription) without warning about resource consumption, blocking behavior, or exposure to continuous unsolicited network data. In an agent communication skill, operators may run these commands in automation and unintentionally create denial-of-service, log flooding, or uncontrolled intake conditions.
No suspicious patterns detected.