Default SuperAGI install has weak sandboxing. Your agent escaping its workspace is a classic path traversal via tool execution. This isn't just a plugin issue—it's in the core orchestration.
You need to enforce boundaries at multiple levels:
**Immediate Fix:**
Check your `config.yaml`. The `RESOURCE_DIR` and `WORKSPACE_DIR` must be explicitly set and the agent's user must have permissions *only* to those.
```
RESOURCE_DIR: "/opt/superagi/resources"
WORKSPACE_DIR: "/opt/superagi/workspace"
```
Then, lock down the OS level:
- Run the SuperAGI container or process under a dedicated, low-privilege user.
- Use `chroot` or container bind mounts to make only the workspace visible.
- Apply mandatory access control (AppArmor/SELinux) to the process.
**Long-term:**
Review every tool in your agent's toolkit. File read/write tools are the obvious vector. The marketplace plugins are a major risk—assume they run with the same permissions as the main agent.
Without runtime integrity checks (e.g., agent action monitoring), you're trusting the tool's code. This is a supply chain problem.
- Bill
Trust the hardware, verify the supply chain.
Yes, the file read/write tools are the biggest culprits. I've seen agents use a 'list files' tool to first map the directory structure, then craft a path like `../../etc/passwd`. They're literally probing for traversal.
> The marketplace plugins are a major risk
This can't be overstated. If a plugin uses `subprocess.run()` or `eval()`, your sandbox is toast. I run all third-party tools in a separate, instrumented sandbox first to see what they *actually* do. Found one last week that was trying to `curl` a remote config on every execution.
Trust but sanitize.
That point about agents probing the directory structure first is really insightful, and it makes me wonder about the order of operations in the agent's thought loop. If it uses a 'list files' tool successfully, that's already a sign the initial path validation might be too permissive. Shouldn't that tool itself refuse to list anything outside the designated workspace root before any read attempt is made?
I'm curious about your instrumented sandbox for testing plugins. Are you intercepting syscalls, or are you looking more at the Python level, like wrapping `open()` and `os.listdir()`? I'm trying to set up something similar, but I'm worried about missing indirect calls through imported libraries.