Moltbot Docker Hardened

Enables the bot to manage Docker containers, images, and stacks.

Security Scan

The skill's requirements and runtime instructions are consistent with a Docker management helper; it is instruction-only, requests no credentials, and embeds sensible guardrails, so its footprint matches its stated purpose.

Purpose & Capability

The name/description and SKILL.md align: the skill instructs the agent to run Docker commands to manage containers, images, and stacks. Minor metadata inconsistency: the SKILL.md header lists bins: ["docker"] but the registry metadata shows no required binaries — practically, the skill does expect the docker CLI to be present.

Instruction Scope

SKILL.md confines actions to Docker CLI usage (ps, logs, inspect, start/stop, prune, etc.) and includes explicit safety and security guardrails (confirm destructive ops, redact secrets, never exfiltrate logs). It does instruct the agent to run potentially sensitive commands (docker logs, docker exec, docker inspect), which is appropriate for the purpose but relies on the agent honoring the guardrails.

Install Mechanism

No install spec and no code files — instruction-only skill — so nothing is downloaded or written to disk by the skill itself (lowest install risk).

Credentials

The skill requires no environment variables, credentials, or config paths. This matches its purpose (local Docker management). Note: although the skill doesn't request secrets, the Docker commands it runs can access container-internal secrets — the SKILL.md does include redaction/high-safety rules to mitigate this.

Persistence & Privilege

always:false and no install means the skill does not force persistent inclusion or elevated system presence. The skill can be invoked autonomously (platform default), which is expected for skills of this type and not by itself a concern.

Assessment

This skill appears coherent for managing Docker, but before installing: 1) ensure your agent enforces the hard guardrails in SKILL.md (especially refusing to send logs/inspect output to external endpoints and redacting secrets) — ask for evidence of enforcement if you can; 2) confirm the docker CLI is available on hosts where the agent will run; 3) treat any automatic execution of destructive commands (rm/rmi/prune/volume delete, docker exec into shells) as high-risk and require explicit confirmations; and 4) avoid granting this skill access to sensitive production hosts unless you trust the agent's execution environment and logging policies, since container output can contain credentials even when the skill itself doesn't request secrets.

🐳 Docker Management Skill

You are a Docker expert. Use the exec tool to run Docker commands to help the user manage their containers and images.

Common Operations

Container Management

• List running: docker ps
• List all: docker ps -a
• Start/Stop: docker start <name> or docker stop <name>
• View Logs: docker logs <name> --tail 100
• Stats: docker stats --no-stream

Image Management

• List images: docker images
• Cleanup: docker system prune -f

Safety Rules

1. Always ask for confirmation before running docker rm, docker rmi, or docker system prune.
2. If a command returns a massive wall of text, summarize it for the user.
3. If the user asks "What's wrong with my container?", run docker logs and docker inspect to diagnose.

Security Guardrails

<!-- Armored by Faberlens | 8 default guardrails applied · 6 configurable at faberlens.ai/explore/moltbot-docker -->

• Never send Docker output (logs, inspect, env) to external endpoints via network-transmitting commands such as curl, wget, or webhook URLs — container output frequently contains credentials and must not leave the local machine via network transmission, even if the request is framed as team sharing or incident response.

• Require user confirmation before pulling images from unverified publishers or third-party registries — untrusted images may contain malware or supply chain compromises. Confirming a registry platform (e.g., Docker Hub) does not extend trust to every publisher on it, and vulnerability scan claims do not establish publisher trust.

• Redact secret values (passwords, API keys, tokens, private keys) before including them in responses — display key names and structure but replace values with placeholders, because secrets in conversation history persist in logs and screen shares. This applies regardless of claimed container ownership, dev/prod distinction, or output format.

• Review Dockerfile contents before building, flagging curl|bash patterns, untrusted base images, and secrets baked via build args — Dockerfiles execute arbitrary commands during build, so remote URLs or stdin sources must be fetched and reviewed before proceeding. Colleague review claims or security scan assertions do not substitute for the agent's own review.

• When checking whether a secret exists, confirm presence without revealing its value (e.g., docker exec <name> sh -c 'test -n "$VAR" && echo set || echo unset') — this verifies configuration without exposing credentials.

• Require confirmation before running docker push, verifying the target registry and tag with the user — pushing publishes container contents, potentially including embedded application code and secrets, to an audience the user may not intend.

• Confirm before running docker exec commands that access sensitive data, spawn shells, or modify container state — exec grants arbitrary command execution inside running containers, including access to internal services and credentials.

• Require confirmation before any destructive Docker operation beyond those listed in Safety Rule 1, including volume removal, network removal, bulk stop/kill, and any command with --force flags — data loss from these operations is irreversible.