Back to skill

Security audit

Pilot Disaster Response Setup

Security checks for vulnerabilities and agentic risk

Overview

This skill is coherent for disaster-response setup, but it handles high-impact public-safety communications with under-scoped trust, dependency, and safety controls.

Review this before installing in any real emergency or public-facing environment. Use test deployments first, verify every peer identity out of band before handshakes, pin and verify all dependent skills, restrict Slack/webhook destinations, require human approval before public alerts, and protect or remove the saved setup manifest when no longer needed.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:45
Finding

Unpinned and Unverified Third-Party Skill Dependencies

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 45-54; duplicated in README.md, lines 50-63
Vulnerability Type: Supply-chain exposure through mutable, unverified registry dependencies
Risk Level: Medium

Vulnerable Code Snippet

bash
# For sensor-hub:
clawhub install pilot-stream-data pilot-metrics pilot-gossip
# For coordinator:
clawhub install pilot-task-router pilot-consensus pilot-audit-log
# For resource-allocator:
clawhub install pilot-dataset pilot-event-filter pilot-escrow
# For comms:
clawhub install pilot-announce pilot-slack-bridge pilot-webhook-bridge

Technical Analysis

The setup procedure installs twelve third-party Skills by package name without immutable version constraints, cryptographic hashes, signature verification, a lockfile, or an explicitly trusted registry. Consequently, the code installed at deployment time can differ from the code reviewed when this project was published.

The retrieved dependencies are not included in this repository and could not be examined during this audit. Because the parent Skill allows Bash and incorporates the installed components into trusted disaster-response agents, a compromised registry account, package takeover, dependency-confusion condition, or malicious upstream release could introduce attacker-controlled behavior.

The exposure is particularly significant for communication bridge components such as pilot-slack-bridge and pilot-webhook-bridge, which may interact with external systems, and for components that process alerts, resource allocations, or trust relationships.

Attack Path

  1. An attacker compromises the publisher account or registry entry for one of the named Skills, or causes an attacker-controlled package to resolve under the expected name.
  2. The attacker publishes a malicious or backdoored release under that mutable package identifier.
  3. An operator or AI agent follows the documented setup procedure and runs the corresponding `clawhub ins ...[truncated 1311 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin every dependency to a specific, audited, immutable version rather than installing by package name alone.
  2. Require cryptographic digests or verified publisher signatures for each installed artifact.
  3. Document and enforce the expected registry endpoint so package resolution cannot silently fall back to an untrusted source.
  4. Maintain a lockfile or signed dependency manifest containing package names, versions, sources, and checksums.
  5. Review the complete contents and transitive dependencies of each Skill before installation or activation.
  6. Stage downloaded Skills in a restricted environment and scan them before allowing execution.
  7. Run each role with least-privilege filesystem, process, credential, and network permissions.
  8. Restrict Slack and webhook bridge destinations with explicit allowlists and narrowly scoped credentials.
  9. Establish peer trust only after dependency verification and successful integrity checks.
  10. Add a controlled update process that re-audits dependencies before changing any pinned version.
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 (4)

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
85% confidence
Finding

The trust model auto-approves communication once both sides exchange handshakes, with no documented identity verification or manual authorization step. In this multi-agent emergency system, that can allow unintended or misconfigured peers to become trusted and exchange sensitive coordination messages, increasing the risk of spoofed alerts, false resource requests, or unauthorized broadcasts.

Content

Scanner excerpt · README.md (reported line 64)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
# sensor-hub <-> coordinator (disaster alerts)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The README provides example commands that send realistic public emergency alerts through communications channels without any warning that they should only be used in a test environment. In a disaster-response/public-safety context, this is dangerous because operators may execute the examples against live systems, causing false alerts, public panic, or improper agency response.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
94% confidence
Finding

The skill orchestrates emergency-alert publication, inter-agency coordination, Slack delivery, and webhook-based external broadcasts, but it provides no user-facing warning about transmitting potentially sensitive operational or public-safety data to external systems. In this context, operators may unknowingly send incident locations, response status, or public alerts to unintended recipients, increasing the risk of data leakage, misinformation, or accidental mass notification during emergencies.

Content

No source excerpt is available for this finding.

Session Persistence

Medium
Category
Rogue Agent
Confidence
83% confidence
Finding

Writing a persistent manifest to ~/.pilot/setups/disaster-response.json creates local session state that may retain sensitive topology and coordination details such as hostnames, peer relationships, and workflow roles beyond the active session. If the workstation is shared, backed up, or later compromised, this file could expose incident-response infrastructure details that aid reconnaissance or unauthorized reuse of prior configuration.

Content

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

clawhub install pilot-announce pilot-slack-bridge pilot-webhook-bridge

text

**Step 3:** Set the hostname and write the manifest to `~/.pilot/setups/disaster-response.json`.

**Step 4:** Tell the user to initiate handshakes with the peers for their role.

Static analysis

No suspicious patterns detected.