Pilot S3 Bridge
Security checks across static analysis, malware telemetry, and agentic risk
Overview
The skill is purpose-aligned for cloud storage bridging, but its example sets up a public, long-running bridge that can use cloud credentials to read, write, list, and send storage data without clear sender checks or scope limits.
Only install or use this skill if you understand Pilot Protocol and can restrict the bridge to trusted senders. Use a dedicated least-privilege cloud credential, limit it to specific buckets and actions, avoid public mode unless necessary, and stop the daemon when the transfer task is complete.
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.
A bridge configured this way could modify or disclose cloud storage objects if it processes an unsafe or unauthorized request.
The workflow executes cloud storage read, write, and list operations using bucket/key values taken from received messages, but the artifact does not show validation, approval, allowlisting, or action limits.
case "$ACTION" in
upload)
...
aws s3 cp /tmp/upload_file "s3://$BUCKET/$KEY"
...
download)
aws s3 cp "s3://$BUCKET/$KEY" /tmp/download_file
pilotctl --json send-file "$SENDER" /tmp/download_file
...
list)
OBJECTS=$(aws s3 ls "s3://$BUCKET/$(echo "$REQUEST" | jq -r '.prefix')" --recursive)Require explicit user approval for high-impact actions, validate bucket/key/prefix values, restrict allowed actions and storage locations, and prefer narrowly scoped wrapper commands over raw shell-driven cloud operations.
The bridge may act with all permissions granted to the configured cloud credentials, potentially exceeding the user's intended storage access.
The skill relies on delegated cloud credentials, but it does not define least-privilege permissions, specific buckets, credential handling boundaries, or which operations those credentials should allow.
export AWS_ACCESS_KEY_ID="your_key" export AWS_SECRET_ACCESS_KEY="your_secret" ... Requires pilot-protocol skill, running daemon, S3 bridge agent with cloud credentials (AWS CLI, gsutil, or az CLI).
Use dedicated least-privilege credentials limited to specific buckets/prefixes and actions, document the required credential scope, and avoid using broad personal or administrative cloud keys.
Cloud files or listings could be exposed through the bridge if messages are accepted from an unexpected or unauthorized sender.
The example starts a public Pilot agent and processes received messages, but does not show authentication, sender verification, message signing, or an allowlist before using cloud credentials.
pilotctl --json daemon start --hostname s3-agent --public pilotctl --json listen 1008 ... REQUEST=$(pilotctl --json recv 1008 --timeout 120s) SENDER=$(echo "$REQUEST" | jq -r '.sender')
Run the bridge privately by default, verify sender identity, restrict accepted peers, and require authenticated or signed requests before performing cloud storage operations.
The bridge could keep operating after the intended task and continue accepting storage-related requests while cloud credentials remain available.
The documented workflow creates a public, long-running worker loop but does not include a stop condition, lifecycle control, logging guidance, or cleanup instructions.
pilotctl --json daemon start --hostname s3-agent --public ... while true; do REQUEST=$(pilotctl --json recv 1008 --timeout 120s)
Add explicit start/stop instructions, timeouts, logging, user-visible status, and cleanup steps; avoid public long-running mode unless the user intentionally enables it.