Security audit
Security checks for vulnerabilities and agentic risk
This skill is a coherent SSH-based Docker administration helper, but it merits review because it can run commands and change remote services without strong built-in scoping or safety warnings.
Install only if you intend the agent to administer trusted remote Docker hosts over SSH. Use a dedicated least-privilege deployment user, avoid root where possible, review any deploy-apps.json aliases and update commands, and require human confirmation before stop/down/update/exec operations on production services.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
To use a specific key:
docker_compose_up host=192.168.1.100 user=admin path=/opt/app key_path=/home/admin/.ssh/deploy_key
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
## Security Best Practices
1. **Never expose sensitive configurations** - Protect .env files, credentials, and secrets:
- Never log, display, or output `.env` files or any configuration containing secrets
- When exec'ing into containers, avoid printing sensitive environment variables
2. **Use dedicated deployment users** instead of root
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
ssh user@host "sudo systemctl status sshd"
chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
ssh user@host "sudo systemctl status sshd"
chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub
Potential security issue detected. Manual review is recommended.
ssh user@host "groups"
ssh user@host "ls -la /var/run/docker.sock"
The skill documents docker_compose_down as stopping and removing containers, networks, and volumes on a remote host, but it does not include any explicit warning that this can cause service outage and potential data loss. In a remote-management skill, destructive actions are expected, but omitting impact warnings increases the chance of accidental misuse, especially when examples use privileged accounts and production-like paths.
The docker_compose_update action allows a custom command to be executed remotely, e.g. sh ./upgrade.sh, which is effectively arbitrary remote command execution. Because the documentation presents this capability without a strong warning, restriction, or validation guidance, a user or downstream agent could execute unsafe commands on the remote server, leading to host compromise or destructive changes.
The docker_compose_exec action exposes arbitrary command execution inside a running container on a remote server, again without warning about operational impact, secret exposure, or the possibility of container escape through misconfiguration. In this skill context, remote container exec is a legitimate admin function, but it is inherently dangerous because it can alter application state, read sensitive data, and potentially pivot if the container is privileged or mounted to sensitive host resources.
This JSON manifest contains example commands and descriptions, but it does not define any explicit activation boundaries, negative examples, or scope constraints for when these remote Docker operations should be invoked. Because manifest files are in scope for vague-trigger review, the absence of specificity around invocation context could allow overly broad matching to common intents like starting, restarting, or checking services.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# Add user to docker group
ssh user@host "sudo usermod -aG docker $USER"
# Or use root user for docker commands
docker_compose_up host=192.168.1.100 user=root path=/opt/app
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# Add user to docker group
ssh user@host "sudo usermod -aG docker $USER"
# Or use root user for docker commands
docker_compose_up host=192.168.1.100 user=root path=/opt/app
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
ssh -p 22 user@host "pwd"
# Check SSH daemon status
ssh user@host "sudo systemctl status sshd"
# Verify key permissions
chmod 600 ~/.ssh/id_rsa
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
ssh -p 22 user@host "pwd"
# Check SSH daemon status
ssh user@host "sudo systemctl status sshd"
# Verify key permissions
chmod 600 ~/.ssh/id_rsa
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
ssh user@host "sudo systemctl status sshd"
chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub
### Docker Issues
The natural-language descriptions and command strings assume a fixed environment using host 192.168.1.100 and user admin, but they do not explain whether the skill is restricted to a specific environment or region. While not a strong violation, this kind of implicit environment constraint can create policy ambiguity if the skill is distributed beyond its intended context.