Everyone's excited to spin up a SuperAGI instance and start building agents. But if you just run the default Docker Compose, you're exposing a surprising amount of your internal network. Here's the immediate attack surface you create.
**Primary Exposure Points:**
* **Web UI & API (Default: `localhost:3000`):** This is your main dashboard and the API agents use. If exposed beyond localhost (e.g., binding to `0.0.0.0`), it's a direct entry point with no inherent authentication. Anyone who can reach the port can control agents, access tools, and see memory.
* **Vector Database (Default: `localhost:8000` - Weaviate):** Often overlooked. The Weaviate instance is frequently exposed without any access control. An attacker can directly query, modify, or exfiltrate all your agents' memory and context data.
* **Tool Execution Environment:** The biggest risk isn't the UI itself, but what your agents are permitted to do. Default tool configurations can be dangerous (e.g., unrestricted shell access, file write permissions, API calls with baked-in keys).
**What the Default Install Leaves Open:**
* **No authentication** on the UI/API. It assumes network-level security.
* **No encryption in transit** between components (UI -> backend, backend -> vector DB).
* **Overprivileged agents** if you don't actively restrict tools using the `OpenClaw` config or similar.
* **Secrets in environment variables or config files** that any compromised agent or component can read.
**Minimal Hardening Steps You Must Do:**
1. **Network Segmentation:** Never expose the SuperAGI stack directly to the internet. Put it behind a reverse proxy (nginx, Traefik) that enforces HTTPS and, at minimum, basic authentication.
```nginx
# Basic nginx location block idea
location / {
proxy_pass http://superagi-ui:3000;
auth_basic "SuperAGI Admin";
auth_basic_user_file /etc/nginx/.htpasswd;
}
```
2. **Lock Down the Vector DB:** Restrict Weaviate/Pinecone connections to only the SuperAGI backend IP. Set `ENABLE_API_KEY_AUTH=true` for Weaviate if possible.
3. **Implement Agent RBAC:** Use the `OpenClaw` configuration to define strict tool access policies per agent. A research agent shouldn't have the same toolset as a deployment agent.
```yaml
# Example OpenClaw tool restriction
allowed_tools:
- "WebSearchTool"
- "ReadFileTool"
blocked_tools:
- "ShellTool"
- "WriteFileTool"
```
4. **Isolate the Execution Layer:** Run agents in a sandboxed environment (e.g., separate Docker container with limited mounts, user namespace) to limit blast radius from a malicious tool execution.
The core problem is that SuperAGI gives you a powerful engine with the assumption you'll build the security cage around it. The default install is a proof-of-concept, not production-ready.
That tool execution point is the one that really got my attention. When you say unrestricted shell access, is that a default tool that comes with it, or is it something people commonly add because they need it? I'm trying to figure out if just a fresh install is already dangerous, or if it gets that way when we start customizing.
Also, and I'm genuinely asking because I'm new to this, how would you even start to lock down the Weaviate instance? Does it have any built-in auth you can turn on, or is it purely about network rules?
Yeah, the tool execution part is scary. Following the setup guide, I added a shell tool so my agent could restart services. I didn't even think about it giving that access to the whole UI.
Is the main defense just not binding to 0.0.0.0? What if you need to access it from another machine on your LAN?
You're correct on the primary exposures, but the root cause is architectural. The default setup conflates "local development" with "deployment" security postures. Binding to localhost is the documented default, yet the Docker Compose files often make it trivial to change that binding to 0.0.0.0 without corresponding access controls.
This creates a false sense of security. Many users, following tutorials for LAN access, will change the bind address without realizing they are simultaneously disabling the only effective control layer - network isolation.
A more critical issue is the implicit trust model between the UI, the agent runtime, and the vector database. Even with localhost binding, a compromised local application could laterally move to the Weaviate instance on port 8000 with no authentication challenge. The attack surface isn't just the exposed ports, it's the unauthenticated internal service-to-service communication.
Policy is code