Showcase: My 'lint' script that validates SuperAGI config files against a security baseline.

Leo M. · 2026-06-23T07:01:12Z

Alright, let's cut to the chase. The default SuperAGI deployment, especially the self-hosted one, is a compliance and attack surface nightmare waiting to happen. It's not hardened out of the box. You're left with exposed endpoints, arbitrary code execution vectors via the marketplace, and database backends with zero encryption. I see too many of you deploying this in a container with `--privileged` and a wide-open `network_mode: host` because the quickstart guide told you to. I don't trust manual reviews. I wrote a lint script that parses the `config.yaml` and associated Docker/service definitions against a security baseline I enforce. It's a bash script that uses `yq` and `docker inspect` templates. It checks for the following critical failures: * **Network Exposure:** Flags any API or GUI port binding to `0.0.0.0` without explicit intent logged. * **Container Runtime Privilege:** Validates against `privileged: true`, excessive `cap_add`, and missing `security_opt` for seccomp/apparmor. * **Marketplace & Plugin Risk:** Ensures `ALLOW_UNVERIFIED_CUSTOM_PLUGINS` is set to `False` if the marketplace is enabled at all. * **Memory Backend:** Checks the vector database configuration. Flags if `Pinecone` or similar external service API keys are passed via environment variables in plaintext within the compose file (they should be sourced from external secrets). * **Default Credentials:** Warns on unchanged default user/pass or API keys in the config. Here's the core of the check for the Docker Compose posture: ```bash #!/bin/bash set -euo pipefail CONFIG_FILE="${1:-./docker-compose.yml}" echo "[!] Validating: $CONFIG_FILE" echo "========================" # Check for privileged mode if yq e '.services[].privileged == true' "$CONFIG_FILE" | grep -q true; then echo "[FAIL] Container(s) running in privileged mode. Absolute non-starter." exit 1 fi # Check for host network if yq e '.services[].network_mode == "host"' "$CONFIG_FILE" | grep -q true; then echo "[FAIL] Container(s) using host network. Isolate your stack." exit 1 fi # Check for dangerous cap_add DANGEROUS_CAPS="SYS_ADMIN SYS_MODULE SYS_PTRACE SYS_RAWIO" for cap in $DANGEROUS_CAPS; do if yq e ".services[].cap_add[] | select(. == "$cap")" "$CONFIG_FILE" &>/dev/null; then echo "[FAIL] Dangerous capability added: $cap" exit 1 fi done # Validate seccomp profile is set and not unconfined if ! yq e '.services[].security_opt[] | select(. == "seccomp=*")' "$CONFIG_FILE" | grep -q 'seccomp'; then echo "[WARN] No custom seccomp profile specified. Default may be overly permissive." fi ``` It then cross-references the SuperAGI `config.yaml`: ```bash SUPERAGI_CONFIG="./superagi/config.yaml" if [[ -f "$SUPERAGI_CONFIG" ]]; then echo "[!] Validating SuperAGI config.yaml" echo "========================" # Check for unverified plugins allowed if [[ "$(yq e '.allow_unverified_plugins // "True"' "$SUPERAGI_CONFIG")" == "True" ]]; then echo "[FAIL] ALLOW_UNVERIFIED_CUSTOM_PLUGINS is True. Marketplace plugins can run arbitrary code." exit 1 fi # Check if default credentials are in use (example) DEFAULT_API_KEY="sk-4nDn23d2b3d2b3d2b3d2b3d2b3d2b3d2b3d2b3d" if grep -q "$DEFAULT_API_KEY" "$SUPERAGI_CONFIG"; then echo "[FAIL] Default API key detected in config. Change it." exit 1 fi fi ``` Run this in your CI/CD pipeline, or at least pre-commit. It will stop you from deploying a ticking time bomb. If any of these checks fail, you must fix the underlying issue, not just adjust the script. This is the bare minimum. - Leo

Page 2 / 2 Prev

SuperAGI Security

Last Post by Ray Tanaka 2 months ago

16 Posts

16 Users

0 Reactions

23 Views

RSS

Ray Tanaka

(@ray_selfhost)

Eminent Member

Joined: 2 months ago

Posts: 19

June 24, 2026 1:21 pm

This is exactly why I built my own home server for this stuff. The quickstart guides are basically "here's how to have a bad time."

That check for 0.0.0.0 binding is smart. I ran into that with a different agent tool. My router picked up weird outbound traffic, and it turned out the admin UI was listening on all interfaces by default. Had to trace it through iptables.

For the database encryption, are you just checking for a local path, or are you also validating the connection string for something like "ssl=true" if it's using an external Postgres? That's my next problem to solve.

ReplyQuote

Page 2 / 2 Prev

80 Forums
1,924 Topics
10.2 K Posts
16 Online
508 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed