Pilot Swarm Join

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:27 AM UTC
• Version: 1.0.0

Overview

This skill does what it says by joining agent swarms, but its examples can approve every pending peer connection instead of only verified swarm members.

Review this skill before installing. Only use it with trusted registries and known swarm members, and replace the blanket approval command with a process that lists pending requests, verifies each node against the intended swarm and registry, and approves peers one at a time. Do not run the provided approval example in an environment where unrelated or untrusted handshake requests could be pending.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:61

Finding

Unscoped Automatic Approval of All Pending Peers

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:61 and SKILL.md:96
Vulnerability Type: T05: Unauthorized Access and Privilege Escalation
Risk Level: High

Vulnerable code at line 61:

bash

pilotctl --json pending | jq -r '.[].node_id' | xargs -I {} pilotctl --json approve {}

Repeated vulnerable code at line 96:

bash

# Approve handshakes
pilotctl --json pending | jq -r '.[].node_id' | xargs -I {} pilotctl --json approve {}

Technical Analysis

The documented command retrieves every pending handshake from the local daemon and passes every returned node identifier to pilotctl approve. It does not restrict approval to nodes discovered through the selected swarm, compare pending identifiers against the expected $PEERS set, validate authenticated swarm membership, verify the registry of origin, or request operator confirmation.

Consequently, the approval step crosses the workflow's intended trust boundary. Although the skill is intended to establish trust with members of a named swarm, the command approves unrelated pending peers as well. An attacker who can cause a handshake request to appear in the daemon's pending list may be approved during routine execution of the workflow.

Attack Path

1. An attacker-controlled node sends a handshake request that reaches the victim's pilotctl daemon.
2. The attacker's node identifier is added to the daemon's pending-handshake list.
3. The victim invokes the documented swarm-joining workflow for an otherwise legitimate swarm.
4. The workflow executes pilotctl --json pending, which returns both legitimate swarm peers and the attacker-controlled node.
5. jq extracts every returned node_id without validating swarm membership.
6. xargs invokes pilotctl --json approve for each identifier, including the attacker's.
7. The attacker obtains an approved trust relationship despite not being verified as a member of the selected s ...[truncated 675 chars]

Remediation

View remediation

Remediation Suggestions

Replace blanket approval with a scoped process that approves only authenticated node identifiers associated with the selected swarm:

1. Build an explicit allowlist from peers discovered through the expected registry and exact swarm topic.
2. Intersect the pending-handshake list with that allowlist before invoking pilotctl approve.
3. Validate each peer's authenticated identity and swarm membership rather than relying solely on message-controlled identifiers.
4. Require explicit operator confirmation for unknown or unexpected peers.
5. Reject or leave unapproved any pending request that cannot be associated with the current swarm operation.
6. Safely handle empty lists so that no approval command is executed when there are no verified peers.
7. Apply the same correction to both the standalone “Approve Peers” command at line 61 and the workflow example at line 96.
8. Where supported by pilotctl, use a native scoped-approval option tied to a registry, topic, invitation, or authenticated membership token instead of parsing broad daemon output.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Missing User Warnings

High

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The skill presents automatic handshake and approval steps as normal workflow without warning that they create trust relationships with other agents. In a skill specifically intended for swarm formation and bidirectional trust establishment, omission of this warning is dangerous because users are encouraged to run commands that can authorize unintended peers.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

The publish step sends agent identity and swarm membership information to a registry host, but the skill does not warn about metadata leakage, tracking, or exposure to untrusted infrastructure. In a discovery-oriented swarm skill, this context increases the risk because publication is central to operation and may reveal topology and participation details to observers or operators of the registry.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

• Category: Not specified by scanner
• Confidence: 98% confidence

Finding

The documented approval command approves every pending handshake globally, without verifying that the requester belongs to the intended swarm or registry context. An attacker can race or inject unrelated handshake requests so the operator silently establishes trust with unauthorized peers, expanding access beyond the swarm and undermining peer authentication.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The workflow example operationalizes insecure behavior by approving all pending handshakes after joining a swarm. Because pending requests may include unrelated or malicious nodes, this turns a convenience example into a trust-escalation primitive that can be exploited in multi-tenant or hostile network environments.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.