Back to skill

Security audit

Pilot Inventory Management Setup

Security checks for vulnerabilities and agentic risk

Overview

This skill is a coherent inventory automation setup, but it can persist configuration and trigger external purchase-order workflows without enough scoping or confirmation.

Review this before installing in production. Use only verified dependency versions, choose a simple hostname-safe prefix, confirm every peer identity before handshakes, back up any existing Pilot setup manifest, and keep supplier webhooks or Slack bridges disabled or in dry-run mode until endpoints and purchase-order approval rules are explicitly configured.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:48
Finding

Unpinned Third-Party Skill Dependencies

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:48-56; equivalent installation instructions also appear in README.md:40-51
Vulnerability Type: Supply-chain exposure through mutable, unverified dependencies
Risk Level: Medium

Vulnerable Code

bash
# For tracker:
clawhub install pilot-metrics pilot-stream-data pilot-audit-log

# For forecaster:
clawhub install pilot-dataset pilot-task-router pilot-cron

# For alerter:
clawhub install pilot-alert pilot-webhook-bridge pilot-slack-bridge

Technical Analysis

The setup instructions install nine third-party skills by package name without specifying immutable versions, commit hashes, checksums, trusted publisher identities, or a verified package registry. Consequently, the code installed during deployment may differ from the code that was originally reviewed.

Because these dependencies perform sensitive operations—including processing inventory data, scheduling tasks, creating alerts, communicating through Slack, and sending supplier webhooks—a compromised or unexpectedly updated package could execute within the agent's security context and abuse its available capabilities.

The repository does not itself contain evidence that any named dependency is malicious. The vulnerability is the absence of dependency pinning and integrity verification, which leaves the deployment exposed to registry compromise, account takeover, dependency substitution, and malicious future releases.

Attack Path

  1. An attacker compromises a publisher account, the configured package registry, or the distribution channel for one of the named skills.
  2. The attacker publishes a malicious release under the expected package name.
  3. An operator or agent follows the documented setup procedure and runs the unpinned clawhub install command.
  4. clawhub resolves and installs the attacker-controlled release.
  5. The malicious skill executes with the permissions and tool a ...[truncated 792 chars]
Remediation
View remediation

Remediation Suggestions

  • Pin every dependency to an immutable, audited version or content digest.
  • Verify package signatures and cryptographic checksums before installation.
  • Restrict package resolution to an explicitly configured, trusted registry.
  • Verify publisher identities and protect publisher accounts with strong authentication.
  • Maintain a lockfile or deployment manifest recording resolved versions and hashes.
  • Audit each dependency and its transitive dependencies before deployment.
  • Run installed skills with least-privilege filesystem, network, shell, and credential access.
  • Use an allowlist for approved package names, versions, publishers, and integrity hashes.
  • Monitor dependency updates and require review before changing pinned versions.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:44
Finding

Unvalidated User-Controlled Prefix Used in Shell Commands

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:44-61; the same substitution pattern is also used in handshake commands at SKILL.md:148-154 and setup commands in README.md:43-68
Vulnerability Type: Potential OS command injection through unsafe shell interpolation
Risk Level: High

Vulnerable Code

markdown
**Step 1:** Ask the user which role this agent should play and what prefix to use.

**Step 2:** Install the skills for the chosen role:
```bash
# For tracker:
clawhub install pilot-metrics pilot-stream-data pilot-audit-log

# For forecaster:
clawhub install pilot-dataset pilot-task-router pilot-cron

# For alerter:
clawhub install pilot-alert pilot-webhook-bridge pilot-slack-bridge

Step 3: Set the hostname:

bash
pilotctl --json set-hostname <prefix>-<role>
text

Related handshake commands use the same value:

```bash
pilotctl --json handshake <prefix>-forecaster "setup: inventory-management"
pilotctl --json handshake <prefix>-tracker "setup: inventory-management"
pilotctl --json handshake <prefix>-alerter "setup: inventory-management"

Technical Analysis

The skill explicitly asks the user to provide a deployment prefix and then directs the agent to substitute that value into Bash command templates. It does not define a validation rule, reject shell metacharacters, or require execution through an argument-vector API that bypasses shell parsing.

If an implementation performs textual placeholder replacement and submits the resulting string to a shell, metacharacters in the prefix—such as command separators, command substitutions, redirects, or newline characters—can alter the intended command. Quoting alone is insufficient unless it is implemented correctly and consistently; strict validation and shell-free argument passing are preferable.

Exploitability depends on how the agent runtime performs substitution and invokes Bas ...[truncated 1549 chars]

Remediation
View remediation

Remediation Suggestions

  • Validate the prefix before any use with a strict hostname-label allowlist, for example:
    regex
    ^[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?$
    
  • Enforce an appropriate total hostname-length limit after appending the role suffix.
  • Reject whitespace, newlines, quotes, substitutions, redirects, separators, control characters, and values beginning with option prefixes.
  • Restrict the role to the fixed allowlist tracker, forecaster, or alerter.
  • Invoke pilotctl through a process API with a discrete argument array rather than constructing a shell command string.
  • If Bash is unavoidable, pass validated values through positional parameters rather than interpolating them into executable command text.
  • Apply the same validation to hostname, handshake, subscription, and publication commands.
  • Display the normalized hostname to the user and obtain confirmation before changing configuration or establishing trust.
  • Add tests covering semicolons, command substitution, newlines, redirects, quotes, leading dashes, Unicode control characters, and overlong prefixes.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (5)

Missing User Warnings

High
Category
Not specified by scanner
Confidence
96% confidence
Finding

The skill sets up an alerter role that sends purchase-order requests to external supplier systems via webhook, but it does not prominently warn the user that business data will leave the local agent environment. This can cause unintended disclosure of inventory and procurement data or trigger real-world downstream actions if configured against live endpoints.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
95% confidence
Finding

The trust model auto-approves communication once both sides send a handshake, with no manual verification or strong identity validation step described. In a multi-agent deployment, this can allow misbinding or unintended trust establishment if operators target the wrong hostname/prefix or if naming collisions and spoofed identities are possible, leading to unauthorized data exchange between agents.

Content

Scanner excerpt · README.md (reported line 54)May include surrounding context.

2. Establish trust

Agents are private by default. Each pair that communicates must exchange handshakes. When both sides send a handshake, trust is auto-approved -- no manual step needed.

bash
# tracker <-> forecaster

Session Persistence

Medium
Category
Rogue Agent
Confidence
89% confidence
Finding

The manifest-writing step creates persistent state in the user's home directory, causing the setup to survive beyond the current session. While persistence is part of legitimate configuration here, it still has security relevance because it changes future agent behavior and may be used without clear acknowledgment from the user.

Content

Scanner excerpt · SKILL.md (reported line 67)May include surrounding context.

pilotctl --json set-hostname -

text

**Step 4:** Write the setup manifest:
```bash
mkdir -p ~/.pilot/setups
cat > ~/.pilot/setups/inventory-management.json << 'MANIFEST'

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The skill instructs the agent to create and overwrite a persistent file under ~/.pilot/setups without any explicit warning, consent checkpoint, or safer write strategy. This can modify the user's environment in a lasting way and may overwrite prior configuration, which is risky even though the destination appears application-specific.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
84% confidence
Finding

The markdown states that the alerter sends purchase order requests to suppliers and notifies procurement teams via Slack, which involves transmitting operational data to external parties/services. While the behavior is described, the document does not include any caution or warning about sharing inventory or procurement data outside the local system.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.