Pilot Slack Bridge

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

Overview

This Slack bridge is mostly coherent, but its example exposes a public daemon and lets Slack text trigger operational lookups without documented access controls.

Review before installing. Use this only in a controlled Slack workspace and private Pilot deployment, avoid the --public daemon example unless you have strong authentication and network allowlisting, and restrict or remove commands that return daemon status or peer lists to Slack.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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

Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:57

Finding

Publicly Exposed Pilot Daemon Without Documented Access Controls

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:57
Vulnerability Type: Public service exposure and violation of least privilege
Risk Level: High

bash

pilotctl --json daemon start --hostname slack-relay --public

Technical Analysis

The documented workflow starts the Pilot daemon with the --public option, expanding its network exposure beyond a local-only deployment. The example does not require authentication, TLS, interface restrictions, firewall allowlisting, or any other compensating access control.

Because the precise behavior and built-in security controls of pilotctl are outside the audited project, successful unauthorized access depends on the daemon's implementation and deployment environment. Nevertheless, instructing users to enable public access without documenting mandatory protections creates an unsafe default and violates least-privilege principles.

Attack Path

1. An operator follows the workflow and starts the daemon using --public.
2. The daemon becomes reachable from networks permitted by the host and perimeter firewall configuration.
3. An attacker discovers the exposed service through direct probing, service enumeration, or knowledge of the deployment address.
4. If the daemon does not independently enforce strong authentication and authorization, the attacker submits Pilot Protocol requests or interacts with exposed bridge capabilities.
5. The attacker may enumerate operational state, access messaging functions, or invoke any other daemon operations available to unauthenticated or underprivileged clients.

Impact Assessment

The affected scope is the publicly reachable Pilot daemon and any agents, event streams, or messaging capabilities exposed through it. Depending on daemon-side controls, exploitation could permit unauthorized service access, operational reconnaissance, message injection, or interaction with connected agents. The documentation alone does not prov ...[truncated 158 chars]

Remediation

View remediation

Remediation Suggestions

• Remove --public from the default example and bind the daemon to localhost or a dedicated private interface.
• If remote access is required, mandate mutually authenticated TLS or an equivalent strong authentication mechanism.
• Enforce authorization separately for subscription, publication, peer enumeration, and administrative operations.
• Restrict network access with host and perimeter firewall allowlists.
• Run the daemon under a dedicated, minimally privileged operating-system account.
• Document the exact listening interface, port, authentication requirements, and secure deployment prerequisites.
• Add logging, rate limiting, failed-authentication monitoring, and alerting for unauthorized connection attempts.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:64

Finding

Inbound Slack Commands Are Processed Without Sender Authentication or Authorization

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:64-76
Vulnerability Type: Unauthenticated command processing and information disclosure
Risk Level: Medium

bash

# Process Slack commands
while true; do
  EVENT=$(pilotctl --json recv 1002 --timeout 60s)
  TEXT=$(echo "$EVENT" | jq -r '.event.text')

  case "$TEXT" in
    "status")
      pilotctl --json publish localhost slack-responses --data "Status: $(pilotctl --json daemon status)"
      ;;
    "list agents")
      pilotctl --json publish localhost slack-responses --data "Agents: $(pilotctl --json peers)"
      ;;
  esac
done

Technical Analysis

The workflow treats the event text as sufficient authority to invoke operational commands. It does not inspect or validate the originating Slack workspace, channel, user, role, event identifier, signature, or timestamp before executing pilotctl daemon status or pilotctl peers.

As a result, any party capable of placing a forged or unauthorized event onto the subscribed stream can trigger the supported commands. The current fixed-string case statement limits the demonstrated behavior and does not directly create shell command injection. However, the returned daemon status and peer list may expose operational state and agent topology.

The external inbound component referenced by the workflow, slack_relay.py, is not present in the project and therefore could not be audited for Slack signature verification or authorization. Security must not rely on undocumented behavior in that absent component.

Attack Path

1. The bridge subscribes to the slack-events stream and begins receiving events on listener 1002.
2. An attacker sends a message through an unauthorized Slack account or channel, compromises an allowed Slack identity, exploits an insufficiently protected relay, or otherwise injects an event into the stream.
3. The event contains the exact text status or list agents. 4 ...[truncated 747 chars]

Remediation

View remediation

Remediation Suggestions

• Verify Slack signing secrets, request timestamps, and signatures at the HTTP relay before accepting an event.
• Reject stale requests and retain processed event identifiers for replay prevention.
• Allowlist authorized Slack workspace, enterprise, channel, and user identifiers.
• Apply command-specific role authorization rather than treating message text as authority.
• Pass authenticated identity metadata through the relay and validate it again before dispatching commands.
• Validate the complete event schema and reject missing, malformed, bot-generated, or unexpected event types.
• Return only the minimum required operational information and redact peer identifiers or sensitive metadata.
• Publish responses to a restricted channel or directly to the authorized requester.
• Add security logging and rate limiting for command attempts.
• Include the relay implementation in the project so its signature validation and authorization controls can be audited.

SkillSpector

Vulnerability Patterns

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

Findings (2)

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 60% confidence

Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

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

md

3. You're building agents that interact with Slack workspaces

  Do NOT use this skill when:
  - You only need simple webhooks (use curl instead)
  - Slack is not configured or accessible
  - The daemon is not running
tags:

Missing User Warnings

Medium

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

Finding

The workflow explicitly bridges messages and events between Pilot and Slack, and the example publishes daemon status and peer information back to Slack without any warning about data exposure or trust boundaries. In a chat-integrated agent context, this can leak operational metadata and potentially sensitive event contents to an external SaaS channel where retention, membership, and app access may be broader than intended.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.