Pilot Slack Bridge
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This is a coherent Slack-to-Pilot bridge skill, but it should be used carefully because it involves Slack webhooks, a public/listening daemon example, and long-running relay processes.
Use this skill only if you intentionally want a persistent Slack/Pilot bridge. Protect the Slack webhook, review any external slack_relay.py or HTTP relay before running it, avoid exposing the Pilot daemon publicly unless necessary, and apply channel/user allowlists for inbound Slack events.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If copied without review, the commands could start network-facing Pilot services or publish messages to Slack/Pilot streams.
The skill intentionally uses Bash to run pilotctl commands, including a public daemon example. This is relevant to the bridge purpose, but it gives the agent/user operational control over Pilot services.
allowed-tools: - Bash ... pilotctl --json daemon start --hostname slack-relay --public
Run these commands only in the intended environment, avoid --public unless needed, and verify Pilot daemon access controls before exposing it.
Anyone who obtains the webhook URL may be able to post messages to the configured Slack channel.
A Slack webhook URL acts as a credential that can post to a Slack destination. Its use is expected for Slack notifications, but it should be treated as secret.
pilotctl --json set-webhook https://hooks.slack.com/services/YOUR/WEBHOOK/URL
Store the Slack webhook securely, rotate it if exposed, and prefer scoped/limited Slack app permissions where possible.
Security depends partly on whatever external relay implementation the user supplies.
The inbound relay is referenced as an external script/service, but no such code is included for review in this instruction-only skill.
python3 slack_relay.py & ... Requires pilot-protocol skill, running daemon, Slack webhook URL, and HTTP relay service for inbound.
Review and trust the relay script/service before running it, and ensure dependencies are pinned and sourced from a trusted location.
Slack messages may influence Pilot-side behavior, so unauthorized or spoofed inbound events could trigger unwanted responses if the relay is not secured.
The skill bridges Slack-originated messages into Pilot event handling. This is the intended function, but the artifact does not describe origin verification, channel allowlisting, or relay authentication.
Subscribe to Slack Events ... EVENT=$(pilotctl --json recv 1002 --timeout 60s) TEXT=$(echo "$EVENT" | jq -r '.event.text')
Verify Slack request signatures in the relay, restrict accepted channels/users, and limit what inbound Slack commands are allowed to do.
The bridge may continue receiving and sending events in the background, which can surprise users if they forget it is running.
The workflow shows background listeners and a continuous loop. This persistence is expected for a bridge, but it keeps operating after setup until stopped.
pilotctl --json listen 1002 & ... while true; do
Run the bridge under a supervised service or terminal session, log its activity, and document how to stop it cleanly.